Aspectos Legales
Aspectos Legales
Por que importa lo legal
El contenido creativo (codigo, graficos, escritura) esta protegido por derechos de autor automaticamente. Sin una licencia explicita, nadie puede usar, copiar, distribuir o modificar tu trabajo legalmente.
Hacer un proyecto publico en GitHub no es lo mismo que otorgar licencia. Sin licencia, tu trabajo no tiene permisos adicionales mas alla de los terminos de servicio de GitHub.
Elegir la licencia correcta
Licencias permisivas
| Licencia | Caracteristica clave |
|---|---|
| MIT | Corta, comprensible, maxima libertad |
| Apache 2.0 | Incluye concesion de patentes explicita |
| BSD | Similar a MIT, variantes de 2 y 3 clausulas |
Permiten licenciar tu proyecto como desees. Los derivados pueden ser closed source.
Licencias copyleft
| Licencia | Caracteristica clave |
|---|---|
| GPLv2/GPLv3 | Derivados deben ser open source con misma licencia |
| AGPLv3 | Como GPL pero aplica a uso en red (SaaS) |
| LGPLv3 | Copyleft debil, permite linking con closed source |
| MPL 2.0 | Copyleft por archivo, no por proyecto |
Licencias source-available
BSL, SSPL: pueden restringir uso y modelos de negocio. No son aprobadas por OSI como “open source”.
Contenido no-codigo
Imagenes, videos, fuentes, datos necesitan sus propias licencias. Creative Commons ofrece opciones desde CC0 (dominio publico) hasta CC-SA (copyleft).
Criterios de decision
| Escenario | Licencia recomendada |
|---|---|
| Maxima adopcion | MIT |
| Atractivo empresarial | Apache 2.0 (proteccion de patentes) |
| Software libre estricto | GPLv3 o AGPLv3 |
| Tu comunidad usa X | Usa la mas popular de tu ecosistema |
Usa choosealicense.com para decidir.
Cambiar licencia
Factores a considerar
- Compatibilidad: de permisiva a restrictiva es posible. Al reves necesitas acuerdo de todos los titulares
- Titulares de derechos: si eres el unico, puedes cambiar libremente. Con multiples contribuyentes, necesitas aprobacion de todos
- Escala: proyectos grandes pueden tomar anos (Mozilla tardo 5 anos)
Acuerdos de contribuyente (CLA)
Necesitas uno? Probablemente NO
Para la mayoria de proyectos, la licencia open source es suficiente. GitHub hace explicito el modelo “inbound=outbound” por defecto: al contribuir, aceptas la licencia del proyecto.
Desventajas
- Trabajo administrativo extra
- Puede parecer “no amigable” con la comunidad
- Eliminar el CLA de Node.js amplio su base de colaboradores
Cuando considerar un CLA
- Tus abogados lo requieren expresamente
- Necesitas concesion de patentes explicita (si usas MIT)
- Necesitas poder cambiar la licencia en el futuro
- Proyecto copyleft que tambien necesita version propietaria
Alternativa ligera: DCO
El Developer Certificate of Origin es mas ligero que un CLA. Node.js lo usa. Se automatiza con DCO Probot — cada commit incluye un Signed-off-by.
Consideraciones corporativas
Como empleado
- Tu empresa podria tener derechos sobre codigo que escribes
- Consulta politicas de IP incluso para proyectos personales
- Negocia o busca una politica amigable con empleados
Como empresa
El equipo legal debe estar involucrado:
- Dependencias: verificar compatibilidad de licencias
- Secretos: extraer material privado antes de abrir el codigo
- Patentes: considerar implicaciones de divulgacion
- Marcas: verificar conflictos de nombres
- SBOM: lista de dependencias con versiones y licencias (obligatoria en algunas jurisdicciones)
Estrategia corporativa
- Desarrollar politica clara para contribuciones de empleados
- Entender cumplimiento de licencias de dependencias que usas
- Considerar Open Invention Network para proteccion de patentes defensiva
Resumen
- Siempre agrega una licencia explicita — sin ella no es open source
- MIT para maxima libertad, Apache 2.0 para proteccion de patentes, GPLv3 para copyleft
- Publico en GitHub ≠ open source
- Evita CLAs a menos que sea absolutamente necesario — prefiere DCO
- Consulta a tu equipo legal si eres empresa o empleado
- Planifica cambios de licencia desde el inicio, no despues