Entendiendo las implicaciones legales del código abierto

Compartir tu trabajo creativo con el mundo puede ser una experiencia excitante y gratificante. Esto también conlleva un conjunto de aspectos legales de los cuales debes ocuparte. Afortunadamente, no tienes que empezar desde cero. Nosotros tenemos cubiertas tus necesidades legales. (Antes de continuar, asegúrate de leer nuestro aviso legal.)

¿Por qué la gente se preocupa tanto acerca de los aspectos legales del código abierto?

¡Me alegro que lo preguntes! Cuando realizas trabajo creativo (como escritura, dibujo, o código), ese trabajo se encuentra bajo derechos de autor por defecto. Es decir, la ley asume que, como autor de tu trabajo, tienes poder de decisión sobre lo que los otros pueden o no hacer con ello.

En general, esto significa que nadie más puede usar, copiar, distribuir, o modificar tu trabajo sin tener riesgo de sufrir bajas, ser investigado o demandado.

Sin embargo, el código abierto es una circunstancia inusual debido a que el autor espera que otros usen, modifiquen, y compartan el trabajo. Pero, debido a que legalmente por defecto los derechos de autor son exclusivos, se necesita una licencia que enuncie explícitamente estos permisos.

Si tú no aplicas una licencia de código abierto, todo aquel que contribuya a tu proyecto también tiene derechos de autor de su trabajo. Esto significa que nadie puede usar, copiar, distribuir, o modificar sus contribuciones – y ese “nadie” te incluye a ti.

Finalmente, tu proyecto puede tener dependencias con requisitos de licencia que no conoces. La comunidad de tu proyecto, o tus políticas de empleador, pueden requerir que tu proyecto haga uso de una licencia de código abierto específica. Cubriremos estas situaciones a continuación.

¿Son públicos los proyectos de código abierto de GitHub?

Cuando tú creas un nuevo proyecto en GitHub, tienes la opción de hacerlo privado o público.

crear repositorio

Hacer tu proyecto de GitHub público, no es lo mismo que licenciar tu proyecto. Los proyectos públicos son cubiertos por los Términos de Servicio de GitHub, lo que les permite a otros ver y bifurcar el proyecto, pero su trabajo viene de otra manera sin permisos.

Si quieres que otros usen, copien, modifiquen, o contribuyan a tu proyecto, debes incluir una licencia de código abierto. Por ejemplo, nadie puede usar legalmente cualquier parte de tu proyecto de GitHub en su código, incluso si es público, a menos que explícitamente le concedas dicho derecho.

Solo dame un resumen acerca de lo que necesito para proteger mi proyecto.

Tienes suerte, porque hoy, las licencias de código abierto están estandarizadas y son fáciles de usar. Puedes copiar-pegar una licencia existente directamente en tu proyecto.

MIT, Apache 2.0, y GPLv3 son las licencias de código abierto más populares, pero también tienes otras opciones para elegir. Puedes encontrar un texto completo sobre estas licencias, e instrucciones de uso de las mismas en choosealicense.com.

Cuando crees un nuevo proyecto en GitHub, se te pedirá que agregues una licencia.

¿Cuál licencia de código abierto es apropiada para mi proyecto?

Si estás comenzando desde cero, es difícil equivocarse al elegir la Licencia MIT. Es corta, muy fácil de entender, y permite a cualquiera hacer lo que sea, siempre y cuando guarde una copia de la licencia, incluyendo tu aviso de derechos de autor. Tendrás la posibilidad de lanzar el proyecto bajo otra licencia si alguna vez así lo necesitas.

Elegir la licencia de código abierto correcta para tu proyecto, depende de tus objetivos.

Muy probablemente, tu proyecto tiene (o tendrá) dependencias. Por ejemplo, si es un proyecto de código abierto de Node.js, seguramente utilizarás librerías del Node Package Manager (npm). Cada una de esas librerías que utilizas, tendrán su propia licencia de código abierto. Si cada una de dichas licencias es “permisiva” (otorga permiso público de uso, modificación, y distribución, sin ninguna condición de bajada), puedes usar cualquier licencia que quieras. Las licencias permisivas más comunes son MIT, Apache 2.0, ISC, y BSD.

Por otro lado, si cualquiera de las licencias de tus dependencias son copyleft “fuerte” (también brindan los mismos permisos, siempre y cuando se utilice la misma licencia consecuente), en este caso, tu proyecto deberá usar la misma licencia. Las licencias strong copyleft más comunes son GPLv2, GPLv3, and AGPLv3.

