社会・産業のデジタル変革

処方箋2【権利へのバイアス】GitHubにあるコードは「フリー素材」ではありません ~コンプライアンスを守るための基本知識~

OSSに対する誤解を解く5つの処方箋

「ご自由にどうぞ」の罠と法的リスク

「ネットで公開されていて無料で利用できるなら、フリー素材と同じでしょ?どう使っても自由だし、責任なんて問われないよね」。
もしあなたのチーム内でこのような会話が聞こえたら、即座に訂正する必要があります。これは企業のコンプライアンスにとって、最も危険かつ高額な代償を伴う誤解です。
一般的に、OSSの世界における「Free」とは直接的に「無料」を指すのではなく「自由」を意味します。しかし、この自由は無条件ではありません。OSSには必ず「ライセンス」という利用規約が付与されています。これは、開発者の権利と利用者の自由を守るための「取り決め」です。
ライセンス条件(著作権表示、ソースコードの提供など)を無視して利用することは著作者の権利を侵害する行為です。その結果、差止請求(製品の出荷停止)、損害賠償請求、社会的信用の失墜といった深刻なダメージを企業に与える可能性があります。

企業が陥りやすい「配布」の落とし穴

ライセンス違反が起きる最大の原因は、「自分たちは配布していないから大丈夫」という思い込みです。しかし、OSSライセンスにおける「配布(Distribution)」の定義は、企業の実感よりもはるかに広範囲です。

誤解1:「社内ツールだから関係ない」

グループ会社、子会社、あるいは協力会社にツールを提供する場合、それは法的に「配布」とみなされる可能性があります。特にグループ会社間であっても、別法人であれば「第三者への配布」と解釈される可能性があります。配布が発生すれば、ライセンス義務(著作権表示やソースコード開示)が生じます。

誤解2:「SaaSだから配布していない」

Webサービス(SaaS)として機能を提供する場合、ユーザーの手元にバイナリ(実行ファイル)は渡りません。従来のGPLなどのライセンスでは、これは配布とみなされず、ソースコード提供義務は発生しませんでした(これを「ASPループホール」と呼びます)。
そこで、この抜け穴を塞ぐために作られたのがAGPL(Affero GPL)などのOSSライセンスです。AGPLは、ネットワーク経由での利用も「配布」と同等とみなし、サーバー側のソースコード提供を義務付けます。知らずにAGPLのモジュールを組み込んでSaaSをローンチすれば、サービス全体のコード提供を迫られるリスクがあります。

誤解3:「成果物(バイナリ)だけ渡せばいい」

「ソースコードは見せたくないから、コンパイルした実行ファイルだけ渡そう」。これはGPLなどのOSSライセンスでは明確な違反です。ソースコードの提供義務があるOSSライセンスを用いる場合、バイナリを配布する際には、対応するソースコードも同時に提供するか、ソースコードを提供する旨と連絡先を明記し、要求があった際には速やかに提供する必要があります。

実務で頻出する代表的なOSSライセンス

数多く存在するOSSライセンスですが、実務で頻繁に遭遇する主要なライセンスごとの特徴と注意点を以下に整理します。

MIT / BSD 3-Clause

最も制約が緩く、企業フレンドリーなライセンスです。「著作権表示とライセンス全文を残す」ことさえ守れば、商用利用も、改変も、ソースコードを非公開にしたまま製品化することも自由です。

Apache License 2.0

MITなどと同様に非常に緩やかなライセンスですが、特許条項が含まれている点が特徴です。また、オリジナルのOSSに「NOTICEファイル」が含まれている場合、それを利用者が継承・表示する義務があるため、単なるコピー&ペーストでは不十分な場合があります。

LGPL / MPL

OSS自体(ライブラリ部分)を改変した場合はその部分の公開が必要ですが、単にリンクして利用するだけの自社アプリ部分はソースコード提供義務の対象外にできるケースが多いライセンスです。 ただし、LGPLの場合、技術的な実装方法(静的リンクなど)によっては、後述するGPLと同じく強い提供義務が生じる場合があるため注意が必要です。

GPL (v2 / v3)

強力な「伝播性」を持つライセンスです。このOSSを組み込んだり、静的にリンクしたりしたソフトウェア全体が「派生著作物」とみなされ、全体をGPLライセンスとして(つまりソースコードを提供して)配布する義務が生じます。 社内利用のみであれば問題ありませんが、特に製品に組み込んで出荷する場合は、自社の独自知財を開示する可能性に対する配慮や、厳密な隔離設計(別プロセス化など)が必要になる場合があります。

AGPL / SSPL

従来のライセンスの抜け穴(ASPループホール)を塞ぐために作られたライセンスです。 製品を配布せず、SaaSなどのクラウドサービスとして機能を提供する場合であっても、ネットワーク経由で利用させるならばソースコード提供義務が発生します。クラウドビジネスにおいては、不用意に混入させるとサービス全体のコード公開を迫られるリスクがあるため注意が必要です。

ライセンスの探し方と読み方

実プロジェクトでOSSを導入する際、どこを見ればよいのでしょうか?
一般的にはリポジトリのルートにある「LICENSE」または「COPYING」ファイルを確認します。また、個別ファイルのヘッダに記載されている場合もあります。
長文のライセンスを読む際は、以下のキーワードで構造を把握すると効率的です。

  • Grant(付与):何が許可されているか(使用、改変、配布など)。

  • Condition / Obligation(条件・義務):何をしなければならないか(著作権表示、ソースコード提供など)。

  • Restriction(禁止):何をしてはいけないか(商標利用の禁止など)。

結論:ライセンスは「恐れるもの」ではなく、あなた自身を「守るもの」

OSSライセンスは、一見複雑で面倒な制約のように思えるかもしれませんが、開発者の権利を守り、エコシステムを健全に保つための重要なルールです。
「知らなかった」では済まされませんが、恐れる必要もありません。OSSライセンスを理解し、自社の利用形態(社内・配布・SaaS)と照らし合わせるプロセスさえ確立すれば、OSSは安全に利用できます。
GitHubにあるコードはフリー素材ではありませんが、ルールを守る者には無限の可能性を提供する「共有財産」なのです。迷ったときは自己判断せず、必ずOSPOや法務部門へ相談してください。

法務・リスク管理担当のための要点メモ

  • 利用規約(ライセンス)なき利用はNGです:OSSは「利用条件」が定められたソフトウェアです。ライセンスを確認せずに利用することは、契約書を読まずに捺印するのと同じくらい危険な行為です。

  • 「配布」がリスクの境界線です:社内で使うだけなら問題ないケースが大半ですが、アプリをお客様に渡す(配布する)場合や、クラウドで機能提供する場合にリスクが跳ね上がります。事業モデルとライセンスの整合性確認は必須です。

  • 現場と法務の連携フロー:エンジニアが法律用語を理解するのが難しいのと同様に、法務がエンジニアリングを理解するのも難しいものです。ひとりで悩まずに、エンジニアと法務が協力することが重要です。「判断に迷ったらOSPOや法務に相談する」というエスカレーションフローの確立こそが、最大の防御策です。