「ライセンスって1つじゃないの？」「OSSを『配布する』ってどういうこと？」：解決！OSSコンプライアンス（5）

OSSコンプライアンスに関するお悩みポイントと解決策を具体的に紹介する連載「解決！ OSSコンプライアンス」。5回目は、「ライセンスって1つじゃないの？」「OSSを配布するってどういうこと？」という2つのエピソードと解決策を紹介する。

» 2022年06月15日 05時00分公開

[島直道，OpenChain Japan Work Group]

この記事は会員限定です。会員登録（無料）すると全てご覧いただけます。

　本連載では、オープンソースソフトウェア（OSS）の利活用に伴う「ライセンスリスク」と、それをマネジメントするための活動である「OSSコンプライアンス」について取り上げ、エンジニアの方がOSSをスムーズに利用するための実務上の勘所や、これから戦略的にOSSを活用していきたいと考えている企業の方へのヒントとなる情報を紹介しています。

　今回も前回に引き続き、ソフトウェア開発企業X社の新人開発者である新城くんが経験した、OSSコンプライアンス問題とその解決策を解説していきます。思わぬ落とし穴や難しい問題に直面しながらOSSコンプライアンスに対応していく新城くんのエピソードを通して、皆さんも理解を深めていってください。

　なお、本連載では、特に記載がない限り日本国内でOSSを活用する場合を前提としており、本連載の執筆チームの経験に基づいて説明を記載しています。厳密な法解釈や海外での利用など、判断に迷う場合は専門家にご相談ください。

■今回の登場人物

新城くん　日本のソフトウェア開発企業X社の新人開発者。OSSは指示を受けながらソフトウェア製品で利用した経験あり。

佳美先輩　X社の先輩エンジニアで、新城くんの指導担当。OSSを活用した開発の経験が豊富。

エピソード7　ライセンスって1つじゃないの？

　前回までにリリースしたソフトウェア製品の評判がよく、さらにビジネスを拡大していくために、クラウドサービスとして展開していくことになった。クラウド版の開発に当たり、利用できそうなOSSをインターネットで調べていたところ、幾つか使えそうなものを見つけた新城くん。早速、次の定例ミーティングで報告することにした。

新城くん、調査状況を報告してくれる？

はい、実装を予定している機能を含むOSSを幾つか見つけました。

ライセンスも調査できた？

はい。ただ、このOSSはちょっと変なんです。ダウンロードしたOSSの圧縮ファイルを解凍したら、Licenseのファイルが複数見つかったんです。これって解凍したディレクトリの直下で見つけたライセンスが適用されるということなんですか？

新城くん、複数のライセンスが含まれている場合っていうのはちょっと複雑だから、細かく調査する必要があるのよね。代表的なパターンを教えてあげるから、一緒に調べてみよう。

解説：複数ライセンスが含まれているケースについて

　1つのOSSに複数のライセンス文が含まれているケースは幾つか考えられます。代表的なパターンとしては、以下のものが挙げられます。

1. あるOSSが幾つかのOSSの組み合わせによって作られているケース

　OSSはソースコードが公開されていて、誰でも自由に改変・配布などの利用が許諾されているという性質上、さまざまな方法で再利用されています。

　例えば、より大きなソフトウェアを開発するためにOSSのライブラリを部品として用いることがあります。この結果、公開されているOSS自体が複数のOSSの組み合わせで作られている場合があります。

　また、あるOSSをベースに別の開発者が機能拡張を行い、元のOSSとは異なるライセンス文をつけて再公開するという場合もあります。

　このようなOSSを公開する際には各OSSのライセンス条件を全て満たす必要があるため、表面上は1つの大きなOSSに見えていても、その中には複数のOSSとそれぞれのライセンス文が含まれているということになります。

　例としては、インテルが開発・公開しているコンピュータビジョン向けライブラリであるOpenCVや、SSL/TLSプロトコルのオープンソース実装であるOpenSSL（バージョン1.1.1系まで）が挙げられます。

　OpenCVには「3rdparty」というディレクトリがあり、その中にさまざまなOSSのライブラリが含まれています。こうしたOSSそれぞれに、著作権表示とライセンス文があります。

　具体的には、画像フォーマットのエンコード／デコードのライブラリであるlibjpeg、libpng、libtiff、libwebpや、データ圧縮ライブラリであるzlibなど、OpenCVが提供する機能を実現するために多数のライブラリが使われており、これらの各ライブラリそれぞれにライセンス文があります。

　また、バージョン1.1.1系までのOpenSSLは、OpenSSL LicenseとOriginal SSLeay Licenseの両方のライセンスが適用されているため、これを利用する際には両方のライセンス条件に従う必要があります。

