Tipos de Licencias en el Desarrollo de Aplicaciones y sus Diferencias

¿Qué es una Licencia de Software?

Una licencia de software es un conjunto de reglas que explica cómo otros pueden usar una aplicación o código fuente.

Mediante una licencia, el creador de la aplicación puede determinar si otros pueden:

• Usar la aplicación de forma gratuita.
• Modificar el código fuente.
• Revender la aplicación.
• Usar el código para proyectos comerciales.
• Crear trabajos derivados.
• Cerrar el código fuente después de la modificación.
• Debe compartir el código fuente modificado.

Por lo tanto, incluso si el código fuente está disponible públicamente en GitHub, no significa que el código se pueda usar libremente sin restricciones.

Sin una licencia, las reglas de derechos de autor se aplican automáticamente. Esto significa que el propietario del código conserva todos los derechos, y otros esencialmente no tienen permiso para copiar, modificar ni distribuir el código.

Código Abierto No Significa Gratuito Sin Reglas

Muchas personas asumen que el código abierto significa que el código fuente se puede usar para cualquier cosa sin condiciones. En realidad, cada licencia de código abierto tiene reglas diferentes.

Generalmente, las licencias de código abierto permiten usar, estudiar, modificar y compartir el software. Sin embargo, algunas licencias otorgan libertades muy amplias, mientras que otras requieren que las aplicaciones derivadas permanezcan como código abierto.

Las licencias de software generalmente se dividen en varios grupos principales:

1. Licencia permisiva
2. Licencia copyleft
3. Licencia copyleft débil
4. Licencia propietaria
5. Licencia de dominio público

Tabla Comparativa de Licencias de Software

Licencia	Tipo	Uso Comercial Permitido	Modificación Permitida	Puede Hacerse Código Cerrado	Debe Abrir Código Fuente	Protección de Patentes	Adecuado Para
MIT	Permisiva	Sí	Sí	Sí	No	No establecido explícitamente	Bibliotecas, aplicaciones, proyectos personales
Apache 2.0	Permisiva	Sí	Sí	Sí	No	Sí	Proyectos empresariales y tecnología
BSD 2-Clause	Permisiva	Sí	Sí	Sí	No	No establecido explícitamente	Sistemas, bibliotecas y aplicaciones
BSD 3-Clause	Permisiva	Sí	Sí	Sí	No	No establecido explícitamente	Proyectos que requieren protección del nombre del creador
ISC	Permisiva	Sí	Sí	Sí	No	No establecido explícitamente	Proyectos pequeños y bibliotecas JavaScript
GNU GPL	Copyleft fuerte	Sí	Sí	No para trabajos derivados	Sí, cuando se distribuye	Depende de la versión	Aplicaciones completamente de código abierto
GNU LGPL	Copyleft débil	Sí	Sí	Sí, con ciertas condiciones	Solo partes específicas de la biblioteca	Depende de la versión	Bibliotecas de código abierto
GNU AGPL	Copyleft fuerte de red	Sí	Sí	Generalmente no	Sí, incluyendo servicio de red	Sí en AGPLv3	Servidores, SaaS y aplicaciones web
MPL 2.0	Copyleft a nivel de archivo	Sí	Sí	Sí, para archivos separados	Solo archivos modificados bajo licencia MPL	Sí	Proyectos mixtos de código abierto y propietario
Unlicense	Estilo dominio público	Sí	Sí	Sí	No	No	Código simple destinado a ser liberado
Propietaria	Código cerrado	Según permiso del propietario	Generalmente no	Sí	No	Según acuerdo	Aplicaciones internas y productos de pago

1. Licencia MIT

La Licencia MIT es una de las licencias de código abierto más simples y flexibles.

Esta licencia permite a otros:

• Usar el software.
• Copiar el código fuente.
• Modificar el código fuente.
• Vender el software.
• Incluir el código en aplicaciones de pago.
• Convertir la aplicación a código cerrado.

El requisito principal es que el aviso de derechos de autor y el texto de la licencia MIT deben permanecer incluidos en todas las copias o partes sustanciales del software.

Ventajas de la Licencia MIT

