オープンソース ソフトウェアを非常に優れたものにする共同開発のために、オープンソース ソフトウェア ライセンスは、従来のソフトウェア ライセンスとは異なる方法で多くのサポートを提供します。

従来のソフトウェアライセンスを使用する際の慣習や期待は、オープンソースソフトウェアに直面した際にフラストレーションにつながる可能性があります。「ライセンスを見せてください」といった単純な要求では、満足のいく回答が得られない場合があります。回答が非常にシンプルな場合もありますが、オープンソースソフトウェアのライセンス情報はより複雑で、従来のソフトウェアライセンスが期待する水準に達していないことがよくあります。

一体何が起こっているのでしょうか？オープンソースソフトウェアのライセンスに何か問題があるのでしょうか？いいえ、そうではありません。ライセンス条件とソフトウェア開発手法の違いにより、ソフトウェアライセンス情報の伝達方法も異なります。弁護士の利便性と開発者の利便性のトレードオフが、このような状況の一因となっています。

オープンソースソフトウェアは「共同で」開発できると述べるだけでは、オープンソース開発と従来型ライセンスのソフトウェアの潜在的な違いを十分に捉えきれません。オープンソースプロジェクトの中には、1人または少人数の専任グループによって維持されているものもありますが、オープンソースプロジェクトにおける共同作業は、幅広い潜在的な貢献者間で行われる可能性があります。例えば、GitHubの「2019 Octoverse Report」によると、上位1,000のプロジェクトには35万人以上が貢献しています。しかし、オープンソースソフトウェア開発と従来型ライセンスのソフトウェア開発の違いは、貢献者の数だけではありません。プロジェクトに対する共通の関心を除けば、貢献者同士の間に繋がりがない場合もあります。関与は時間の経過とともに変化する可能性があります。当初の開発者がプロ​​ジェクトを離れ、他の人がプロジェクトを継続する場合もあります。こうしたことは、計画や包括的なガバナンス組織がないままに起こり得ます。

規範的なガバナンスルールを遵守することに加え、オープンソースのコラボレーションは軽量で、従来のライセンスのソフトウェアよりも迅速に対応できます。オープンソースのライセンス情報に関するプラクティスは、この共同開発アプローチに適しています。

バイナリファイルとソースコードの両方において、オープンソースライセンスの条項は、複製、改変、配布など必要な権限を付与することで、共同開発を促進します。オープンソース定義（OSD）は、その要件を満たすライセンスに焦点を絞る上で役立つことが証明されています。

オープンソースソフトウェアのライセンス情報はソースコードに埋め込まれています。ソースコードを入手すると、対応するライセンス情報が提供されます。年間数百万件もの貢献を想像してみてください。ライセンスを個別に管理することは、果たして完全に実現可能でしょうか？同様に、ライセンス情報をソースコードに埋め込むことで、ライセンスに関する詳細情報を反映させることができます。これは、個別に管理されているライセンス管理プロセスでは実現できない詳細情報です。例えば、ライセンス情報をソースコードに埋め込むことで、どのライセンス条項がソフトウェアのどの部分に適用されるかを示すことが現実的になります。

オープンソース ライセンスの実践によって達成できる効果を説明するために、次の典型的なソフトウェア プロジェクトを考えてみましょう。

このプロジェクトは 5 年前に始まり、現在までに 50 人の貢献者が貢献し、他のプロジェクトのソフトウェアの一部を適応させることでいくつかの機能が追加されました。元のコード開発者は 3 年後に退職しましたが、いくつかの営利企業はすでに社内または自社製品の一部でこのソフトウェアを利用しています。ソフトウェアとコンピュータの世界におけるその他の変化を考慮すると、このソフトウェアはさらに 5 ～ 10 年開発される可能性があります。

オープンソースプロジェクトにおいてライセンス情報を表現する既存の一般的な方法は、このようなプロジェクトのプロセスにも容易に適用できます。事前の計画がなければ、貢献者がプロジェクトに出入りしたり、プロジェクトの各部署が異なるライセンス条項に従ったりする可能性があります。また、他社との協力体制が崩壊した場合でも、営利企業は最小限の管理オーバーヘッドでソフトウェアのメンテナンス作業を共有し続けながら、ソフトウェアブランチを完全に独立して開発する能力を維持できます。

逆に、従来のソフトウェアライセンス方式は、このような開発をどのようにサポートするのでしょうか？このような連携はそもそも可能でしょうか？数千もの「マスターソフトウェア開発・配布契約」の適用範囲を追跡できる、単一の包括的なライセンス基盤は存在するのでしょうか？特定の企業にすべてを管理させることで、ライセンスを簡素化すべきでしょうか？

「どのようなライセンスなのか？」という問いに戻りましょう。オープンソース開発の特徴について議論する目的は、オープンソースのライセンス情報がどのように表現されるかに影響を与える、法的ではない重要な要因を明らかにすることです。オープンソースソフトウェアにおけるライセンス情報の表現方法は、従来のソフトウェアライセンスの想定とは必ずしも一致しません。しかし、こうした違いが存在するからといって、システムに問題があるわけではありません。むしろ、こうした違いは、過去20年間の大規模な共同開発を通じてその有効性が実証されてきたソフトウェア開発方法論にとって、非常に大きな力となります。

