Las regulaciones de código abierto tienen requisitos inusuales para tener éxito. Descubra cómo los abogados de código abierto pueden ayudar a sus empleadores a encontrar un camino viable a seguir.
Como compartí en la primera parte de esta serie de dos partes , soy abogado de código abierto en Red Hat. Una parte importante de mi trabajo es brindar información a otras empresas, incluido su asesor interno, sobre cómo Red Hat está adoptando un modelo de desarrollo de código abierto para crear productos de nivel empresarial y responder a sus preguntas generales sobre las licencias de código abierto. Después de escuchar sobre los éxitos de Red Hat, la conversación que estos abogados tienen conmigo a menudo gira en torno a cómo sus organizaciones pueden evolucionar hacia organizaciones más capaces y conscientes del código abierto, y a menudo me preguntan cómo pueden mejorar sus prácticas para ser más competentes. Asesoramiento jurídico a los empleados de sus organizaciones. En estos dos artículos, compartiré lo que normalmente les cuento a mis abogados internos sobre estos temas.
Encuentre siempre un camino factible
Lo que hace que mi empleador, Red Hat, sea único en su uso de software de código abierto es que nuestro modelo de desarrollo comienza con una comunidad de código abierto con miles de contribuyentes y da como resultado un producto final probado y confiable. Más específicamente, a través de nuestro modelo de desarrollo único, comenzamos con software de código abierto creado por la comunidad y trabajamos en cada proyecto para fortalecer la seguridad, corregir errores, parchear vulnerabilidades y agregar nuevas funciones. Luego contribuimos con estas mejoras a cada proyecto para que beneficien a toda la comunidad de código abierto. Los beneficios de este enfoque son importantes e incluyen:
- Aprovechar la innovación externa a través de la colaboración entre equipos internos y otros fuera de la organización;
- Cuando una comunidad existente o potencial está trabajando en el mismo problema que usted y puede colaborar, usted evita los costos y las ineficiencias de desarrollar y mantener una solución de código abierto usted mismo;
- A través de una colaboración productiva con los socios y la comunidad del proyecto upstream, se puede evitar el costoso mantenimiento de las ramas downstream del proyecto principal.
- A algunas empresas les resulta tentador crear ramas no públicas de código ascendente porque es una forma rápida de resolver un caso de uso específico o porque no están dispuestas a colaborar en la comunidad. Sin embargo, la carga de mantenimiento a largo plazo de dicha sucursal puede resultar prohibitiva debido al aumento de los costos de desarrollo, la pérdida de interoperabilidad y otras razones. Por el contrario, centralizar el desarrollo en la comunidad río arriba original distribuye los costos de desarrollo entre todos los participantes.
Con algunas excepciones (como Red Hat), la mayoría de las organizaciones que utilizan software de código abierto probablemente tengan un modelo de licencia de software propietario (o el equivalente de SaaS) y concedan licencias de software propietario como parte de su negocio. Estas organizaciones creen que tienen componentes de software que brindan alguna ventaja competitiva y no quieren que estos componentes estén disponibles para otros bajo términos de código abierto. Esto es comprensible. Sin embargo, alentaría a cualquier abogado de código abierto consultado sobre estos asuntos a que inste a sus clientes a adoptar un modelo de desarrollo de código abierto, especialmente para todo el software que sea indiferenciado y común.
Por ejemplo, si su empresa desarrolla una aplicación para teléfonos móviles y necesita un módulo de software para leer y escribir archivos de imágenes PNG, será mucho más económico utilizar uno de los populares módulos de software PNG de código abierto en GitHub. La codificación y decodificación de imágenes PNG puede ser indistinguible para su empresa, entonces, ¿por qué dedicar un valioso tiempo de ingeniería a escribir su propia versión? Además, escribir su propio módulo para esta funcionalidad también puede causar problemas de compatibilidad con otro software que utilice módulos de código abierto comúnmente disponibles. ¿Por qué es esto? Aunque sus módulos y módulos de código abierto pueden haber sido escritos para codificar y decodificar la especificación PNG publicada, a veces la especificación puede interpretarse de manera diferente y pueden ocurrir errores de implementación. Todos los que usan el mismo módulo para realizar esta funcionalidad garantizan la compatibilidad para la mayoría de los usuarios y reducen los costos de desarrollo y mantenimiento.
También es importante darse cuenta de que es posible que necesite que algún software siga siendo propietario y no esté sujeto a términos de código abierto. Dependiendo de la arquitectura de software de su sistema y de la licencia de código abierto utilizada, el código de software que se pretende que siga siendo propietario puede quedar sujeto a los términos de la licencia de código abierto a menos que se tomen ciertas medidas (más allá del alcance de este artículo). Aquí es donde sería útil brindar algunos servicios de consultoría a los clientes sobre la selección de licencias y la arquitectura.
Encuentre soluciones flexibles
Las organizaciones que anteriormente otorgaban principalmente licencias de software propietario están aumentando gradualmente su uso de software de código abierto, pero es probable que los requisitos de revisión y aprobación crezcan (incluso exponencialmente, en mi experiencia). Estas organizaciones pueden tener dificultades debido a las limitaciones de recursos. Aquí hay algunas soluciones flexibles que puede adoptar.
Autorizar y delegar en otros
Los abogados no pueden ni deben ser guardianes. Esto es ineficiente y definitivamente generará cuellos de botella en los tiempos de desarrollo y lanzamiento, generando frustración y pérdida de ingresos. En cambio, la autoridad de aprobación debe otorgarse a personas competentes en ingeniería y gestión de productos o proyectos. Esto permite a las organizaciones permanecer efectivamente flexibles. Educar a sus clientes (consulte la siguiente sección) es fundamental para lograrlo con éxito.
Un enfoque que tomo es brindar capacitación de código abierto a toda la organización de ingeniería para que puedan tomar decisiones básicas sobre el modelo de licencia y la arquitectura, al mismo tiempo que brindo capacitación más especializada a los desarrolladores de software para permitirles brindar orientación y decisiones más complejas. Considere también límites claros en los permisos en cada nivel, incluido qué tipos de problemas y decisiones se le deben derivar a usted como su abogado de código abierto. El nivel de autorización específico de su organización dependerá de la experiencia de su equipo con el código abierto y la sensibilidad a ciertos problemas de código abierto.
Educar a los clientes
Descubrí que la capacitación es una de las herramientas más efectivas para migrar su organización a una organización con una mentalidad de código más abierto. Capacitar a sus ingenieros de software y gerentes de productos es fundamental. Déjame explicarte.
Aunque sus ingenieros de software están a la vanguardia y, en general, pueden tener muchos conocimientos sobre cuestiones de código abierto y licencias de software, sigue siendo importante capacitarlos en función de los requisitos específicos de su organización. Por ejemplo, es posible que su empresa solo permita el uso de licencias permisivas de código abierto y que tenga ciertos requisitos en cuanto a su aviso de derechos de autor y disponibilidad del código fuente. Para evitar problemas en el desarrollo que deban corregirse posteriormente (una práctica costosa y que requiere mucho tiempo), es mejor capacitar a los ingenieros para minimizar la posibilidad de comportamientos inadecuados, especialmente al comienzo de cualquier proceso de desarrollo (consulte la siguiente sección).
Los gerentes de producto también deben recibir capacitación. En muchas empresas, los gerentes de producto son responsables de los cuatro aspectos clásicos del marketing (producto, precio, posicionamiento y promoción) y son responsables de todo el ciclo de vida de un producto, desde el nacimiento hasta la muerte. Todos los aspectos del trabajo de un gerente de producto pueden verse afectados por el uso de software de código abierto. Por las mismas razones mencionadas anteriormente, les resulta útil comprender los requisitos para utilizar software de código abierto. Además, y lo que es más importante, la importante influencia de los gerentes de producto dentro de una organización significa que a menudo pueden realizar los cambios necesarios en los procesos y políticas. Los gerentes de producto pueden ser uno de sus más firmes defensores de los cambios de proceso para la apertura.
Detección temprana
Resolver los problemas de licencias de código abierto cerca del final del proceso de desarrollo es difícil y costoso. A medida que se acerca la fecha de lanzamiento del software, la arquitectura y los módulos de software de código abierto se eligen y son difíciles de cambiar. Si se detecta un problema, como software "copyleft" integrado en un módulo de software propietario (cuando ese módulo propietario no está destinado a estar sujeto a términos de código abierto), modificar la arquitectura o el módulo en esta etapa de desarrollo puede ser difícil y costoso. caro. En cambio, el proceso de análisis arquitectónico y selección de módulos de código abierto debe ocurrir temprano en el proceso de desarrollo para que se puedan realizar correcciones menos costosas y más efectivas.
Las “recompensas” de las regulaciones de código abierto
Practicar la regulación de código abierto es una carrera gratificante porque la capacidad de influir en una organización en una dirección "abierta" tiene grandes beneficios. El éxito depende de su capacidad para encontrar soluciones que sean factibles y flexibles a medida que su organización crece y madura.
Sobre el autor: Jeffrey R. Kaufman es asesor jurídico empresarial senior en el equipo jurídico de código abierto de Red Hat, el proveedor líder mundial de soluciones de software de código abierto. También se desempeña como profesor adjunto de derecho en la Universidad de Carolina del Norte. Antes de unirse a Red Hat, Jeffrey trabajó como asesor de patentes y código abierto para Qualcomm.
Perfil del traductor: Xue Liang, director del Departamento de Negocios de Internet de Jihuizhijia Intellectual Property Consulting Company, es bueno en análisis de patentes, diseño de patentes, seguimiento de competidores, análisis FTO y análisis de riesgos de propiedad intelectual de software de código abierto. Está comprometido a proporcionar empresas de Internet. y empresas de alta tecnología con servicios de consultoría en propiedad intelectual.
