このシナリオは、法的形式と違法形式の両方で発生する可能性があることに注意することが重要です。
これは、会社がコードに関連付けられている著作権を所有している、またはアクセスできる場合、合法的に発生する可能性があります。たとえば、小規模の独立した開発チームは、大企業に著作権を販売またはライセンス供与することができます。同様に、コードの著作権の大部分を取得できる場合、「達成できない」部分は単に破棄され、書き換えられる可能性があります。
コインの反対側では、コードは単に違法に取られる可能性があります。New Corp、Inc.は、法的な影響を気にしません。プロジェクトが古すぎるか放棄されているか、New Corpが訴訟で勝つと考えています。または、New Corpは、この種の「買収」が単に違法と定義されていない地域に登録されている可能性があります。すべてのOSSライセンスが強制可能であるわけではありません。特に、法律の非専門家によってまとめられたものはそうではありません。すべてのプロジェクトオーナーが著作権の申し立てを実施できるわけではなく、FSFなどの大規模な組織がその申し立ての管轄権を持たない場合があります。TL; DR-このエリアは、かすみ、andいものになります。
移行と予防
移行はどのように行われ、異なるライセンスを選択する以外にそれを防ぐために何ができますか？
移行は、New Corp、Inc.がコードベースを取得し、そのコピーを管理下に置いたときに発生します。新社の開発者は、その後の作業を開始し、その企業の君主が必要命じているものは何でも変更するコードベース作りのバージョン。このフォークの実際の仕組みは、リポジトリによって異なります。そして、それは哲学的には大したことですが、実際にはかなり圧倒的です。 get allOpenReposからPrivateRepos checkinへ。
ソースを決して配布しないようにするにはどうすればよいですか？なし。ごめんなさい。
GPL（GNUパブリックライセンス）を例として使用してみましょう。GPLでは、プロジェクトの合法的なコピーを受け取るすべての人がソースを利用できるようにする必要があります。ソースの所有者が、GPLが適用されたアプリケーションのコピーの正当な所有者へのソースの配信を拒否することを許可する規定はありません。それはフリーソフトウェアの粒度に反するので、GPLコピーレフトが配置されているのはそのためです。
潜在的に、追求する事後の法的措置があります。しかし、それらはすべて、ソースが脱出して分岐した後のことであり、前ではありません。また、一部の管轄区域では、法的手段はありません。そして、これらはすべて、フォークが発生したことを認識していることを前提としています。あなたは決して見つけないかもしれません。
倫理
会社の（倫理的または社会的）責任は何ですか？（例：オープンソースプロジェクトに戻ることは倫理的なことです）
倫理は文化にとってローカルです。このセクションを塩の粒で和らげてください。倫理に関する文化的考慮の完全な議論は、この答えの範囲を超えており、プログラマーにとってはトピック外です。
私は、プログラミングコミュニティが敵対的なフォークに否定的に反応する傾向があることに気付きました。ヘック、場合によっては、同じコミュニティが友好的かつ合法的な分岐に対して依然として否定的に反応することがあります。とても複雑なコミュニティです。
FOSSの観点から見ると、New Corpは、分岐した貢献に対してコミュニティに「返済」することを期待しています。その返済の条件、条件、期間は、存在するOSSプロジェクトの数と同じくらい多様です。コミュニティの一部（リチャードストールマンを考えてください）は、オープンプロジェクトが終了することに決して満足しません。他の人々は、コミュニティ全体に提供される利益を探し、それに基づいて判断します。また、他の人は、元のプロジェクトを知らなかったり、気にしたりしないので、単に気にしません。
ソースの可用性
オープンソースバージョンとクローズドソースバージョンの両方が利用可能な場合、競合はどの製品に影響しますか？
それは、機能、パフォーマンス、および安定性に関して、2つのコードベースがどれだけ匹敵するかに大きく依存しています。
コードベースが類似したままで、New CorpがOSSコミュニティに友好的である場合、それらはベースプロジェクトに更新を提供する可能性があります。この場合、誰もが恩恵を受けます。この場合の「競争」ではなく、相互に有益なコラボレーションです。
コードベースが大幅に分岐し、New CorpがOSSコミュニティに友好的でない場合、競合はまだありません。機能が豊富な製品は存続し、機能が少ない製品は消滅する傾向があります。これはどちらの方法でも実行できることに注意してください。オープンソースバージョンが引き続き革新を続けるか、コミュニティのニーズを満たしている場合、クローズバージョンは終了する可能性があります。
現実は、これらのスペクトルの両端の間のどこかになります。
例
Red Hatには、Enterprise LinuxとFedoraの2つの主要なディストリビューションがあります。ELは「クローズド」ライセンスバージョンであり、Fedoraはコミュニティエディションです。GPLにより、すべてではないとしても多くのELエディションがソース形式でリリースされます。Red Hatと提携していないCentOSと呼ばれる別のプロジェクトは、ELへの変更をピックアップし、マイナーなブランド変更後にそのプロジェクトを配布します。
Red Hatが2つの別々のエディションに分岐したときに不満がありましたが、概して、それはかなり実行可能な合意でした。Fedoraコミュニティは、Red Hatのエンタープライズ顧客が満足しているよりも早く機能をディストリビューションに展開したいと考えていました。コードベースの機能強化は両方向に流れます。