developersIO
OSSライセンスについてまとめてみた

OSSライセンスについてまとめてみた

OSS
2025.12.06

こんにちは！製造ビジネステクノロジー部の小林です。

最近、負荷テストツールの k6 を導入しようとして調べていたところ、「AGPL-3.0」というライセンスで公開されていることを知りました。

「OSSだから自由に使えるよね？」と思っていたのですが、調べてみるとApache、MIT、GPLなど様々なライセンスがあり、それぞれ利用条件が異なることが判明しました。

「これ、よく理解せずに使ったらマズいのでは...？」と思い、OSSライセンスについて整理してみることにしました。

OSS とは？

OSS（Open Source Software） は、ソースコードが公開されており、誰でも自由に利用・改変・再配布できるソフトウェアのことです。

無償で利用できることが多い

  • ほとんどの OSS は無料で利用可能
  • ただし「オープンソース」は「ソースコードが公開されている」という意味であり、必ずしも「無料」を意味するわけではない
  • 実際には、サポート付きの有償版を提供しているOSSも多い（例：Red Hat Enterprise Linux、GitLab）

自由にカスタマイズできる

  • ソースコードが公開されているため、自分のニーズに合わせて改変できる
  • 実際のコードを読んで学習できるため、技術力向上にも役立つ

透明性とセキュリティ

  • コードの動作を直接確認できる
  • 世界中の開発者によってチェックされるため、脆弱性が発見されやすい
  • セキュリティ監査を自分で実施することも可能

コミュニティの力

  • グローバルな開発者コミュニティによる継続的な改善
  • 問題が発生した際には、世界中の開発者から助けを得られる

https://opensource.org/osd

OSS の例

OS

  • Linux、FreeBSD

Webサーバー

  • Apache HTTP Server、Nginx

データベース

  • MySQL、PostgreSQL、MongoDB

プログラミング言語

  • Python、Ruby、PHP

ライブラリ・フレームワーク

  • React、Vue.js、Django、Node.js

開発ツール

  • VS Code、Git、Docker

CMS（コンテンツ管理システム）

  • WordPress

その他

  • Android、Kubernetes

OSS のライセンスとは？

OSSライセンスは、ソフトウェアの使用・改変・配布を定めた利用規約です。

なぜライセンスが必要？

「オープンソース＝何でも自由」ではありません。

OSS は無償で利用できることが多いですが、利用する際のルールは各ライセンスによって異なります。ライセンスを確認しないと、以下のような問題が起こる可能性があります。

  • 商用利用したつもりが、実は禁止されていた
  • 改変したコードは社内だけで使うつもりだったが、公開義務があった
  • 著作権表示を忘れて、法的問題になった

そのため、OSS を使う前にライセンスを確認し、以下のようなルールを理解する必要があります。

  • 商用利用：ビジネスで使って良いか？
  • 改変：コードを変更して良いか？
  • 再配布：改変したコードを他の人に配布できるか？
  • ソースコード公開義務：改変したコードを公開する必要があるか？
  • 著作権表示：元の作者の名前やライセンス情報を残す必要があるか？

ライセンスを守らないとどうなるか？

OSS ライセンスは法的な契約であり、違反すると以下のようなリスクがあります。

法的リスク

  • 著作権侵害として訴訟を起こされる可能性
  • 損害賠償を請求されることもある

ビジネスへの影響

  • GPL 系ライセンスの場合、自社の商用コードの公開を求められる可能性
  • 製品の販売停止や回収を余儀なくされるケースもあり得る

ライセンス比較表

OSS ライセンスの違いを表にまとめました。用語の詳細は表の下で説明します。

ライセンス 商用利用 改変コードの公開 著作権表示 特許保護
MIT 可 不要 必要 なし
Apache 2.0 可 不要 必要 あり
BSD 可 不要 必要 なし
GPL 可 必要 必要 あり
AGPL 可 必要 必要 あり
LGPL 可 条件付き 必要 あり

表の用語説明

  • 商用利用：ビジネスで使えるか
  • 改変コードの公開：コードを変更した場合、その変更内容を公開する必要があるか
    • GPL：改変版を配布する場合は公開が必要
    • AGPL：改変版を配布する場合 + Webサービスとして提供する場合も公開が必要
    • LGPL：ライブラリ自体を改変した場合のみ公開が必要
  • 著作権表示：ソースコードやドキュメントに、元のライセンス文と著作権者名を残す必要がある
  • 特許保護：ライセンスに特許権の扱いが明記されているか
    • 「あり」の場合：コードの作者が持つ特許権も一緒に許諾される。後から「このコードは私の特許を侵害している」と訴えられるリスクが低い
    • 「なし」の場合：特許については触れられていない

OSS ライセンスの種類

MIT License

  • 最もシンプルで制約が少ない
  • 商用利用、改変、再配布すべて自由
  • 著作権表示とライセンス表示のみ必要
  • 使用例：React、Node.js、jQuery
  • こんな人におすすめ：広く使ってもらいたい、企業にも使ってほしい
  • MIT License 公式ページ

