Future Tech Blog
フューチャー技術ブログ
Infrastructureカテゴリ

エンジニアが最低限理解しておくべきOSSライセンスの基礎知識

フューチャー夏休み自由研究連載15本目の記事です。

はじめに

システム開発にてオープンソースのライブラリやフレームワークを利用することは、もはや当たり前となっています。
みなさんはOSSのライセンスについてどの程度理解していますでしょうか。
OSSだから無条件に利用可能だと思っていませんか？
本記事では、OSSのライセンスについて最低限エンジニアとして理解しておくべき内容を整理します。

なお、筆者は法学の専門家ではないことを事前にご了承ください。
本記事の内容は筆者個人の調査によるものであり、正確であるよう可能な限り努力しておりますが、間違いが含まれている可能性があります。あくまで参考資料としてご活用いただければ幸いです。

前提として

OSSとは

オープンソースソフトウェア（OSS）とは、利用者の目的を問わずソースコードを使用、調査、再利用、修正、拡張、再配布が可能なソフトウェアの総称となります。

オープンソースの定義については、Open Source Initiative（OSI）と呼ばれるオープンソースを促進することを目的とした組織によってOSD（Open Source Defition）という形でまとめられています。
現在はこのOSDが「オープンソースの定義」としてデファクトスタンダードになっています。

OSSライセンスとは

OSSライセンスとは、OSSの使用許諾条件のことであり、著作権に基づいてOSSの利用条件を定義するものとなります。逆に言えばOSSとは、OSSライセンスを遵守することを条件に使用が許諾されていると言うことができます。

OSSライセンスは、先に述べたOSSの定義に基づく限り、著作権者が独自に定めることができる（と筆者は認識しています）ものですが、OSIによって承認された代表的なライセンスが下記に一覧化されています。
https://opensource.org/licenses/alphabetical

実際にGitHubなどを覗いてみても、OSIによって承認されたライセンスで公開されているOSSがほとんどであることが確認できるでしょう。

OSSライセンスを理解する上でのポイント

OSSライセンスの種類は数多くありますが、各ライセンスを理解する上での重要なポイントとして下記の3点を取りあげます。

無保証

主要なOSSライセンスは「著作権者は、対象ソフトウェアの動作を保証せず、発生した結果について一切の責任を負わない」とする免責条項を持っています。
つまり、著作者は、そのソフトウェアについて、予期した動作をする/しないの保証をせず、また、その動作の結果何らかの損害をもたらしたとしても、それを保障しないと定めています。

著作権表示

もう1つ主要なライセンスに共通する特徴として、派生ソフトウェアを頒布する際は、利用元OSSの「著作権」「ライセンス文」「免責事項」などを表示しなければならない点が挙げられます。
具体的に「何を」「どこに」「どのように」表示するかは各ライセンスによって異なる可能性があるので、詳細は個別のライセンスを丁寧に確認する必要があります。

例えば MIT License では下記の記述によって「著作権表示」および「ライセンス文」を、「ソフトウェアのすべての複製または重要な部分に記載する」よう定められています。

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

また、著作権やライセンスをどこに記載するかに関しては派生ソフトウェアの頒布形式によって解釈が異なる模様です。
参考: https://opensource.stackexchange.com/questions/4058/what-is-the-point-of-including-the-mit-copyright-text-if-you-use-someones-code

  • ソースコード形式で頒布する場合
    利用元のソースコード中に「著作権」及び「ライセンス文」が含まれているため、意図的にこれらを除去するなどしなければ、特に何もする必要はない、と解釈できます。
    実際にOSSとして公開されている一般的なソースコードを見ても、これらについて特別に個別のファイルなどで明記していないものを見かけることは少なくありません。
  • バイナリ形式で頒布する場合
    バイナリを配布する場合はコンパイル時にライセンス文が消えてしまうため、バイナリとは別にライセンス表示用のファイルなどにまとめて記載し、頒布先に提供する必要があります。

正直筆者としては、この辺りの正確な解釈に自信がない（原文からは判断できない）のですが、要は派生ソフトウェアの利用者が派生ソフトウェア内で利用しているOSSのライセンスを知ることができないケースはNGとみて間違い無いでしょう。

補足: 誰に対して表示するか

著作権やライセンス文を「誰に」対して表示するかですが、これは派生ソフトウェアの頒布先となります。
例えば、あるアプリケーションがWeb APIを提供する場合などは、アプリケーション自体はエンドユーザに頒布されておらず、あくまでネットワークを介してアプリケーションの機能を利用しているだけ、と解釈できるので、このエンドユーザに対して著作権表示を行う必要がないケースがほとんどです。
※ 後述するAGPLライセンスのようなネットワーク経由の利用に対しても強い制限を持つライセンスなどは例外です。