• El texto de la licencia es corto.
• Fácil de entender.
• Amigable para uso comercial.
• Se puede usar en aplicaciones de código cerrado.
• Ampliamente utilizada en bibliotecas y frameworks.

Desventajas de la Licencia MIT

• Otros pueden tomar el código, modificarlo y luego venderlo como una aplicación de código cerrado.
• No tiene protección de patentes tan clara como Apache 2.0.
• El propietario del código no puede exigir que las versiones modificadas permanezcan como código abierto.

Adecuada cuando

MIT es adecuada para desarrolladores que quieren que su código fuente se use lo más ampliamente posible sin imponer muchas restricciones.

2. Licencia Apache 2.0

La Licencia Apache 2.0 tiene características similares a MIT. El software puede ser usado, modificado, distribuido e incluido en aplicaciones comerciales.

La diferencia clave es que Apache 2.0 incluye disposiciones sobre concesiones de patentes. Esta licencia también requiere avisos de atribución a través de archivos como LICENSE y, si está disponible, NOTICE.

Ventajas de Apache 2.0

• Se puede usar para proyectos comerciales.
• Se puede incluir en aplicaciones de código cerrado.
• Tiene una protección de patentes y disposiciones más claras.
• Adecuada para proyectos empresariales.
• Se requiere que los usuarios documenten los cambios importantes realizados.

Desventajas de Apache 2.0

• El texto de la licencia es más largo en comparación con MIT.
• Gestionar la atribución y el archivo NOTICE puede ser más complejo.
• No exige que los trabajos derivados sean de código abierto.

Adecuada cuando

Apache 2.0 es adecuada para proyectos profesionales o empresas que desean una licencia flexible con una protección de patentes más clara.

3. Licencia BSD

La Licencia BSD es una licencia permisiva similar a MIT. Tiene varias versiones, pero las más comunes son BSD 2-Cláusulas y BSD 3-Cláusulas.

Ambas permiten el uso, modificación y distribución tanto en forma de código fuente como binaria.

BSD 2-Cláusulas

BSD 2-Cláusulas también se llama Licencia BSD Simplificada.

Sus requisitos principales:

• El aviso de derechos de autor debe permanecer incluido.
• El texto de la licencia y el descargo de responsabilidad deben permanecer incluidos.

BSD 3-Cláusulas

BSD 3-Cláusulas tiene una regla adicional: los nombres de los creadores o contribuyentes no pueden usarse para promocionar productos derivados sin permiso.

Ventajas de la Licencia BSD

• Simple y flexible.
• Se puede usar comercialmente.
• Se puede incluir en aplicaciones de código cerrado.
• Adecuada para bibliotecas y software de sistemas.

Desventajas de la Licencia BSD

• No se requiere compartir los cambios de código.
• No tiene disposiciones de patentes tan claras como Apache 2.0.
• Otros pueden crear productos propietarios usando el código.

4. Licencia ISC

La Licencia ISC es una licencia permisiva muy concisa. Funcionalmente, es casi idéntica a MIT y BSD 2-Cláusulas.

Los usuarios pueden usar, copiar, modificar y distribuir el software siempre que el aviso de derechos de autor y el texto de permiso permanezcan incluidos.

Ventajas de la Licencia ISC

• Texto muy corto.
• Fácil de aplicar.
• Permitido para uso comercial.
• Se puede usar en aplicaciones de código cerrado.

Desventajas de la Licencia ISC

• No exige que las versiones modificadas sean de código abierto.
• Las disposiciones de patentes no son tan claras como Apache 2.0.
• Menos adecuada cuando el creador desea mantener la apertura del código derivado.

ISC es bastante común en paquetes y bibliotecas dentro del ecosistema JavaScript.

5. Licencia Pública General GNU o GPL

GNU no es un nombre de licencia único. GNU tiene varios tipos de licencias, como:

• GNU GPL
• GNU LGPL
• GNU AGPL

La Licencia Pública General GNU o GPL es una licencia copyleft fuerte. Esto significa que cuando el software GPL se modifica y distribuye como trabajo derivado, el código fuente de esa aplicación también debe estar disponible bajo una licencia compatible con GPL.

