「無料だから何でもOK」という誤解
あるWeb制作会社が、クライアント向けのECサイトにオープンソースのショッピングカートシステムを組み込んだ。担当者は「GitHubで公開されているから無料で使える」と判断し、ライセンスの確認を省略した。システムは問題なく稼働したが、半年後に開発元から連絡が入る。そのシステムはGPL v2ライセンスで公開されており、クライアントへの納品物に組み込んだ時点でソースコードの開示義務が生じていた、という指摘だった。
この事例が示すのは、「公開されている＝自由に使える」という思い込みの危険性である。オープンソースソフトウェア（OSS）は著作権者が一定の条件のもとで利用を許可したものであり、その条件を規定するのがライセンスだ。ライセンスを確認せずに利用すれば、意図せず著作権侵害の状態に陥る可能性がある。
OSSライセンスは数百種類が存在するが、実務上遭遇する頻度が高いのはMITライセンス、GNU General Public License（GPL）、Apache License 2.0の3種類だ。この3つの違いを理解することが、OSS利用における最初のステップとなる。
OSSライセンスの法的構造
OSSライセンスを理解するには、まず著作権との関係を把握する必要がある。ソフトウェアは著作物であり、作成者に著作権が自動的に発生する。著作権者の許可なくソフトウェアを複製・改変・配布することは著作権侵害に当たる。
OSSライセンスとは、著作権者が「一定の条件を守る限り、誰でも利用・改変・配布してよい」と宣言した許諾文書である。この「一定の条件」がライセンスの種類によって大きく異なる。条件を守っている限りは合法的な利用が認められるが、条件に違反した場合は許諾が失効し、著作権侵害の状態になり得る。
OSSライセンスは大きく2種類に分類できる。
**コピーレフト型（Copyleft）**は、OSSを改変・組み込んだ派生物にも同じライセンスの適用を要求するものだ。GPLがその代表例で、「ウイルス性」「感染性」と呼ばれることもある。このタイプのライセンスは、ソフトウェアの自由を永続的に保護することを目的としている。
**非コピーレフト型（Permissive）**は、派生物のライセンス形態に制限を設けないものだ。MITライセンスやApache License 2.0がこれに該当する。改変したコードをプロプライエタリ（独自）ライセンスで配布することも認められる。
この分類を理解した上で、各ライセンスの具体的な条件を見ていく。
MIT・GPL・Apache License 2.0の違い
MITライセンス
MITライセンスはオープンソースライセンスの中で最も制限が少ないものの一つだ。条件は実質的に1つ、「著作権表示とライセンス文を保持すること」のみである。
商用利用、改変、再配布、サブライセンス（別のライセンスで再配布すること）はすべて許可されている。ソースコードを公開する義務もない。クローズドソースのプロダクトにMITライセンスのコードを組み込み、バイナリのみを配布することも合法だ。
ただし、免責条項が含まれており、ソフトウェアの使用によって生じた損害について著作権者は責任を負わない。これは他のライセンスにも共通する点だが、MITはその中でも特に簡潔な文書で構成されており、法的リスクの観点からも扱いやすいとされる。
実務上の注意点は、依存ライブラリのMITライセンスの著作権表示を納品物や配布物に含める必要がある点だ。アプリケーションのソースコードに LICENSE ファイルを含めるか、ドキュメントに表示することで対応できる。
GNU GPL（General Public License）
GPLはコピーレフト型の代表的なライセンスで、GNU v2（GPL-2.0）とGNU v3（GPL-3.0）が広く使われている。Linuxカーネル（GPL-2.0）、WordPressのコア（GPL-2.0以降）などがこのライセンスを採用している。
最大の特徴が「コピーレフト条項」だ。GPLのコードを組み込んだり、改変したりして派生物を作成し、それを第三者に配布する場合、その派生物もGPLライセンスのもとで配布し、ソースコードを開示しなければならない。
この「配布」の定義が重要だ。社内での利用のみであれば、ソースコードの公開義務は発生しない。問題が生じるのは、GPLのコードを組み込んだソフトウェアをクライアントや顧客に納品・配布する場合だ。
GPL-2.0とGPL-3.0の違いも実務上重要だ。GPL-3.0では特許報復条項が追加され、GPLソフトウェアのユーザーに対して特許訴訟を起こした場合にライセンスが自動的に失効する仕組みが導入された。また、「チコライズ」問題（ハードウェア制限によるユーザーの自由の侵害）への対応として、インストール情報の提供義務も追加されている。
なお、GPLには例外的な条項として「GPL例外」がある。著作権者が明示的に例外を設けることで、特定の用途についてはGPLの条件が緩和される。OpenSSLに適用されているSSL例外、GCCに含まれるランタイムライブラリ例外などが代表例だ。
Apache License 2.0
Apache License 2.0は、非コピーレフト型でありながらMITよりも詳細な条件を規定するライセンスだ。Apache Software Foundationが開発し、Apache HTTPサーバー、Android、Kubernetes、TensorFlowなど多くのプロジェクトで採用されている。
MITとの最大の違いは2点ある。
第1に、特許権の明示的許諾だ。Apache License 2.0では、コントリビューターが保有する特許権について、そのソフトウェアの利用に必要な範囲で明示的にライセンスが付与される。MITには特許に関する明示的な条項がないため、特許リスクの観点からはApache License 2.0の方が安全性が高いとされる。
第2に、帰属表示と変更通知の義務だ。再配布する際には NOTICE ファイルに帰属情報を含め、改変を行った場合はその旨を明記する必要がある。
Apache License 2.0は、コピーレフト条項がないためプロプライエタリソフトウェアへの組み込みが可能で、かつ特許リスクへの明示的な対応がある点から、エンタープライズ用途に適したライセンスとして広く認識されている。
コピーレフトが実務に与える影響
GPLのコピーレフト条項は、商用ソフトウェア開発において特に慎重な対応が求められる。具体的なリスクシナリオを整理する。
シナリオ1: クライアントへの納品
クライアント向けのWebシステム開発において、GPL v2ライセンスのライブラリをシステムに組み込んだ場合、そのシステムをクライアントに納品（配布）した時点でコピーレフト義務が生じる。クライアントからソースコードの開示を求められる可能性があるだけでなく、クライアントがそのシステムをさらに第三者に配布する際にも同様の義務が連鎖する。
シナリオ2: SaaS・クラウドサービス
SaaSの形態でサービスを提供する場合、ユーザーにソフトウェア自体を配布するわけではないため、原則としてGPLのコピーレフト義務は発生しない。ただし、AGPL（Affero GPL）はこの「SaaS抜け穴」を塞ぐために設計されており、ネットワーク経由でサービスを提供する場合にもソースコード開示義務が課される。サーバーサイドにAGPLのソフトウェアを使用する場合は特に注意が必要だ。
シナリオ3: GPL-2.0とGPL-3.0の非互換
GPL-2.0のコードとGPL-3.0のコードを組み合わせることは、ライセンスの互換性問題から原則として認められていない。Linuxカーネルが「GPL-2.0 only」を採用しているのはこの理由による。プロジェクトで使用するGPLコードのバージョンを統一するか、例外条項が付与されているかを確認することが重要だ。
コピーレフトリスクへの対処として、LGPL（Lesser GPL）の活用がある。LGPLはGPLの緩和版であり、LGPLライブラリを動的リンクで利用する場合には、アプリケーション側にGPL条件が波及しない。ただし、LGPLライブラリ自体を改変した場合は、その改変部分をLGPLで公開する義務がある。
ライセンス選択の判断フレームワーク
自社のプロダクトやサービスに適したOSSライセンスを選ぶ際は、以下の観点で判断する。
軸1: コードの公開意図
自社のコードを広くオープンにして普及させたい場合はMITまたはApache License 2.0が適している。コミュニティへの貢献を重視し、派生物もオープンであることを求めるならGPLを選ぶ。商用製品への組み込みを意図的に制限したい場合もGPLが有効だ。
軸2: 特許リスクの懸念度
特許問題が重要な業界・領域で使用するコードには、特許許諾条項が明示されているApache License 2.0を推奨する。MITは特許について明示的な規定がなく、将来的な特許紛争のリスクがゼロではない。
軸3: 企業内での採用容易性
多くの企業の法務部門では、MITとApache License 2.0は比較的容易に承認が得られる。GPLは法的レビューに時間がかかる場合が多く、また組み込みを禁止しているポリシーを持つ企業もある。OSS採用の意思決定を迅速に行いたい場合は、MITまたはApache License 2.0を選ぶことがスムーズだ。
利用者側の判断フレームワーク
OSSを利用する立場では、以下の問いに答える形で選択を判断できる。
- そのOSSを「改変・配布する」のか、「そのまま使う」だけか
- 配布先は「社内のみ」か「クライアント・エンドユーザー」か
- 商用プロダクトにソースコードを「組み込む」のか、「外部ライブラリとして参照する」だけか
「そのまま使う」「社内のみ」「外部参照のみ」であれば、ほぼすべてのライセンスで問題は生じない。「改変・配布する」「クライアントへの納品を含む」「ソースコードを直接組み込む」の組み合わせがある場合に、コピーレフト条項の確認が必要になる。
実務での確認チェックリスト
OSSを業務利用する際に最低限確認すべき事項をまとめる。
プロジェクト開始時
- 使用するすべてのOSSライブラリのライセンスを
package.json、requirements.txtなどから確認する - コピーレフト型（GPL・AGPL・LGPL等）が含まれる場合、配布形態と照合してコピーレフト義務の有無を判断する
- 不明なライセンスのコードは使用を保留し、法務担当者に確認する
開発・納品時
- MITやApache License 2.0の著作権表示を
NOTICEファイルまたはドキュメントに含める - クライアントへの納品仕様書にOSSの使用状況とライセンスの一覧を記載する
- 納品後にクライアントがシステムをさらに配布・改変する可能性がある場合、その条件を契約書に明記する
継続的な管理
- 依存ライブラリのアップデートの際にライセンスが変更されていないかを確認する（ライセンス変更は珍しくない）
license-checker（Node.js）、pip-licenses（Python）などのツールを使って定期的にライセンスを棚卸しする
OSSライセンスの問題は、発覚した時には既に多くのコードが書かれた後であることが多い。プロジェクト初期段階での確認と、ライセンスポリシーの社内整備が予防策として最も効果的だ。知らなかったでは済まされない領域であるため、開発チーム全体でのリテラシー向上が求められる。
参考文献
- Open Source Initiative. "Licenses & Standards." https://opensource.org/licenses
- GNU Project. "GNU General Public License, version 2." https://www.gnu.org/licenses/old-licenses/gpl-2.0.html
- Apache Software Foundation. "Apache License, Version 2.0." https://www.apache.org/licenses/LICENSE-2.0
- Software Freedom Law Center. "A Practical Guide to GPL Compliance." https://softwarefreedom.org/resources/2008/compliance-guide.html