Permisos, condiciones y limitaciones de un vistazo
Condiciones
- Divulgar el código fuenteAl distribuir hay que proporcionar el código fuente.
- Aviso de copyright y licenciaAl distribuir hay que incluir una copia de la licencia y el aviso de copyright.
- Misma licenciaLas versiones modificadas y obras derivadas deben distribuirse con la misma licencia (o una compatible).
Limitaciones
- Limitación de responsabilidadIndica expresamente que no se asume responsabilidad por daños.
- Sin garantíaIndica expresamente que no ofrece ninguna garantía.
Fuente de la clasificación de permisos, condiciones y limitaciones: datos de choosealicense.com (GitHub, licencia MIT).
Qué es esta licencia
La Eclipse Foundation publicó la EPL 2.0 en agosto de 2017. La usan Eclipse IDE, Jakarta EE y numerosos proyectos de la Eclipse Foundation. Al distribuir un programa bajo EPL y sus modificaciones ('Contribution') hay que publicar el código fuente, pero el código separado en módulos independientes que no deriva del código EPL puede distribuirse con otra licencia (incluso comercial). Incluye una licencia de patentes explícita y una cláusula que termina la licencia de patentes de quien presente una demanda alegando que el programa infringe sus patentes.
Cambios respecto a EPL-1.0
- Se eliminó la cláusula que fijaba la ley del estado de Nueva York como ley aplicable.
- Se redefinió 'obra derivada' conforme al concepto de la ley de propiedad intelectual.
- Se creó el mecanismo de Secondary License (Exhibit A): si el autor original lo designa, el resultado combinado con GPL-2.0 u otras puede distribuirse bajo esa licencia.
Qué hay que cumplir al distribuir
- Al distribuir en forma de código fuente, hacerlo bajo las condiciones de EPL-2.0 e incluir una copia de la licencia.
- Al distribuir en código objeto (binario), informar de cómo obtener el código fuente por un medio razonable y asegurarse de que tus condiciones de licencia no limitan los derechos de los receptores EPL.
- Conservar los avisos de copyright.
- Los distribuidores comerciales asumen obligaciones de defensa e indemnización para que la responsabilidad no recaiga en otros contribuidores (sección 4).
Malentendidos frecuentes
- "La EPL es compatible con la GPL" — Por defecto no lo es. Solo lo es el código para el que el autor original designó una Secondary License mediante el Exhibit A.
- "Todos los plugins EPL tienen que ser EPL" — Si funcionan como módulos independientes y no derivan del código EPL, pueden tener otra licencia. Si hay derivación se juzga con criterios de propiedad intelectual.
- "Aunque solo lo use sin modificar, tengo que publicar el código" — La obligación se refiere al código EPL (y sus modificaciones). Si no lo has modificado, basta con informar de cómo obtener el código fuente original.
Cómo aplicarla
Pon el texto en LICENSE y, si hace falta, añade a cada archivo el aviso de Secondary License con el formato del Exhibit A. La EPL no tiene un texto de cabecera establecido como GNU o Apache, así que se recomienda una cabecera con el identificador SPDX EPL-2.0 (si se designa GPL-2.0 como Secondary License, la expresión SPDX a veces se escribe como EPL-2.0 OR GPL-2.0-or-later WITH Classpath-exception-2.0).
Cuándo encaja
Encaja en ecosistemas impulsados por empresas que quieren mantener abierto el núcleo de una plataforma o framework y permitir vender comercialmente los módulos de extensión construidos sobre él. Una alternativa más sencilla, por archivo, es MPL-2.0.
¿Puedo incluir código EPL-2.0 en otro proyecto?
Resultado general al tomar código publicado bajo esta licencia y distribuirlo combinado en un proyecto con cada una de las licencias siguientes. Ver otras combinaciones en el comprobador de compatibilidad →
| Proyecto de destino | Resultado | Nota |
|---|---|---|
| Software privativo (comercial) | Sí, con condiciones | El código EPL y sus modificaciones deben mantenerse bajo EPL-2.0 y hay que proporcionar su código fuente. Tu propio código separado en módulos independientes puede tener otra licencia. |
| MIT | Sí, con condiciones | El código EPL y sus modificaciones deben mantenerse bajo EPL-2.0 y hay que proporcionar su código fuente. Tu propio código separado en módulos independientes puede tener otra licencia. |
| Apache-2.0 | Sí, con condiciones | El código EPL y sus modificaciones deben mantenerse bajo EPL-2.0 y hay que proporcionar su código fuente. Tu propio código separado en módulos independientes puede tener otra licencia. |
| MPL-2.0 | Sí, con condiciones | El código EPL y sus modificaciones deben mantenerse bajo EPL-2.0 y hay que proporcionar su código fuente. Tu propio código separado en módulos independientes puede tener otra licencia. |
| LGPL-2.1 | Sí, con condiciones | Solo si el autor original designó GPL u otra licencia como Secondary License mediante el Exhibit A puedes combinarlo y distribuirlo bajo una licencia GNU. Sin esa designación no son compatibles. |
| LGPL-3.0 | Sí, con condiciones | Solo si el autor original designó GPL u otra licencia como Secondary License mediante el Exhibit A puedes combinarlo y distribuirlo bajo una licencia GNU. Sin esa designación no son compatibles. |
| GPL-2.0 | Sí, con condiciones | Solo si el autor original designó GPL u otra licencia como Secondary License mediante el Exhibit A puedes combinarlo y distribuirlo bajo una licencia GNU. Sin esa designación no son compatibles. |
| GPL-3.0 | Sí, con condiciones | Solo si el autor original designó GPL u otra licencia como Secondary License mediante el Exhibit A puedes combinarlo y distribuirlo bajo una licencia GNU. Sin esa designación no son compatibles. |
| AGPL-3.0 | Sí, con condiciones | Solo si el autor original designó GPL u otra licencia como Secondary License mediante el Exhibit A puedes combinarlo y distribuirlo bajo una licencia GNU. Sin esa designación no son compatibles. |
El contenido de este sitio es información general y no constituye asesoramiento jurídico. Para decisiones reales de distribución, contratos o litigios, consulta con un abogado u otro profesional.