MIT vs. BSD vs. Licencia dual


87

Entiendo que:

  • Los proyectos con licencia MIT se pueden usar / redistribuir en proyectos con licencia BSD .
  • Los proyectos con licencia BSD se pueden usar / redistribuir en proyectos con licencia MIT.
  • Las licencias MIT y BSD de 2 cláusulas son esencialmente idénticas .
  • BSD 3-cláusula = BSD 2-cláusula + la cláusula de "no endoso"
  • La emisión de una licencia dual permite a los usuarios elegir entre esas licencias, no estar obligados a ambas.

Si todo lo anterior es correcto, ¿cuál es el punto de usar una licencia dual MIT / BSD? Incluso si el BSD se refiere a la versión de 3 cláusulas, ¿no puede un usuario elegir legalmente cumplir únicamente con la licencia MIT?

Parece que si realmente desea que se aplique la cláusula de "no endoso", entonces debe licenciarla solo como BSD (no dual). Si no le importa la cláusula de "no endoso", entonces MIT solo es suficiente y MIT / BSD es redundante.

Del mismo modo, dado que las licencias MIT y BSD son " compatibles con GPL " y se pueden redistribuir en proyectos con licencia GPL , entonces las licencias dobles MIT / GPL también parecen redundantes.


1
¿Puede proporcionar un ejemplo de licencias MIT + BSD? Por lo general, es redundante a la licencia dual bajo dos licencias permisivas similares, pero he visto que se abusa de la licencia dual como una forma de declarar explícitamente que el código podría redistribuirse bajo cada una de las licencias.
Yannis

@ Yannis Sí, me preguntaba si las personas tenían doble licencia para ser más explícitos para las personas que no saben. Pero creo que lo hace más confuso para ellos.
Ryan



1
En mi experiencia, la gente usa principalmente licencias dobles para licencias incompatibles. por ejemplo, MPL + (L) GPL o una licencia paga sin copyleft junto con (A) GPL.
CodesInChaos

Respuestas:


60

