「ライセンスが英語で分からない！」「ソースコード提供ってどういう方法でやればいい？」：解決！ OSSコンプライアンス（3）

OSSコンプライアンスに関するお悩みポイントと解決策を具体的に紹介する連載「解決！ OSSコンプライアンス」。3回目は、「ライセンスが英語で分からない！」「ソースコード提供ってどういう方法でやればいい？」という2つのエピソードと解決策を紹介する。

» 2022年03月16日 05時00分公開

[大内佳子, 渡邊歩，OpenChain Japan Work Group]

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

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

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

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

■今回の登場人物

新城くん　日本のソフトウェア開発企業X社の新人開発者。OSSは今回のプロジェクトで初めて利用する。

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

エピソード3　ライセンスが英語で分からない！

　佳美先輩に手伝ってもらって見つけたライセンスファイルを開いてみると、中身は英語の文章だった。学生時代から英語は大の苦手の新城くん、何が書いてあるのかさっぱり分からない。ライセンス調査の結果を報告しなければならない定例会が明日に迫り、焦ってインターネットで検索したところ、日本語で解説してくれているページを発見。「これはいい！なんと親切なページだろう」

　解説ページに書かれている内容をまとめて、新城くんは定例会に臨むことにした。

新城くん、ライセンス調査の結果を報告してくれる？

ええ？　表示しなければならないのは、OSSの著作者の著作権であって、うちの会社の著作権ではないよ。それに、WebサイトのURLはサイトの管理者が変更することもあるから、リンク切れになったら何のライセンスか分からなくなるよ。ちょっと新城くん、ライセンスはちゃんと読んでみたの？

実は、英語は苦手でライセンスの内容が理解できなかったので、インターネットに書いてある情報を参考にしたんです……。

インターネットの情報を参考にするのもいいけど、自分できちんとライセンスを読まないとね。MITライセンスの読み方を教えてあげるから、一緒に読んでみよう。

解説：MITライセンスで、ライセンスの読み方を知る

　OSSのライセンスはほとんどが英語なので、英語が苦手な人にとっては、解釈が難しいかもしれませんが、必ずライセンスを読み、内容を理解してから利用してください。ここでは、Open Source Group Japanの日本語の参考訳_（注1）を使ってMITライセンスを解説していきます。

　MITライセンスは、以下の4つに区分できます。

（1）著作権表示

　まず、１行目に以下のように著作権表示が記載されています。

Copyright (c) ＜year＞＜copyright holders＞

　(c)は©マークがプログラムで表示できないため、代わりに形を似せて記載したものです_（注２）。“year”は著作権の保護期間の開始年（最初の発行年）になります。"copyright holders"というのは、著作権者のことです。自社以外で開発されたOSSを使用する場合は、そのOSSの著作権者の名前が記載されているはずですので、それをそのまま利用します。新城くんは間違って自社の名前を入れていましたが、OSSを単に使用するだけの人は著作権者ではありませんので、新城くんの会社名を記載することはできません。

（2）許諾する利用行為

　前回、著作権は、複製、改変、配布などの行為をコントロールできる権利だと説明しました。MITライセンスの最初の段落には、著作権者がどのような行為を許諾するかを記載しています。

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

以下に定める条件に従い、本ソフトウェアおよび関連文書のファイル（以下「ソフトウェア」）の複製を取得するすべての人に対し、ソフトウェアを無制限に扱うことを無償で許可します。これには、ソフトウェアの複製を使用、複写、変更、結合、掲載、頒布、サブライセンス、および/または販売する権利、およびソフトウェアを提供する相手に同じことを許可する権利も無制限に含まれます。

　日本の著作権法では、著作権者が占有する権利（複製権、公衆送信権、譲渡権、翻案権など）を第21条から第28条に記載していて、OSSの利用者は著作権者の許諾がなければ、これらの行為をすることはできません。

　MITライセンスでは、「ソフトウェアを無制限に扱うことを無償で許可」する旨と、その中に「使用、複写、変更、結合、掲載、頒布、サブライセンス、および/または販売する権利、およびソフトウェアを提供する相手に同じことを許可する権利」が含まれることを明記しています。

　今回、新城くんのプロジェクトは、ソフトウェア製品にOSSを組み込んで利用します。すなわち、OSSを複製（copy）したり、改変（modify）したり、製品の顧客へ譲渡（distribute）したりすることが考えられ、これらの行為はMITライセンスで許諾されていることが分かります。ただし、「以下に定める条件に従い」とのことですので、条件を順守する必要があります。