GPL no prohíbe el uso comercial. Los desarrolladores aún pueden vender software GPL. Sin embargo, los destinatarios del software deben recibir los derechos otorgados por GPL, incluido el acceso al código fuente bajo las condiciones requeridas por la licencia.

Ventajas de GNU GPL

• Mantiene el software y sus derivados abiertos.
• Las mejoras y desarrollos pueden fluir de vuelta a la comunidad.
• Evita que otros tomen el código y cierren la fuente de los trabajos derivados.
• Adecuada para proyectos basados en la comunidad.

Desventajas de GNU GPL

• Difícil de usar en productos propietarios.
• Se debe tener cuidado al combinar con otro código con licencia.
• Menos adecuada para empresas que quieren mantener cerrado el código fuente de su producto.

¿Se requiere abrir el código interno?

No siempre.

Si una aplicación GPL solo se usa internamente y no se distribuye a otros, generalmente el código fuente no tiene que divulgarse al público automáticamente.

La obligación principal de GPL generalmente surge cuando el software o los trabajos derivados se distribuyen.

6. Licencia Pública General Reducida GNU o LGPL

LGPL es una versión copyleft más flexible en comparación con GPL.

Esta licencia generalmente se usa para bibliotecas. Las aplicaciones propietarias pueden usar o enlazar bibliotecas LGPL siempre que cumplan con los términos de la licencia. GNU establece que las bibliotecas LGPL pueden enlazarse con aplicaciones propietarias, a diferencia de GPL que tiene un efecto copyleft más fuerte sobre los trabajos derivados.

Ventajas de GNU LGPL

• Adecuada para bibliotecas de código abierto.
• Puede ser usada por aplicaciones de código cerrado.
• Los cambios a la biblioteca LGPL deben seguir las reglas de LGPL.
• Amplía el uso de la biblioteca sin liberar todas las protecciones copyleft.

Desventajas de GNU LGPL

• Las reglas de integración son más complejas que MIT.
• Se debe prestar atención a los métodos de enlace y distribución.
• Las modificaciones directas a la biblioteca pueden desencadenar obligaciones de compartir el código fuente de la biblioteca.

Adecuada cuando

LGPL es adecuada cuando creas una biblioteca que deseas que sea utilizable tanto por aplicaciones de código abierto como propietarias.

7. Licencia Pública General Affero GNU o AGPL

AGPL es una licencia copyleft diseñada específicamente para software usado a través de una red, como:

• Aplicaciones web.
• Software como Servicio o SaaS.
• APIs.
• Servidores.
• Plataformas en línea.

Con GPL regular, una empresa puede modificar el software y ejecutarlo en un servidor sin distribuir la aplicación. En tal situación, el requisito de distribución del código fuente de GPL puede no aplicarse.

AGPL agrega obligaciones relacionadas con el uso del software a través de una red. Los usuarios que interactúan con una versión modificada del software a través de una red deben tener la oportunidad de acceder al código fuente correspondiente.

Ventajas de GNU AGPL

• Adecuada para mantener aplicaciones SaaS como código abierto.
• Evita que otros modifiquen una aplicación de servidor y cierren su código.
• Proporciona una protección copyleft más fuerte.

Desventajas de GNU AGPL

• Difícil de usar en aplicaciones propietarias.
• A menudo evitada por empresas que no quieren abrir el código fuente del servidor.
• La integración necesita una revisión cuidadosa.

8. Licencia Pública de Mozilla 2.0

La Licencia Pública de Mozilla o MPL 2.0 es una licencia copyleft a nivel de archivo.

Esto significa que los archivos que ya están bajo MPL y luego se modifican deben permanecer disponibles bajo MPL. Sin embargo, esos archivos aún pueden combinarse con otros archivos propietarios dentro de una sola aplicación.

Por lo tanto, MPL se encuentra entre las licencias permisivas como MIT y las licencias copyleft fuertes como GPL. MPL 2.0 también es una licencia de código abierto reconocida por la Open Source Initiative.

Ventajas de MPL 2.0

• Más flexible que GPL.
• Los archivos de código abierto modificados permanecen abiertos.
• Se puede combinar con código de código cerrado.
• Adecuada para proyectos con módulos tanto abiertos como propietarios.

Desventajas de MPL 2.0

