レッスン4：OSS ライセンスを読む——MIT ／Apache 2.0 ／GPL

このレッスンで学ぶこと

オープンソースが「無料」ではなく「条件付きの許諾」であることを理解する
OSSライセンスが定める代表的な義務を把握する
MIT・Apache 2.0・GPL・AGPL・LGPLといった主要ライセンスの違いを比較できる
非エンジニアがツールを選ぶときに確認すべき手順を身につける

レッスン2・3では、画像や動画といった「素材」を使う実務を扱いました。今回は、素材ではなく「ツール」を使う実務として、オープンソースソフトウェア（OSS）のライセンスを取り上げます。エンジニアだけの話だと思われがちですが、業務でツールやライブラリを選ぶ立場にある人であれば、誰にとっても関わりのあるテーマです。

オープンソースは「無料」ではなく「条件付きの許諾」

オープンソースソフトウェアは、多くの場合、無料でダウンロードし、利用できます。この手軽さから、「オープンソース＝無料で自由に使えるもの」という印象を持つ方が少なくありません。しかし、これは正確な理解ではありません。

オープンソースソフトウェアは、著作権法上は通常のソフトウェアと同じく著作物です。作者が著作権を放棄しているわけではなく、「一定の条件を守るなら、誰でも自由に使ってよい」という許諾を、ライセンスという形で与えているにすぎません。無料であることと、無条件であることは別の話です。

💡 ポイント オープンソースは「タダで使えるソフトウェア」ではなく、「条件付きで使わせてもらっているソフトウェア」と理解するのが正確です。条件を守らなければ、無料であっても著作権侵害になりえます。

この条件は、ライセンスの種類によって内容が異なります。同じ「オープンソース」という括りの中に、ごく緩やかな条件のものから、厳格な条件のものまで、幅広いバリエーションが存在します。次のセクションから、代表的な条件の内容を見ていきます。

OSSライセンスが定める代表的な義務

OSSライセンスが利用者に課す義務には、いくつかの共通したパターンがあります。代表的な4つを紹介します。

義務1:著作権表示 ソフトウェアを利用・配布する際、元の作者の著作権表示を残すことを求める義務です。ほとんどのOSSライセンスに共通して含まれています。

義務2:ライセンス告知 ソフトウェアを配布する際、そのソフトウェアがどのライセンスの下で提供されているかを明示する義務です。ライセンス文書そのものを添付することを求めるライセンスもあります。

義務3:同一ライセンスでの再配布（コピーレフト） そのソフトウェアを改変して配布する場合、改変後のソフトウェアも同じライセンスで公開することを求める義務です。この性質を持つライセンスは、次のセクションで詳しく扱います。

義務4:特許条項 ソフトウェアに関連する特許について、利用者への実施許諾や、逆に訴訟を起こした場合のライセンス失効といった条件を定める義務です。比較的新しいライセンスに多く見られます。

すべてのOSSライセンスが、この4つすべてを課しているわけではありません。どの義務を、どの程度課しているかの組み合わせによって、ライセンスの性格が大きく変わります。

主要ライセンスの比較

代表的なOSSライセンスの特徴を比較します。細かな法的文言の解釈は専門家に委ねるべき領域ですが、業務でツールを選ぶ際に押さえておきたい大枠の傾向を整理します。

ライセンス	著作権表示	改変部分の同一ライセンス化	主な性格
MITライセンス	必要	不要	非常に緩やかで、商用利用・改変・再配布とも自由度が高い
BSDライセンス	必要	不要	MITと同系統で緩やか。派生形が複数存在する
Apache License 2.0	必要	不要（特許条項あり）	MIT系より条件はやや詳細だが、緩やかな部類。特許に関する条項を含む
GPL(v2・v3)	必要	必要	改変・組み込みをしたソフトウェア全体を同じライセンスで公開する義務がある
LGPL	必要	ライブラリ部分のみ必要	GPLよりも緩やかで、ライブラリとして利用する分には自社コードの公開義務が生じにくい
AGPL	必要	必要（ネットワーク経由の利用も対象）	GPLよりもさらに厳格。サーバー経由で利用させる場合も公開義務が生じる

この表からわかるように、MIT・BSD・Apache 2.0は、比較的緩やかな条件で使えるライセンスです。一方、GPL系統のライセンスは、改変したソフトウェアを配布する際に、ソースコードを同じ条件で公開する義務が発生する点が大きな特徴です。

🔰 初学者の方へ ライセンスの名前を見ただけで条件を判断するのは難しいものです。まずは「このライセンスは、改変した場合に自社のコードも公開しなければならないタイプか」という1点だけでも確認する習慣をつけましょう。この1点を押さえるだけで、多くのリスクを回避できます。