　それから、「本ソフトウェアおよび関連文書のファイル」を"ソフトウェア（Software）"と定義しているところに注目してください。多くのライセンスでは、このように定義用語の最初の文字を大文字にしています。MITライセンスには出てきませんが、仮に、"software"と小文字の単語が出てきたら、一般のソフトウェアを意味しているので、MITライセンスが適用された"Software"とは区別して解釈することになります。しかし、日本語の参考和訳だと、どちらも「ソフトウェア」となり、区別できなくなることがありますので、英語の原文と日本語の参考和訳の両方を確認しながら解釈してください。

（3）利用条件

　次の段落には、OSSを利用する際の条件が記載されています。

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

上記の著作権表示および本許諾表示を、ソフトウェアのすべての複製または重要な部分に記載するものとします。

　新城くんは、著作権表示とダウンロードサイトに掲載されたMITライセンスのURLを記載すればいいと誤解していましたが、ライセンスでは本許諾表示を記載することも求められており、正しくは、「著作権表示を含むMITライセンス全文」を記載する必要があります。

（4）免責条項

　最後の段落には、OSSには一切の保証はなく、著作権者は一切の責任を負わない旨が掲載されています。このような免責の条件は、無償で利用許諾されるOSSのほとんどのライセンスに記載されています。また、英文の場合、目立つように大文字で記載されていることが多いです。

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

ソフトウェアは「現状のまま」で、明示であるか暗黙であるかを問わず、何らの保証もなく提供されます。ここでいう保証とは、商品性、特定の目的への適合性、および権利非侵害についての保証も含みますが、それに限定されるものではありません。作者または著作権者は、契約行為、不法行為、またはそれ以外であろうと、ソフトウェアに起因または関連し、あるいはソフトウェアの使用またはその他の扱いによって生じる一切の請求、損害、その他の義務について何らの責任も負わないものとします。

　以上より、新城くんは、上記の（3）利用条件に従うと、MITライセンスの（1）著作権表示、（2）許諾する利用行為、（3）利用条件、（4）免責条項を含む、ライセンス全文を記載する必要があるということになります。

　ライセンスを参照するときには、自分のやろうとしている行為が許諾されているか、そのための条件にどのような内容があるか、その内容を順守できるかを確認する必要があります。また、ライセンスによっては、禁止事項を設けているものもあるので、自分の利用方法がその禁止事項に該当しないかも確認する必要があります。さらに、ライセンスの中で用語を定義しているものがあり、一般的な意味とは異なることがありますので内容を理解するときには注意が必要です。

注1：オープンソースライセンスの日本語参考訳
https://licenses.opensource.jp/
上記サイトのライセンスは、Attribution 4.0 International（CC BY 4.0）です。
https://creativecommons.org/licenses/by/4.0/
注2：万国著作権条約にて、加盟国の著作物を保護するための要件として著作権表示（©、最初の発行年、著作権者）を付すことが定められていました。その後、著作権表示を不要とするベルヌ条約に多くの国が加盟したため表示は必須ではありませんが、著作権者を明確にするために現在でも多くの著作物に表示されています。

ライセンスの名称と作成者

　ライセンスの名称には、ライセンスを作成した組織の名前が付くことがあります。

　例えば、MITライセンスは、マサチューセッツ工科大学（Massachusetts Institute of Technology）にて作成されたライセンスです。

　Apache License は、Apache Software Foundationが作成したライセンスです。ライセンスの改変に合わせてバージョンが付けられていて、バージョン1.0と1.1はApache Software Licenseという名称でしたが、バージョン2.0からApache Licenseという名称になりました。

　Eclipse Public License（EPL）は、Eclipse Foundationが作成したライセンスで、バージョン1.0と2.0があります。また、このライセンスは、IBMのCommon Public License (CPL)がベースになっており、CPLはIBM Public License （IPL）がベースになっています。

　Mozilla Public License（MPL）はバージョン1.0をNetscape Communicationsが作成したライセンスで、その後Mozilla Foundationが独立して、MPLバージョン1.1、2.0が作成されました。

　Common Development and Distribution License（CDDL）は、Sun Microsystemsが作成したライセンスで、MPL version 1.1 がベースになっています。Sun MicrosystemsがOracleに吸収合併されたことから、ライセンスの中に記載された企業名が変更され、バージョンが1.0から1.1に変更されました。