Entiendo que:

  1. Los proyectos con licencia MIT se pueden usar / redistribuir en proyectos con licencia BSD.
    VERDADERO (pero a menos que haya modificaciones, los usuarios también pueden obtenerlo de las fuentes originales.

  2. Los proyectos con licencia BSD se pueden usar / redistribuir en proyectos con licencia MIT.
    La licencia FALSE MIT permite la distribución sin créditos de contribución; BSD no lo hace.

  3. Las licencias MIT y BSD de 2 cláusulas son esencialmente idénticas.
    FALSO Ver arriba.

  4. BSD 3-cláusula = BSD 2-cláusula + la cláusula "no endoso"
    VERDADERO

  5. La emisión de una licencia dual permite a los usuarios elegir entre esas licencias, no estar obligados a ambas.
    VERDADERO (¡Creo que sí!)

Del mismo modo, dado que las licencias MIT y BSD son "compatibles con GPL" y pueden redistribuirse en proyectos con licencia GPL, entonces la licencia dual MIT / GPL también parece redundante.

NO . Aquí hay una gran diferencia. La licencia MIT y la licencia Apache solo requieren que otorgue crédito a los titulares de derechos de autor originales. Si elige, puede redistribuir la fuente; pero si elige puede conservar su nuevo producto derivado sin código de apertura. Por lo tanto, es posible usar código desarrollado bajo MIT y Apache, bajo licencia comercial.

Si alguna vez usa código con licencia basada en GPL y lo modifica, debe distribuir su código modificado también bajo GPL. En otras palabras, una vez que se utiliza cualquier base de código GPL en un proyecto, y si desea publicarlo como un producto, debe publicarse con el código fuente y debe publicarse bajo GPL. Nunca puede ser una licencia comercial o de código cerrado, y no puede ser ninguna otra licencia que sea menos estricta que GPL.

Es posible, por ejemplo, tomar el código de licencia MIT, Apache o BSD, modificado y distribuido bajo GPL. Una vez que una base de código se distribuye como GPL, sus versiones derivadas adicionales no se pueden distribuir bajo licencia MIT, Apache o BSD, sino que deben ser solo GPL.

Editar:
Ejemplo de caso de licencia dual: supongamos que Nice Office se lanza bajo licencia dual: MIT y GPL. Tiene dos posibilidades. Algunas personas pueden crear NicePro Office, que puede ser comercial y venderse. Mientras que otra comunidad de código abierto crea una bifurcación NiceOpen Office. En este caso, puede imponerse sobre la distribución de GPL (de la versión original de Nice Office y NiceOpen Office), por lo tanto, si comienza con NiceOpen Office, debe cumplir solo con GPL y no con la licencia MIT.

El caso es que, en caso de doble licencia, la primera persona que obtiene una licencia tiene una opción. Puede elegir de cualquier manera; sin embargo, la segunda persona debe adherirse a la elección que hizo la primera persona. Él / Ella no puede anular los derechos originales de ninguna generación y de ninguna manera puede reducir la obligación de la licencia aplicable.

EDITAR 2 Agregar una lectura interesante: las licencias GPL y MPL tienen serios conflictos. Lee esto. http://www.tomhull.com/ocston/docs/mozgpl.html


44
@Dipan Si un proyecto tiene doble licencia bajo MIT / GPL, entonces puede usarse en un proyecto patentado b / c, el usuario puede elegir seguir solo el MIT. Si un proyecto posee solo la licencia MIT, puede redistribuirse bajo otras licencias, incluida la GPL. Eso es lo que quise decir con redundante.
Ryan

11
@DipanMehta ¿Qué quiere decir con "créditos de contribución" en el n. ° 2? Parece que te refieres a la licencia BSD de 4 cláusulas, que no está verificada por la FSF como lo son las cláusulas 3 y 2. Estoy hablando de las cláusulas 3 y 2, en cuyo caso estoy bastante seguro de que las cinco afirmaciones son verdaderas .
Ryan

44
Puede usar el código con licencia BSD junto con el código con licencia MIT; solo tiene que mencionar en los materiales del proyecto que "BazApp usa libfoobar, que se distribuye bajo una licencia BSD" o algo así. Las licencias BSD y MIT se aplican en un nivel por archivo, en lugar de por proyecto.
mipadi

10
@Dipan_Mehta Como ryanve ya te dijo, estás hablando de la licencia BSD original de 4 cláusulas, mientras que el OP está hablando de las licencias BSD revisadas de 3 y 2 cláusulas. La licencia BSD de 2 cláusulas es en realidad equivalente a la licencia MIT. Incluso la página OSI lo dice.

17
El punto n. ° 2 (el código BSD no se puede incluir en el código MIT) es contrario a toda la información que he leído sobre BSD de 3 y 2 cláusulas. El punto # 2 sería cierto sobre el BSD de 4 cláusulas (ahora antiguo y olvidado), pero el OP ha dejado en claro que esta pregunta no se trata del BSD de 4 cláusulas. Parece bastante dañino tener una información tan enormemente engañosa en una respuesta muy buena y creíble.
apsillers

4

Tus cinco puntos son todos verdaderos .

La otra respuesta parece suponer que está incluyendo la licencia BSD de 4 cláusulas más antigua y raramente utilizada .

Si interpreta que las "licencias BSD" se refieren a las variantes de 3 o 2 cláusulas más comúnmente usadas de la licencia BSD, las cinco afirmaciones en la pregunta son verdaderas.

Si todo lo anterior es correcto, ¿cuál es el punto de usar una licencia dual MIT / BSD?

Técnicamente no debería ser necesario. Cualquiera de los dos puede usarse en las mismas situaciones.

Incluso si el BSD se refiere a la versión de 3 cláusulas, ¿no puede un usuario elegir legalmente cumplir únicamente con la licencia MIT?

Eso suena correcto

Parece que si realmente desea que se aplique la cláusula de "no endoso", entonces debe licenciarla solo como BSD (no dual). Si no le importa la cláusula de "no endoso", entonces MIT solo es suficiente y MIT / BSD es redundante.

Eso es correcto. Si le importa esa cláusula en particular, no tendría sentido también licenciar el mismo trabajo bajo licencias sin esa cláusula.

Del mismo modo, dado que las licencias MIT y BSD son "compatibles con GPL" y pueden redistribuirse en proyectos con licencia GPL, entonces la licencia dual MIT / GPL también parece redundante.

Si.

Sin embargo, a veces un producto de software afirmará tener doble licencia como MIT y GPL (o alguna licencia permisiva y GPL), pero en realidad se refieren a dos versiones diferentes del software.

Por ejemplo, algunos programas pueden compilarse y distribuirse con una licencia permisiva como BSD o MIT, pero si omite algunas bibliotecas y, por lo tanto, algunas funciones, puede distribuirse como GPL. Las bibliotecas omitidas generalmente serán bibliotecas de terceros que no son compatibles con la GPL pero que de otro modo podrían distribuirse.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.