054.3 Lección 1

Las licencias de software libre y de código abierto deben tratarse con la misma seriedad que otras licencias y contratos. Las organizaciones sí las hacen cumplir, como Software Freedom Conservancy, que actúa en nombre de pequeños proyectos con copyleft que no tienen sus propios mecanismos de aplicación.

Estas organizaciones suelen abordar las demandas como último recurso. La mayoría de las violaciones no son intencionadas y son fáciles de resolver con educación. Aún así, perjudica la reputación de una organización si se le considera ignorante e insensible hacia las comunidades de cuyo software depende.

Y de hecho, se han iniciado demandas cuando un usuario de software se niega flagrantemente a cooperar cuando el software y el demandado son lo suficientemente importantes.

Incluso si una organización no es castigada con una demanda, el daño que una violación de licencia causa a su relación con la comunidad, así como a su reputación, puede ser sustancial. Un proyecto puede descarrilarse por algo tan simple como que las preguntas de los desarrolladores queden sin respuesta en los foros dedicados al software que están intentando utilizar.

Puede ser un desastre para alguien encontrar software con copyleft en un producto propietario. Para cumplir con la licencia, los desarrolladores deben eliminar todo el código copyleft o liberar su producto bajo la licencia copyleft. Hacer que su software sea gratuito, con el código fuente disponible, podría tener efectos nefastos en los modelos de negocio basados en derechos de licencia u otras formas de monopolizar el valor del producto.

Hemos visto que las violaciones de licencias pueden ser muy dañinas. Otros tipos de comportamiento que perturban la confianza y la reputación también introducen riesgos.

Algunas organizaciones lanzan software bajo una licencia de software libre o de código abierto y luego anuncian en algún momento que las versiones futuras estarán bajo una licencia propietaria. Este cambio puede resultar tentador, porque muchos proyectos de código abierto no reciben apoyo financiero de suficientes clientes.

Pero tales cambios de licencia provocan enojo tanto entre los clientes como entre los desarrolladores externos que contribuyen al proyecto. A veces, los desarrolladores externos toman la versión libre y continúan desarrollándola de forma independiente, un paso conocido como bifurcación del proyecto. La versión libre podría volverse competitiva con la versión propietaria de la empresa y alejar a los clientes de la empresa.

También existen riesgos al participar en foros de proyectos. Una empresa debe aprender a ser un buen ciudadano. Los problemas comunes incluyen:

Los modelos de negocio se analizan en otra lección; Esta sección solo señala el riesgo financiero de participar en proyectos de código abierto.

Las empresas pueden iniciar o unirse a proyectos de código abierto con la expectativa de obtener ingresos a través de algún mecanismo, como contratos de soporte, contratos SaaS, recopilación de datos o incluso donaciones y subvenciones. Desafortunadamente, quienes llevan a cabo proyectos de código abierto a menudo los encuentran menos lucrativos de lo esperado. Por supuesto, cualquier empresa corre un riesgo al iniciar un nuevo proyecto, pero es particularmente difícil encontrar una fuente confiable de ingresos para el código abierto.

El código abierto parece más sostenible cuando respalda alguna otra forma de ingresos, como la venta de dispositivos de hardware, automóviles, impresoras, etc.

Como hemos visto, los miembros de un proyecto a veces no están de acuerdo con la hoja de ruta (roadmap), el liderazgo u otros aspectos del proyecto, por tanto, crean un proyecto alternativo en la misma base de código. Una organización también puede realizar la bifurcación para crear una versión especializada del software. Por ejemplo, Android utiliza una versión especializada de Linux que mantiene Google. (Google también hace muchas contribuciones a la versión principal de Linux y no siempre son aceptadas).

Las organizaciones pueden crear una bifurcación por varias razones. Es posible que envíen sus cambios al proyecto principal y los rechacen porque otros desarrolladores no los quieren. En un proyecto con una licencia permisiva, o un proyecto utilizado sólo dentro de la organización, es posible que desee mantener sus cambios en secreto.

El riesgo de una bifurcación es que los desarrolladores del proyecto bifurcado son responsables del mantenimiento de todo el producto. Si se agregan correcciones de errores importantes o nuevas características al proyecto principal, los desarrolladores del proyecto bifurcado deben duplicar los cambios o renunciar a sus beneficios. A medida que pasa el tiempo y los proyectos se alejan, ya que mantenerse al día con los cambios en el proyecto principal se vuelve cada vez más difícil.

Como se explicó en otras lecciones, algunas licencias de software libre y de código abierto tienen cláusulas incompatibles. Estos componentes no se pueden utilizar juntos en un producto.

Es probable que este problema surja durante una fusión o adquisición. Es posible que cada empresa haya estado utilizando software con una licencia particular y, si quieren combinar el código en sus proyectos, deben asegurarse de que las licencias sean compatibles.

Muchas licencias de software de código abierto (y los términos de servicio de muchos software y servicios propietarios, de hecho) rechazan explícitamente cualquier responsabilidad por el uso del software. Otra forma de decir esto es que la licencia o los términos de servicio no ofrecen ninguna garantía.

