Elegir una licencia para proyectos de código abierto

He realizado algunos proyectos de código abierto y planeo hacer más en el futuro. Hasta ahora, he publicado todo mi código bajo GPL, pero he leído algunos artículos que afirman que GPL es demasiado restrictivo para que cualquier código pueda usarse en un entorno corporativo. Esto, supuestamente, reduce las contribuciones.

Esto es lo que quería lograr:

Para aplicaciones completas :

• sin uso comercial con la excepción de vender soporte para la aplicación (es decir, la aplicación no se puede vender, pero todo lo que la rodea sí)

Para bibliotecas (componentes, complementos, ...):

• se puede incluir en proyectos comerciales sin modificaciones
• cualquier modificación de la biblioteca / componente debe ser de código abierto (contribuido de nuevo): el resto del proyecto, comercial o no, no se ve afectado

Para las aplicaciones, GPL todavía parece la opción lógica. Para las bibliotecas, mi comprensión primitiva de las licencias me hace pensar que LGPL es una buena combinación, pero no estoy seguro. He mirado la licencia MIT, y eso parece demasiado permisivo.

La mayoría de las veces, quiero que las personas usen mi código en cualquier lugar que deseen, siempre que se aporten las mejoras.

Esto me lleva a mi pregunta (s): ¿LGPL es una opción lógica para bibliotecas de código abierto, componentes, complementos, etc.? ¿Hay una mejor alternativa? ¿Es GPL una buena opción para mis aplicaciones o hay algo mejor?

Actualizar:

Para aquellos que estén interesados ​​en mi decisión final, he decidido lanzar mis bibliotecas bajo el esquema de múltiples licencias, MPL, LGPL y GPL. Esto permite que prácticamente todos usen mi código sin obligaciones, a menos que lo modifiquen bajo MPL, en cuyo caso tendría que ser devuelto.

Esto significa que el código puede ser utilizado tanto por FSF como por software privativo, pero se evita la explotación comercial "mala" (o eso me gustaría pensar).

Me parece que GPL y LGPL son lo que quieres para tus proyectos.

• sin uso comercial con la excepción de vender soporte para la aplicación (es decir, la aplicación no se puede vender, pero todo lo que la rodea sí)

Tenga en cuenta que la GPL no prohíbe vender la aplicación, y prohibir esto de hecho haría que su licencia no sea gratuita, como lo observó Huperniketes. Lo único que garantiza la GPL es que la empresa que vende el software también tendría que proporcionar la base de código de forma gratuita. Pero no tienen que proporcionar el paquete de software tal cual es gratis. Esa es una gran diferencia, ya que el código fuente de un software no es un producto fácilmente utilizable.

Si desea evitar el uso comercial de su software, GPL no lo cortará. Las empresas comerciales tienden a evitar la GPL en los productos que venden debido al requisito de redistribuir la fuente modificada, pero son libres de usar el software GPL internamente. Eso no quiere decir que las empresas no estén configuradas para vender software GPL o construir hardware alrededor del software GPL (LinkSys, por ejemplo), pero la mayoría de las empresas preferirían no compartir su producto con sus competidores.

No sé si la licencia Creative Commons Attribution Non-Commercial No Derivatives es lo que desea (la única restricción que mencionó es el uso comercial ), pero si no, es posible que necesite un abogado preparado para usted que contenga el idioma que otorga los derechos que desea que tengan los titulares de licencias.

Además, una vez que comience a incluir restricciones tales como el uso no comercial y la no modificabilidad , es posible que ya no cumpla con los criterios para una licencia de código abierto según lo define la Open Source Initiative . Su sitio también enumera otras licencias OSS aprobadas . Quizás ya haya uno que coincida con tus objetivos.

Y definir adecuadamente sus objetivos será clave antes de seleccionar los derechos y limitaciones que impone a los usuarios de su software. ¿Es la popularidad más importante que la modificabilidad o distribución o uso o ...? Para empezar, piense en sus objetivos al lanzar el código, y con qué espíritu lo hace o los términos bajo los cuales otorga acceso pueden tener el efecto contrario.

Si lo que le interesa es asegurarse de que su código permanezca libre, recuperar mejoras y asegurarse de que cualquiera pueda usarlo, entonces MPL es la licencia adecuada para usted. Es de uso gratuito en cualquier producto, incluido el software comercial, sin restricciones extrañas de enlaces arcanos como lo impone la LGPL. Requiere que cualquiera que use su código y lo modifique libere los cambios bajo MPL, pero no toca ni restringe el resto del código en el proyecto.

Si escribió todo su código (es decir, si es el propietario de su código), también puede obtener una doble licencia : publique su código en, por ejemplo, GPLv3 y ofrezca venderlo (con otra licencia) a aquellos que quieran usarlo de manera menos restrictiva.

(Esto es particularmente relevante para una biblioteca, porque una biblioteca GPL-ed solo puede usarse en el software GPL).

Tenga cuidado con las contribuciones o parches externos que incorpore a su código (ya que no los posee).

Si realmente puede solicitar MPL o solo GPL depende de una diferencia crítica:

Los "derechos en virtud del presente" incluyen el derecho otorgado a los destinatarios para vincular el "Código cubierto" MPL con el código privado que no es MPL para formar un "Trabajo más grande" (MPL 3.7 Obras más grandes). GPL no otorga a los destinatarios ningún derecho de este tipo. Por lo tanto, el destinatario no puede cambiar los términos de licencia para aplicar la GPL en lugar de MPL.

Mira esto .

Lo que esto significa para usted es que si está utilizando algún componente que en sí mismo tiene GPL, usted (probablemente) no puede liberar el código (que está utilizando esto) en MPL; MPL intentará erróneamente redistribuir el código GPL bajo MPL, lo cual es incorrecto. Esto está bien, si sus dependencias están en el orden de la licencia MIT o Apache.

En general, si usted está no haciendo nada mejor eligiendo MPL sobre GPL solo a menos que ya se está utilizando material MPL. GPL también se asegurará de que las contribuciones se vuelvan a publicar también.

Solo hay un cambio crítico que MPL proporciona es la protección contra las infracciones de patentes inducidas sin saberlo. Como dice la licencia:

No está bien que alguien cree una Modificación para la cual tiene una patente, haga que la Modificación esté disponible de forma gratuita según lo requerido por la Licencia, y luego regrese e intente cobrar a todos por los derechos de patente.

MPL y GPL no son del todo compatibles.

Puede ver aquí: MIT vs. BSD vs. Licencia Dual para una discusión sobre la implicación de las licencias duales.

Nadie parece hablar de ellos, pero podría considerar una licencia Creative Commons. Tienen una gama de licencias (o una que usted adapta a sus necesidades, visto de otra manera).