Es importante tener en cuenta que este escenario puede ocurrir tanto en forma legal como ilegal.
Esto puede ocurrir legalmente si la empresa posee o tiene acceso a los derechos de autor asociados con el código. Por ejemplo, equipos de desarrollo independientes más pequeños pueden desear vender o licenciar sus derechos de autor a una empresa más grande. Del mismo modo, si se puede adquirir la mayor parte de los derechos de autor del código, la parte "inalcanzable" simplemente puede desecharse y reescribirse.
En el otro lado de la moneda, el código simplemente puede tomarse ilegalmente. New Corp, Inc. puede no importarle cuáles son las ramificaciones legales. El proyecto puede ser demasiado viejo o abandonado o New Corp cree que ganarán en una demanda. O New Corp puede estar registrado en un área donde este tipo de "adquisición" simplemente no se define como ilegal. No todas las licencias de OSS son exigibles, especialmente las que no fueron expertas en la ley. No todos los propietarios de proyectos pueden tener la capacidad de hacer cumplir sus reclamos de derechos de autor, y las organizaciones más grandes como la FSF pueden no tener legitimación en esa jurisdicción para ese reclamo. TL; DR: esta área puede volverse nebulosa y fea muy rápido.
Transición y prevención
¿Cómo sucede la transición y qué se puede hacer para evitarla más allá de elegir una licencia diferente?
La transición ocurre cuando New Corp, Inc. adquiere la base del código y coloca esa copia bajo su control. Los desarrolladores de New Corp luego comienzan a trabajar en su versión de la base de código haciendo cualquier cambio que los señores corporativos hayan decretado necesario. La mecánica real de esta bifurcación variará según el repositorio. Y si bien es un gran problema filosófico, en la práctica es bastante decepcionante. get alldesde OpenRepos y luego checkina PrivateRepos.
¿Qué se puede hacer para evitar que nunca se distribuya la fuente? Nada. Lo siento.
Usemos GPL (licencia pública GNU) como ejemplo. GPL requiere que la fuente esté disponible para cualquier persona que reciba una copia legítima del proyecto. Hay no hay disposiciones que permiten al titular de la fuente a denegar la entrega de la fuente a un titular legítimo de una copia de la aplicación GPL. Va contra la corriente del software libre, y es por eso que el copyleft de GPL está en su lugar.
Potencialmente, usted tiene que seguir cursos legales de acción después de los hechos. Pero todo eso es después de que la fuente haya escapado y se haya bifurcado, no antes. Y en algunas jurisdicciones no tendrá ningún recurso legal. Y todo esto supone que incluso eres consciente de que ocurrió la bifurcación. Puede que nunca lo descubras.
Ética
¿Cuáles son las responsabilidades (éticas o sociales) de la empresa? (Por ejemplo: Devolver al proyecto de código abierto sería lo ético)
La ética es local a la cultura. Así que templa esta sección con ese grano de sal. Una discusión completa de la consideración cultural de la ética está más allá del alcance de esta respuesta y fuera del tema para los programadores.
He notado que la comunidad de programación tiende a reaccionar negativamente a una bifurcación hostil. Diablos, en algunos casos la misma comunidad aún reacciona negativamente a una bifurcación amistosa y legal. Es una comunidad bastante compleja.
Desde una perspectiva de software libre, existe la expectativa de que New Corp "pagará" a la comunidad por la contribución que bifurcó. Los términos, condiciones y duración de ese reembolso son tan variados como el número de proyectos OSS existentes. Algunos en la comunidad (piense en Richard Stallman) nunca se contentarán con que un proyecto abierto se cierre. Otros buscarán el beneficio proporcionado a la comunidad en general y juzgarán en base a eso. Y a otros simplemente no les importará porque nunca supieron o se preocuparon por el proyecto de origen.
Disponibilidad de fuente
Si la versión de código abierto y la versión de código cerrado están disponibles, ¿cómo afecta la competencia a cualquiera de los productos?
Realmente depende de cuán comparables sean las dos bases de código con respecto a la funcionalidad, el rendimiento y la estabilidad.
Si las bases del código siguen siendo similares y New Corp es amigable con la comunidad OSS, pueden contribuir con sus actualizaciones nuevamente en el proyecto base. En este caso, todos se benefician. No es una "competencia" en este caso, sino más bien una colaboración mutuamente beneficiosa.
Si las bases del código divergen y New Corp no es amigable con la comunidad OSS, entonces todavía no hay competencia. El producto más rico en características sobrevive y el producto menos rico tiende a desaparecer. Tenga en cuenta que esto puede ir en cualquier dirección: la versión cerrada podría desaparecer si la versión de código abierto continúa innovando o satisface mejor las necesidades de la comunidad.
La realidad estará en algún lugar entre esos dos extremos del espectro.
Ejemplo
Red Hat tiene dos distribuciones principales: Enterprise Linux y Fedora. EL es su versión con licencia "cerrada" y Fedora es su edición comunitaria. Debido a la GPL, gran parte, si no toda, de la edición EL se lanza en forma de fuente. Otro proyecto no afiliado a Red Hat llamado CentOS recoge los cambios en EL y lo distribuye después de un cambio de marca menor.
Hubo algunas quejas cuando Red Hat se bifurcó en dos ediciones separadas, pero en general, ha sido un acuerdo bastante viable. La comunidad de Fedora quería que las funciones se integraran en la distribución más rápido de lo que los clientes empresariales de Red Hat se sentían cómodos. Las mejoras en las bases del código fluyen en ambas direcciones.