OSSコンプライアンスに関するお悩みポイントと解決策を具体的に紹介する連載「解決! OSSコンプライアンス」。7回目は、意図的に使ってはいないが、OSSコンプライアンスで対応しなければならないOSSのユースケースについて説明する。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
本連載では、オープンソースソフトウェア(OSS)の利活用に伴う「ライセンスリスク」と、それをマネジメントするための活動である「OSSコンプライアンス」について取り上げ、エンジニアの方がOSSをスムーズに利用するための実務上の勘所や、これから戦略的にOSSを活用していきたいと考えている企業の方へのヒントとなる情報を紹介しています。
今回も前回に引き続き、ソフトウェア開発企業X社の開発者である新城くんが経験した、OSSコンプライアンス問題とその解決策を解説していきます。思わぬ落とし穴や難しい問題に直面しながらOSSコンプライアンスに対応していく新城くんのエピソードを通して、皆さんも理解を深めていってください。
なお、本連載では、特に記載がない限り日本国内でOSSを活用する場合を前提としており、本連載の執筆チームの経験に基づいて説明を記載しています。厳密な法解釈や海外での利用など、判断に迷う場合は専門家にご相談ください。
新城くん 日本のソフトウェア開発企業X社で働く入社2年目の開発者。OSSは、指示を受けながらソフトウェア製品やクラウドサービスで利用した経験あり。
佳美先輩 X社の先輩エンジニアで、新城くんの指導担当。OSSを活用した開発の経験が豊富。
開発中のソフトウェア製品で利用するOSSについて、開発チームのメンバーにOSSリストを見せてもらったところ、開発ツールが含まれていた。製品を開発するときだけに利用する開発ツールがなぜリストされているのかを疑問に思った新城くん。
新城くん、OSSリストについて聞きたいことって何?
どうして開発ツールがOSSリストに入っているんですか? 開発ツールは製品として配布しないですよね?
開発ツールの一部が製品に入る場合があるのよ。
え、どういうことですか?
開発者が意識して利用したものではないOSSが、製品に入り込むことがあります。OSSリスト作成時に確実にチェックしておきたい幾つかのパターンを、以下に紹介します。該当する場合には、対象をOSSリストに含めます。これらのパターンではソフトウェアの技術的な理解が要求されますので、開発者と法務・知財メンバーが協力してライセンスクリアランスを実施する必要があります。
1.開発環境
GCC、LLVMなどのコンパイラでは、ランタイムライブラリと呼ばれるソフトウェアが、自分の開発したコードとリンクされることがあります。ランタイムライブラリは、例えばC言語の場合のC標準ライブラリのように、実行時に利用されるソフトウェアです。
ランタイムライブラリには、コンパイラと同じOSSライセンスが適用されていることが多いですが、コンパイラが生成するオブジェクトコードについては、他のライセンスでの配布を認めるとの例外規定がライセンスに追加されていることがあります。
クリアランスを実施するためには、コンパイラも含めて開発環境の動作を技術的に理解しておくとともに、開発環境のOSSライセンスを確認する必要があります。
2.動作環境
ソフトウェア製品が動作する環境(Linux、Docker等)を誰が準備するのかを確認する必要があります。顧客が準備するのか、第三者のベンダーが準備するのか、あるいは自分たちが提供するのかを確認します。自分たちで提供する場合には、提供する動作環境のクリアランスも必要になります。
例えばLinux上で動作するソフトウェアを開発しているときに、ソフトウェア製品と一緒にLinuxディストリビューションパッケージも提供するのであれば、ディストリビューションパッケージのクリアランスも行います。Linuxは、OSのコアであるLinuxカーネルだけでは簡単に使うことができません。そこで、利便性のために、Linuxを利用するのに有用なアプリケーション群を含めたディストリビューションパッケージがあります。ディストリビューションパッケージには、Linuxカーネル以外にさまざまなソフトウェアが多数含まれていますが、配布する全てのソフトウェアがクリアランスの対象となります。
3.依存関係
あるソフトウェアを実行させるために、別のソフトウェアを必要とするときに、この関係を「依存関係」と呼びます。自分の開発したソフトウェアが直接使っているOSSが、さらに他のOSSを利用していることがありますが、これが依存関係に当たります。
依存関係を確認する方法としては、開発ツールによって管理されている依存関係をチェックすることが挙げられます。
例えば、C言語などのソフトウェア開発でよく使われるmakeという開発ツールの場合、makefileというファイルで依存関係を管理していることが多いです。この場合、makefileの中で記述されているライブラリを確認します。
別の例として、JavaScriptのソフトウェア開発でよく使われるnpm(Node Package Manager)という開発ツールの場合、package.jsonというファイルで依存関係を管理していることが多いです。この場合、package.jsonの中で記述されているライブラリを確認します。
このエピソードで紹介したチェックで、開発者が意識して利用したものではない隠れたOSSが見つかったら、そのOSSをOSSリストに追加し、エピソード9で説明したクリアランス手順を繰り返します。隠れたOSSをリストにする作業には時間がかかりますので、OSSリスト作成には十分な時間を見積もり、設計段階で早めに着手するのが良いでしょう。
クリアランスにおいて、基本的でかつ重要なことは、OSSリストを網羅的に作ることです。これを地道に実施することで、抜け漏れを防ぐことができます。そのコードの開発者にしか分からない場合が多いですので、エンジニアと法務・知財が協力して作業を行うことをお勧めします。
以下は、my_programがlibraryとの間に依存関係がある場合のMakefileの記述例です。依存関係があるmy_programとlibraryが一緒にリンクされてtargetが生成されています。依存関係を探すには、一緒にリンクされているソフトウェアがないか確認します。
Makefile:
target : my_program.o library.o cc -o target my_program.o library.o my_program.o : my_program.c defs.h cc -c my_program.c library.o : library.c defs.h cc -c library.c
説明:
target Makeによって生成される実行形式ファイル
my_program 自分が書いたプログラム
library 依存関係があるので一緒にリンクされるライブラリ
次回の「解決! OSSコンプライアンス」では、利用するOSSの選定とコンプライアンスについて解説します。お楽しみに!
Copyright © ITmedia, Inc. All Rights Reserved.