クローズドソースへのコミュニティの貢献を伴うオープンソースプロジェクトを合法的かつ倫理的に受け入れることはできますか？[閉まっている]

オープンソースライセンスの下でプロジェクトを開始および開発し、コミュニティの貢献を受け入れたとします。プロジェクトを商用およびクローズドソース（または分割ライセンス）にすると決めた場合、私はどの程度根拠がありますか？

この質問は、少なくとも倫理に関する限り、地域貢献のあるプロジェクトの問題を直接扱っていません。貢献が私の著作権に該当するかどうか、または貢献者が彼が追加したプロジェクトの一部の著作権を保持しているかどうかわからないので、法的に、これも同様に不確かかもしれません。

プロジェクトを将来商業化する可能性を事前に把握している限り、（倫理的および法的に）安全ですか？

一般に、コミュニティの貢献者は、プロジェクトに貢献したコードの著作権を保持します。彼らは、コードを提供するときにあなたに貢献を許可します。将来的にライセンス条件を変更する可能性を保持したい場合は、通常、貢献者が自分の著作権をあなたに割り当てる必要があります（個人またはこのプロジェクトの著作権を所有するために作成した法人）新しいライセンス条項と互換性があるようにします。もちろん、コミュニティからの貢献を受け入れる前にこの種の著作権の割り当て書類が必要な場合、コミュニティが貢献することを決定する可能性ははるかに低く、法的フォームを取得するためにかなりの量の作業を行う必要があります各貢献を受け入れる前に順番に。プラス、ライセンス条項の変更を決定した場合、プロジェクトが分岐する可能性が高くなります。そのような状況下では、新しいオープンソースプロジェクトがコミュニティから多くの貢献を得る可能性は低いと思います。

通常、最初に分割ライセンス条項に基づいて製品のライセンスを取得した場合、または最初のライセンス条項が将来のクローズドソース製品と互換性がある場合は、一般的に簡単です。たとえば、BSDライセンスの下にあるコードは、いつでも商用製品に組み込むことができるため、プロジェクトとコントリビューションがBSDライセンスの下にあれば、同じ製品の商用バージョンを簡単にリリースできます。ただし、商用製品を作成するというあなたの意図（またはオプション）は、プロジェクトへの貢献への関心を低下させる可能性があります。ほとんどのオープンソース開発者は、商用製品への無給の貢献に関心がありません。

もちろん、法的問題と同様に、何らかの決定的な行動をとる前にフォーラムの投稿に頼るのではなく、弁護士と話したいと思うでしょう。ほぼ確実に、その弁護士に、人々に署名してもらう必要のある著作権譲渡文書を起草することを望み、すべてが正しく設定されるように、弁護士と将来の計画について話し合う必要があります。

プロジェクトがより寛容なライセンスのいずれかでライセンスされている場合（BSD、MIT、Boost、またはApacheがこれを許可していることを知っています）、合法的にあなたはオブジェクトコードを配布することができ、あなたが行った変更を提供する必要はありませんソースコードをコミュニティに戻します。別のライセンスの下で派生物のライセンスを取得することもできます。ライセンス要件に従ってライセンステキストを含める必要があることに注意してください。

これが倫理的であるかどうかは、非常に物議を醸すものです。開発者がこれらのより寛容なライセンスのいずれかでコードのライセンスを取得した場合、開発者はソフトウェアをオープンソースプロジェクトと商用プロジェクトの両方で使用したいと考える傾向があります。もし彼らが自分のコードを商用利用したくないなら、彼らはGPLv3の下でそれをライセンスするべきだった。

私があなたのプロジェクトに行った貢献は、他の人に割り当てない限り、私の著作権のままです。著作権者になるということは、自分の作品がどのライセンスの下で利用可能かを判断できるということです。

そのため、ライセンスは関連していますが、別の問題です。私があなたのプロジェクトに貢献する場合、プロジェクトライセンス（または互換性のあるライセンス）の下で作品をリリースすることに同意する必要があります。

多くのオープンソースライセンスでは、後で派生ソースを閉じることはできませんが、一部は許可します。私が正しく理解していれば、現在の（開いている）コードベースを閉じることはできません。したがって、これも考慮する必要があります。

そのため、将来の開発を終了できるライセンスから始めるか、すべての貢献者とその効果について合意する必要があります。重要な貢献がある前に後者を弁護士と一緒に取り上げ、あなたがやろうとしていることについて非常に前もって対応するのが最善です。

プロジェクトのライセンスを変更する場合は、すべての貢献者に「貢献者契約」への署名を要求するか、すべての貢献者の許可を要求する必要があります。

これは非常に難しく、Linuxカーネルがまだgpl v2の下にある理由

大部分のOSプロジェクトには、Enterpriseバージョンのような商用アームが付属しているようです。基本的に、SLA、サポートなどを提供します。プロジェクトがオープンソースである場合、基本的には単に閉じることはできないと思います。将来のバージョンをクローズドソースにして名前を変更したり、アドオンをクローズドソースにすることができますが、実際のプロジェクトはオープンソースのままにしておく必要があります。しかし、企業はより良い方法だと思いますが、あなたはまだオープンソースの利益を享受し、収益を上げることができます。
好奇心から、なぜプロジェクトのソースをクローズしたいのですか？

法的には、十分にオープンなライセンスを使用して、関係者がそれを商業化できる場合、私も想像できます（弁護士ではありません）。

倫理的に、あなたはより強い義務を負うことになります。計画が変更されたとき、最初と時間の両方で、あなたの意図について非常にオープンで明確でなければなりません。

また、Redhatに似たモデルを採用することもできます。クローズドソースのプラグインを構築しますが、コアはオープンソースのままにします。これにより、オープンソースコミュニティに利益をもたらす製品のコミュニティサポートが引き続き得られるため、イノベーションの向上にもつながります。トレーニング、コンサルティング、およびサポートを提供することも、取引を甘くすることができます。