Open source no significa libre de obligaciones
El 96% del software comercial contiene componentes open source. Para startups y empresas de software, esto no es un problema en sí mismo — es una realidad del desarrollo moderno. El problema surge cuando no se gestionan las licencias de esos componentes, lo que puede generar riesgos legales que van desde obligaciones de publicación de código hasta litigios por infracción de copyright.
Tipos de licencias y sus implicaciones comerciales
Las licencias open source se dividen en dos grandes familias, con implicaciones radicalmente distintas:
Licencias permisivas (MIT, BSD, Apache 2.0). Permiten usar, modificar y distribuir el software con pocas restricciones. Generalmente solo requieren mantener la atribución y la copia de la licencia. Son compatibles con modelos de negocio propietarios y comerciales.
- MIT — La más simple. Permite casi cualquier uso siempre que incluyas el aviso de copyright.
- Apache 2.0 — Similar a MIT pero incluye una concesión explícita de licencia de patentes del contribuidor y una cláusula de terminación si inicias litigios de patentes.
- BSD — Variantes de 2 y 3 cláusulas. La versión de 3 cláusulas prohíbe usar el nombre del proyecto para promoción sin permiso.
Licencias copyleft (GPL, LGPL, AGPL, MPL). Requieren que las obras derivadas se distribuyan bajo la misma licencia o una compatible. Esto puede obligarte a publicar tu código propietario en determinadas circunstancias.
- GPL v3 — Cualquier software que enlace con código GPL debe distribuirse también bajo GPL. Esto significa que si incorporas una librería GPL en tu producto, todo tu producto podría tener que ser open source.
- AGPL v3 — Extiende las obligaciones de GPL al uso en red. Si ofreces un servicio SaaS que usa código AGPL, debes proporcionar el código fuente a los usuarios del servicio. Esto es especialmente relevante para empresas SaaS.
- LGPL — Más permisiva que GPL para linking dinámico. Puedes enlazar con librerías LGPL desde código propietario sin que este se “contamine”, siempre que uses linking dinámico.
- MPL 2.0 — Copyleft a nivel de archivo. Solo los archivos modificados deben distribuirse bajo MPL, no todo el proyecto.
Riesgos concretos para startups
1. Contaminación copyleft inadvertida. Un desarrollador incorpora una dependencia GPL sin revisión. Todo el producto podría quedar sujeto a GPL, obligando a publicar el código fuente.
2. Incompatibilidad de licencias. Combinar componentes con licencias incompatibles (por ejemplo, GPL v2 y Apache 2.0 en ciertas configuraciones) puede crear situaciones donde la distribución del software es técnicamente ilegal.
3. Incumplimiento de atribución. Incluso licencias permisivas requieren atribución. No incluir los avisos de copyright obligatorios es una infracción técnica que puede ser explotada en litigios o due diligence.
4. Riesgo en due diligence de inversión. Los fondos de VC y compradores en M&A revisan el inventario de licencias open source. Problemas de compliance pueden reducir la valoración, retrasar operaciones o incluso bloquear la transacción.
Cómo implementar un programa de compliance open source
Paso 1: Inventario de dependencias. Utiliza herramientas como FOSSA, Snyk, o Black Duck para escanear tu codebase y generar un inventario completo de componentes open source y sus licencias.
Paso 2: Clasificación de riesgos. Categoriza cada componente según el tipo de licencia y cómo se integra en tu producto (linking estático vs dinámico, distribución vs uso interno, SaaS vs on-premise).
Paso 3: Política de licencias. Define qué licencias son aceptables para tu modelo de negocio. Una política típica para SaaS podría ser:
- Aprobadas: MIT, BSD, Apache 2.0, ISC
- Revisión requerida: LGPL, MPL, CDDL
- Prohibidas: GPL, AGPL (salvo uso aislado sin linking)
Paso 4: Proceso de aprobación. Integra la revisión de licencias en tu pipeline de desarrollo. Cada nueva dependencia debe ser evaluada antes de incorporarse al proyecto.
Paso 5: Documentación y atribución. Mantén un archivo NOTICE o THIRD_PARTY_LICENSES actualizado con todos los componentes y sus licencias. Esto es obligatorio para muchas licencias y valorado en due diligence.
El caso especial de AGPL y SaaS
AGPL merece atención especial para empresas SaaS. A diferencia de GPL, que se activa con la distribución del software, AGPL se activa cuando el software se ofrece como servicio en red. Si tu SaaS incorpora código AGPL (incluso a través de una dependencia indirecta), podrías estar obligado a ofrecer el código fuente completo de tu aplicación a cualquier usuario.
Empresas como Google prohíben internamente el uso de código AGPL. Para startups SaaS, recomendamos tratar AGPL como una licencia de alto riesgo que requiere revisión legal antes de su uso.
Open source y el AI Act
El AI Act incluye excepciones limitadas para modelos de IA open source. Los modelos liberados bajo licencia open source están exentos de ciertas obligaciones de transparencia del AI Act, siempre que no se clasifiquen como de riesgo sistémico. Sin embargo, esta exención no elimina las obligaciones de la licencia open source en sí misma.
Si distribuyes un modelo de IA bajo licencia open source, debes cumplir tanto con las condiciones de la licencia como con las obligaciones aplicables del AI Act.
En A2 ayudamos a empresas de software a diseñar políticas de compliance open source que protejan su propiedad intelectual sin limitar su capacidad de innovación. Consulta con nuestro equipo.