【OSS】OSSライセンス違反が起きる原因｜GPL・MIT・Apacheを現場向けにやさしく解説

OSS（オープンソースソフトウェア）を業務で活用する企業は増えています。

一方で、情報システム担当者にとって見落とせないのがOSSライセンスです。

ライセンスを軽視すると、意図せず「違反状態」になってしまい、

取引先からの指摘
監査での問題
社内ルール違反
法務対応の発生

といった形で、業務に大きな負担がかかります。

この記事では、情報システム担当者向けに、OSSライセンス違反が起きる原因と、最低限押さえるべきポイントをやさしく解説します。

OSSライセンスでよくある誤解

まず最初に、現場でよくある誤解を整理します。

OSSは無料だから、何をしてもOK
社内で使うだけなら、ライセンスは気にしなくていい
GitHubにあるものは全部自由に使える
ライセンスは法務が見るものなので、情シスは関係ない

結論から言うと、これらはすべて危険です。

OSSは「自由に使える」ものですが、その自由には条件があります。

そもそもOSSライセンスとは何か

OSSライセンスは、簡単に言うと

「このソフトを使っていいよ。ただし、こういう条件を守ってね」

というルールです。

そして業務利用では、次の2つの観点が特に重要になります。

著作権表示やライセンス文の同梱が必要か
ソースコード公開義務が発生する可能性があるか

OSSライセンス違反が起きる典型パターン

実務では、悪意がなくても違反が起きます。

特に多いのは以下のパターンです。

パターン1：OSSを組み込んだまま納品してしまう

社内システムでは問題にならなくても、外部に納品する場合は話が変わります。

例えば以下のケースです。

OSSを組み込んだWebシステムを顧客に納品
OSSを含むアプリを配布
OSSを含むソフトを社外に提供

この場合、ライセンスによっては

著作権表示
ライセンス文の同梱
ソースコード公開

などが必要になる可能性があります。

パターン2：ライセンス文（LICENSE）を消してしまう

OSSを導入するときに、

必要なファイルだけ抜き出す
フォルダ構成を整理する

といった作業をすることがあります。

このとき、LICENSEファイルや著作権表示を消してしまうと、ライセンス違反になる可能性があります。

パターン3：GPL系ライセンスを「知らずに」使う

業務で最も注意が必要なのがGPL系です。

GPLは「OSSとして公開されているものを、さらに改変して配布する場合、ソースコード公開義務が発生する可能性がある」タイプのライセンスです。

社内利用だけなら問題にならないケースもありますが、外部提供が絡むと影響が大きくなります。

パターン4：依存ライブラリのライセンスを把握していない

現代のOSSは、単体で動くことは少なく、

Composer（PHP）
npm（JavaScript）
pip（Python）

などで大量のライブラリを依存関係として取り込みます。

つまり、あなたが使っているOSSは、実際には「数十〜数百のOSSの集合体」です。

その中にGPL系が混ざっているケースもあり、ここがライセンス問題の温床になります。

現場でよく出てくる代表的ライセンス（ざっくり理解）

ここでは、現場でよく出てくるライセンスを「超ざっくり」整理します。

MITライセンス

非常に緩い
著作権表示とライセンス文の保持が基本
商用利用も可能

業務利用では最も扱いやすいライセンスのひとつです。

Apache License 2.0

MITに近いが、特許（Patent）条項がある
著作権表示やNOTICEの保持が必要になる場合がある
商用利用も可能

こちらも業務利用でよく使われます。

GPL（GNU General Public License）

条件が厳しめ
配布形態によってソース公開義務が発生する可能性がある
組み込み方によって影響範囲が変わる

特に、外部への納品や配布がある場合は、必ず慎重に扱う必要があります。

LGPL

GPLよりは緩い
主に「ライブラリとして使う」場合に配慮されている

とはいえ、業務利用では判断が難しいため、重要システムでは注意が必要です。

情報システム担当者がやるべき最低限の対策

法務がいる会社でも、現場で最低限やっておくべきことがあります。

1. OSSを使うときは「必ずライセンスを記録する」

まずはこれが最重要です。

ソフト名
バージョン
ライセンス種別
入手元（GitHub等）

これがないと、後から調査ができません。

2. OSS利用台帳を作る（ExcelでもOK）

大企業ほど専用ツールを使いますが、中小企業ではExcelでも十分です。

ポイントは「属人化させない」ことです。

3. 外部に納品・配布する場合は必ず確認する

社内利用だけなら問題にならないケースでも、外部提供が絡むと条件が変わることがあります。

この線引きを社内ルール化しておくと、事故が減ります。

4. 依存ライブラリも対象にする

OSSの本体だけではなく、依存ライブラリも確認対象です。

ここを見落とすと、後から問題になりやすいです。

5. 判断が難しいものは「使わない」が最も安全

GPL系のように判断が難しい場合、

代替OSSを探す
商用ライセンス版を検討する

など、リスクを減らす選択を取るのが現実的です。

まとめ

OSSライセンスは難しく感じますが、業務利用で重要なのは次のポイントです。

OSSは「無料」ではなく「条件付きで使える」
違反は悪意ではなく「知らずに」起きる
外部納品・配布がある場合は特に注意
依存ライブラリも含めて把握する必要がある
OSS利用台帳を作るだけでも事故は減る

OSSを安全に業務利用するために、まずは「記録」と「把握」から始めていきましょう。

情報システム担当者のためのOSS業務利用実践ガイド

【AI】第5回：生成AIを「使われる仕組み」にするための導入ステップ｜生成AIを「使える技術」に変える ― 情報システム担当者のための実践ガイド