競技場
基本的に、OpenSourceで広く使用されているライセンスは2種類のみです。
私が最も頻繁に使用したタイプは、BSDまたはMITライセンスです。 これらのライセンスでは、ソースコードの無制限の使用、変更、配布、および商用化が許可されますが、2つの注意事項があります。 まず、著作権表示をソースコードとともに配布する必要があります。 第二に、MITライセンスの下で私のコードを使用する場合、これらのソースコードを使用した結果について私を訴えることはできません。
もう1つの主要なタイプのライセンスはCopyLeftと呼ばれ、変更されたバージョンが配布される場合、ソースコードへの変更も公開する必要があります。 このライセンスの実際の効果は、著作権法における政府の支援なしには実現できません。
最も人気のあるCopyLeftライセンスはGPLです。これはLinuxで使用され、ウイルス性も持っています。 GPLの下で公開されているコードを独自のコードで使用する場合は、コードを開く必要があります（配布する場合）。
GPLのウイルス性の低いバージョン（LGPL）では、ソフトウェアに加えられた変更も公開する必要がありますが、簡単に使用するための公開の要件は削除されています。
GPLのウイルス特性に関する不確実性のため、大企業の法務部門はGPLに対して非常に敵対的です。 LGPLの下でライセンスされたソフトウェアは、企業の弁護士の承認を得る可能性が高く、MIT / BSDライセンスは一般的に彼らのお気に入りです（明らかに、企業に義務を課していないため）。
オープンソースを書くときに欲しいもの。
Ruby on RailsやjQueryのような本格的なオープンソースプロジェクトに取り組んでいるとき、私は比較的単純な望みを持っています。
- 私が取り組んでいるソフトウェアは、できるだけ多くの人に使用してもらいたいです。 これはおそらく利己的な願望ですが、多くの人が実際に使用している結果として有用なソフトウェアを見たいという願望と見ることができます。
- バグレポートを送信する多くのユーザーのサブセットを持ち、さまざまな使用状況や作業環境でコードの機能をテストして、結果としてソフトウェアの品質を向上させたいと考えています。 これは、「すべてのエラーが表面に浮かぶように十分な目を持つために」と要約できます。
- ソフトウェアの改善に十分興味がある人々にパッチを提出してほしい。 特に、私は問題について考え、エラーの原因を見つけて修正しようとしている人々からパッチを取得したいと思います。また、何かを機能させるためだけに別のハックを思いついた人々からパッチを減らしたいです。 本質的に、パッチの高い信号対雑音比は、多数のパッチよりも重要です。
- 長期にわたってソフトウェアの改善に興味がある人が欲しい。 プロジェクトに長期参加者（貢献者）と最終的に開発者（コミッター）を受け入れたこと。
これらの欲望のうち、2番と3番が最も優先順位が高くなっています。 コードをできるだけ現実の世界の影響にさらしたいです。 そして、検出されたエラーを修正するために、できるだけ多くの高品質のパッチが必要です。 ただし、これらの2つのポイントの間で選択する必要がある場合は、2番目を選択します。コードを現実世界の影響に「さらす」ことが、設計のエラーや誤った仮定を迅速に検出する最良の方法です。
これらの要件を満たす
私は最も単純なものから始めます：私の最初の欲求（私のソフトウェアが可能な限り使用されるように）は、非常に自由な使用ポリシーで最も簡単に満足されます。 定義によりソフトウェアの使用に制限を追加すると、その採用度が低下します。
さらに重要なことは、実際の世界でコードを公開することについても同じことが言えます。 この目標を達成するための最も重要な方法は、「できるだけ多くの人にとってできるだけ便利なコードを使用する」ことです。
MITライセンス下のコードのすべてのユーザーの少なくとも1％が常に検出されたエラーを報告する場合、CopyLeftライセンスの場合の100％の専有ユーザーとは異なり、これは数千人の潜在的なユーザーの1％になります。 プロプライエタリなソフトウェアユーザーは、OpenSourceユーザーと同じ方法でバグレポートを作成するため、実際には、この数字は1％をはるかに超えています。
これに対する唯一の反論は、CopyLeftライセンスの場合、多数の専有ユーザーがOpenSourceユーザーになることを余儀なくされ、その貢献はMITライセンスに対する専有ユーザーの貢献を上回ることです。 しかし、実際には、プロプライエタリなユーザーは、制限された使用パターンと他のプロプライエタリなソフトウェアを使用して、オープンソースから選択することを余儀なくされる場合、プロプライエタリなソリューションを選択します。
オープンソースプロジェクトにプロプライエタリな開発者が関与することの間違いない利点は、プロプライエタリな環境でコードが追加的にチェックされることです。 さらに、彼らはプライベートユースケースへのアクセスと、オープンソースの普及率が低い市場へのアクセスを持っています。
次の大きな欲求は、高品質のパッチの絶え間ない流れです。 すべてのソフトウェアユーザーが貢献を余儀なくされるため、これはCopyLeftライセンスの長所であると思われます。 ただし、CopyLeftライセンスを使用したプロジェクトはいずれの場合もプロプライエタリな環境では使用されないため、より自由なライセンスのプロジェクトのこれらの環境からのオープンソースプロジェクトのパッチは非常に多くなります。 繰り返しになりますが、プロプライエタリユーザーのわずか数パーセントがプロジェクトに貢献したとしても、プロプライエタリユーザーがゼロの100％よりもかなり多くの貢献を意味します。
もちろん、jQueryとRails（および私が取り組んでいる他の小規模なオープンソースプロジェクト）についてのみ話すことができますが、多数の新しい長期参加者が、ライセンスライセンスが向かう企業プロジェクトに取り組んでいる間にオープンソースプロジェクトに従事し始めました内部使用のソフトウェアを選択する際の角度。
低参入障壁により、オープンソースの目標を達成できます
上記の議論にどれだけ同意しても、CopyLeftライセンスは意図的に、より多くのリベラルライセンスよりも意思決定に高い障壁を導入することは明らかです。
より寛大なライセンスを使用するプロジェクトの場合、ソフトウェアの多くの専有ユーザーが変更を加えないという事実は、バグではなく機能です。
これは、寄付なしでプログラムを使用するすべての人々に固執しているわけではないからです。 代わりに、ユーザー、バグレポート、パッチ、および長期的な参加者に焦点を当てます。これらは、参入障壁をできるだけ低く保つことで、長期的に見ます。
結局のところ、オープンソースの広範な使用の世界はすでに私たちの周りにあります。 そして、強制や完全に自律的なソフトウェアセットの形成に頼ることなくこれを行いました。 これは、優れたソフトウェアを作成し、実際のユーザーにこれが他の選択肢よりも優れていることを納得させることで実現しました。
追記：Linux
Linuxは、ライセンスが使用を大きく妨げることはないため、珍しい例です。 特に、これはほとんどのLinuxユーザーが変更を加えないためであり、GPLライセンスの制限が適用されることはめったにありません。
このような場合、CopyLeftライセンスは使用を最大化するのに十分近いと言えます。これは、より自由なライセンスの主な利点です。 ただし、これらの（かなりまれな）場合でも、CopyLeftライセンスがどのような利点を提供できるかは明確ではありません。