Deberías considerar también a las comunidades qué esperas que usarán y contribuirán a tu proyecto:

  • ¿Quieres que tu proyecto sea usado como dependencia por otros proyectos? Probablemente, la mejor opción sea usar la licencia más popular en tu comunidad. Por ejemplo, MIT es la licencia más popular para npm libraries.
  • ¿Quieres que tu proyecto atraiga a grandes empresas? Una gran empresa seguramente querrá una licencia de patente expresa por parte de todos los contribuyentes. En este caso, Apache 2.0 te tiene a ti (y a ellos) cubiertos.
  • ¿Quieres que tu proyecto atraiga a colaboradores los cuales no quieren que sus contribuciones sean usado en software de código cerrado? GPLv3 o (si tampoco quieren contribuir a servicios de código cerrado) AGPLv3 sería el más apropiado.

Tu empresa puede que tenga requisitos específicos para licencias de proyectos de código abierto. Por ejemplo, tal vez requiera una licencia permisiva de modo que dicho proyecto pueda utilizarse en el producto de código cerrado de dicha empresa. O tu empresa puede requerir una licencia strong copyleft y un acuerdo de colaboradores adicional (leer más abajo) para que solo tu empresa, y nadie más, pueda usar tu proyecto en software de código cerrado. O tal vez, tu empresa tiene ciertas necesidades relacionadas con estándares, responsabilidad social, o transparencia; en tales casos requerirán una estrategia de licencia particular. Habla con el departamento legal de tu empresa.

Cuando creas un Nuevo proyecto en GitHub, te son brindadas opciones para elegir una licencia. Incluir cualquiera de las licencias enunciadas anteriormente, harán de tu proyecto de GitHub, un proyecto de código abierto. Si quisieras considerar otras opciones, revisa choosealicense.com en donde encontrarás licencias adecuadas para tu proyecto, incluso si el mismo no es software.

Y si quieres cambiar la licencia de tu proyecto

La mayoría de los proyectos no necesitan cambios de licencias. Pero ocasionalmente las circunstancias cambian.

Por ejemplo, a medida que tu proyecto crezca se añadirán dependencias y usuarios, o tu empresa modifica estrategias, cualquiera de estos escenarios requerirán diferentes licencias. También, si te negaste a establecer una licencia a tu proyecto desde el comienzo, agregar una licencia es efectivamente lo mismo que cambiar las licencias. Hay tres aspectos fundamentales que debes considerar al añadir o cambiar la licencia de tu proyecto:

Es complicado. Determinar la compatibilidad y conformidad de la licencia con quienes son propietarios de sus derechos de autor puede volverse complicado y confuso muy rápidamente. Cambiar a una nueva pero a una licencia compatible para nuevos lanzamientos y colaboradores es diferente a cambiar la licencia de todos los colaboradores ya existentes. Involucre a su equipo legal frente a cualquier deseo de cambiar licencias. Incluso si tú tienes o puedes obtener permiso de los titulares de derechos de autor de su proyecto para un cambio de licencia, considera el impacto de los cambios en los colaboradores y usuarios de tu proyecto. Imagina al cambio de licencia como un “evento de gobierno” para tu proyecto que probablemente marchará sin contratiempos mediante la comunicación y consultas claras con las partes interesadas en el proyecto. ¡Más razones para elegir y utilizar una licencia adecuada para su proyecto desde el comienzo!

La licencia existente de su proyecto. Si la licencia existente de su proyecto es compatible con la licencia a la que quieres cambiar, puedes simplemente empezar a usar la nueva licencia. Esto sucede debido a que si la licencia A es compatible con la licencia B, vas a estar cumpliendo con los términos de A mientras cumples con los términos de B (pero no necesariamente viceversa). Así que, si estás utilizando una licencia permisiva (por ejemplo, MIT), puedes cambiar a una licencia con más condiciones, siempre y cuando mantengas una copia de la licencia MIT y cualquier aviso de derechos de autos asociado (esto implicaría, continuar cumpliendo con las condiciones mínimas de la licencia MIT). Pero si tu licencia actual no es permisiva (por ejemplo, copyleft, o si no tienes licencia) y no eres el único propietario de los derechos de autor, no podrías simplemente cambiar la licencia del proyecto a MIT. Esencialmente, con una licencia permisiva del proyecto, en la cual los propietarios de derechos de autor han dado permiso por adelantado de cambiar licencias.