コピーレフトという考え方と「感染」という現象

GPL系統のライセンスが持つ、「改変・組み込みをしたソフトウェアも同じ条件で公開しなければならない」という性質は、「コピーレフト」と呼ばれます。著作権（コピーライト）が権利者に独占を認める考え方であるのに対し、コピーレフトは「自由な利用と再配布の権利を、後の利用者にも引き継がせる」という考え方に基づいています。

コピーレフトの狙いは、オープンソースの精神を維持することにあります。誰かが自由に使えるソフトウェアを改良したときに、その改良版を独占して公開しないという行動を防ぐ仕組みです。

一方、この性質は実務上、しばしば「感染」という俗称で呼ばれます。GPLのライブラリを自社の製品コードに組み込んで配布すると、組み込んだ自社コードの部分まで、GPLの条件が及んでしまう可能性があるためです。「一部だけGPLで、残りは非公開」という都合のよい組み合わせが難しいという特徴を指して、こう呼ばれています。

⚠️ 注意 「感染」という表現はやや刺激的ですが、実態を的確に表しています。GPLライブラリを製品に組み込む前に、この性質を理解していないと、意図せず自社の製品コード全体を公開しなければならない事態になりかねません。組み込みを検討する際は、必ず事前に確認しましょう。

自社製品に組み込む場合と社内利用のみの場合の違い

コピーレフトの影響は、そのソフトウェアをどう使うかによって大きく変わります。ここが実務で最も誤解されやすいポイントです。

社内でのみ利用する場合 社内の業務効率化ツールとして、GPLのソフトウェアをそのまま使う、あるいは社内向けに改変して使うだけであれば、外部への配布が発生しないため、ソースコードの公開義務が生じないのが一般的な理解です。多くのOSSライセンスの義務は「配布」を条件に発生するためです。

社外に配布・提供する場合 GPLのソフトウェアを組み込んだ製品を販売したり、社外の顧客に提供したりする場合は、話が変わります。組み込んだ製品全体について、ソースコードを公開する義務が生じる可能性があります。

AGPLが対象とする、サーバー経由での提供 AGPLは、この「配布」の考え方をさらに広げ、ソフトウェアを直接配布しなくても、サーバー経由でユーザーに機能を使わせる場合（SaaSのような形態）も、義務の対象に含めています。「配布していないから大丈夫」という従来の理解が通用しない点が、AGPLの特徴です。

この違いを整理すると、「使う目的が社内向けか、社外向けか」「配布という形を取るか、サーバー経由での提供か」という2つの軸で、義務の発生範囲が変わってくることがわかります。

📝 補足 「配布」の定義や、義務がどこまで及ぶかの解釈は、法的に専門的な判断を要する場面があります。自社製品にGPL系のソフトウェアを組み込む可能性がある場合は、判断を個人の理解だけに委ねず、法務や技術部門と連携して確認することをすすめます。

非エンジニアがツールを選ぶときの確認手順

エンジニアではない立場でも、業務でツールやソフトウェアの導入を検討する場面はあります。専門的なライセンス解釈まではできなくても、次の手順を踏むことで、大きなリスクは避けられます。

手順1:そのツールがオープンソースかどうかを確認する 公式サイトやドキュメントに、ライセンスの種類が明記されていることが一般的です。

手順2:ライセンスの名称を確認する MIT・Apache・GPL・AGPLなど、どのライセンスが採用されているかを確認します。

手順3:自社での利用形態を整理する 社内でのみ使うのか、製品に組み込んで社外に提供するのか、SaaSのような形でサービス提供するのかを整理します。

手順4:GPL系統かどうかで、慎重さのレベルを分ける MIT・BSD・Apache系であれば、比較的リスクは低い部類です。GPL・AGPL系統で、かつ社外への提供を予定している場合は、技術部門や法務への確認を挟むことをすすめます。

手順5:わからない場合は、社内の技術部門に確認する 自分だけで判断がつかない場合、無理に判断せず、社内の技術部門や、ライセンスに詳しい担当者に相談する経路を持っておきます。

この5つの手順は、専門知識がなくても実行できるチェックリストとして機能します。「オープンソースだから安心して使える」のではなく、「オープンソースだからこそ、条件を確認してから使う」という順序を守ることが大切です。

SBOMという言葉に出会ったら

近年、SBOM（エスボム、Software Bill of Materials、ソフトウェア部品表）という言葉を耳にする機会が増えています。SBOMとは、あるソフトウェア製品が、どんな部品（ライブラリやコンポーネント）で構成されているかを一覧化したものです。