• Más compleja que MIT o BSD.
• Los desarrolladores deben saber qué archivos están bajo MPL.
• Menos adecuada si deseas que toda la aplicación derivada permanezca como código abierto.

9. Unlicense

Unlicense se usa cuando un creador desea liberar código al dominio público en la mayor medida permitida por la ley.

Generalmente, los usuarios pueden:

• Copiar el código.
• Modificar el código.
• Vender el código.
• Distribuir el código.
• Usar el código sin atribución.

Unlicense impone muy pocas condiciones a los usuarios.

Ventajas de Unlicense

• Muy libre.
• Casi sin obligaciones de atribución.
• Adecuada para fragmentos de código pequeños o código de ejemplo.

Desventajas de Unlicense

• El concepto de dominio público puede tratarse de manera diferente en cada país.
• No es ideal para proyectos empresariales.
• No proporciona una protección de patentes clara.
• Los contribuyentes de empresas pueden preferir MIT o Apache 2.0.

10. Licencia Propietaria

Una licencia propietaria es una licencia para aplicaciones de código cerrado. Los derechos de uso del software son determinados completamente por el propietario de la aplicación.

Los usuarios típicamente solo reciben permiso para usar la aplicación, no para poseer ni modificar el código fuente.

Ejemplos:

• Aplicaciones de suscripción.
• Software interno de empresa.
• Aplicaciones de caja de pago.
• Sistemas de gestión hotelera.
• Aplicaciones específicas para clientes.
• Software de escritorio de pago.

Reglas comunes

• No se puede copiar la aplicación.
• No se pueden compartir cuentas.
• No se puede ver ni modificar el código fuente.
• No se puede revender la aplicación.
• El uso está limitado por dispositivo, usuario, empresa o tiempo.
• Los derechos de uso terminan cuando se detiene la suscripción.

Adecuada cuando

Una licencia propietaria es adecuada cuando la aplicación es un producto comercial y el código fuente debe mantenerse cerrado.

11. Licencia Dual

La licencia dual es un método de ofrecer dos opciones de licencia para el mismo software.

Ejemplos:

• Gratuita con GPL para proyectos de código abierto.
• De pago con una licencia comercial para empresas que quieren usar el software sin seguir GPL.

Este modelo permite a los creadores de software beneficiarse de la comunidad de código abierto mientras también venden licencias comerciales.

Sin embargo, la licencia dual es más fácil de implementar cuando los derechos de autor del código fuente son totalmente propiedad de una sola empresa o entidad. Si hay muchos contribuyentes, la gestión de los derechos de contribución debe estar claramente establecida.

¿Se Puede Usar Creative Commons para el Código Fuente?

Creative Commons o CC es más adecuado para:

• Artículos.
• Imágenes.
• Videos.
• Música.
• Documentación.
• Materiales de aprendizaje.
• Diseños y contenido creativo.

Creative Commons no recomienda usar licencias CC para software y hardware porque existen licencias de software específicas que abordan de manera más adecuada asuntos como el código fuente, la distribución y la modificación.

En un proyecto de aplicación único, puedes usar:

• MIT, Apache o GPL para el código fuente.
• Creative Commons para documentación, imágenes u otros materiales.

Asegúrate de que cada parte se explique por separado para no confundir a los usuarios.

Diferencias Entre Permisivo y Copyleft

Aspecto	Licencia Permisiva	Licencia Copyleft
Ejemplos	MIT, Apache 2.0, BSD, ISC	GPL, AGPL
Uso comercial	Permitido	Permitido
Modificación de código	Permitido	Permitido
Puede volverse código cerrado	Generalmente permitido	Generalmente no para trabajos derivados
Debe compartir cambios	No	Sí bajo ciertas condiciones
Nivel de restricción	Más simple	Más estricto
Adecuado para empresas	Muy adecuado	Depende del modelo de negocio
Adecuado para comunidad de código abierto	Adecuado	Muy adecuado
Protección de apertura de código	Baja	Alta

¿Qué Licencia Deberías Elegir?

Usa MIT cuando

• Quieres una licencia simple.
• Quieres que el código se use lo más ampliamente posible.
• No te importa si el código se usa en aplicaciones de código cerrado.
• Estás creando una biblioteca o proyecto personal.

