Il est important de noter que ce scénario peut se produire sous des formes légales et illégales.
Cela peut se produire légalement si l'entreprise détient ou a accès au droit d'auteur associé au code. Par exemple, des équipes de développement plus petites et indépendantes peuvent souhaiter vendre ou concéder sous licence leurs droits d'auteur à une plus grande entreprise. De même, si la majeure partie du droit d'auteur du code peut être acquise, la partie "inaccessible" peut simplement être jetée et réécrite.
De l'autre côté de la médaille, le code peut simplement être pris illégalement. New Corp, Inc. peut ne pas se soucier des ramifications légales. Le projet peut être trop ancien ou abandonné ou New Corp pense qu'ils gagneront dans un procès. Ou New Corp peut être enregistré dans une zone où ce type d '"acquisition" n'est tout simplement pas défini comme illégal. Toutes les licences OSS ne sont pas exécutoires, en particulier celles qui ont été concoctées par des non-experts en droit. Tous les propriétaires de projets peuvent ne pas être en mesure de faire valoir leurs droits d'auteur, et des organisations plus importantes telles que la FSF peuvent ne pas avoir qualité pour agir dans cette juridiction. TL; DR - cette zone peut devenir trouble et laide très rapidement.
Transition et prévention
Comment se déroule la transition et que peut-on faire pour l'empêcher au-delà du choix d'une licence différente?
La transition se produit lorsque New Corp, Inc. acquiert la base de code et place cette copie sous leur contrôle. Les développeurs de New Corp commencent alors à travailler sur leur version de la base de code en apportant les modifications que les suzerains d'entreprise ont jugées nécessaires. La mécanique réelle de cette fourchette variera en fonction du référentiel. Et même si c'est un gros problème philosophique, c'est vraiment assez décevant dans la pratique. get alldepuis OpenRepos puis checkinvers PrivateRepos.
Que peut-on faire pour l'empêcher de ne jamais distribuer la source? Rien. Pardon.
Prenons la GPL (licence publique GNU) comme exemple. GPL exige que la source soit disponible pour toute personne recevant une copie légitime du projet. Il n'y a pas de dispositions qui permettent au titulaire de la source de refuser la livraison de la source à un détenteur légitime d'une copie de la demande sous licence GPL. Cela va à l'encontre du logiciel libre, et c'est pourquoi le copyleft GPL est en place.
Potentiellement, vous avez des mesures juridiques à suivre après le fait. Mais ce n'est que lorsque la source s'est échappée et a été bifurquée, pas avant. Et dans certaines juridictions, vous n'aurez aucun recours juridique. Et tout cela suppose que vous êtes même conscient que la fourchette s'est produite. Vous ne le saurez peut-être jamais.
Éthique
Quelles sont les responsabilités (éthiques ou sociales) de l'entreprise? (Par exemple: redonner au projet open source serait la chose éthique à faire)
L'éthique est locale à la culture. Alors tempérez cette section avec ce grain de sel. Une discussion complète de la considération culturelle de l'éthique dépasse la portée de cette réponse et hors sujet pour les programmeurs.
J'ai remarqué que la communauté de programmation a tendance à réagir négativement à une fourchette hostile. Heck, dans certains cas, la même communauté réagit toujours négativement à une fourchette amicale et légale. C'est une communauté assez complexe.
Du point de vue du SSOBL, on s'attend à ce que New Corp «rembourse» la communauté pour la contribution qu'elle a apportée. Les termes, conditions et durée de ce remboursement sont aussi variés que le nombre de projets OSS existants. Certains membres de la communauté (pensez à Richard Stallman) ne se contenteront jamais qu'un projet ouvert soit fermé. D'autres chercheront les avantages offerts à la communauté dans son ensemble et jugeront en fonction de cela. Et d'autres ne s'en soucient tout simplement pas parce qu'ils n'ont jamais connu le projet d'origine ni s'en sont souciés.
Disponibilité de la source
Si la version open source et la version open source sont toutes deux disponibles, comment la concurrence affecte-t-elle l'un ou l'autre produit?
Cela dépend vraiment de la comparabilité des deux bases de code en termes de fonctionnalité, de performances et de stabilité.
Si les bases de code restent similaires et que New Corp est convivial avec la communauté OSS, ils peuvent contribuer leurs mises à jour dans le projet de base. Dans ce cas, tout le monde en profite. Ce n'est pas une «compétition» dans ce cas, mais plutôt une collaboration mutuellement bénéfique.
Si les bases de code divergent énormément et que New Corp n'est pas favorable à la communauté OSS, il n'y a toujours pas de concurrence. Le produit le plus riche en fonctionnalités survit et le produit le moins riche a tendance à mourir. Notez que cela peut aller dans les deux sens - la version fermée pourrait mourir si la version open source continue d'innover ou de mieux répondre aux besoins de la communauté.
La réalité se situera quelque part entre ces deux extrémités du spectre.
Exemple
Red Hat a deux distributions principales - Enterprise Linux et Fedora. EL est leur version sous licence "fermée" et Fedora est leur édition communautaire. En raison de la GPL, une grande partie, sinon la totalité, de l'édition EL est publiée sous forme de source. Un autre projet non affilié à Red Hat appelé CentOS reprend les modifications apportées à EL et distribue ce projet après un changement de marque mineur.
Il y a eu quelques grognements lorsque Red Hat a débouché sur deux éditions distinctes, mais dans l'ensemble, cela a été un accord assez viable. La communauté Fedora voulait que les fonctionnalités soient intégrées dans la distribution plus rapidement que ce à quoi les clients d'entreprise de Red Hat étaient à l'aise. Les améliorations apportées aux bases de code vont dans les deux sens.