¿Existe algún término para el software propietario de código cuasi abierto?

Supongamos que una empresa quiere mantener el desarrollo de nuevas funciones de un software interno, pero quiere hacer público el código fuente de las versiones anteriores, incluidas las funciones públicas existentes, para que otras personas puedan beneficiarse del uso y la modificación del software. , e incluso posiblemente contribuir con cambios que se pueden aplicar a la rama de desarrollo.

¿Existe un término para este tipo de arreglo, y cuál es la mejor manera de lograrlo utilizando las herramientas y plataformas de control de versiones existentes?

No sé el nombre, pero para la implementación, la siguiente configuración podría funcionar:

Cree dos repositorios en github (reemplace con cualquier otra plataforma que haga lo mismo), una pública y otra privada. Mantenga la última versión X en una privada y vX-1 en una pública. Al lanzar una nueva versión, actualice una pública de una privada. De esta manera, podrá usar fácilmente el control de versiones y también permitirá que los usuarios de repositorios públicos le envíen sus contribuciones a través de solicitudes de extracción, y luego podrá fusionarlo con su repositorio privado, enviar problemas, etc. Esto también le dará el opciones para permitir que los usuarios pagos hagan lo mismo con su código privado: les da acceso de solo lectura o incluso de lectura y escritura.

Parece una fuente compartida, que es un término utilizado por Microsoft para describir la forma en que permiten a los clientes obtener una copia de su código fuente por razones como auditoría de seguridad o referencia. Microsoft retiene el control total de la base de código para nuevos desarrollos.

Las licencias asociadas con las ofertas varían desde ser de código cerrado, permitiendo solo ver el código como referencia, hasta permitir que sea modificado y redistribuido tanto para fines comerciales como no comerciales.

No sé de un término para esto.

Tal vez debería llamarse el modelo de puerta de granero con candado. En lugar de "cerrar la puerta del establo después de que el caballo se haya desbocado" (es decir, intentar recuperar la exclusividad después de lanzar el software bajo una licencia demasiado liberal), cierra la puerta del establo y espera que el caballo no muera de hambre en el establo. :-)

Sin embargo, en serio, si la gerencia de la compañía cree que esto es necesario para ganar dinero con el código abierto, no se puede discutir. Después de todo, son responsables de administrar la inversión de recursos que están haciendo.

Sin embargo, este no es un modelo que sea bueno para el cliente que paga. (Si el cliente no puede obtener el código fuente de la versión premium que está ejecutando, ¿de qué sirve pagar la prima?) No es probable que fomente las contribuciones de la comunidad de usuarios, y va a hacer esas contribuciones de menos valor ... porque siempre estarán en contra de una versión anterior de la base de código. De hecho, podría argumentar que es más probable que fomente la bifurcación.

Este patrón es bastante frecuente en la industria. Un ejemplo es cuando un producto está disponible como una edición comunitaria y una edición empresarial. Por lo general, la edición comunitaria está disponible sin costo e incluso puede ser un software gratuito / de código abierto y, por lo general, carece de algunas características comercializadas como solo necesarias para los usuarios empresariales. La edición empresarial generalmente está disponible comprando una licencia comercial y se puede incluir opcionalmente con un paquete de soporte, actualizaciones integradas de software, más funciones o condiciones de uso más permisivas. Este patrón puede verse en muchas formas y variaciones en el mercado. Un ejemplo es la plataforma Eclipse frente a los productos comerciales basados ​​en ella, como el cliente IBM Lotus. Otro ejemplo es el inicio de lo que ahora se conoce como Mozilla Firefox, que comenzó como Netscape Browser vs Mozilla Browser.

Otro enfoque es separar el producto en dos productos independientes por separado. Esto es adecuado para grandes proyectos que están compuestos por muchos subproyectos más pequeños. Un ejemplo es Fedora Linux vs Red Hat Enterprise Linux o OpenSuse vs Suse Linux Enterprise.

Creo que el término es de doble licencia . (o licencias múltiples )

La parte del proyecto que desea que la gente analice con usted se publica bajo, por ejemplo, la LGPL, que le permite llamar material patentado. El puerto del proyecto que desea mantener bajo su control es un software patentado para la venta.

Si todo el código es tuyo, puedes relicenciar como mejor te parezca. Si alguien más ha contribuido al código que desea cerrar, entonces DEBE obtener su permiso o hacer que le firmen los derechos de autor. En cuanto a un nombre, no sé de una licencia estándar, ¿quizás doble? Creo que MySQL está en la misma posición, ¿y quizás QT?