¿Cuál es la mejor manera de proporcionar versiones de código abierto y cerrado de forma segura?

Mi empresa está buscando desarrollar y lanzar un proyecto de software de código abierto junto con una versión mejorada patentada, similar a VirtualBox anterior a la 4.0.

¿Cuál es la mejor manera de mantener las dos bases de código de modo que los cambios en la versión de código abierto se puedan incorporar fácilmente a la versión comercial con un riesgo mínimo de introducir accidentalmente código propietario en el producto de código abierto?

open-source proprietary version-control

— rkjnsn
fuente

Respuestas:

Yo crearía 2 proyectos.

Proyecto OSS que puede ejecutarse de forma independiente.
Código de propiedad que depende del código del proyecto OSS.

Puede hacer que la dependencia sea una dependencia de tiempo de compilación o de ejecución. Si desea que cada paquete sea independiente, puede hacer que el paquete propietario extraiga los archivos OSS que necesita durante la creación / creación del paquete. Si está bien con una dependencia de tiempo de ejecución, puede empaquetar solo el código propietario y hacer que dependa del paquete OSS en tiempo de ejecución.

Beneficios:

Lo libera de duplicar código.
Obtenga correcciones de errores en ambos por el costo de obtenerlo en uno.
Delimitación clara entre OSS y Propietario.

— dietbuddha
fuente

+2: Si es posible, cree los complementos de funciones propietarias. La experiencia de las personas con la versión OSS les abrirá el apetito y podrán comprar / instalar directamente las nuevas funciones mientras ejecutan la aplicación. Incluso puede configurarlo para que cada complemento propietario tenga un período de prueba de X días. Esto no solo resuelve su problema de administración de la base de código, sino que facilita el marketing.

— Peter Rowell

Control de fuente y ramificación

La raíz sería el código común a ambas distribuciones. También (presumiblemente) crearía dos ramas desde su raíz:

Open Source

Closed Source

Open Sourceprobablemente reflejaría su raíz en este escenario. De forma regular, se fusionaría Open Sourcey Closed Sourcea mano ( Closed Sourceprobablemente no obtendría tantas actualizaciones).

De esta manera, puede mantener las mejoras en su Closed Sourcesucursal y obtener nuevos cambios de la versión de código abierto.

— Craige
fuente

¿Hay alguna manera de hacer esto usando repositorios separados? Esperamos tener el repositorio que contiene el código fuente abierto visible públicamente.

— rkjnsn

Depende de la licencia de código abierto que no se menciona en la pregunta. GPL da la mayoría de los problemas a este respecto y cualquier enlace estático o enlace de tiempo de ejecución es sospechoso.

Lea las preguntas frecuentes para obtener los mejores resultados; No confíes en otras respuestas. El uso de complementos no es realmente legítimo. Muchos productos comerciales violan la GPL de diferentes maneras y básicamente miran para otro lado.

http://www.gnu.org/licenses/gpl-faq.html

Si un programa lanzado bajo la GPL usa complementos, ¿cuáles son los requisitos para las licencias de un complemento? Depende de cómo el programa invoca sus complementos. Si el programa usa fork y exec para invocar complementos, entonces los complementos son programas separados, por lo que la licencia del programa principal no los exige.

Si el programa vincula dinámicamente los complementos, y realizan llamadas de función entre sí y comparten estructuras de datos, creemos que forman un solo programa, que debe tratarse como una extensión tanto del programa principal como de los complementos. Esto significa que los complementos deben publicarse bajo la GPL o una licencia de software libre compatible con GPL, y que los términos de la GPL deben seguirse cuando se distribuyen dichos complementos.

Si el programa vincula dinámicamente los complementos, pero la comunicación entre ellos se limita a invocar la función 'principal' del complemento con algunas opciones y esperar a que regrese, ese es un caso límite.

— Jonathan Cline IEEE
fuente

Si tiene los derechos de autor del software GPL, puede distribuir los complementos de código cerrado usted mismo: el titular original de los derechos de autor es quien establece las reglas de la licencia y ciertamente no está sujeto a la licencia. Por otro lado, significa que 1) no puede aceptar contribuciones de GPL sin requerir una asignación de derechos de autor, y 2) que otros no pueden distribuir los complementos con el software GPL.

— han

¿Por qué confiarías en las preguntas frecuentes sobre otras fuentes? Proviene de quizás la fuente más sesgada concebible. Y si coloco mi trabajo bajo la GPL, no importa si la FSF dice la GPL dice que puede hacer X. Si la ley y la licencia dicen que no se puede, que todavía puede demandar y todavía me va a ganar.

— David Schwartz

"¿Por qué confiarías en las preguntas frecuentes sobre otras fuentes?" Debido a que las preguntas frecuentes se basan en casos anteriores del mundo real, no en la hipótesis del sillón de los escritores de blogs de intercambio de fichas cuyas reputaciones técnicas solo son visibles principalmente por puntos otorgados por popularidad en lugar de por corrección.

— Jonathan Cline IEEE

Todavía no hemos elegido una licencia para la versión de código abierto. Tenemos los derechos de autor en todo el código, por lo que liberarlo bajo dos licencias separadas no debería ser un problema.

— rkjnsn

Si no ha elegido una licencia, es mucho mejor que use una licencia basada en BSD en lugar de una viral (viral = que significa basada en GPL). Muchos productos utilizan con éxito netbsd integrado en un producto de servidor con código propietario (las partes de valor agregado) directamente integradas en el árbol. Aunque, como lo indica otro autor, puede liberar usando una licencia dual ... aunque eso puede ser confuso para ventas y ventas. Quizás un ejemplo exitoso de referencia sea Apple Darwin ("Licencia de fuente pública de Apple", ahora licencia Apache): en.wikipedia.org/wiki/Darwin_(operating_system)#License

— Jonathan Cline IEEE