Los propietarios de derechos de autor de tu proyecto. Si eres el único contribuyente a tu proyecto, entonces tú o tu empresa es el único titular de los derechos de autor del proyecto. Puedes añadir o cambiar a cualquier licencia que tú o tu empresa deseen. En otros casos, podría haber propietarios de derechos de autor de los cuales necesitarías realizar un acuerdo para poder cambiar las licencias. ¿Quiénes? Personas que hayan realizado commits a tu proyecto es una buena forma de comenzar. Pero en algunos casos los derechos de autor estarán en propiedad de los empleadores de dichas personas. En algunos casos las personas solo habrán hecho la menor parte de las contribuciones, pero no hay una regla rápida y firme que establezca a partir de que cantidad de líneas de código están o no sujetos a derechos de autor dichos colaboradores. Para proyectos jóvenes y pequeños, puede ser factible lograr que todos los colaboradores acepten un cambio de licencia en una issue o un pull request. Para proyectos largos y de larga vida, tendrás que buscar a muchos contribuyentes e incluso sus herederos. Mozilla tardó años (2001-2006) para cambiar de licencia a Firefox, Thunderbird, y software relacionado.

De manera alternativa, puedes tener colaboradores que estén de acuerdo por adelantado (mediante un acuerdo adicional de colaboradores – ver más abajo) con cambios de licencia bajo ciertas condiciones, más allá de los permitidos por tu licencia de código abierto existente. Esto cambia la complejidad de cambiar la licencia. Necesitarás más ayuda por parte de tus abogados, y aun deberás comunicarte claramente con las partes interesadas en su proyecto al ejecutar un cambio de licencia.

¿Necesita mi proyecto un acuerdo adicional de colaboradores?

Probablemente no. En la mayoría de los proyectos de código abierto, una licencia de código abierto sirve implícitamente de licencia tanto para el interior (colaboradores) como para el exterior (a otros colaboradores y usuarios). Si tu proyecto se encuentra en GitHub, los Términos de Servicio de GitHub la hacen “entrante=saliente” la explícita por defecto.

Un acuerdo adicional de colaboradores – a menudo llamado Acuerdo de Licencia de colaboradores (en inglés, CLA) – puede crear trabajo administrativo para mantenedores de proyecto. La cantidad de trabajo que suma un acuerdo depende del proyecto y su implementación. Un acuerdo simple puede requerir que los colaboradores confirmen, con un clic, que tienen los derechos necesarios para contribuir bajo la licencia de código abierto del proyecto. Un acuerdo más complicado, requerirá revisión legal y la aprobación de los empleadores del contribuyente.

También, al añadir “papeleo” que algunos consideran innecesario, difícil de entender, o injusto (cuando el beneficiario del acuerdo obtiene más derechos que los colaboradores o el público a través de la licencia de código abierto del proyecto), un acuerdo adicional de colaboradores puede ser percibido poco amigable a la comunidad del proyecto.

Algunas situaciones en las cuales deberías considerar un acuerdo adicional de colaboradores pueden ser:

  • Tus abogados quieren que todos los colaboradores acepten expresamente (firma, online o offline) los términos de contribución, quizás porque sienten que una licencia de código abierto no es suficiente (incluso cuando lo sea!). Si esta es la única preocupación, un acuerdo adicional de colaboradores que afirme la licencia de código abierto del proyecto, debería ser suficiente. El Acuerdo Adicional de colaboradores Individual de jQuery es un buen ejemplo de un acuerdo adicional de colaboradores ligero. Para algunos proyectos, un Certificado de Origen del Desarrollador puede ser una alternativa aún más simple.

  • Tu proyecto usa una licencia de código abierto que no incluye una concesión de patentes explicita (como MIT), y necesitas una concesión de patentes por parte de todos los colaboradores, algunos de los cuales quizás trabajen para empresas con grandes cantidades de patentes que podrían utilizarse para dirigirse a usted o a otros contribuyentes y usuarios del proyecto. El Acuerdo Adicional de colaboradores Individual de Apache es un acuerdo adicional de colaboradores que posee una concesión de patentes reflejando el que se encuentra en Apache License 2.0.

  • Tu proyecto está bajo una licencia copyleft, pero también necesitas distribuir una versión propietaria del proyecto. Necesitaras que cada colaborador te asigne sus derechos de autor o te garantice a ti (pero no al público) una licencia permisiva. El Acuerdo de colaboradores MongoDB es un ejemplo de este tipo de acuerdo.

  • Crees que el proyecto necesitará cambiar la licencia durante su tiempo de vida y quieres que los colaboradores acepten por adelantado esos cambios.

Si necesitas usar un acuerdo adicional de colaboradores para tu proyecto, considere el uso de una integración como CLA assistant para minimizar la distracción de los contribuyentes.