オープンソースライセンス情報はどのようになっているのでしょうか?

通常、人々は各「ソフトウェアコンポーネント」のライセンス条項を考慮します。ソフトウェアコンポーネントは、アプリケーションとしてユーザーに見える場合もあれば、大規模なプログラムと組み合わせて使用​​することで特定の機能を提供するライブラリのように、ユーザーにとってそれほど目立たない場合もあります。

多くのソフトウェアコンポーネントのライセンスは、非常にシンプルです。コンポーネント内のすべてのソフトウェアは、数十種類ある最も一般的なオープンソースライセンスのいずれかに準拠します。これらの最も一般的なライセンス以外にも、文言は様々ですが、あまり使用されていないライセンスが数多く存在します。しかしながら、「オープンソースの定義」に基づき、オープンソースライセンスの条項における許可と制限は、一定の範囲内にとどまります。

オープンソース ソフトウェアを他のソフトウェアに統合するソフトウェアを開発する場合は、統合されたソフトウェアに適用されるすべてのコピーレフト条項 (よく知られている GPL ファミリーのライセンスなど) を理解する必要があります。

オープンソース ソフトウェアの開発方法についての説明で明らかにした理由により、ライセンス情報は単一のライセンスよりも複雑になる可能性があります。

ソフトウェアコンポーネントには主要な「プロジェクトライセンス」が適用される場合がありますが、ソフトウェアの他の部分には異なるライセンスが適用される場合があります。その結果、ソースコードの異なる部分に異なるライセンスステートメントが表示される場合があります。

プロジェクトによっては、各ソースファイルに著作権表示を配置するものもあります。また、ライセンステキストを含む1つ以上のファイルを配置することに主眼を置いているプロジェクトもあります。

著作権表示は、ソフトウェアのその部分の著作権所有者が誰であるかを示します (ただし、著作権表示の慣行の多様性を考慮すると、この表示の役割は無視できる可能性があります)。

ソフトウェアコンポーネントのビルドに使用されるソースコードには、テストやビルドに関連するファイルなど、結果のコンポーネントには反映されないソフトウェアが含まれる場合があります。これは、GPLフリーのルール（プロジェクトにはGPLライセンスのファイルを含めることができますが、実行ファイルを生成するために使用されるファイルにはGPLライセンスのファイルを含めてはなりません）を採用している人にとって重要となる場合があります。

多くの詳細は、特定のライセンス情報の対象となるソフトウェアの特定の部分に関連するため、こうしたきめ細かなライセンス情報は、ソースコードで最も効果的に伝達されます。最も詳細なレベルでは、ソースコード自体がライセンスです。ライセンス情報がソースコード内に含まれている場合、ソースコードと同様に（例えばバージョン管理システムなどで）管理することができ、この情報はソースコードを入手した人なら誰でも本質的に利用できます。

ソースコードからライセンス情報を抽出し、ライセンス条項の要約を作成するのは一見簡単そうに見えます。しかし、ある個人や企業にとって十分な要約が、別の個人や企業にとっては不十分な場合があります。人によって、ライセンス情報の関心は異なる可能性があります。ソフトウェアのどのコンポーネントが「左側」の条項の対象となるのかを正確に知りたい人もいれば、すべてのコンポーネントのライセンス条項の要約には関心がない人もいるでしょう。また、すべての著作権表示を含むすべてのライセンス情報を必要とする人もいるでしょう。

どのようなライセンス情報の詳細を確認したいですか？ソフトウェア開発には数多くのツールが利用可能です。既存のライセンス情報をスキャン、抽出、レポートするためのツールは、継続的な開発において活発なトピックとなっています。「どんなライセンスですか？」という質問は、「ライセンス情報レポートを見せてください」と言い換えることもできます。レポートを要求した人にとっての重要度に応じて、様々な詳細レベルを含めることができます。最も詳細なレベルでは、ソースコード自体がライセンスとなります。

ソフトウェアは様々な方法で構築できるため、従来のソフトウェアライセンスとオープンソースソフトウェアライセンスは適用範囲が異なります。両者には違いがある場合があり、その点に留意する必要があります。

著者について：スコット・ピーターソンはRed Hatの法務チームのメンバーです。昔、あるエンジニアがGPLという奇妙な文書についてスコットに法的助言を求めました。この重大な問題がきっかけで、スコットは技術標準やオープンソースソフトウェアなど、共同開発を取り巻く法的問題を探求するという、複雑な道を歩み始めました。

翻訳者プロフィール：薛良氏は、済恵智佳知的財産コンサルティング有限公司のインターネット事業部部長です。特許調査、特許分析、競合企業追跡、FTO分析、オープンソースソフトウェアの知的財産リスク分析を専門とし、インターネット企業やハイテク企業への知的財産コンサルティングサービスの提供に尽力しています。