OSS概要

OSSとは

OSSの定義については、OSI(open source initiative, オープンソースを促進している米国の団体)の定めた定義(The Open Source Definition)が標準的です。

ここでは、以下の10項目を満たすものをOSSとしています。

• Free Redistribution (自由な再配布を認めること)
• Source Code (コンパイル前のソースコードを無償で配布すること)
• Derived Works (改変や派生作品の配布を許可すること)
• Integrity of The Author’s Source Code (改変コードによるソフトウェアの配布を許可すること)
• No Discrimination Against Persons or Groups (特定の個人またはグループを差別をしないこと)
• No Discrimination Against Fields of Endeavor (特定の分野での利用を制限しないこと)
• Distribution of License (プログラムに関する権利が再配布者に与えられること)
• License Must Not Be Specific to a Product (ライセンスを特定の製品に限定しないこと)
• License Must Not Restrict Other Software (ライセンスが他のソフトウェアを制限しないこと)
• License Must Be Technology-Neutral (ライセンスが技術的に中立であること)

10項目を列挙すると複雑ですが、要約すれば、「改変する自由」と「頒布する自由」が無償で認められているものがOSSと呼ばれています。

OSSに関する誤解

OSSは著作権フリーか

OSSが著作権フリーであると勘違いしているエンジニアが散見されますが、これは完全な誤りです。むしろ、OSSの本質は利用許諾（ライセンシング）です。OSSの著作権が開発者等の著作権者に帰属することを大前提として、著作権者が上述の条件を満たす利用許諾を行ったものをOSSと呼んでいるというのが正しい理解です。

各ライセンスの概要

OSSライセンスは大別すると寛容型と互恵型があります。

寛容型

寛容型ライセンスとは一般的に、著作権とライセンスの表記さえすれば自由な改変・頒布が認められているライセンスを指します。以下のものが代表的です。

• MITライセンス
  多くのOSSプロジェクトで採用されている代表的な寛容型OSSライセンスです。
  Node.js, Ruby on Rails, jQuery, React JS, Angular JS, Vue JS, Visual Studio Code, bootstrap等
• BSDライセンス（3項型 / 2項型）
  UCB（カリフォルニア州立大学バークレー校）が頒布したソフトウェアに由来するライセンスです。2項型、3項型、4項型の3種類がありますが、4項型は現在はほぼみられません。
  nginx, golang, numpy, pandas, PyTorch, Flask, Django, flutter等
• Apache 2.0 ライセンス
  利用者へ特許利用許諾を与える（許諾者からの著作権行使を禁じる）のが特徴の寛容型ライセンスです。
  Android, tensorflow, opencv等

上記の他にも、PSFL（Python Software Foundation License, pythonやmatplotlibの配布に用いられるライセンス）や、 SIL Open Font License（フォントに特化したライセンス）等、寛容型ライセンスには多くの種類が存在します。利用者に大きな負担を課さずに自由な改変・頒布を認めているという点では共通ですが、細かな相違点には注意が必要です。

また、Chromium(BSD, LGPL,MIT等)の様に複数ライセンスが混在するプロジェクトや、Meta社が開発したLlama2の様に、一見OSSの条件を満たすように見えるが詳細に検討すると微妙なケースもあります。特殊なライセンスについては個別の条項を慎重に確認する必要があります。

著作権・ライセンスの表記方法

Webサービスの場合、利用規約やヘルプページに記載するのが一般的です。ライセンスに関するページを独自に設置する場合もあります。

アプリの場合、アプリ内にライセンスに関するページを設置し、「設定」メニュー等からアクセスできるようにするのが一般的です。ヘルプページに記載する場合もあります。

互恵型

互恵型は、改変・頒布について寛容型より重い負担が課されているOSSライセンスを指します。一般的にはGPL又はLGPLを指します。

GPLは代表的な互恵型ライセンスで、GPL v2とGPL v3が存在します。

GPL (GNU General Public License) v2

1991年にリリースされたGPL v2は、プログラムの改変・頒布にあたり以下を遵守することを要求するライセンスです。

• ライセンス文言を、頒布を受けた人が読める状態で表記する
• ソースコードを最低3年間継続して開示する
• ソースコードの入手方法を明記する（バイナリで配布する場合、別に入手方法を設定する）

改変後のソースコードの開示が必要となる点が寛容型と大きく異なります。GPL v2の代表例としてlinux, git, mysql, wordpress, wireshark, blender等があります。

GPLライセンスのOSSを自社プロダクトに使用した場合、そのプロダクトについてもソースコードの公開が必要となります。実際、多くのソフトウェア開発企業や電子機器メーカーが、linux関連のプログラムのソースコード頒布ページを公式サイト上に設置しています。このことを「GPL汚染」と呼ぶことがあり、ソフトウェア開発にあたってGPLライセンスの利用が忌避される原因にもなっています。GPL汚染の問題は複雑なため、別記事にて詳述します。

GPL v3

2007年に公開されたGPL v3は、GPL v2をベースとしながら、著作権者や利用者の権利、特に特許の取扱いを明確化したものです。背景には、巨大IT企業（主にマイクロソフト）による特許権侵害訴訟の多発があります。

