Propósito:

El propósito de estas Directrices de Cumplimiento de Software de Código Abierto (Directrices) es proporcionar orientación en el desarrollo de procedimientos diseñados para verificar el cumplimiento de los requisitos de licencia de varias aplicaciones de software de código abierto (OSS) utilizadas internamente o incluidas en productos para distribución. Los abogados, asesores y consultores tecnológicos deben conocer los problemas relacionados con el software de código abierto para asesorar adecuadamente a sus clientes.

El resultado de estas Directrices debe ser (1) una Política de cumplimiento de software de código abierto (Política OSS) que describa las políticas y procedimientos aplicables al uso de OSS por parte de la compañía, y (2) un inventario (Inventario OSS) de todos los OSS aprobados para su uso dentro de la compañia.

La Política de OSS debe diseñarse teniendo en cuenta la cultura de la empresa y la forma específica de operar para ser efectiva. La política de OSS también debe revisarse y actualizarse periódicamente.

El Inventario de OSS es el resultado final de estas Directrices y la Política de OSS. Sin embargo, también servirá como un documento listo, en forma modificada, que se puede proporcionar a los clientes que pueden solicitar una lista de OSS contenidos en productos distribuidos y a un posible socio o adquirente que esté realizando la debida diligencia.

Es importante tener en cuenta que el software patentado de terceros a menudo contendrá componentes OSS. Por lo tanto, particularmente cuando dicho software se incluye en un producto distribuido, es necesario que el proveedor identifique todos los componentes de OSS para que puedan considerarse a lo largo de las líneas como se establece a continuación.

Guardián designado:

Se debe designar una persona o comité para la aprobación de todos los OSS propuestos para ser utilizados internamente o incluidos en productos para su distribución. Para que este procedimiento sea efectivo, se debe notificar al personal relevante de la compañía que la compañía requiere la aprobación previa de todos los OSS utilizados de cualquier manera dentro de la compañía. Dicha notificación debe ser visible y repetida a intervalos regulares. Además, los supervisores también deben recibir instrucciones para reforzar este requisito. Se debe prestar especial atención a los equipos de desarrollo que están acostumbrados a extraer OSS de varios lugares, y generalmente operan sujetos a plazos ajustados.

Solicitud de aprobación:

1. Las solicitudes de aprobación deben presentarse dentro del período de tiempo anterior al uso / implementación según lo establecido en la Política de OSS. El proceso de aprobación debe iniciarse con la presentación de un documento que contenga al menos la siguiente información:

2. Nombre / Número de versión / Fuente del software de código abierto

3. Nombre de la licencia aplicable (p. Ej., GNU General Public License v.2, zlib, BSD) y dirección de origen de la licencia

4. Nombre de la entidad / persona que otorga la licencia

5. Dirección de origen desde la cual se obtendrá OSS

6. Descripción de cómo se utilizará OSS (por ejemplo, internamente, como herramienta de desarrollo, incrustado en un producto distribuido, etc.)

7. Si se incluye en el producto distribuido, descripción de la forma en que estos OSS interactuarán con el código fuente de propiedad de la compañía (es decir, ¿se compilará y / o vinculará el OSS de forma estática o dinámica con el código fuente de propiedad de la compañía?)

8. La forma en que se implementará el OSS (p. Ej., Modificado frente a no modificado, independiente, vinculado estáticamente, vinculado dinámicamente, etc.).

9. Descripción de si se modificará el OSS

10. Declaración sobre si el OSS es un componente clave del producto

11. Declaración sobre si el OSS es conocido y ampliamente utilizado

12. Fecha objetivo para el uso / implementación de OSS

Proceso de aprobación:

El proceso de aprobación implica examinar áreas de riesgo relacionadas con el uso de un OSS particular. Las áreas de riesgo pueden incluir:

1. ¿La licencia OSS requiere que el código fuente modificado esté disponible públicamente?

2. ¿La licencia OSS requiere que el código fuente del software propietario de la compañía se ponga a disposición del público? (por ejemplo, ¿habrá un enlace estático del código GPL con el software propietario de la compañía?)

3. ¿Ha habido litigios u otros asuntos relacionados con el tema OSS?

4. ¿La licencia de OSS contiene términos ambiguos, lo que limita una nube en los derechos de la compañía para usar el OSS de cierta manera?

5. La falta de garantías y la indemnización de propiedad intelectual supondrán un riesgo para la empresa y agrave; -vis expectativas y demandas del cliente?

Es importante que el proceso de aprobación se realice rápidamente, y el período de tiempo esperado para la aprobación debe establecerse en la Política de OSS. De lo contrario, es probable que los usuarios y desarrolladores se sientan frustrados y encuentren formas de sortear los procedimientos a medida que se acercan los plazos.

Cuando se utilizan nuevas versiones de OSS aprobados, debe llevarse a cabo un proceso de aprobación acelerado. Esto permite que el inventario de OSS se mantenga actualizado y evitará la formación de brechas en el inventario que podrían terminar convirtiéndose en grandes agujeros.

Conformidad:

El objetivo de una política de OSS es lograr el cumplimiento de cada licencia de OSS. Dependiendo de las licencias involucradas, el cumplimiento puede incluir cualquiera de los siguientes:

1. Inclusión en la documentación apropiada de renuncias de garantía, exclusiones de responsabilidad, atribución de autor y avisos de derechos de propiedad.

2. Inclusión en la documentación apropiada del acuerdo de licencia de usuario final de OSS aplicable.

3. Entrega pública o disponibilidad del código fuente para la versión no modificada o la versión modificada.

4. Entrega pública o disponibilidad de código fuente para el software propietario de una compañía si está vinculado a un código de software de código abierto “copyleft” de una manera que requiera este resultado.

5. Marcado de modificaciones realizadas al código fuente OSS.

Auditorias:

Periódicamente, al menos una vez al año, debe realizarse una auditoría para verificar que el Inventario de OSS sea exacto y esté actualizado. El proceso de auditoría puede ser tan simple como distribuir el Inventario de OSS al personal clave que lo firmará, o tan complejo como instalar un software de monitoreo que identificará OSS en el sistema informático de la compañía. El alcance de la auditoría dependerá de las necesidades de la compañía y del volumen de OSS de código abierto en uso.

Entrenamiento OSS:

Los empleados actuales y nuevos deben participar en una sesión de capacitación sobre políticas de OSS para asegurarse de conocer los procedimientos y requisitos de la compañía en esta área.