取引先から「御社の製品のSBOMを提供してください」と求められる場面が、今後増えていくと考えられます。これは、製品に組み込まれているOSSのライセンスや、既知の脆弱性を、取引先が事前に把握したいという背景から生まれた要求です。

非エンジニアの立場でSBOMそのものを作成することはありませんが、「自社の製品やサービスが、どんなOSSで構成されているかを一覧で把握しておく」という発想自体は、業務のさまざまな場面で役立ちます。取引先からSBOMを求められた際に、社内のどこに情報があるかを把握しておくだけでも、対応がスムーズになります。

📖 もっと詳しく SBOMは、ソフトウェアの構成部品を管理するという観点では、レッスン2で紹介した素材台帳と似た発想の仕組みです。素材台帳が画像や音源の出所を記録するように、SBOMはソフトウェアの部品の出所とライセンスを記録します。分野は違っても、「何を、どこから、どんな条件で入手したかを記録する」という考え方は共通しています。

判断の流れを図で確認する

ここまで説明した内容を、実際の判断フローとして整理します。次の図は、ツール導入を検討する際に、どの段階で誰に相談すべきかを示したものです。

flowchart TD
  A[ツール・ライブラリを見つけた] --> B{ライセンスは MIT / BSD / Apache系か}
  B -->|はい| C[社内・社外どちらの用途でも比較的リスクは低い]
  B -->|いいえ・GPL系か| D{社内利用のみか}
  D -->|はい| E[公開義務が生じにくいが技術部門に一報しておく]
  D -->|いいえ・社外提供や配布を伴う| F[技術部門・法務に必ず確認]
  B -->|ライセンス表記が見当たらない| G[提供元に確認するか導入を保留]

この図からわかるように、最初に確認すべき分岐点は「ライセンスの系統」であり、次に確認すべき分岐点は「利用形態」です。この2つの軸さえ押さえておけば、専門的な法律知識がなくても、相談すべきタイミングを逃さずに済みます。

ケーススタディ:社内ツールと外部提供ツールの違い

企画部門のCさんは、社内の業務効率化のために、あるオープンソースのタスク管理ツールを導入しようとしていました。調べてみると、このツールはGPLライセンスで公開されていました。

Cさんは最初、「GPLと聞いたことがあるから、なんとなく避けたほうがよさそうだ」と考えましたが、レッスンで学んだ手順を思い出し、まず自社での利用形態を整理しました。このツールは社内のメンバーだけが使う予定で、外部の顧客に提供したり、改変版を配布したりする計画はありません。

この場合、GPLの公開義務は主に「配布」を条件に発生するため、社内利用のみであれば、ソースコードの公開義務が生じる可能性は低いと考えられます。念のため、Cさんは技術部門に「社内利用限定のGPLツールを導入したい」と一報し、利用形態に変更が生じた場合（例えば将来、顧客向けの機能として外部提供する可能性が出てきた場合）は、改めて確認する約束を取り付けました。

一方、別の案件で、Cさんのチームが開発中の自社サービスに、同じGPLのライブラリを組み込もうとする計画が持ち上がりました。この場合は「社外への提供」に該当するため、Cさんは導入を保留し、技術部門と法務に相談する場を設けました。結果として、同じ機能を持つApache License 2.0のライブラリに切り替えることで、公開義務のリスクを避けながら開発を進められました。

このケーススタディが示すのは、同じライセンスのソフトウェアでも、使い方によって注意すべき度合いが変わるという点です。「GPLだから絶対に使わない」と一律に避けるのではなく、利用形態を整理したうえで判断することが、実務的な対応につながります。

まとめ

このレッスンでは、以下のことを学びました。

オープンソースは無料であっても無条件ではなく、著作権法に基づく「条件付きの許諾」である
OSSライセンスは、著作権表示・ライセンス告知・同一ライセンスでの再配布・特許条項といった義務を課すことがある
MIT・BSD・Apache 2.0は比較的緩やかで、GPL・AGPLは改変部分の公開義務（コピーレフト）を伴う点で性格が異なる
社内利用のみか、社外への配布・SaaS提供かによって、義務が発生する範囲が変わる
非エンジニアでも、ライセンスの種類を確認し、利用形態を整理し、判断に迷ったら技術部門に相談するという手順でリスクを避けられる

次のレッスンでは、素材やツールの話から離れ、人を撮影し、名前を使う場面での肖像権とパブリシティ権を扱います。

確認クイズ

このレッスンの理解度をチェックしましょう。