オープンソースのライセンスと、発注者が確かめること

オープンソースのソフトウェアは、ソースコードが公開され、誰でも使えるソフトウェアですが、無条件に使えるわけではありません。使う人は、それぞれのライセンスに書かれた条件に従う必要があります。いまのシステム開発では、多くのオープンソースの部品を組み合わせて作ることが一般的なため、発注者もライセンスの基本を知っておくと、納品の後の管理や、売却・事業の承継のときの確認に備えられます。

この記事では、よく使われるライセンスの型と、発注者が確かめておきたいことを整理します。ライセンスの文面は、2026年11月時点で Open Source Initiative（OSI）のサイトに掲載されているもので確かめています。

オープンソースとは

オープンソースのソフトウェアとは、ソースコードを公開し、決められた条件のもとで誰でも使用・改変・再配布できるソフトウェアです。OSIの「オープンソースの定義」は、オープンソースはソースコードを見られるというだけの意味ではなく、配布の条件が、自由な再配布を妨げないことなどの基準を満たす必要がある、としています。

ソフトウェアには著作権があり、ライセンスは、著作権を持つ人が「この条件を守るなら使ってよい」と示した利用の許諾です。条件を守らずに使うと、許諾の範囲の外の利用として、著作権の侵害を問われるおそれがあります。

出典：The Open Source Definition（Open Source Initiative）

ライセンスの2つの型

オープンソースのライセンスは、大きく「寛容型」と「コピーレフト型」に分けて説明されることが多いです。違いは、改変したものや組み込んだものを配布するときに、同じライセンスでソースコードを公開する義務が生じるかどうかです。

寛容型（MIT ライセンス、Apache License 2.0 など）は、著作権の表示などの条件を守れば、改変したものや組み込んだものを、ソースコードを公開せずに配布することも認める型です。コピーレフト型（GPL など）は、改変したものや組み込んだものを配布するときに、同じライセンスでソースコードを提供することを求める型です。コピーレフト型の中には、改変したものをネットワークを通じて使わせる場合にも、ソースコードを受け取る機会の提供を求めるもの（AGPL）もあります。

寛容型（MIT・Apache License 2.0）

MIT ライセンスは、著作権の表示と許諾の文を、ソフトウェアのすべての複製や重要な部分に含めることを条件に、使用・複製・改変・配布などを広く認めるライセンスです。ソフトウェアは「現状のまま」提供され、保証はないとされています。

Apache License 2.0 も寛容型で、配布するときに、ライセンスの写しを渡すこと、改変したファイルに変更した旨を示すこと、元の著作権・特許・商標・帰属の表示を残すことなどを条件としています。あわせて、貢献した人からの特許の利用の許諾も定めています。

出典：The MIT License（Open Source Initiative）
Apache License, Version 2.0（Open Source Initiative）

コピーレフト型（GPL・AGPL）

コピーレフトとは、改変したものや組み込んだものにも、元と同じ利用の自由を引き継がせる考え方です。代表的な GNU General Public License（GPL）バージョン3では、対象のソフトウェアを実行できる形（オブジェクトコード）で配布するときに、対応するソースコードも、GPL の条件で提供することを求めています。

一方で、GPL バージョン3は、コピーを渡さずにネットワークを通じて利用者とやり取りするだけでは「頒布（convey）」に当たらない、としています。そのため、サーバーの上で動かして Web サービスとして提供するだけの使い方では、GPL のソースコードの提供の義務は生じない、と説明されることが多いです。

これに対して、GNU Affero General Public License（AGPL）バージョン3は、改変したソフトウェアを、ネットワークを通じて利用者に使わせる場合にも、その利用者に対応するソースコードを受け取る機会を提供することを求めています。Web サービスとして提供するシステムで AGPL の部品を改変して使う場合は、注意が要ります。

出典：GNU General Public License version 3（Open Source Initiative）
GNU Affero General Public License version 3（Open Source Initiative）

どの使い方で、どこまでがソースコードの提供の対象になるかは、ライセンスの文面と使い方の組み合わせで判断が分かれることがあります。迷う場合は、ライセンスに詳しい専門家に確かめることをおすすめします。

発注者が確かめておきたいこと

発注者がオープンソースについて確かめておきたいことは、「何が使われているか」「条件を守っているか」「更新できるか」の3つです。

1. 何が使われているか：使った部品と、その版、ライセンスの一覧を受け取る
2. 条件を守っているか：著作権の表示やライセンスの写しが、決められた形で残されているか。コピーレフト型の部品を、配布するソフトウェア（お客様に渡すアプリなど）に組み込んでいないか
3. 更新できるか：部品に脆弱性が見つかったときに、新しい版に入れ替えられるか。開発が止まっている部品を使っていないか

IPA（情報処理推進機構）の「情報システム・モデル取引・契約書」では、オープンソースを含むソフトウェア（FOSS）を組み込む場合に、開発会社が主体で選ぶ場合の案として、開発会社が、利用の許諾の条件、機能、開発しているコミュニティの情報、機能上の制限などを書面で示して提案し、発注者が採否を決める形の条項例を示しています。開発会社が FOSS の権利の侵害や不具合がないことを保証するものではない、という考え方も示されています。

出典：情報システム・モデル取引・契約書（第二版）（IPA）

SBOMで部品の一覧を受け取る

使っている部品の一覧を作る方法として、SBOM（ソフトウェア部品表）があります。経済産業省は、2024年8月29日に「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引ver2.0」を公表しており、SBOMをソフトウェアの部品構成表と説明しています。ver2.0では、部品の発注者と供給者が契約で決める事項の例（SBOM取引モデル）も示されています。

SBOMがあると、ある部品に脆弱性が見つかったときに、自社のシステムがその部品を使っているかをすぐに確かめられます。ライセンスの一覧としても使えます。詳しくはSBOM（ソフトウェアの部品表）とはと、用語のSBOMで説明しています。脆弱性の情報の集め方は脆弱性の情報を、どう集めて優先順位をつけるかで扱っています。

出典：「SBOM」を活用してソフトウェアの脆弱性を管理する具体的手法についての改訂手引を策定しました（経済産業省、2024年8月29日）

契約と納品物に書いておくこと

発注のときに、次の点を契約書や仕様書に書いておくと、後の管理がしやすくなります。

• オープンソースを使う場合は、事前に部品とライセンスを示してもらい、発注者が確かめる
• 使ってよいライセンス、使う前に相談が要るライセンス（コピーレフト型など）を決めておく
• 納品物に、部品とその版・ライセンスの一覧（SBOMなど）を含める
• 公開した後に部品を更新する作業を、保守の範囲に入れるかを決める

成果物の著作権の扱いはシステム開発の成果物の著作権は誰のものかで説明しています。オープンソースの部品は、著作権を譲り受ける対象にはならず、ライセンスの条件で使い続けるものだという点を押さえておきます。本記事は一般的な整理です。個別のライセンスの解釈や契約の判断については、弁護士などの専門家にご確認ください。

当社のご支援

当社は、Webシステム開発で、公開した後の運用と改善まで同じチームで受け持っています。PHPで動くサイトのPHPのバージョンアップ支援では、使っている部品とその版の一覧を残し、次の版上げに備えます。いま使っているシステムの部品の版や脆弱性が気になる場合は、セキュリティ診断と対策でもお手伝いします。PHPで動くサイトは、無料のPHPバージョン診断で版を確かめられます。まずはお問い合わせからご相談ください。