GPL v3では許諾者による特許の利用保証を明文化しており、利用者が許諾者から特許権侵害訴訟を提起されるリスクが低減されています。もっとも、当然のことならがら、当該OSSが許諾者以外の特許を侵害している場合、利用者も当該特許の権利者からの訴訟リスクを免れません。

GPL v3の代表例として、Emacs, Samba, PyQt, R, gcc等があります。GPL v3のリリースから15年超が経過した今でも、GPL v2とv3が共存している状況です。

LGPL (Lessor GPL)

LGPLは、GPLをベースとしつつ、LGPLで利用許諾されたライブラリを「動的リンク」したプログラムは任意のライセンスが可能としている点が特徴です。もっとも、何が「動的リンク」に該当するかについては統一的な見解が必ずしも無いため、同条項の活用には注意が必要です。

AGPL (Affero GPL)

AGPLは、GPLのソースコード公開義務を加重したライセンスです。極めて特徴的なのが第13条で、ソースコードを頒布しなくてもASP/SaaSとして提供した場合にはソースコード公開義務が生じる旨を定めています。これはASP黎明期にサービスへのフリーライドを防止するために策定されたものです。AGPL13条の規定は広範かつ抽象的であり、依拠には注意が必要です。

なおAGPLの公開義務を更に加重したSSPL (Server Side Public License) というライセンスも存在しますが、その過度の広汎性から、OSIはSSPLをオープンソースライセンスとして承認していません。

OSS活用に伴うリスク

OSSは、高品質なソフトウェアを無償で活用できるというメリットがある一方、様々なリスクを内包しています。

OSSの品質に関するリスク

OSSは無償かつ現況有姿で提供されているものであり、基本的に提供者は瑕疵担保責任を負いません。OSSの品質については利用者が責任を持って検証する必要があります。
品質担保のアプローチとしては、利用者側でOSS毎にテストを行うのが理想ですが、多数のOSSを活用する環境では限界があります。OSSのリリース頻度やissue解消状況、github star数等のメトリックスを活用して信頼性を管理していくアプローチが一般的です。

OSSの更新停止・陳腐化リスク

高名なOSSであっても、更新は特定・少数のエンジニアチームによって行われているケースが散見されます。その場合、チームの解散等によってOSSの更新が停止されることで、ライブラリ間の依存関係が解決できなくなってプロダクト全体に影響が及んだりセキュリティリスクにつながるおそれがあります。
日常的にgithub等でオープンソースの開発状況をチェックし、OSSコミュニティが活発に活動しているか、定期的なリリースがあるか等を確認することが重要です。

OSSの特許侵害リスク

OSSが第三者の特許権を侵害している場合、OSSの提供者だけでなく、その利用者も特許権侵害の主体となり、損害賠償請求や差止請求を受けるリスクを負うこととなります。OSSを利用しておきながら、特許侵害については開発者に責任を転嫁することはできません。多くのOSSではこの点を明記しています（以下はMITライセンスの例）。

IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

The MIT License

実際、OSSに対する特許訴訟は頻繁に発生しています。有名なケースでは、Microsoftが2010年にAndroid (Googleのスマートフォン向けOSS, Apache 2.0 ライセンス)を搭載した端末を販売していたMotorolaを提訴した事件があります。Androidの様な極めて普及度の高いOSSでも、他社の知財を侵害するリスクと無縁でないのです。そもそもOSSは「自由な改変・頒布」を認めるものである一方、特許は特定の者（特許権者）に対して排他的・独占的権利を与えるものであり、両者に緊張関係が生じるのは必然といえます。

現在はOpen Invention Network (OIN) 等の業界団体が、OSSの知財リスク低減に向けた活動を行っています。OINに参加している企業間では、特定のOSSに関する特許訴訟が禁じられています。

このように、現代のOSS活用にあたっては、特許訴訟リスクの評価・低減が必須の検討事項となっています。

契約上の対応

ソフトウェア開発委託契約における条項例

ソフトウェア開発を委託する際、ベンダーが問題のあるOSSを無断で使用することで、上述のリスクが顕在化するおそれがあります。ソフトウェア開発委託契約においては、納入ベンダに対して、利用予定のOSSの情報を事前に提供させることが望ましいです。

第●条（OSSの利用）
１　甲（ベンダ）は、本件開発ソフトウェアの構成要素としてオープンソースソフトウェア（以下「OSS」）を利用するときは、当該OSSの名称、著作権者、ライセンス条項、機能内容、脆弱性等に関する情報を乙（ユーザ）に対して事前に提供し、利用可否を照会する。
２　乙は前項の場合、自らの責任で当該OSSについて検討・評価し、利用可否を決定する。

ロジットパートナーズ法律会計事務所のサービス

当事務所では、ITの深い知見と豊富な業務経験を有するエンジニア兼弁護士・公認会計士が、OSS活用・管理に係る基本方針の策定、態勢構築、規程類・ガイドラインの策定、内部統制資料の作成、契約書ドラフト・チェック、役職員に対する教育研修、個別の紛争対応等、OSSに関連する法務やガバナンス構築を幅広くサポートしています。

お気軽にお問合せください。

* 2024.7.16 : AGPL/SSPLについて追記

The post OSS (オープンソースソフトウェア)活用上の留意点 first appeared on ロジットパートナーズ法律会計事務所.