Los proveedores de software rara vez son responsables de los problemas con su software, pero en ocasiones los clientes los demandan o intentan otras formas de castigo. Los tribunales no tienen que reconocer las cláusulas de “no garantía”.

Cada vez más, las leyes y regulaciones imponen responsabilidades a los creadores de software. Estas restricciones legales — o al menos, propuestas de restricciones — ahora se ven particularmente para la inteligencia artificial, pero a veces son más amplias.

Muchos países restringen la exportación de bienes y software. En el ámbito del software, dichas regulaciones se aplican con mayor frecuencia a los productos de seguridad y, específicamente, al uso de la criptografía. Estados Unidos solía tener controles estrictos sobre cualquier software que contenga criptografía, pero los controles se han relajado en los proyectos de código abierto.

Las empresas deben conocer las regulaciones de exportación donde están creando software, en caso de que estas regulaciones afecten la venta y distribución de sus productos.

Debido a que los entornos informáticos utilizan enormes cantidades (a veces decenas de miles) de componentes y realizan cambios frecuentes, los SBOM deben estar altamente estructurados para que la información se pueda extraer de forma automática y rápida. Esta sección describe dos de los formatos más populares en el mundo del código abierto:

Tanto SPDX como CycloneDX crean estructuras jerárquicas en varios formatos, incluidos JSON y XML. Existen muchas herramientas para cada estándar, tanto para crear los formatos como para escanear los archivos creados en busca de información. Los sitios populares de repositorios de control de versiones permiten a los desarrolladores crear un SBOM en uno de estos formatos con solo hacer clic en un botón.

Saber qué está utilizando una organización requiere una evaluación de su software que incluya una comprensión de su procedencia, qué vulnerabilidades contiene, qué licencias utiliza y otros factores que ayudan a un individuo u organización a decidir si utilizar el software. Esta tarea se llama Análisis de composición de software (SCA) y existen muchas herramientas para realizar análisis sofisticados de SBOM y del propio software.

Algunas herramientas extraen información de licencia, lo que ayuda a una organización a decidir si es seguro incluir el software en un producto y si los diferentes componentes tienen licencias compatibles. Algunas herramientas incluso comparan fragmentos de código con bibliotecas de proyectos de código abierto comunes para descubrir si el código se tomó de los proyectos sin la atribución adecuada.

El uso de estas herramientas es especialmente crucial durante una fusión o adquisición. La empresa adquirente podría descubrir que el software que desea adquirir es menos valioso de lo que esperaba, porque contiene componentes de código abierto que imponen requisitos que interfieren con su uso previsto en la nueva organización.

Las organizaciones pueden beneficiarse enormemente del uso y la contribución al software de código abierto, pero deben hacerlo de manera que protejan sus propios intereses y beneficien a los proyectos de código abierto. Se deben definir políticas para:

La OSPO puede coordinar la creación de estas políticas y la educación para garantizar su cumplimiento.

Los proyectos de código abierto deben garantizar que las contribuciones sean legítimas: por ejemplo, que el código no haya sido tomado de algún producto propietario o de un proyecto de código abierto con una licencia incompatible. Muchos proyectos de código abierto requieren que los desarrolladores proporcionen un documento llamado Acuerdo de licencia de colaborador (CLA) para garantizar la legitimidad de su contribución.

Los desarrolladores de una organización que contribuyen a estos proyectos pueden solicitar a los abogados de la organización que revisen y aprueben el CLA. Por lo tanto, los abogados deben comprender la relevancia de las cláusulas de los CLA y estar preparados para examinarlas.

Se han emitido numerosas críticas sobre los CLA, incluida su complejidad y las brechas que dejan para que los proyectos utilicen el código aportado de formas no deseadas por los contribuyentes.

Muchos proyectos, en lugar de un CLA, solicitan al desarrollador que firme un breve documento llamado Certificado de origen del desarrollador (DCO), que certifica que el desarrollador tiene derecho a contribuir con el código. La DCO, que se analiza en otra lección, generalmente no se presenta a un abogado para su revisión.

Algunos proyectos simplemente piden a los contribuyentes que firmen los derechos de autor de su código en el proyecto en un Acuerdo de cesión de derechos de autor (CAA). Sin embargo, a muchos contribuyentes no les gusta esta práctica porque no pueden usar el código en algún proyecto propio y porque otorga mucho poder al proyecto.

Los proyectos de código abierto combinan factores sociales, técnicos, legales y organizativos inusuales. En este momento, el conocimiento de estos factores no se ha extendido por las organizaciones hasta el punto de que todos los gerentes, desarrolladores, abogados y otros los comprendan profundamente. Por lo tanto, las organizaciones pueden beneficiarse enormemente de la creación de una Oficina de Programas de Código Abierto (OSPO) como punto central para la promoción, la formulación de políticas, la aplicación de políticas y la educación.

Como una especie de departamento multipropósito, los OSPO pueden desempeñar muchas funciones, tales como:

Existen numerosos documentos y recursos en línea para crear una OSPO. Una organización pequeña puede encargar la tarea a un tercero que sea experto en esa área.