Por qué dar varias licencias a un mismo código
El titular del copyright puede licenciar el mismo código bajo varias condiciones a la vez. Quien lo recibe solo tiene que elegir una y cumplir sus condiciones. Hay dos grandes motivos para hacerlo.
- Ampliar la compatibilidad — para encajar bien con ecosistemas distintos.
- Modelo de negocio — para publicar como código abierto y vender a la vez una licencia comercial aparte.
Tipo 1: dos licencias permisivas juntas — MIT OR Apache-2.0
Es lo que hacen el lenguaje Rust y la mayoría de los crates de Rust. El usuario elige la que le convenga entre MIT y Apache-2.0.
- Si elige Apache-2.0, recibe una licencia de patentes explícita.
- Si elige MIT, puede incluirlo incluso en proyectos GPL-2.0-only (porque la FSF considera Apache-2.0 incompatible con GPL-2.0).
Se obtienen las ventajas de ambas, por lo que es muy popular entre autores de bibliotecas. Por convención, el repositorio incluye dos archivos: LICENSE-MIT y LICENSE-APACHE.
Tipo 2: copyleft + comercial — 'o GPL, o pagas'
Se publica el código bajo GPL o AGPL y, a las empresas que no quieren asumir la obligación de publicar su código, se les vende una licencia comercial mediante un contrato aparte. MySQL (GPL + licencia comercial de Oracle) y Qt (LGPL-3.0/GPL + comercial) son casos representativos.
Este modelo solo funciona si el titular tiene los derechos sobre todo el código. El titular no tiene derecho a vender con licencia comercial el código que contribuidores externos aportaron solo bajo GPL.
CLA y DCO
- CLA (acuerdo de licencia de contribuidor): contrato por el que el contribuidor concede a la entidad que gestiona el proyecto amplios derechos de uso sobre su contribución (incluida la relicencia) o le cede el copyright. En la práctica es imprescindible para una licencia dual comercial. También hay modalidades, como el ICLA de la Fundación Apache, que solo conceden el derecho de relicencia y dejan el copyright al contribuidor.
- DCO (Developer Certificate of Origin): el contribuidor confirma en cada commit que 'tiene derecho a enviar este código bajo la licencia del proyecto' (con
git commit -sse añade la líneaSigned-off-by:). Lo usa el kernel de Linux. El DCO no concede derechos de relicencia, por lo que no basta para una licencia dual comercial.
Cómo escribirlo con expresiones SPDX
La relación entre varias licencias se escribe con expresiones de licencia SPDX.
| Expresión | Significado | Ejemplo |
|---|---|---|
A OR B | Se elige una de las dos (licencia dual a elegir) | MIT OR Apache-2.0 |
A AND B | Hay que cumplir ambas (se mezclan partes distintas) | MIT AND BSD-3-Clause |
A WITH excepción | Añade una excepción a la licencia | GPL-2.0-only WITH Linux-syscall-note |
| Paréntesis | Fijan el orden de agrupación | (MIT OR Apache-2.0) AND Unicode-3.0 |
Si confundes OR y AND, el significado se invierte. Si el usuario puede elegir, es OR; si hay que cumplir todas, AND.
Qué tener en cuenta
- Los derechos ya recibidos se mantienen: aunque más adelante solo quede la licencia comercial, los permisos de las versiones distribuidas antes como código abierto normalmente siguen siendo válidos.
- No es lo mismo que el 'open core': el modelo en el que el núcleo es de código abierto y las funciones adicionales se venden como producto comercial cerrado no es una licencia dual. Licencia dual es dar dos licencias al mismo código.
- No confundir con las licencias de código disponible: cada vez hay más casos de paso a licencias como BUSL o SSPL, en las que el código es visible pero que no son de código abierto según la OSI. Es una estrategia distinta de la licencia dual.
- Archivos de aviso precisos: si es a elegir, ofrece el texto completo de cada licencia y deja claro en el README que 'se puede elegir una de las dos'.
Ejemplo de aplicación
Para aplicar una licencia dual al estilo Rust, descarga en el generador los archivos MIT y Apache-2.0, guárdalos como LICENSE-MIT y LICENSE-APACHE y pon license = "MIT OR Apache-2.0" en los metadatos. En la cabecera de cada archivo escribe SPDX-License-Identifier: MIT OR Apache-2.0.
Este artículo es información general y no constituye asesoramiento jurídico. Para decisiones importantes, consulta con un profesional.
Fuentes
- SPDX Specification, License Expressions — https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/
- Rust API Guidelines, Licensing — https://rust-lang.github.io/api-guidelines/necessities.html
- Developer Certificate of Origin — https://developercertificate.org/
- Apache ICLA — https://www.apache.org/licenses/contributor-agreements.html