Apache License 2.0

  • 商用利用可能で制約が緩い
  • 特許権の明示的な許諾がある
  • 変更箇所の明示が必要
  • 使用例：Android、Apache HTTP Server、Kubernetes
  • こんな人におすすめ：企業利用を想定、特許関連の保護が欲しい
  • Apache License 2.0 公式ページ

BSD License (2条項/3条項)

  • MITに似た寛容なライセンス
  • 商用利用可能
  • 著作権表示が必要
  • 使用例：FreeBSD、Django
  • MITとの違い：3条項版は「プロジェクト名を勝手に使って宣伝してはいけない」という条項がある
  • BSD 3-Clause License

GPL (GNU General Public License)

  • コピーレフト型ライセンス
  • ソースコード公開義務あり
  • 派生物も同じライセンスにする必要がある（伝播性）
  • 使用例：Linux、Git、WordPress
  • 注意：GPLライブラリを使うと、自分のコードもGPLで公開する必要がある場合がある
  • こんな人におすすめ：改変版も公開してほしい
  • GPL v3 公式ページ

AGPL (GNU Affero General Public License)

  • GPLの派生版
  • ネットワーク経由のサービス提供も「配布」とみなす
  • SaaS対策として作られた（Webサービスでも公開義務が発生）
  • 使用例：k6
  • 注意：AGPLでは、ネットワーク経由でソフトウェアを利用させる場合、改変版のソースコード公開が義務付けられます。詳細はAGPLの公式ページで確認してください
  • こんな人におすすめ：SaaS化されても改変版を公開してほしい
  • AGPL v3 公式ページ

LGPL (GNU Lesser General Public License)

  • GPLより制約が緩い
  • ライブラリとしてリンクする場合は公開義務なし
  • ライブラリ自体を改変した場合は公開が必要
  • 使用例：FFmpeg、GTK
  • こんな人におすすめ：ライブラリとして使ってほしいが、利用者のコードまで公開を強制したくない
  • LGPL v3 公式ページ

ライセンスの分類について

OSS ライセンスは、元のコードを改変・利用して新しいソフトウェアを作った時のルールによって特徴が異なります。

一般的な分類と正式な用語について
よく「寛容型（Permissive）」vs「コピーレフト型（Copyleft）」という分類を見かけますが、実はOSI（Open Source Initiative）の公式見解では、この対立概念は正確ではありません。

OSIによれば

  • すべてのOSSライセンスは本来「permissive（許可的）」である
  • 区別するなら「相互性のある（reciprocal）」と「相互性のない（non-reciprocal）」という用語が適切

ただし、一般的な理解のために、以下では広く使われている分類を紹介します。

相互性のないライセンス（一般的に「寛容型」と呼ばれる）

  • 代表例：MIT、Apache、BSD
  • 特徴：改変したコードを公開する義務がない
  • 例：MITライセンスのライブラリを使って商用アプリを作る → 改変したコードを公開しなくてもOK

相互性のあるライセンス（「コピーレフト型」）

  • 代表例：GPL、AGPL、LGPL
  • 特徴：改変したコードも同じライセンスで公開する必要がある
  • 例：GPLライセンスのライブラリを使って商用アプリを作る → 改変したコードも公開が必要

参考：OSI FAQ - What is a "permissive" Open Source license?

実務での注意点

使用する側として

  • プロジェクトで使うライブラリのライセンスを確認
  • GPL ライブラリは商用製品に組み込むと公開義務が発生する可能性
  • 使用した OSS のライセンス文と著作権表示を自分のプロジェクトに含める
    • 例：LICENSEファイルや README に記載、アプリの「ライセンス情報」画面に表示
  • package.jsonやgo.modなどで依存ライブラリのライセンスをチェック

公開する側として

  • プロジェクトの目的に合ったライセンスを選ぶ
    • 広く使ってほしいなら MIT や Apache
    • オープンソースを守りたいなら GPL
  • LICENSE ファイルをリポジトリのルートに配置

まとめ

今回は OSS ライセンスについて整理してみました。

漠然と「無料で使えるもの」と認識していましたが、実際にはライセンスによって利用条件が異なることがわかりました。特に、GPL系のライセンスを使う場合は、自分のコードも公開する必要が出てくる可能性があるため、事前の確認が重要ですね！

よく調べずにうっかり使ってしまうと思わぬトラブルになりかねないので、プロジェクトで使うライブラリのライセンスは必ずチェックするようにしようと思います。この記事がみなさまの参考になれば幸いです。

参考リンク

その他のライセンス

今回紹介したのは代表的なライセンスです。他にも 40 種類以上の OSS ライセンスが存在します。特殊なライセンスに遭遇した場合は、以下のサイトで詳細を確認できます。

この記事をシェアする

関連記事

「OSS開発者は今何をするべきか？ソフトウェアサプライチェーン侵害対策を考える」参加レポート #oss_supplychain
quiver
2026.07.09
ちょっと話題の記事
マイクロソフト公式OSS「ghqr」でGitHub設定をベストプラクティス診断してみた
quiver
2026.05.01
SnykOpenSourceで始めるセキュリティチェック #Snyk
きだぱん
2025.03.21
Google Cloud の Assured OSS とは？ Google 検証済 OSS パッケージを活用しソフトウェアサプライチェーンを保護する #cm_google_cloud_adcal_2024
村田一紘
2024.12.22