Usa Apache 2.0 cuando

• Quieres la libertad de MIT.
• Necesitas disposiciones de patentes más claras.
• Estás creando un proyecto empresarial.
• Planeas aceptar muchas contribuciones.

Usa BSD cuando

• Quieres una licencia permisiva simple.
• Estás creando software de sistemas o una biblioteca.
• No quieres que el nombre del creador se use para promocionar productos derivados.

Usa GPL cuando

• Quieres que las aplicaciones derivadas permanezcan como código abierto.
• No quieres que las empresas tomen el código y cierren su fuente.
• Estás creando un proyecto comunitario.

Usa LGPL cuando

• Estás creando una biblioteca.
• Quieres que la biblioteca sea utilizable por aplicaciones propietarias.
• Quieres que las modificaciones a la biblioteca permanezcan abiertas.

Usa AGPL cuando

• Estás creando una aplicación SaaS o de servidor.
• Quieres que los cambios usados a través de una red se compartan.
• No quieres que las empresas ejecuten versiones modificadas de forma privada en sus servidores.

Usa MPL 2.0 cuando

• Quieres que parte del código permanezca abierto.
• Aún deseas combinar código con módulos propietarios.
• Necesitas un punto medio entre MIT y GPL.

Usa una licencia propietaria cuando

• El código fuente no puede abrirse.
• La aplicación está hecha para fines comerciales.
• Quieres restringir el uso del software.
• La aplicación se vende a través de un sistema de licencia o suscripción.

Ejemplo de Aplicación de Licencia en GitHub

Normalmente, el texto de la licencia se almacena en el siguiente archivo:

LICENSE

o:

LICENSE.md

Ese archivo se coloca en la carpeta principal o raíz del repositorio. GitHub también recomienda incluir el archivo de licencia directamente en el repositorio para que esté disponible cuando se clona, descarga o distribuye el proyecto.

Ejemplo de estructura de proyecto:

app-name/
├── app/
├── public/
├── src/
├── README.md
├── LICENSE
└── package.json

También se puede agregar información breve en README.md:

## Licencia

Este proyecto está licenciado bajo la Licencia MIT.
Consulte el archivo LICENSE para obtener más información.

Cosas a Revisar Antes de Elegir una Licencia

Antes de decidir una licencia, considera lo siguiente:

1. ¿Se puede usar la aplicación comercialmente?
2. ¿Pueden otros modificar el código fuente?
3. ¿Deben compartirse las modificaciones?
4. ¿Pueden los trabajos derivados ser de código cerrado?
5. ¿Se usará la aplicación como SaaS?
6. ¿El proyecto utiliza bibliotecas de terceros?
7. ¿Son las licencias de cada dependencia compatibles?
8. ¿Hay código de otros contribuyentes?
9. ¿Se necesita protección de patentes?
10. ¿Se venderá la aplicación a clientes?

No elijas una licencia solo porque es popular. Elige una licencia basada en los objetivos del proyecto y cómo se usará la aplicación.

Conclusión

Cada licencia de software proporciona diferentes derechos y obligaciones.

MIT, BSD e ISC son adecuadas para proyectos que quieren dar amplias libertades a los usuarios. Apache 2.0 ofrece libertad similar con disposiciones de patentes más claras.

GPL es adecuada para mantener aplicaciones derivadas como código abierto. LGPL es más apropiada para bibliotecas, mientras que AGPL proporciona protección adicional para aplicaciones web, servidores y SaaS.

MPL 2.0 puede ser un punto medio porque solo requiere que ciertos archivos permanezcan abiertos. Mientras tanto, una licencia propietaria es más adecuada para aplicaciones comerciales cuyo código fuente debe permanecer cerrado.

La selección de licencia debe realizarse al inicio del desarrollo. Además de proteger al creador de la aplicación, una licencia clara también ayuda a los usuarios y contribuyentes a entender qué está y qué no está permitido.

Nota: Este artículo proporciona una explicación general y no es asesoramiento legal. Para aplicaciones comerciales a gran escala, uso intensivo de dependencias o proyectos con muchos contribuyentes, consulta a alguien con conocimientos sobre propiedad intelectual en cuanto a la selección de licencia.