A社がB社に、toC向けのWebアプリケーションの開発を依頼した、というケースでは、どうなるでしょうか。
この場合は下記のような整理になります。

  • B社はA社に対してアプリケーション自体を頒布しているため、B社はA社に対してアプリケーション内で利用しているOSSの著作権表示を行う義務が発生します。
  • A社はエンドユーザに対してアプリケーションの機能のみを提供しているため、エンドユーザ向けに著作権表示を行う必要はありません。

エンドユーザに対してネットワークを介した機能提供ではなく、アプリケーション自体を頒布するケース（SPAやiOS, Androidアプリなど）では、エンドユーザに対して著作権表示を行う義務があります。
スマホアプリ等では、アプリ内から著作権表示を確認できるものがほとんどでしょう。

コピーレフトと非コピーレフト

OSSライセンスを理解するにあたってコピーレフトの理解は非常に重要です。
コピーレフトとは「著作物の自由な利用・改変・再配布を認め、また、そこから派生した著作物についてこれらの行為を制限してはならない」という考え方です。
詰まるところ「あるOSSから派生ソフトウェアを作成して配布するときに元のOSSと同じ条件でソースコードを公開しなさい」ということです。
なお、このコピーレフトの考え方ですが、OSSを個人で利用する場合や自社内のみで利用する場合は当てはまりません。

OSSライセンスは、OSSの利用形態とライセンスの伝搬性の範囲に応じて下記のとおり分類できます。

利用形態

まずはOSSの利用形態について説明しましょう。

ソースコードの再利用

OSSのソースコードを直接改変したり、コードを追加したりする利用形態となります。

ライブラリとしての利用

OSSのソースコード自体には手を加えずライブラリとして利用する形態となります。
ライブラリのリンク方法は「静的リンク」と呼ばれる方法と「動的リンク」と呼ばれる方法があります。

  • 静的リンク
    実行可能形式のバイナリを作成する際に、ライブラリを含む必要なコードの実態を全てリンクしてモジュールに含める方式
  • 動的リンク
    実行可能形式のバイナリにライブラリの実体を含めず、プログラムの実行開始時にローダによってリンクする方式
ネットワーク経由での利用

OSSを利用して、ネットワークサービスを提供する形態となります。
例えばWeb APIを提供する場合などがこれにあたります。

ライセンスの分類

さてOSSの利用形態が理解できたところで、次にライセンスの分類について見ていきましょう。
OSSライセンスは「コピーレフト型」「準コピーレフト型」「非コピーレフト型」のいずれかに分類できます。

コピーレフト型

元となるOSSのソースコードを再利用またはライブラリとして利用した際に、元のOSSと同じ条件で配布する必要があるものをコピーレフト型のライセンスといいます。

主要なところではGPLライセンス（GPL-2.0, GPL-3.0）がこれに該当します。
GPLでライセンスされたOSSを組み込む場合、それがライブラリとしての利用であったとしても、派生したソフトウェアはGPLライセンスで公開しなければならないということです（その特性からGPL汚染と言われたりもします）。

ただし、GPLライセンスのOSSを利用して、Web APIなどのネットワークサービスを提供する場合はこの限りではありません（ソースコードの公開などのコピーレフトは発生しません）。
ネットワーク経由でサービスを利用するエンドユーザは、ソースコードへアクセスする権利を持つ利用者には該当しないからです。

一方でコピーレフト型のライセンスの中で最も強い伝播性を持つAGPL（Affero General Public License）と呼ばれるものもあります。これはネットワークサービスを提供する場合にもコピーレフトが必要とされるライセンスとなります。

準コピーレフト型

OSSのソースコードを再利用した場合のみ、元のOSSと同じ条件で配布する必要があり、ライブラリとしての利用やネットワーク経由での利用はコピーレフトの対象とならないものを準コピーレフト型のライセンスといいます。

主要なところではLGPLライセンス（LGPL-2.1, LGPL-3.0）がこれに該当します。
LGPLライセンスはライブラリを静的リンクするか、動的リンクするかに応じて、異なる要求がある点が注意です。
※いずれにしても派生ソフトウェアをLGPLライセンスで公開する必要はありません。

下記を参考にすると次のように解釈できます。
https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic

  • 静的リンクする場合
    リバースエンジニアリングを禁止せず、アプリケーションのオブジェクトコードまたはソースコードの提供が必要となります。
  • 動的リンクする場合
    特に制約はありません。
  • 静的、動的にかかわらずアプリケーションと一緒にライブラリを配布する場合
    ライブラリのソースを配布またはリンクなどを公開する必要があります。

