Elige tu licencia
Si su código ha sido código cerrado hasta ahora, lo primero que debe hacer es decidir qué licencia de código abierto ( GPL < = 2, GPL 3 , LGPL , BSD , Eclipse etc.) que desee utilizar.
Hay puntos a favor y en contra de cada uno, así que lea qué restricciones aplican al código y decida quién quiere poder usarlo. Advertencia , cualquiera que sea la persona que elija, se quejará: este es guerra santa , y está fuera del alcance de esta pregunta.
- Un gran recurso para determinar qué licencia es la correcta para usted es el diferenciador de licencias muy completo e interactivo , de las Universidades de Oxford OSS Watch .
Desinfecte su repositorio
Si el código en su repositorio aún no tiene aplicada su licencia elegida, revisaría su historial de revisión completo hasta el momento y lo aplicaría de manera retroactiva (esto puede requerir una nueva base en cada punto donde una nueva fuente se introduce el archivo). Sin embargo, esto producirá un buen repositorio limpio que, cuando lo publique al público, no tiene revisiones donde la licencia elegida no esté vigente.
Otra opción es iniciar tu repositorio público en el momento de tu primer lanzamiento, con un historial mínimo o nulo hasta ese momento.
Esto tiene la desventaja de que las personas no pueden volver a tu historial y descubrir cómo llegaste a donde estás hoy, pero tiene la ventaja de que las personas No puedo volver a tu historia y descubrir cómo llegaste a donde estás hoy. * 8 ')
Cuando la empresa para la que trabajo creó el software con el que trabajaba en código abierto, comenzamos solo con la creación de instantáneas del directorio de trabajo en los puntos de lanzamiento. Cuando pasamos a usar repositorios públicos de github, comenzamos cada git repo en el punto en que un complemento (o conjunto de complementos se eliminó) de svn , rara vez incluye ningún historial.
Considera una licencia dual
Si cree que puede haber un interés comercial en usar su software, pero tiene una preferencia ideológica por una licencia de reutilización restrictiva como la GPL 3, considere la posibilidad de ofrecer una licencia dual. La oferta de licencias GPL 3 para descarga pública y las licencias comerciales por una tarifa le ofrecen lo mejor de ambos mundos.
Es probable que hacer esto desde el principio cause menos fricción que comenzar a ofrecer licencias comerciales más adelante. Si su comunidad se vuelve popular, las personas pueden acusarlo de liquidación si usted no se hubiera enterado de la posibilidad de una explotación comercial más adelante.
Considera un Acuerdo de Colaborador
Si alguna vez planea una licencia doble, o simplemente desea mantener su código base, deberá reimplementar las correcciones aportadas usted mismo o hacer que los colaboradores asignen derechos sobre sus contribuciones a usted. De lo contrario, encontrará que sus contribuciones le impiden liberar su código base bajo otras licencias.
La respuesta de Mason Wheeler a la pregunta ¿El código de licencia de código abierto me limita más tarde? proporciona buena información sobre esto y cómo se usó el proyecto libsdl para resolver este problema.
Sin embargo, tenga en cuenta que, al igual que su elección de licencia puede restringir a las personas y organizaciones que utilizarán y contribuirán a su proyecto, también lo hará la elección de tener un acuerdo de contribución. Algunas personas no estarán felices de contribuir a un proyecto que les obliga a firmar un acuerdo de contribución.
Acuerdos de Colaborador de doble licencia
El Acuerdo de Colaborador de Oracle (los enlaces son difíciles de ver en esa página) es una buena idea. Plantilla para un acuerdo de colaborador. También tiene licencia (CC) de manera que puede modificarlo y reutilizarlo.