Si vas a lanzar un proyecto de código abierto como un empleado de una empresa, primero, tu equipo legal debería saber que estás por lanzar un proyecto de código abierto.

Para mejor, o peor, considera comentarles incluso en el caso en que sea un proyecto personal.

Probablemente tengas un “acuerdo IP de empleado” con tu empresa que les da cierto tipo de control sobre tus proyectos, especialmente si ellos están relacionados con el negocio de la empresa o si utilizan recursos de la empresa para desarrollar el proyecto. Tu empresa debería brindarte fácilmente permisos, y tal vez ya cuentes con ellos a través de un acuerdo de IP amigable hacia los empleados o mediante políticas empresariales. Si no es el caso, puedes negociar (por ejemplo, explicar que su proyecto posee objetivos profesionales de aprendizaje y desarrollo de la empresa para ti), o evitar trabajar en proyectos hasta que encuentres una mejor empresa.

Si estás trabajando en un proyecto de código abierto para tu empresa entonces definitivamente debes hacerles saber. Tu equipo legal seguramente ya cuenta con políticas para esa licencia de código abierto (y puede que también un acuerdo adicional de colaboradores) para usar basado en los requisitos y pericia del negocio de la empresa para asegurar que tu proyecto cumple con la licencia de sus dependencias. De lo contrario, tanto tú como ellos, están de suerte! tu equipo legal debería estar ansioso por trabajar con usted para acordar estas cosas. Algunos aspectos a considerar:

  • Material de terceros ¿tiene tu proyecto dependencias creadas por otros o bien incluye o usa códigos ajenos? Esto comienza con la elección de una licencia que funcione con las licencias de código abierto de terceros (ver arriba). Si su proyecto modifica o distribuye código abierto de terceros, su equipo legal también querrá saber si cumple con otras condiciones de las licencias de código abierto de terceros, como la retención de avisos de derechos de autor. Si tu proyecto utiliza código de otros que no tienen una licencia de código abierto, probablemente tendrás que pedirle a los mantenedores que agreguen una licencia de código abierto, y si no puedes conseguir una, deja de usar su código en tu proyecto.

  • Secretos comerciales: Considera si hay algo en el proyecto que la empresa no quiere poner a disposición del público en general. Si es así, puedes hacer de código abierto al resto del proyecto, después de extraer el material que desea mantener privado.

  • Patentes: ¿Está tu empresa solicitando una patente, cuya liberación del código fuente del proyecto implique una revelación pública? Tristemente, puede que te pidan que esperes (o tal vez, la empresa volverá a considerar la sabiduría de la aplicación). Si estás esperando contribuciones a tu proyecto de los empleados de empresas con cantidades grandes de patentes, tu equipo legal puede que desee que utilices una licencia con una concesión de patente expresa de los contribuyentes (como Apache 2.0 o GPLv3), o un acuerdo adicional de colaboradores (ver más arriba).

  • Marca comercial Verifica que el nombre de tu proyecto no entre en conflicto con alguna marca existente. Si utilizas marcas comerciales de tu empresa en el proyecto, comprueba que no genere ningún conflicto. FOSSmarks es una guía práctica para la comprensión de las marcas en el contexto de los proyectos de código libre y abierto.

  • Privacidad ¿Recolecta tu proyecto datos de sus usuarios? ¿Recopila su proyecto datos en los servidores de la empresa sin el consentimiento de los usuarios? Tu equipo legal puede ayudarte a cumplir con las políticas de la empresa y las regulaciones externas.

Si estás lanzando el primer proyecto de código abierto de tu empresa, lo anterior es más que suficiente para conseguirlo.

A largo plazo, tu equipo legal puede hacer más para ayudar a la empresa a obtener su participación en código abierto y mantenerse a salvo:

  • Políticas de contribución de empleados: Considera la posibilidad de desarrollar una política corporativa que especifique cómo sus empleados contribuyen a proyectos de código abierto. Una política clara reducirá la confusión entre sus empleados y los ayudará a contribuir a proyectos de código abierto de la empresa, ya sea como parte de su trabajo o en su tiempo libre. Un buen ejemplo es Rackspace’s Model IP and Open Source Contribution Policy.

  • Qué liberar: ¿(casi) todo? Si tu equipo legal entiende e invierte en la estrategia de código abierto de su empresa, serán más capaces de ayudar en lugar de dificultar tus esfuerzos.

  • Conformidad: Incluso si tu empresa no libera ningún proyecto de código abierto, utiliza otro software de código abierto. La conciencia y el proceso puede prevenir dolores de cabeza, retrasos del producto, y demandas.