Tipos de Licencias Open Source: Guía para developers

¿Sabías que una empresa multimillonaria perdió una demanda de 50 millones de dólares por usar mal código open source? Sí, así como lo lees. La diferencia entre elegir la licencia correcta y meter la pata puede hacer que tu proyecto despegue o se estrelle.

Al terminar de leer esto, vas a saber exactamente qué tipos de licencias existen y cuál elegir para no meterte en líos legales. Créeme, es más importante de lo que parece.

Las licencias: el manual de instrucciones del código abierto

Las licencias open source son como las reglas de un juego. Definen qué puede y qué no puede hacer otra persona con tu código. Si subes algo a GitHub sin licencia, técnicamente nadie puede usarlo legalmente. Raro, ¿verdad?

Ojo, open source no significa "gratis y haz lo que quieras". Cada licencia tiene sus propias reglas del juego. Algunas son súper relajadas, otras son más estrictas que un profesor de matemáticas.

Los tipos de licencias van desde "úsalo como quieras" hasta "si lo usas, tienes que compartir tus cambios también". Entender estas diferencias es clave si no quieres problemas después.

Las licencias permisivas (o: "haz lo que quieras, pero no me demandes")

MIT License: la favorita de todos

La licencia MIT es como ese amigo que te presta dinero sin preguntar cuándo se lo vas a devolver. Es la más popular de los tipos de licencias permisivas y por algo será.

Lo que te permite hacer:

• Úsalo comercialmente sin problemas
• Modifícalo como quieras sin avisar a nadie
• Solo tienes que mantener el aviso de copyright
• Combínalo con cualquier otra licencia

Cuándo usarla:

• Quieres que tu código se use masivamente
• No te molesta que hagan dinero con tu trabajo
• Prefieres simplicidad por encima de todo

En mi experiencia, si dudas entre varias opciones, MIT rara vez es una mala decisión. React, jQuery, Node.js... todos usan MIT.

Apache License 2.0: MIT con superpoderes legales

Apache es como MIT pero con un buen abogado. Incluye protecciones extra que las empresas grandes aman.

Por qué es mejor que MIT para algunos casos:

• Te protege contra demandas de patentes (súper importante)
• Manejo claro de contribuciones externas
• Las empresas se sienten más seguras usándola

Cuándo elegirla:

• Tu proyecto puede tener implicaciones de patentes
• Empresas grandes van a contribuir
• Quieres dormir tranquilo legalmente

Android, Kubernetes, TensorFlow... el mundo de las empresas tecnológicas ama Apache.

BSD License: la veterana respetable

BSD viene en dos sabores: de 2 cláusulas y de 3 cláusulas. Es como MIT pero con un poquito más de protección para el autor.

BSD 2-Clause (la simple):

• Básicamente es MIT con otras palabras
• No pueden usar tu nombre para promocionar sus cosas

BSD 3-Clause (la original):

• Un poquito más de protección
• Más clara sobre no usar tu nombre

Las licencias copyleft (o: "si lo usas, comparte también")

GNU General Public License (GPL): la activista

La GPL es como esa persona que siempre habla de justicia social, pero en el mundo del software. Si usas código GPL, todo tu proyecto tiene que ser open source también.

GPL v3 en pocas palabras:

• Todo código derivado tiene que seguir siendo open source
• Los cambios se tienen que publicar
• No se puede usar en software propietario
• Es como un virus (pero del bueno)

Cuándo usarla:

• Crees firmemente en el software libre
• Quieres que tu código siempre sea público
• No te importa limitar su uso comercial

Linux usa GPL (bueno, GPLv2), WordPress también. Es la licencia de los puristas.

LGPL: GPL light

La LGPL es como la hermana pequeña de GPL, menos estricta pero con los mismos valores. Permite que se use en software propietario pero con condiciones.

Las diferencias importantes:

• Bibliotecas se pueden usar en software privado
• Solo las modificaciones a tu código tienen que ser públicas
• Perfecto para librerías que quieres que se adopten masivamente

Cuándo elegirla:

• Estás haciendo una biblioteca
• Quieres adopción comercial pero con copyleft
• Buscas equilibrio entre libertad y practicidad

Las licencias especializadas (para casos raros)

Mozilla Public License (MPL): la del medio

La MPL es como ese político que trata de contentar a todos. Combina lo mejor de las licencias permisivas y copyleft.

Lo que la hace única:

• Copyleft solo a nivel de archivo (no todo el proyecto)
• Se puede combinar con código propietario
• Un punto medio entre GPL y MIT

Creative Commons: para todo lo que no es código

Aunque no es específicamente para código, Creative Commons tiene tipos de licencias geniales para contenido creativo.

Los sabores principales:

• CC0: "Haz lo que quieras, incluso no me menciones"
• CC BY: "Úsalo, pero di que es mío"
• CC BY-SA: "Úsalo, mencióname, y comparte igual"
• CC BY-NC: "Úsalo pero no para ganar dinero"

Cómo elegir sin volverse loco

Para proyectos personales

Si quieres que tu código se use muchísimo, ve con MIT. Es simple, todos la entienden, y no asusta a las empresas.

Si te molesta que alguien haga dinero con tu trabajo sin compartir mejoras, GPL puede ser tu opción.

Para empresas

Las empresas casi siempre prefieren Apache License 2.0. Les da tranquilidad legal sin complicarles la vida.

Si estás haciendo una biblioteca que quieres que adopten pero que las mejoras sean públicas, LGPL puede funcionar.

Para bibliotecas y frameworks

Lo importante es maximizar adopción. MIT o Apache son casi siempre la mejor opción aquí.

LGPL es alternativa si realmente quieres que las mejoras a tu biblioteca se mantengan abiertas.

Cosas legales que no te enseñan en tutoriales

No todas las licencias se llevan bien

Ojo con esto: no puedes mezclar licencias como si fueran ingredientes de cocina. GPL es especialmente territorial.

Reglas básicas:

• Las permisivas (MIT, Apache) casi siempre se pueden mezclar
• GPL requiere que TODO el proyecto sea GPL
• LGPL es más flexible para enlazar con código propietario

Cambiar de licencia es un dolor de cabeza

Cambiar licencias después requiere permiso de TODOS los que contribuyeron. En proyectos grandes es prácticamente imposible.

Estrategias inteligentes:

• Pide que te cedan el copyright de las contribuciones
• Usa un Contributor License Agreement (CLA) desde el inicio
• Elige bien desde el primer día

Herramientas que te van a salvar la vida

Para elegir licencia

• choosealicense.com: GitHub te ayuda a elegir
• tldrlegal.com: Explica licencias en español normal
• SPDX License List: La lista oficial completa

Para implementar

// Así se ve un header típico de MIT
/*
MIT License

Copyright (c) 2024 Tu Nombre

Permission is hereby granted, free of charge, to any person obtaining a copy...
*/

Lo que realmente importa

Los tipos de licencias open source no son solo papelerío. Son decisiones estratégicas que van a afectar todo el futuro de tu proyecto.

Elegir bien desde el principio te ahorra dolores de cabeza legales y maximiza las posibilidades de que tu código realmente ayude a otros developers. Y al final del día, ¿no es eso lo que queremos? Que nuestro código trascienda y ayude a construir cosas geniales.

Ojo, cuando tengas dudas, MIT rara vez es mala opción. Es simple, todos la entienden, y es la autopista hacia la adopción masiva.