Supongamos que desarrollo una biblioteca útil y decido publicarla como código abierto. Algún tiempo después, tengo una necesidad comercial de hacer algo que no cumpla con la licencia de código abierto. ¿Se me permite hacer eso?
¿Cómo debo publicar el software de una manera que mantenga la propiedad y no me impida usar la biblioteca en el futuro de ninguna manera?
Tenga en cuenta que, al menos en teoría, otros desarrolladores pueden decidir contribuir a mi proyecto de código abierto. ¿Puedo especificar en una licencia que yo, como desarrollador original, también obtenga la propiedad de sus contribuciones? No me malinterpreten aquí, no estoy tratando de ser malvado y obtener la propiedad del trabajo de los demás, solo quiero mantener la propiedad del mío, y si alguien publica una corrección de errores importante, podría ser incapaz de usar el código original a menos que Yo también uso su trabajo.
fuente
Respuestas:
Siempre mantiene la propiedad bajo licencias de código abierto. El trabajo que creó es de su propiedad, y puede hacer lo que quiera con él (dentro de los límites legales, por supuesto), incluso permitir que otras personas lo usen bajo los términos de una licencia de código abierto. Si desea usarlo para un proyecto propietario, puede hacerlo, a menos que haya cedido completamente los derechos de otra persona por contrato. Pero esto no es lo que hacen las licencias de código abierto. Se trata de compartir la utilidad, no de renunciar a la propiedad.
Las cosas se ponen un poco pegadas una vez que otras personas comienzan a contribuir. Es su trabajo, entonces, no el tuyo, y necesitas obtener su permiso. Una cosa que puede hacer es publicar su biblioteca con una licencia dual. Eso es lo que hace Sam Lantinga, el principal creador y mantenedor de SDL . Debido a que a Apple no le gustan las bibliotecas de enlaces dinámicos para iOS, y cumplir con la LGPL en una aplicación estáticamente vinculada es más problemático de lo que vale, publica SDL tanto bajo la licencia LGPL como comercial para aplicaciones estáticas de iPhone. Cuando alguien envía un parche, explícitamente les pide permiso para implementar su parche en la biblioteca con ambas licencias, y si no les gusta, no lo agrega a la base de código.
EDITAR: Mi ejemplo ya no es exacto. Hace un tiempo, Sam cambió el modelo (no estoy seguro de por qué; tal vez se cansó de las molestias de la administración) y ahora licencia SDL bajo una licencia de estilo zlib altamente permisiva. Pero solía hacerlo de esta manera.
fuente
No soy abogado y este no es un consejo legal. Si necesita seguridad jurídica, contrate a un abogado.
Absolutamente puede obtener una doble licencia de su software: Trolltech lo hizo durante muchos años con Qt y Linden Lab lo hizo con el cliente SecondLife.
Puede usar cualquier licencia que desee. Algunas licencias son compatibles con entornos comerciales cerrados, como las licencias Mozilla MPL, MIT y BSD, y (creo) las licencias CDDL y Apache de Sun.
Sin embargo, si necesita la flexibilidad para lanzar su software como un proyecto de código abierto y como un producto de código cerrado, está absolutamente autorizado a hacerlo como autor original. El único problema es el tema de las contribuciones de los usuarios. No puede incorporar las contribuciones de otros en su versión comercial del software a menos que legalmente le divulguen los derechos de autor. GNU hace esto por la única razón de que actualizarán sus licencias en el futuro.
Tenga en cuenta que a los usuarios y especialmente a los contribuyentes probablemente no les gustará esto, por lo que afectará a la comunidad en torno a su proyecto, probablemente de manera adversa.
Nuevamente, consulte a un abogado para obtener más detalles.
fuente
Yo tampoco soy abogado, pero ...
Además de las licencias restrictivas (que lo obligarán a Open Source a cada proyecto que las use) como GPL, también existen licencias no restrictivas (lo que significa que puede usar dicho software en un proyecto comercial) como Lesser GPL o Apache License (2.0 ?) Entonces, tal vez pueda simplemente lanzar su software bajo términos no restrictivos.
fuente