オープンソースプロジェクトのライセンスを選択する

私はいくつかのオープンソースプロジェクトを行ってきましたが、将来さらに多くのことをする予定です。これまで、すべてのコードをGPLでリリースしましたが、GPLは企業環境で使用するコードには制限が強すぎると主張する記事をいくつか読みました。これは、おそらく、貢献を減らします。

私が達成したかったのは次のとおりです。

以下のための完全なアプリケーション：

• アプリケーションのサポートを販売する以外の商用利用はできません（つまり、アプリを販売することはできませんが、周辺のすべては販売できます）

以下のためのライブラリ（コンポーネント、プラグイン、...）：

• 変更せずに商用プロジェクトに含めることができます
• ライブラリ/コンポーネントの変更はオープンソースでなければなりません（貢献します）-プロジェクトの残りの部分、商用かどうかは影響を受けません

アプリケーションにとって、GPLは依然として論理的な選択のようです。図書館については、ライセンスに関する私の原始的な理解から、LGPLはぴったりだと思うようになりますが、よくわかりません。私はMITライセンスを見てきましたが、それは寛容すぎるようです。

たいていの場合、改善が貢献している限り、人々に自分のコードを好きな場所で使用してもらいたいです。

これは私の質問に私を連れて来ます：LGPLはオープンソースライブラリ、コンポーネント、プラグインなどの論理的な選択ですか？より良い代替手段はありますか？GPLは私のアプリケーションにとって良い選択ですか、それとももっと良いものがありますか？

更新：

私の最終決定に興味がある人のために、マルチライセンス方式、MPL、LGPL、GPLでライブラリをリリースすることにしました。これにより、MPLの下でコードを変更しない限り、事実上すべての人が義務なくコードを使用できます。

これは、コードがFSFとプロプライエタリソフトウェアの両方で使用できることを意味しますが、「悪い」商業的悪用は防止されます（または、私は考えたいと思います）。

GPLとLGPLがあなたのプロジェクトに必要なものであるように思えます。

• アプリケーションのサポートを販売する以外の商用利用はできません（つまり、アプリを販売することはできませんが、周辺のすべては販売できます）

GPLはアプリケーションの販売を禁止していないことに注意してください。これを禁止すると、Huperniketesが観察するように、実際にライセンスがフリーになります。GPLが保証する唯一のことは、ソフトウェアを販売する会社も無料でコードベースを提供する必要があるということです。ただし、ソフトウェアパッケージを現状のまま無料で提供する必要はありません。ソフトウェアのソースコードはすぐに使える製品ではないため、これは非常に大きな違いです。

ソフトウェアの商用利用を防止したい場合、GPLはそれを削減しません。GPLは、変更されたソースを再配布する必要があるため、販売する製品で営利企業によって回避される傾向がありますが、GPLソフトウェアを内部で自由に使用できます。それは、企業がGPLソフトウェアを販売したり、GPLソフトウェア（LinkSysなど）を中心にハードウェアを構築したりするわけではないということではありませんが、ほとんどの企業は自社製品を競合他社と共有したくないと考えています。

Creative Commons Attribution Non-Commercial No Derivativesライセンスがあなたが望むものであるかどうかはわかりません（あなたが言及した唯一の制限は商業利用です）ライセンス所有者に付与する権利を付与する言語。

また、非商用利用や非変更可能性などの制限を含めると、Open Source Initiativeで定義されているオープンソースライセンスの基準を満たさなくなる可能性があります。彼らのサイトには、他の承認されたOSSライセンスもリストされています。おそらく、すでにあなたの目標に合ったものがあります。

そして、ソフトウェアのユーザーに与える権利と制限を選択する前に、目標を適切に定義することが重要です。人気は、変更可能性、配布、使用よりも重要ですか？そもそもコードをリリースする目的と、それをどのような精神で行うか、またはアクセスを許可する条件が逆の効果をもたらす可能性があることを考えてください。

気になるのは、コードが無料であることを確認し、改善を取り戻し、誰でも使用できることを確認することである場合、MPLは適切なライセンスです。LGPLが課すような奇妙で不可解なリンク制限なしに、商用ソフトウェアを含むあらゆる製品で自由に使用できます。それはあなたのコードを使用し、それを変更する誰もがMPLの下で変更をリリースすることを要求しますが、プロジェクト内の残りのコードのいずれにも触れたり制限したりしません。

すべてのコードを作成した場合（つまり、コードを所有している場合）、デュアルライセンスを使用することもできます。たとえば、GPLv3でコードを公開し、制限を緩和して使用したい人に（別のライセンスで）販売することを申し出ます。

（これは、特にライブラリに関連しています。GPLで編集されたライブラリはGPLソフトウェアでのみ使用できるためです）。

コードに組み込む外部の貢献やパッチに注意してください（所有していないため）。

実際にMPLを申請できるかGPLのみを申請できるかは、1つの重要な違いに依存します。

「以下の権利」には、MPL「対象コード」をプライベートな非MPLコードとリンクして「より大きな成果」（MPL 3.7 Larger Works）を形成する受信者に付与される権利が含まれます。GPLは受信者にそのような権利を与えません。したがって、受信者はMPLの代わりにGPLを適用するためにライセンス条件を変更できません。

参照してくださいこれを。

これがあなたにとって意味することは、それ自体がGPLであるコンポーネントを使用している場合、あなたは（おそらく）MPLの下で（これを使用している）コードをリリースできないということです。MPLは、不適切なMPLの下でGPLされたコードの再配布を誤って許可しようとします。依存関係がMITまたはApacheライセンスの順序であれば、これで問題ありません。

一般的には、あなたがしている場合ではないあなたは既にMPLのものを使用していない限り、一人でGPLの上にMPLを選択することで、任意のより良いやって。GPLは、貢献が同様に公開されるようにします。

MPLが提供する重大な変更は、知らないうちに引き起こされた特許侵害に対する保護のみです。ライセンスがそれを置くように：

誰かが特許を取得しているモディフィケーションを作成し、ライセンスに基づいて必要に応じてモディフィケーションを無料で利用できるようにしてから、戻ってすべての人に特許権を請求しようとしても問題ありません。

MPLとGPLは完全に互換性がありません。

デュアルライセンスの意味については、MIT vs. BSD vs. Dual Licenseをご覧ください。

誰も彼らについて話していないようですが、あなたはクリエイティブ・コモンズのライセンスを検討するかもしれません。さまざまなライセンスがあります（または、ニーズに合わせて調整された、別の方法で見たライセンス）。