　OpenSSLの前身は、エリック・ヤング（Eric Young）という開発者が開発したSSLeayというSSLプロトコルの実装でした。その後このSSLeayを元に修正を加え、開発を継続するThe OpenSSL Projectというプロジェクト_（注1）が立ち上がり、その際にOpenSSL Licenseというライセンスが作られて、元となったオリジナルのSSLeayのライセンスに追加する形で適用されました。その結果、OpenSSL LicenseとOriginal SSLeay Licenseの両方が適用されるという経緯になっています。

2. デュアルライセンス、マルチライセンスのケース

　「AかBかのいずれかのライセンス条件に従うことで利用可能」となるライセンスが設定されているというような場合もあります。このようなライセンスを、デュアルライセンス（三択の場合はトリプルライセンス）、またはマルチライセンスといいます。

　この場合、選択肢のうちいずれかのライセンスを選択して従えばよいことになっています。

　また、デュアルライセンスには幾つかのパターンがあり、「OSSライセンス同士のデュアルライセンス」「OSSライセンスと商用ライセンスのデュアルライセンス」などの組み合わせがあります。

　例として、JavaのアプリケーションサーバであるJetty（バージョン10以降）はApache License 2.0とEclipse Public License 2.0のデュアルライセンス、データベースのMySQLはGNU General Public License 2.0と商用ライセンスのデュアルライセンスになっています。

　このようなデュアルライセンスは、他のライセンスのソフトウェアを組み合わせて1つの著作物を作成する際にライセンス条件を全て満たす「ライセンスの両立」を確保するために用意されていることがあります。このため、複数用意されているライセンスを好きに選ぶというよりは、組み合わせるソフトウェアのライセンスやユースケースに合わせて選択することになるでしょう。

　1.のケースとの見分け方は、READMEなどに “under a dual license of the A or B ...” というような説明が書かれていれば一目瞭然です。ただし、例えば古いJavaのライブラリでは、特段の注記がないものの、慣習的にCDDL-1.1とGPLv2 with Classpath Exceptionのデュアルライセンスになっているものがあったりしますので、その言語やプラットフォームのカルチャーを確認しなければならないこともあります。

3. 何らかの手違いやミスなどで複数のライセンス文が含まれているケース

　もともとCというライセンスだったが、あるタイミングでDというライセンスに変更されたものの、古いCのライセンス文を消し忘れていたため複数のライセンス文が含まれているというケースがあります。

　また、ダウンロードサイトに記載されているライセンスとダウンロードしたOSSに含まれるライセンスが異なるということもあるため、ライセンスを確認する際には注意が必要です。

　ダウンロードサイトには通常、最新バージョンのライセンス名が書かれていますが、ライセンス変更前の古いバージョンを利用する場合、古いバージョンに適用されていたライセンスが有効です。このような場合、どちらのライセンスが適用されているのかはchangelog（変更履歴）を参照することで確認できる場合があります。changelogを確認してもよく分からないなど、客観的にはどちらが正解か区別がつかない場合、OSSの作者に確認する必要があります。

注1：プロジェクト立ち上げ期には、The OpenTLS Projectという名称がついていた時期もあったようです。

OSSの作者の意図を理解する

　OSSのライセンスは、作者が自分の作品をどのように扱ってほしいか、あるいはどのような扱いは避けてほしいかという意思や意図を表したものであるともいえます。

　例えば、広場で「談笑したり飲食したりするのは良いけれど、火気を使うようなバーベキューは禁止」であるとか、「バーベキューをする際には必ず炭の燃えカス等含めゴミは全て片付けて持ち帰ること」「事前に所定の申請を行い許可を取ること」「所定の料金を払うこと」などの条件が定められているような状態をイメージすると分かりやすいかもしれません。

　企業が公開しているOSSでは、「製品や会社をプロモーションする」「有償でサポートを提供する」「業界でのシェア向上を図る」などといった意図に応じて、単一ライセンス、あるいは、デュアルライセンス／マルチライセンスになっていたりする場合もあるでしょう。また、このようなOSSの作者の意思や意図を類推することで、ライセンスを理解しやすくなることがあります。

エピソード8　OSSを配布するってどういうこと？

　ライセンスの調査が終わり、クラウドのサーバ側と、サーバにアクセスするためのクライアント側のソフトウェアにOSSを利用することになり、顧客向けのドキュメント作成を指示された新城くん。早速、ソフトウェア製品を作成したときと同じようにドキュメントを作成して、チームでのレビューを受けることになった。