ところで、この静的リンクと動的リンクは具体的にどのように判断すれば良いのでしょうか。
CやC++のような明確なリンク作業を必要とするコンパイル言語を対象とする場合はあまり判断に困らない気がしますが、Javaのようなリンクという明確な作業を必要としない言語や、はたまたPythonのようなインタプリタ言語におけるライブラリの利用はどうなるのでしょうか。

Javaについては公式のQ&Aにて説明があるとおり、ライブラリの利用は「静的リンク」と解釈される模様です。
https://www.gnu.org/licenses/lgpl-java.ja.html

他の言語について正確なところは筆者も判断できません（し明文化もされていないと思われます）が、
import文などを利用してソース内にてライブラリを参照する記述を行っている場合は、静的リンクと解釈しておいた方が良さそうです。

非コピーレフト型

OSSを利用をした際に、元のOSSと同じ条件で配布する必要がないものです。
MIT License や Apache License 2.0, BSDライセンス（BSD 2-clause License, BSD 3-clause License）などがこれに該当します。

主要なライセンス

上記を踏まえつつ、我々が普段目にすることの多い主要なライセンスについて一覧化してみます。

とある調査によると、近年は非コピーレフト型のライセンスが多く好まれる傾向があり、
その中でも MIT License や Apache License 2.0 が上位にきていることがわかります。
https://resources.whitesourcesoftware.com/blog-whitesource/top-open-source-licenses-trends-and-predictions

ライセンス名 商用利用 著作者による保証 著作権・ライセンス表示 類型
MIT License 可 無 要 非コピーレフト
Apache License 2.0 可 無 要 非コピーレフト
BSD 3-Clause License 可 無 要 非コピーレフト
BSD 2-Clause License 可 無 要 非コピーレフト
LGPL 2.1 可 無 要 準コピーレフト
LGPL 3.0 可 無 要 準コピーレフト
GPL-2.0 可 無 要 コピーレフト
GPL-3.0 可 無 要 コピーレフト
AGPL-3.0 可 無 要 コピーレフト

上記の表では一見同じに見えても細かい条件が異なりますので、必ず利用の際には詳細な確認をしてください。
GitHubが公開しているライセンスのガイドラインは、各ライセンスで何が認められていて何が制限されているかが非常にわかりやすく整理されているのでお勧めです。
https://choosealicense.com/appendix/
表のリンク先もこのGitHub社のページへリンクするようにしています。

ライセンス違反とならないために

ここまでOSSライセンスの基礎についてご説明しましたが、いかがでしょうか。
最後にライセンス違反とならないための心得を記載して本記事を終わりにしたいと思います。

OSSライセンスをきちんと自分の目で読み理解する

OSSライセンスの基礎を理解することはもちろんですが、実際に自分の目できちんとライセンス文自体を読んでみることが重要です。ブログを読んで、この記事に書かれていたから大丈夫と鵜呑みにするのは大変危険です。
原文を読むのはハードルが高いという方は、オープンソースグループ・ジャパンなどが公開している日本語訳と照らしながら読んでみるといいかもしれません。
https://osdn.net/projects/opensource/wiki/licenses

またGNUライセンスについては、Q&Aが公開されていたりするので、こういったものも参考になるでしょう。
https://www.gnu.org/licenses/gpl-faq.html.en
（日本語訳はこちら）

法務部門や弁護士など専門家のレビューを受ける

エンジニア個人のレベルで、ライセンスに違反していないかどうかを完全に判断することはまず不可能です。
必ず専門家に依頼して確認を実施するようにしましょう。

補足: ツールを利用してOSSのライセンスを一覧化する

GitHub謹製の licensed を利用することで、インストールしたOSSライブラリのライセンスを一覧化できます。本ツールをCIに組み込むことで、ライブラリが追加される度にライセンスを一覧化し、チェックするという運用が実現できそうですね。
https://github.com/github/licensed

デフォルトでは下記のライブラリ管理ツールがサポートされています。

  • Bower
  • Bundler
  • Cabal
  • Composer
  • Git Submodules (git_submodule)
  • Go
  • Go Dep (dep)
  • Gradle
  • Manifest lists (manifests)
  • Mix
  • NPM
  • NuGet
  • pip
  • Pipenv
  • Yarn

本ツールのREADMEに免責事項として記載されているとおり、これは完全なライセンスのチェックを保証ツールではないので、あくまで人間のレビューの補助ツールとして利用することをお勧めします。

参考