　なお、同じライセンスでもバージョンによって内容が異なりますので、ライセンスを確認する際にはバージョンにも注意するようにしてください。

エピソード4　ソースコード提供ってどういう方法でやればいい？

　佳美先輩に教えてもらってライセンスの読み方を理解した新城くん。ソフトウェア製品で仕様が変更され、他のOSSも使う方が製品機能の実現への近道であることが分かった。ライセンスを調査すると、GPL v2だった。早速GPL v2のライセンスを読んでみたところ、OSSを配布する場合は、ライセンス全文を添付し、ソースコードも提供する必要があるなど、いくつかの条件を順守しなければならないことが分かった。

　開発は順調に進み、新城くんはライセンスに従って必要なドキュメントの準備に着手したが……。

佳美先輩、今回使用しているGPL v2のOSSについては、ソースコードを提供しないといけないんですが、具体的にどうやったらいいんでしょうか？

いい質問だね。一緒にライセンスを見てみよう。ソースコード提供のやり方については3条に書かれているね。

他社がどのようにしているかを調べたところ、Webサイトからダウンロードできるようにしている会社を見つけました。

それも一つのやり方だね。うちは、その方法だと実績がないからちょっと難しいな。他の方法はあるかな？

製品と一緒にソースコードを配布するか、ソースコードを提供する旨の書面による申し出でも良いんですね。

今回は、書面による申し出を記載することにしよう。新城くん、利用するOSSの情報を含めて、製品に添付するドキュメントのドラフトを作ってくれるかな。GPL v2のライセンス文を添付する準備もお願いね。

解説：GPLに従ってソースコードを提供するには　

　OSSのライセンスには非常に多くの種類がありますが、その中でも有名なものに、GNU GENERAL PUBLIC LICENSE（GPL）があります。現在の最新のバージョンは3.0ですが、以前のバージョン2.0が適用されるOSSも数多くあります。GPLには「コピーレフト」と呼ばれる特徴があり、GPLが適用されるOSSの全体または一部を含む著作物や、これらから派生した著作物を作成し頒布する場合、その派生著作物全体のソースコードを提供しなければなりません。GPLが適用されるOSSを利用する際は、このソースコード提供の条件を順守できるかどうかを検討する必要があります。

　ソフトウェア製品にOSSを組み込んだ場合、GPLに従ってソースコードを提供するには、以下の方法があります。いずれの方法にもメリット・デメリットがあるため、会社やプロジェクト、製品の事情に応じて確実に条件を順守できる方法を選択し、実施してください。

CD-ROM等の媒体にソースコードを記録し、製品に添付する
顧客からの要求に応じてソースコードを提供する旨と連絡先を記した書面を製品に添付する
Webサイト等からバイナリーを入手できるようにしている場合、同じ場所からソースコードをダウンロードできるようにする

　GPL v2の場合、OSSの実行可能ファイルに対応するソースコードを提供する必要があります。具体的には、実行可能ファイルに含まれるすべてのモジュールに対応するソースコード、関連するインタフェース定義ファイル、および実行可能ファイルのコンパイルとインストールを制御するために使用されるスクリプトを含める必要があります。

　GPL以外にもソースコードを提供する条件が付けられているライセンスがあります。提供するソースコードの範囲や提供方法はライセンスにより異なりますので、それぞれのライセンスを確認してください。

GPL/LGPLのライセンス　

　GNU GENERAL PUBLIC LICENSE（GPL）は、Free Software Foundationが作成したライセンスで、改変に合わせてバージョン管理されています。OSSのバージョンアップに合わせてライセンスもバージョンアップされることがあり、現在ではGPL v1を見ることはほとんどなくなりました。現在の最新版はバージョン3ですが、バージョン2を適用したOSSの開発者の中にはバージョン3を採用しないことを宣言しているケースもあり、バージョン２とバージョン３は見る機会が多いです。

　GNU LESSER GENERAL PUBLIC LICENSEもFree Software Foundationが作成したライセンスであり、当初はライブラリ向けに作成されたライセンスということでGNU LIBRARY GENERAL PUBLIC LICENSE Version 2という名称でした。しかし、ライセンスの条件がGPLより劣るということからLIBRARY がLESSER に変更され、バージョンが2.1になりました。バージョン2.1までは独立したライセンスでしたが、LGPL v3が作成された際、GPLに追加する条件としてLGPL v3が作成されました。従って、LGPL v3が適用されたOSSについては、GPL v3も含めてライセンス条件を確認する必要があります。