新城くん、作成したドキュメントの内容を説明してくれる？

はい。ソフトウェア製品のドキュメントと同様に、サーバで利用するOSSとクライアントで利用するOSSの情報をまとめて記載しています。また、サーバではソフトウェア製品と同じようにMITライセンスとGPLv3_（注2）のOSSを利用するので、お客さまの要求に応じてソースコードを提供することも記載しました。
注2：GPLv3: GNU GENERAL PUBLIC LICENSE version 3

えっ、サーバで利用するだけなら、お客さまにOSSを配布しないからソースコードを提供する必要はないわよ。ライセンス順守の方法は、ライセンスだけじゃなくてそのOSSの利用方法（ユースケース）も考慮して検討しなければいけないの。一緒に考えてみようよ。

解説：OSSの配布について

　OSSの多くは、PCやサーバで動作させたからといって、著作権の表示やソースコードの提供などが必要になるというわけではありません。また、OSSのライセンスではソースコード形式で配布する場合や、バイナリコード形式で配布する場合、あるいはOSSに改変を加えて配布する場合など、利用方法に応じた場合分けで条件が定められていることがあります。このため、利用者はOSSを配布する際に自分のユースケースに対応するライセンスの利用条件を確認する必要があります。

　一部のライセンスを除き、一般的にはそのOSSの一部または全部を配布する際に、ライセンスで定められた対応が必要になります。OSSの配布に該当する行為の代表例としては以下のものが考えられます。

OSSを含むソフトウェア製品を提供する（有償・無償は問わない。OEM提供を含む。また、CD-ROM/DVD-ROMなどの物理媒体かダウンロード販売かは問わない）。
OSSを含むソフトウェア製品の評価版／試用版を提供する。
OSSを含むソフトウェア製品のアップデートを提供する。
家電製品やカーナビゲーションシステム、POS、スマートフォン等の機器に、OSSを含むソフトウェアを組み込んで販売・貸与（リースやレンタル）する（「貸与」は遊興施設やホテルの客室内等、特定の施設内での使用を前提として施設の運用者が貸し出す場合を除く）。
App StoreやPlayストアなどでOSSを含むアプリケーションを公開する（有償・無償は問わない）。
クライアントサイドで動作するJavaScriptなどのように、OSSがユーザー端末にダウンロードされるWebアプリケーションを公開・提供する。
Linux OSなどのOSSを含むディストリビューションを配布する。
OSSを含むコンテナイメージをコンテナリポジトリで公開する。
研究開発などで、OSSやOSSを含む成果物などを共同研究の相手組織や企業に提供する。

　逆に、配布に該当しない行為の代表例としては、以下のものが考えられます。

OSSを含む社内システムを運用する。
OSSを使って生成したものであるが、その生成物にはOSSを一切含まないものを配布する（OSSのエディタで書いたドキュメントや、OSSの開発環境を用いて開発した全て自作のソフトウェアなど）。
プロジェクト管理やテストなど、開発にOSSを用いるが、最終的に販売するソフトウェア製品にはOSSを含まない。
WebアプリケーションをSaaSで公開/提供するが、全てのOSSはサーバ側でのみ動作する。

　上記のようにOSSを配布しない使い方の場合は、ライセンス条件で配布時のソースコード提供などが定められていても、実施する必要はありません。もちろん、ソースコードを提供してはいけないということはありませんが、通常のビジネスにおいては、必要ないのであれば特段の意図がない限りソースコードを提供しないのが一般的と言えるでしょう。

　従って、「自社が行おうとしているビジネスがOSSの配布に当たるかどうか」、また、「どのようなOSSの使い方をする際に、何をしなければならないかがライセンスで定められているか」を確認することが重要です。

　ただし、これらの例外として、GNU Affero General Public License （AGPL）や、OSI承認ライセンスではありませんがServer Side Public License（SSPL）というライセンスが登場してきています。この2つは、たとえOSSを配布しない場合でもソースコードの提供が必要になる場合があります。これらのライセンスが適用されたソフトウェアを利用する場合は、一層注意が必要といえるでしょう。

ジョークライセンスをどう扱う？

　世の中には「ジョークライセンス」とも呼ばれる、一風変わったライセンスが存在します。「もし将来作者に会うことがあったらビールおごってね」という条件のあるThe Beer-ware License、どのような使い方も許諾する「煮るなり焼くなり好きにしろライセンス」をもじったNYSL（ライセンス）など、さまざまなライセンスが作られています。このようなライセンスも法的には有効であると思われますが、どのように取り扱うのかについては、各企業の法務担当部署など、専門家の意見を聞くのがよいでしょう。