59 To encourage use of open source software, this paper shows an overview of open source software license related research presented in international

(1)

59

チュートリアル

『オープンソースソフトウェア工学』シリーズ

オープンソースライセンスへの

ソフトウェア工学からのアプローチ

眞鍋雄貴

本稿では，オープンソースソフトウェアの利活用を推進するため，ソフトウェア工学分野における国際会議や論文誌で発表されたオープンソースライセンス関連の研究を概観する．オープンソースライセンス関連研究は大きく，オープンソースライセンスの特定，オープンソースライセンスの変更，オープンソースライセンスコンプライアンスからなる．これらの研究を踏まえ，今後の方向性について議論する．

To encourage use of open source software, this paper shows an overview of open source software license related research presented in international conferences or journals in software engineering. These researches are classified into open source license identification, open source software license evolution, and open source license compliance. Based on them, the future are discussed.

1 はじめに

ソフトウェア開発コストを削減する方法の1つとして，ソフトウェアの再利用がある．ソフトウェアの再利用とは，既存のソフトウェアにあるソースファイル，クラス，関数などを新たなソフトウェアの開発に利用することである[2]．再利用を行うことで，開発コストの削減や品質の向上につながるとされる[6]．近年では，多くのオープンソースソフトウェア(以降，単にOSS)が開発，公開されているため，多くの成果物を再利用に用いることができる． OSSを再利用するためには，各ソフトウェアのソフトウェアライセンスに従わなければならない．ソフトウェアライセンスとは，ソフトウェアの利用に関して，その著作者が定めた利用許諾である．ソフトウェ

Approach to Open Source Software License in Soft-ware Engineering.

Yuki Manabe, 熊本大学大学院自然科学研究科, Grad-uate School of Science and Technology, Kumamoto University. コンピュータソフトウェア, Vol.34, No.3 (2017), pp.59–69. [解説論文] 2016 年 6 月 3 日受付. アライセンスを得ることで，利用にあたる行為の一部を行うことができる．一方で使用にあたる行為の一部に制約がかかることがある[37]．特に，オープンソースの定義[28]を満たしたソフトウェアライセンスはオープンソースライセンスと呼ばれる．オープンソースライセンスはOpen Source Initiative(以降，単にOSI)により承認され，現在認証されたオープンソースライセンスは78種類(2016/4 現在．新しいバージョンに変更されたもの，すでに使われなくなったオープンソースライセンスを除く)である[21]．オープンソースライセンスを分類するよく使われる基準として，オープンソースライセンスが持つコピーレフトの強さがある．コピーレフトは派生物をオリジナルと同じオープンソースライセンスの元で配布することを求める義務である．[37] [14]に基づき，主なオープンソースライセンスをコピーレフトの強さに応じて大きく分類したものを表1に示す．オープンソースライセンスに違反した場合，開発したソフトウェアが配布できなくなったり，訴訟を起こされ，賠償しなくてはならない事態に陥る場合がある．これは，開発者がオープンソースライセンスをあ

(2)

60 表 1 主なオープンソースライセンス コピーレフト OSIでのライセンス名なし modified BSD License Apache License 2.0 MIT License

弱い Mozilla Public License 2.0 Eclipse Public License 1.0

あり GNU Aﬀero General Public License v3 GNU General Public License version 3.0

まり理解せず，再利用した場合に起こりうる．Sojer らによる896人のプロフェッショナルの開発者へのサーベイ[25]によると，サーベイに応じた開発者の 1/4がインターネット上のコードの再利用について何もトレーニングを受けておらず，またその他の多くも法律事務所や教育機関から教育を受けているというわけでもなかった．そのため，ソフトウェア開発者が十分にオープンソースライセンスを理解し，活用できるように多くの知見が公になる必要がある．本チュートリアル第1回「オープンソースソフトウェア工学」[38]によると，「OSSおよびOSSを活用したシステムを利用する組織・個人，およびOSSを利用してシステム開発をおこなうベンダ企業が「安心して安全に」OSSを利活用するための技術的方法論の確立を目指す学術分野を「オープンソースソフトウェア工学」と位置づける」とある．オープンソースライセンスはOSSを利活用する上で重要な仕組みであり，ソフトウェア開発に携わる人は理解すべきものである．しかし，一方で，オープンソースライセンスは法的分野と捉えられ，ソフトウェア工学分野の研究者が進出しにくくなっているように感じる．そこで，本解説論文では，OSSの利活用を促進するため，ソフトウェア工学関連の会議や論文誌でどのようにオープンソースライセンスが扱われてきたかを概観することで，ソフトウェア工学の研究者にオープンソースライセンスへのアプローチの一端を示す．

2 オープンソースライセンスと関連要素

本章では，オープンソースライセンスに関する研究を説明する上で必要となる用語や概念について説明する．

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

3. Neither the name of the copyright holder

nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR

SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

図 1 BSD3 項ライセンスの条項．著者により適宜改行． 2. 1 オープンソースライセンスオープンソースライセンス(以降，誤解のない場合はライセンスとする)は条文からなり，ライセンスを参照するものとしてライセンス名やライセンス記述がある．条文は複数の条項の集合として表現される．図1にBSD3項ライセンスの条文を示す．各条項は利用者の権利や義務に関する文章である．本稿では，個々のライセンスについては詳細を述べない．詳細についてはRosen[23]や可知[37]を参照されたい．ライセンスの中にはバージョンや多数の派生があるものがある．バージョンを持つライセンスとしては

(3)

Vol. 34 No. 3 Aug. 2017 61 がある．また，GNU GPLやGNU LGPLについては”or later”という文言を含む場合があり，これを含む場合，ライセンシングされたバージョンよりも新しいバージョンのライセンスに従って利用することができる．多くの派生のあるライセンスとしてはBSD ライセンスがある．BSDライセンスは元々の4項ライセンス，広告条項を除く3項ライセンス，現在の FreeBSDが用いている2項ライセンスがある．これに加え，パーサージェネレータであるBisonやJava 言語用のライブラリであるClasspathなどはGPLライセンスに例外条項を加えたライセンスで配布されている．ライセンス間の整合性は保証されていない．Free Software FoundationはGPLと両立するライセンス，両立しないライセンスについて示している[7]．中に

は，Apache Licenseのように，Apache Licenseバージョン1.0と1.1はGPLライセンスと適合しないが， Apache Licenseバージョン2.0はGPLライセンスと適合するというように，ライセンスのバージョンが異なると他のライセンスとの適合性が異なる場合もある． 2. 1. 1 オープンソースライセンスの参照表現ライセンス名はライセンスの条文に対して設定される名称である．ライセンス名はさらに略称を持つ場合も存在する．例として，GNU General Public License version3はGPLv3と表現されることがある．一方で，MITライセンスなど条項中に名称が明示されないライセンスも存在する．ライセンス名，また略称についてはウェブサイトやLinuxディストリビューションによっても異なる場合がある．なお，

The Software Package Data Exchange(SPDX)[27]

によりソフトウェアパッケージのメタデータに関する標準作成が進められている．その中で，ライセンスとライセンス名を整理したリスト[26]が公開されている．OpenSUSEなどの幾つかのディストリビューションがこのリストに追従し，SPDXに準拠した略称を用いている．OSI[21]，Fedora[29]，SPDX[26] におけるライセンス名の違いを表2に示す．ソースコードにおけるライセンスの指定はソースファイルにコメントととしてライセンス記述を記載 表 2 OSI でのライセンス名と Fedora，SPDX で の略称の違い OSI Fedora SPDX

modified BSD License BSD BSD-3-Clause Apache License 2.0 ASL2.0 Apache-2.0

MIT License MIT MIT

Mozilla Public License 2.0 MPL2.0 MPL-2.0 Eclipse Public License 1.0 EPL EPL-1.0 GNU Aﬀero General AGPLv3 AGPL-3.0 Public License v3

GNU General Public GPLv3 GPL-3.0 License version 3.0

This software is open-source under the BSD license; see either ”license.txt ” or http://jung.sourceforge.net/license.txt for a description. 図 2 ライセンス条文と異なるライセンス記述の例 することで行われる．ライセンス記述は，その著作物がどのライセンスに従っているかを示す自然言語で記載された文章である．ライセンス記述として，ライセンスの条文そのものが使用される場合もあるが，異なる記述である場合もある．異なる場合の例を図 2に示す．また，ライセンス記述には表記揺れが生じる[10][39]ことがある．Marykaら[18]はBSDライセンスやMIT/X11ライセンスについて表記揺れを詳細に調査している． 2. 1. 2 オープンソースライセンスに関連する環境ソフトウェアの開発履歴を管理するGitなどの版管理システムやメーリングリストにはライセンスの変更が記録されることがある．版管理システムは登録された各ファイルについてユーザが登録した変更差分を記録することができ，並行した開発の支援や，過去の版の復元を行うことができる．ライセンスの変更はライセンスが記載されたファイルの変更や，ソースファイル中のコメントの変更として版管理システムに記録される．また，その変更に関する議論がメーリングリストで行われることがある． Linuxディストリビューションが管理するソフトウェアパッケージにもライセンスが設定されている． Linuxディストリビューションは多くの場合，様々なソフトウェアを容易にインストールできるよう，ソフ

(4)

62 sĂŶĚĞƌƵƌŐ䜙΀ϯϭ΁䠈ŚĂŶŐ䜙΀ϯϲ΁䠈ĂǀŝĞƐ䜙΀ϯ΁ 䝷䜲䝉䞁䝇䝁䞁䝥䝷䜲䜰䞁䝇䜸䞊䝥䞁䝋䞊䝇䝷䜲䝉䞁䝇䛾㐍໬ ŝƉĞŶƚĂ䜙΀ϰ΁䠈DĂŶĂďĞ䜙΀ϭϳ΁䠈tƵ䜙΀ϯϱ΁䠈sĞŶĚŽŵĞ䜙΀ϯϮ͕ϯϯ͕ϯϰ΁ 䜸䞊䝥䞁䝋䞊䝇䝷䜲䝉䞁䝇䛾≉ᐃ ฟ⮬䛾≉ᐃ 䜸䞊䝥䞁䝋䞊䝇䝷䜲䝉䞁䝇䛾⤌䜏ྜ䜟䛫 ୍㈏ᛶ䠖 'ĞƌŵĂŶ䜙΀ϴ΁ ⤌䜏ྜ䜟䛫䛾ᢳฟ䠖 <ĞĐŚĂŐŝĂ䜙΀ϭϰ΁䠈 DĂŶĂďĞ䜙΀ϭϲ΁ 䝟䝍䞊䞁䠖 'ĞƌŵĂŶ䜙 ΀ϵ΁ 䜸䞊䝥䞁䝋䞊䝇䝷䜲䝉䞁䝇㐪཯䛾᳨ฟ ṇつ⾲⌧䠖 EŝŶŬĂ΀ϭϬ͕ϯϴ΁ ^>΀ϯϬ΁ 䝔䜻䝇䝖㛫㢮ఝᗘ͗ &K^^ŽůŽŐǇ΀ϭϭ΁ ᳨ฟᡭἲ䠖 DĂƚŚƵƌ䜙΀ϭϵ΁ >ŽŬŚŵĂŶ䜙΀ϭϱ΁ DůŽƵŬŝ䜙΀ϮϬ΁ 䝯䝍䝰䝕䝹䠖 ůƐƉĂƵŐŚ䜙΀ϭ΁ ᐇ⏝ Ꮫ⾡ 図 3 本稿で紹介する事例の分類 トウェアパッケージ管理システムを持っている．個々のパッケージシステムによって形式は異なるが，例としてFedora[22]の場合を説明する．Fedoraではrpm 形式のパッケージを用いている．rpm形式のパッケージは，主にソフトウェアのバイナリファイルのアーカイブとメタデータが記載されたspecファイルで構成される．また，バイナリファイルではなく，ソースコードのアーカイブが入るsrc.rpm形式のパッケージも存在する．specファイルにはバージョンやパッケージ間の依存関係などとともに，そのパッケージのオープンソースライセンスも記載されている．

3 オープンソースライセンスに関する研究の

事例紹介

本章では，ソフトウェア工学分野におけるオープンソースライセンスに関する研究を紹介する．初めに，ライセンスを扱う基盤となるオープンソースライセンス特定についての研究を説明する．次に，オープンソースライセンス特定手法を用いて行われる，ライセンスコンプライアンス，オープンソースライセンスの進化についての研究を紹介する．

研究事例はACM Digital Libraryにて，”software license”をキーワードとする検索結果から以下の基準にて選択している．また，選別された論文が引用している文献についても対象となるものがあれば選択している． • ソフトウェア工学に関する国際会議，または論文誌に掲載されたものであること． • オープンソースライセンスを主体として扱ったもの．手法のケーススタディにてオープンソースライセンスに触れる程度の論文は除外している．図3に，オープンソースライセンス特定手法，ライセンスコンプライアンス，オープンソースライセンスの進化の関係を示す．オープンソースライセンス特定手法はソフトウェア工学におけるオープンソースライセンス研究の基盤となる．オープンソースライセンス特定手法は，正規表現によるもの，テキスト間類似度によるものに分類される．ライセンスコンプライアンスはオープンソースライセンス特定手法の実用面の強い応用と言える．ライセンスコンプライアンスは大きく，出自の特定，オープンソースライセンスの組み合わせ，オープンソースライセンス違反検出に分類できる．また，オープンソースライセンスの組み合わせでは，一貫性，抽出，パターンと分類できる．また，オープンソースライセンス違反検出では違反検出手法とメタモデルに分かれる．オープンソースライセンスの進化はオープンソースライセンス特定手法の学術面の強い応用と言える． 3. 1 オープンソースライセンスの特定オープンソースライセンスの特定とは，ソースファイルやパッケージなどに対応するオープンソースライセンスが何かを決定することである．ソフトウェアを構成するソースファイルについてライセンスを分析する際，大量のソースファイルを確認する必要があり，大きな労力がかかる．オープンソースライセンス

(5)

Vol. 34 No. 3 Aug. 2017 63 ^Ϯ䠖^WƌĞ͕^ĐŽŶĚ^ŽƵƌĐĞ͕^ĐŽŶĚŝŶĂƌǇ͕ ^ĂƐ/Ɛ͕^tĂƌƌ ^ĐŽŶĚ^ŽƵƌĐĞ͗ZĞĚŝƐƚƌŝďƵƚŝŽŶƐ͍ŽĨƐŽƵƌĐĞĐŽĚĞŵƵƐƚ ƌĞƚĂŝŶƚŚĞ;ĂďŽǀĞͿ͍ĐŽƉǇƌŝŐŚƚŶŽƚŝĐĞ͕ƚŚŝƐůŝƐƚŽĨ ĐŽŶĚŝƚŝŽŶƐ;͕Ϳ͍ĂŶĚƚŚĞĨŽůůŽǁŝŶŐĚŝƐĐůĂŝŵĞƌ;͕ǁŝƚŚŽƵƚ ŵŽĚŝĨŝĐĂƚŝŽŶͿ͍͗ 䝷䜲䝉䞁䝇ྡ 䝷䜲䝉䞁䝇ᩥྡ 䝷䜲䝉䞁䝇䝹䞊䝹䝷䜲䝉䞁䝇ᩥ 図 4 Ninka で用いるルールの構造 特定手法はこの労力を削減し，オープンソースライセンスに関するソフトウェア分析を行う上での基盤となる技術である．ソースファイルを対象とするオープンソースライセンス特定手法としては，正規表現を用いたルールを用いる手法と，文書間の類似度を用いる手法がある． ALSA[30]は正規表現を用いたルールを用いてライセンスを特定する．また，ビルド情報とビルドに用いられるソースファイルのライセンスから，バイナリファイルのライセンスをソースファイルのライセンスの和集合であると推定する．また，ライセンス間の適合性についても事前に定められた，ライセンスの組とその適合性からなるルールに基づいて判定する． Germanらはソースファイル中のコメントとそれに対応する知識を用いてライセンスを特定する手法とその実装であるNinkaを提案した [10][39]．German

らは Linux，Eclipse JDT，OpenBSD，FreeBSD，

Mozillaのソースコード約30000ファイルについてライセンス記述を分析し，ライセンス記述が持つ特徴を明らかにしている．それに基づき，複数の階層で構成される知識を用いたライセンス特定ツールNinkaの実装を示している．図4にNinkaで用いるルールの構造を示す．Ninkaは主にライセンスルールとライセンス文を用いる．ソースファイル中のコメントは分割され，ライセンスと関係ない文の除去やカンマなどの一部語句の正規化を行う．次に各文とライセンス文を比較し，マッチした文はライセンス文に変換する．次にライセンス文名の列とライセンスルールを比較し，マッチした場合はその列をライセンス名に変換する．正規表現による手法では正規表現にマッチしない表現の揺れがある場合ライセンスを特定できない．そこで，正規表現ではなく，テンプレートとなるライセンス記述と，ソースコード中のコメント間の類似度を用いてライセンスを特定する手法がある． FOSSol-ogy[11]はNinkaとは異なり，Symbolic Alignment Matrix(bSAM)アルゴリズムを用いて，テンプレートとソースファイルのライセンス記述間の類似度を計算することでライセンスを特定する．なお，FOSSology は現在も開発されており，上記手法に近いオープンソースライセンス特定器のMonkとNinkaに近い手法を用いるオープンソースライセンス特定器のNomos を用いることが可能となっている．その他のライセンス特定手法については紙面の都合上掲載しきれないため，オープンソースライセンス特定手法に関するサーベイであるKapitsakiらのサーベイ[13]を参照されたい．Kapitsakiらはオープンソースライセンスに関する問題点と，既存手法を紹介している．既存手法はライセンスデータ分析，コードリポジトリ中のライセンスデータ，ライセンスのメタモデルとその説明付けの3点から紹介されている． 3. 2 ライセンスコンプライアンス OSSがそのオープンソースライセンスに基づき正しく使用されているかを確認することをライセンスコンプライアンスとする．OSSを開発中のソフトウェアに不用意に混在させた場合，ライセンスに違反する可能性がある．大規模な開発になるとそのリスクはさらに高まる．ライセンスコンプライアンスに関する技術はこのリスクを削減するために必要になる技術である．ライセンスコンプライアンスの主となる技術は出自の特定，オープンソースライセンスの組み合わせ，オープンソースライセンス違反の検出である．本節ではこれらの分野について，それぞれ事例を紹介する． 3. 2. 1 出自の特定ソフトウェアには様々なソースファイルが含まれる．これらのソースファイルは開発の過程で様々なところから混入することがある．ソフトウェアに含まれるソースファイルやソースコードの出自を明らかにすることができれば，ソフトウェアに混入したオープンソースライセンスを特定できる．その結果，オープンソースライセンス違反の発見や違反の解消を行うこ

(6)

64

とができよう．

van der Burgら[31]はビルド時に生じるシステム

コールを追跡することによってConcrete Build De-pendency Graph(CBDG)を構築，分析し，派生物に含まれるファイルや外部コンポーネントを特定することでライセンスコンプライアンスを評価する手法を提案している．CBDGは従来のBuild Dependency Graphでは失われるヘッダファイル，外部コンポーネント，偽のターゲットの情報を含む，頂点をファイルやタスク，辺をデータフローとするグラフである．提案手法により，ﬀmpegにおけるライセンスコンプライアンスの問題を発見している．

Zhangら[36]はGoogle Code Searchサービスを用いて自動的にライセンスコンプライアンスのチェックを行うツールであるLCheckerを提案している．

Google Code Searchを用いることで，インターネット上にあるOSSに含まれるコードから，ローカルにあるファイルと類似するコードを検索し，ローカルにあるファイルのうちライセンスが不明なファイルのライセンスを特定する．著者らはLCheckerを用いて，実際に中国国内の組織で開発されているプロジェクトにおいて，ライセンスコンプライアンスに問題があるソースコードを特定している． DaviesらはJavaで記述されたソフトウェアシステム中のソースやバイナリの起源を特定する手法を提案している．本手法では，Jarファイルに含まれるクラスやクラスに含まれるメソッドのシグネチャを特徴とし，あらかじめ作成されたコーパス中で一致するJar ファイルが起源であると特定する[3]． 3. 2. 2 オープンソースライセンスの組み合わせライセンスコンプライアンス研究の一環として，2 つの対象間からオープンソースライセンスの関係を抽出する研究が行われている．オープンソースライセンス間では，それらの整合性は保証されていない．また，その整合性は自明ではなく，専門家により分析する必要がある．オープンソースライセンスの組み合わせに関する整合性を実例に基づき知ることができれば，開発者はそれを根拠に考え，また，専門家と議論する助けとなるだろう． Germanら[8]はソースコードのライセンスとパッケージで宣言されたライセンスの一貫性を検証するため，一貫性の検証手法の提案と，Fedora12におけるライセンスの一貫性に関する問題を報告している．

Kechagiaら[14]はFreeBSD ports collectionsにおいて依存関係のあるパッケージの組から，依存関係のあるライセンスの組を抽出している．Manabeら[16] はFedoraのソフトウェアパッケージにおいて，パッケージのメタデータに記載されているライセンスと，ソースファイルのライセンス間の関係を抽出した．オープンソースライセンスの組み合わせによっては不整合が生じることがある．不整合が生じた場合，不整合を解消しなければライセンス違反となる．ライセンスの不整合が生じた場合の処理に関する研究として，Germanら[9]の研究がある．Germanらはライセンスのモデルを提案し，その上で，コンポーネントに基づくアプリケーションのライセンス，他のコンポーネントから生成されたコンポーネントの再利用，ライセンスの適合性について議論している．また，124のOSSプロジェクトを分析し，ライセンス不整合が生じたときに解決するためのパターンを示している．これらのパターンはライセンスを与える側，ライセンスを受ける側それぞれに分類されている． 3. 2. 3 オープンソースライセンス違反の検出開発中のソフトウェアにOSSが混入し，オープンソースライセンスに違反してしまうことを防ぐのは難しい．加えて，オープンソースライセンスの違反を容易に見つけることはできない．このような違反を発見し，解消するため，多くのオープンソースライセンス違反検出手法が提案されている． Mathurらは，OSSコミュニティにおける大部分のコード再利用がライセンスの条項を満たしていないというリスクを抱えているという仮説を検証するために，Google Code Project hostingで運用される

1423プロジェクトを分析し，プロジェクト間のコード再利用のインスタンスとそれらのライセンスを比較した[19]．一致部分の発見にはMOSS[24]のアーキテクチャに基づいた手法が用いられている．その結果，4つの違反を発見している． Lokhmanら[15]はソフトウェアアーキテクチャのレベルでオープンソースの法的関心事を取り扱う手

(7)

Vol. 34 No. 3 Aug. 2017 65 >ŝĐĞŶƐĞ ZŝŐŚƚ KďůŝŐĂƚŝŽŶ dƵƉůĞ ĐƚŽƌ DŽĚĂůŝƚǇ ĐƚŝŽŶ KďũĞĐƚ >ŝĐĞŶƐĞ ŽƉǇƌŝŐŚƚ ĐƚŝŽŶ >ŝĐĞŶƐŽƌ >ŝĐĞŶƐĞĞ ͍ Ύ н 図 5 Alspaugh ら [1] が提案するソフトウェア ライセンスメタモデル法とツールを提案している．本手法では，UMLプロファイルを用いてUMLを拡張し，ライセンス間の矛盾を制約の違反として検出する．また，本拡張を Papyrusモデリング環境上で扱えるようにビューを作成している．ケーススタディではSolutions for Open Land Administration (SOLA)[5]を対象にして，本

ビューを用いてライセンスの衝突リスクを特定し，それを考慮しながらソフトウェア全体のライセンスを決定することができている．

Mloukiら[20]はF-droid marketにあるAndroid

アプリケーション857個のモバイルアプリケーションを対象にオープンソースライセンスの分析を行っている．本研究では，ソースファイルのライセンス，ファイル間のコードクローン，ファイルやライブラリ間の依存関係とライセンス違反を検出するための制約を用いて，ライセンス違反を特定している．結果として，17個のライセンスについてはライセンス違反が見つかり，また，そのうち7個については最新版でもライセンス違反が解消されていないことがわかった． Alspaughらはライセンスの異なるコンポーネントを組み合わせて構成されるOpen Architectureのもとでのライセンスについて研究を行っている．Alspaugh らはライセンスのメタモデルを提案し，それを用いた権利や義務の衝突を計算する手法を提案している[1]． Alspaughらが提案するメタモデルを図5に示す．ライセンスは権利(Rights)と義務(Obligation)から構成される．権利と義務はそれぞれタプルとして表現される．タプルはActor，Modality，Action，Object，他のLicenseへの参照から構成される． 3. 3 オープンソースライセンスの進化あるソースファイルのオープンソースライセンスは変更や，追加・削除されることがある．そのようなオープンソースライセンスの変化の過程をオープンソースライセンスの進化と呼ぶ．オープンソースライセンスの進化を知ることは，利用しているOSSが継続的に利用できるか，また，開発者がオープンソースライセンスをどのように扱っているかについて知ることになる．これらを知ることによって，今後のOSS の利用や，オープンソースライセンスが円滑になる．本節では，オープンソースライセンスの進化に関する研究を紹介する． Di Pentaらは，システムのライセンスにおける条項の変更を追跡する手法を提案し，6つの異なるFOSS システムのライセンス進化について調査した[4]．その結果，ライセンスの変更，追加，修正が観察された．また，十分な変更がソースコードファイルに行われた時，新しいコードを保護するためにコピーライトの年が更新されていた．

Manabeら[17]はFreeBSD，OpenBSD，Eclipse，

AlgoUMLにおけるソースコードのライセンス変化を調べた．その結果，システムごとに異なったライセンス変化の傾向を示し，また，ライセンスが変化する際は大規模に変更される事を示している．加えて， FreeBSDやOpenBSDではカーネル部分だけを見ても，OS全体と同じ傾向を示している． Wuら[35]は同じ出自から進化した2つのソースファイルが異なるライセンスを含む時，それをlicense inconsistencyとしている．そのうえで，license in-consistencyを分類し，それらを検出する手法を提案している．また，提案手法を用いて発見されたlicense inconsistencyの一部を手作業で分析し，それが発生した理由を調べている． Vendomeら[32] [33] [34]はGitHubを対象とした一連の研究にて，ライセンス利用の変化とその理由について調査した．VendomeらはGitHub上の16221 個のJavaプロジェクトを対象にした調査を行っている[32] [34]．その結果から，新しいバージョンのライセンスは素早く開発者により適用されること，GPL ライセンスの様な制限のあるライセンスの新しいバー

(8)

66 ジョンは以前のバージョンの長期生存に有利に働くことがわかった．一方，制限の弱いライセンスの場合は以前のバージョンが消えていく．また，ライセンス変更は主にある種の派生や再配布がしやすい制限の弱いライセンスへか，制限の強いライセンスと弱いライセンス間にあるライセンスに向く．加えて，ライセンスの決定が難しいことの示唆として，プロジェクトのライセンスやライセンスが暗に意味することを確認するために開発者は質問を問題管理システムに投稿しているが，議論と関連するライセンスの変更間のトレーサビリティが明確に欠如していることを挙げている．加えて，Vendomeらは開発者へのインタビューを行っている[33]．インタビューの結果から，開発者は最初の数コミットでライセンスを適用している，開発者はライセンスの決定を重要なタスクとして考えており，また同様にほとんどのライセンス変更は開発の短くない期間が経過した後現れる．ソフトウェアのライセンス決定に関して，開発者が経験した初期のライセンス決定，ライセンス変更，問題に対する理由を調査したところ，開発者はライセンス決定をプロジェクトにとって重要であるが，些細でない特徴と見ている．ライセンスが暗に意味することやライセンス間の適合性はまだいつも明確とは限らないため，開発者はライセンスの変更に向かうことがある．加えて，プロジェクトのライセンス決定に影響を与える，コミュニティや利用目的，第三者によるライブラリなどの外部要因があることがわかった．

4 議論

本章では3章で紹介した研究を踏まえ，今後の方向性に影響しうる問題について洗い出す． 4. 1 オープンソースライセンスの特定研究者にとっての問題としては，オープンソースライセンスの特定手法が依存する知識を保守することが難しく，効率良く保守する方法が求められていることである．オープンソースライセンスの特定手法はOSIのウェブサイトに記載されているライセンス記述や，複数のソフトウェアを分析して得られたライセンス記述に関する知識に依存しているため，それらに含まれないライセンス記述に対応するためには知識の保守が行われ続ける必要がある．しかし，現状ではあまり研究が行われていない．Higashiらはライセンス知識の保守を目指し，未知のライセンス記述をクラスタリングする手法を提案している[12]．実務者にとって，オープンソースライセンスの特定技術はライセンスに関するリスクを下げるための重要な基盤技術となる．しかし，現時点で確実に全てのライセンスを特定することのできる技術は存在しない． 1つは，手法が用いるマッチングの方法にあるが，もう1つはライセンスに関する知識である．知識を強化し，特定できるライセンスの種類を増やし，精度を高めるための手段は誤例によるフィードバックであるが，あまり利用者側から提供がないと感じる．実務者からの情報提供により，より精度の高い手法の構築も可能であると考える． 4. 2 ライセンスコンプライアンス出自の特定研究者，実務者どちらについても大規模なデータベースが要求される．Zhangら[36]の手法で

はGoogle Code Searchを，Daviesら[3]はMaven2 repositoryを用いている．これら以外にも大規模なデータベースとして用いることができるソフトウェア集合はあろう．それらのソフトウェア集合を統合したデータベースが望まれる．オープンソースライセンスの組み合わせ研究者にとっての問題は，さらに多くの種類の関係からライセンス間の組み合わせを得ることである．既存手法ではソースパッケージ間，ソースパッケージとソースファイル間からライセンスの関係が得られていた．これら以外にも，ライセンス間の関係を得ることができる可能性がある．また，これらの関係はライセンスにおけるある側面において組み合わせることができるライセンスの組である．これらの関係を統合することができれば開発者がより柔軟にライセンスを利用できるようになる．また，実際にライセンスコンプライアンスに問題が生じた時にはGermanら[9] のパターンや，ソフトウェアの分析から得られたライセンス間で整合性のある組み合わせを用いることで，速やかに問題解決を行える可能性がある．

(9)

Vol. 34 No. 3 Aug. 2017 67 実務者にとっての問題点としては，上記の手段から得られた関係の信頼性をどのように調査し，担保するかである．これは，専門家を頼っても同様の問題が生じる．実際のライセンスコンプライアンスのためのプロセスに組み込む場合は，誤りがあった場合でも大きな影響を与えないような仕組みも合わせて考える必要があろう．オープンソースライセンス違反の検出研究者にとっての問題としては，ソフトウェア開発プロセスの各段階に組み込めるオープンソースライセンス違反検出手法の構築である．Lokhmanら[15]のようにアーキテクチャレベルでオープンソースライセンス違反検出を実現しようとする手法は今後も必要となろう．可能であれば，上流工程から下流工程まで，一貫してライセンスを考慮しうる手法があることが望ましい．また，ライセンスが衝突するかどうかは自動的に判定できる方が良い．Alspaughら[1]のように，ライセンスの条文をコンピュータが扱えるモデルに変換し，それを用いてライセンスの矛盾を検出する手法は今後も必要となるだろう．そのためには，既存の条文を自動的にモデルに変換できる手法が要求される．実務者にとっては，提案されたライセンス違反検出手法をどのように評価するかが難しいと考える．実際に，提案されたライセンス違反検出手法を試し，評価のための知見を蓄積していくことが正しい評価につながる． 4. 3 オープンソースライセンスの進化研究者にとっての問題は，ただ，オープンソースライセンスが変化する特徴を知るだけでなく，それがソフトウェア開発にどのように生かされるのかを考えることである．オープンソースライセンスが変更されること，変更される理由等については3.3節で示した研究にて調査された．しかしながら，このオープンソースライセンスの変更がソフトウェア開発にどのように影響をおよぼすのかについては調査されていない． OSSプロジェクトを円滑にすすめるためにはこれらの影響を調査する必要があろう．加えて，ライセンスの変更については，大規模な対象へと移っている．初期の研究[4] [17]では，複数のアプリケーションが対象であったのが，近年[32] [33] [34] ではGitHubなど大規模なソフトウェアリポジトリ集合を対象としており，今後も大規模になると考えられる．その際，基盤となるライセンス特定ツールのスケーラビリティが要求される．また，ライセンス名の揺れは複数のソフトウェア集合を用いる際に問題となる．この問題を解決するには，ソフトウェア集合間でライセンス名の対応関係を明らかにし，対応表を作成することである．しかし，この部分は各研究にて個別に対応されている．そのため，対応表の自動作成は重要な課題である．実務者にとっては，ライセンスの進化に関する情報はオープンソースソフトウェアを利用する上で知っておくべき知見であると考える．特に，長期間特定の OSSに依存する可能性がある場合は，ライセンスの変更によりその戦略を考え直さなければならない可能性がある．上記の通り，研究者側からかなり大規模な対象を分析した結果から得られた知見も示されてきており，今後もより多くの知見が示されるだろう．そのため，これらの知見を知る努力を惜しまずに追従すべきである．

5 まとめと今後の方向性

本稿ではソフトウェア工学におけるオープンソースライセンス研究の概観を示した．その過程において，オープンソースライセンス研究に関連する要素について説明した．また，オープンソースライセンスの特定，ライセンスコンプライアンス，オープンソースライセンスの進化という観点から既存の研究を紹介した．オープンソースライセンスはOSSの開発，利用どちらの観点からも理解，利用，発展させるべきものである．それらを実現するためには，オープンソースライセンスの実情を知るための基盤の整備，実際の OSSやその開発の際に蓄積された様々な情報を対象とした調査，開発者にとって利用しやすいライセンスコンプライアンス手法が求められるだろう．本稿によって，より多くのソフトウェア工学の研究者，実務者がオープンソースライセンスにアプローチしやすくなれば幸いである．

(10)

68

参考文献

[ 1 ] Alspaugh, T. A., Asuncion, H. U. and Scac-chi, W.: Analyzing software licenses in open archi-tecture software systems, in 2009 ICSE Workshop on Emerging Trends in Free/Libre/Open Source Software Research and Development, IEEE, 2009, pp. 54–57.

[ 2 ] Braun, C. L.: 再利用, ソフトウェア工学大辞典, Marciniak, J. J.(ed.), Vol. 1, 朝倉書店, 1994, pp. 338– 405.

[ 3 ] Davies, J., German, D. M., Godfrey, M. W. and Hindle, A.: Software bertillonage: Finding the Provenance of an Entity, in Proceeding of the 8th working conference on Mining software repositories - MSR ’11, 2011, p. 183.

[ 4 ] Di Penta, M., German, D. M., Gu´eh´eneuc, Y.-G. and Antoniol, Y.-G.: An exploratory study of the evolution of software licensing, in Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering - ICSE ’10, Vol. 1(2010), p. 145.

[ 5 ] FAO: Solutions for Open Land Administration, http://flossola.org/.

[ 6 ] Frakes, W. B. and Kang, K.: Software reuse re-search: Status and future, IEEE Transactions on Software Engineering, Vol. 31, No. 7(2005), pp. 529– 536.

[ 7 ] Free Software Foundation: Various Licenses and Comments about Them, http://www.gnu.org/ licenses/license-list.en.html.

[ 8 ] German, D. M., Di Penta, M. and Davies, J.: Understanding and Auditing the Licensing of Open Source Software Distributions, in 2010 IEEE 18th International Conference on Program Comprehen-sion, IEEE, 2010, pp. 84–93.

[ 9 ] German, D. M. and Hassan, A. E.: License inte-gration patterns: Addressing license mismatches in component-based development, in 2009 IEEE 31st International Conference on Software Engineering, IEEE, 2009, pp. 188–198.

[10] German, D. M., Manabe, Y. and Inoue, K.: A sentence-matching method for automatic license identification of source code files, in Proceedings of the IEEE/ACM international conference on Auto-mated software engineering - ASE ’10, New York, New York, USA, ACM Press, 2010, p. 437. [11] Gobeille, R.: The FOSSology project, in

Pro-ceedings of the 2008 international workshop on Mining software repositories - MSR ’08, New York, New York, USA, ACM Press, 2008, p. 47.

[12] Higashi, Y., Manabe, Y. and Ohira, M.: Clus-tering OSS License Statements toward Automatic Generation of License Rules, in 7th International Workshop on Empirical Software Engineering in Practice, IWESEP@SANER 2016, Osaka, Japan, March 13, 2016, 2016, pp. 30–35.

[13] Kapitsaki, G. M., Tselikas, N. D. and Foukarakis, I. E.: An insight into license tools for

open source software systems, Journal of Systems and Software, Vol. 102(2015), pp. 72–87.

[14] Kechagia, M., Spinellis, D. and Androutsellis-Theotokis, S.: Open Source Licensing Across Pack-age Dependencies, 2010 14th Panhellenic Confer-ence on Informatics, IEEE, 2010.

[15] Lokhman, A., Luoto, A., Hammouda, I. and Mikkonen, T.: Open Source Legality Compliance of Software Architecture, in ICSEA 2013, The Eighth International Conference on Software Engineering Advances, 2013, pp. 571–578.

[16] Manabe, Y., German, D. M. and Inoue, K.: Analyzing the Relationship between the License of Packages and Their Files in Free and Open Source Software, in Open Source Software: Mobile Open Source Technologies: 10th IFIP WG 2.13 Interna-tional Conference on Open Source Systems, OSS 2014, San Jos´e, Costa Rica, May 6-9, 2014. Pro-ceedings, 2014, pp. 51–60.

[17] Manabe, Y., Hayase, Y. and Inoue, K.: Evolu-tional Analysis of Licenses in FOSS, in Proceedings of the Joint ERCIM Workshop on Software Evolu-tion (EVOL) and InternaEvolu-tional Workshop on Prin-ciples of Software Evolution (IWPSE), IWPSE-EVOL’10, New York, NY, USA, ACM, 2010, pp. 83– 87.

[18] Maryka, T., Germ´an, D. M. and Poo-Caama˜no, G.: On the Variability of the BSD and MIT Li-censes, in Open Source Systems: Adoption and Im-pact - 11th IFIP WG 2.13 International Confer-ence, OSS 2015, FlorConfer-ence, Italy, May 16-17, 2015, Proceedings, 2015, pp. 146–156.

[19] Mathur, A., Choudhary, H., Vashist, P., Thies, W. and Thilagam, S.: An Empirical Study of Li-cense Violations in Open Source Projects, in 2012 35th Annual IEEE Software Engineering Work-shop, IEEE, 2012, pp. 168–176.

[20] Mlouki, O., Khomh, F. and Antoniol, G.: On the Detection of Licenses Violations in the An-droid Ecosystem, in 2016 IEEE 23rd International Conference on Software Analysis, Evolution, and Reengineering (SANER), IEEE, 2016, pp. 382–392. [21] Open Source Initiative: Open Source Licenses,

http://opensource.org/licenses/index.html. [22] Red Hat, Inc. and others: Fedora, https://

getfedora.org/ja/.

[23] Rosen, L.: Open Source Licensing: Software Freedom and Intellectual Property Law, Prentice Hall, 2004.

[24] Schleimer, S., Wilkerson, D. S., Aiken, A. and Berkeley, U. C.: Winnowing : Local Algorithms for Document Fingerprinting, in Proceedings of the 2003 ACM SIGMOD international conference on on Management of data - SIGMOD ’03, New York, New York, USA, ACM Press, 2003, p. 76.

[25] Sojer, M. and Henkel, J.: License risks from ad hoc reuse of code from the internet, Communica-tions of the ACM, Vol. 54, No. 12(2011), p. 74.

(11)

Vol. 34 No. 3 Aug. 2017 69 [26] SPDX Workgroup a Linux Foundation

Collabo-rative Project: http://spdx.org/licenses/.

[27] The Linux Foundation: The Software Package Data Exchange c⃝(SPDX c⃝) specification, https: //spdx.org/.

[28] The Open Source Initiative: The Open Source Definition, http://opensource.org/docs/osd, 2006. [29] Tom ’spot’ Callaway: Licensing:Main, https:

//fedoraproject.org/wiki/Licensing:Main.

[30] Tuunanen, T., Koskinen, J. and K¨arkk¨ainen, T.: Automated software license analysis, Auto-mated Software Engineering, Vol. 16, No. 3-4(2009), pp. 455–490.

[31] van der Burg, S., Dolstra, E., McIntosh, S., Davies, J., German, D. M. and Hemel, A.: Trac-ing software build processes to uncover license compliance inconsistencies, in Proceedings of the 29th ACM/IEEE international conference on Au-tomated software engineering - ASE ’14, New York, New York, USA, ACM Press, 2014, pp. 731–742. [32] Vendome, C.: A Large Scale Study of License

Usage on GitHub, in 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering, 2015, pp. 2–4.

[33] Vendome, C., Linares-v, M., Bavota, G., Penta, M. D., German, D. and Poshyvanyk, D.: When and Why Developers Adopt and Change Software Li-censes, in 2015 IEEE 31st International Conference on Software Maintenance and Evolution (ICSME), 2015.

[34] Vendome, C., Linares-V´asquez, M., Bavota, G., Di Penta, M., German, D. and Poshyvanyk, D.: Li-cense usage and changes: A largescale study of java projects on github, in International Conference on Program Comprehension, 2015, pp. 218–228. [35] Wu, Y., Manabe, Y., Kanda, T., German, D. M.

and Inoue, K.: A Method to Detect License Incon-sistencies in Large-Scale Open Source Projects, in The 12th Working Conference on Mining Software Repositories, 2015.

[36] Zhang, H., Bei, S. and Lu, Z.: Automatic check-ing of license compliance, in 2010 IEEE Interna-tional Conference on Software Maintenance, IEEE, 2010, pp. 1–3. [37] 可知豊: ソフトウェアライセンスの基礎知識 : オー プンソース×ソフトウェア開発×ビジネス, ソフトバンククリエイティブ, 2008. [38] 伊原彰紀, 大平雅雄: 『オープンソースソフトウェア工学』シリーズオープンソースソフトウェア工学, コンピュータソフトウェア, Vol. 33, No. 1(2016), pp. 28–40. [39] 真鍋雄貴, ダニエルモラレスゲルマン, 井上克郎: 階層的ライセンス知識を用いたライセンス特定ツールの開発, 情報処理学会論文誌, Vol. 52, No. 8(2011), pp. 2402–2411. 眞鍋雄貴 2006年大阪大学基礎工学部情報科学科退学．2011年同大学大学院情報科学研究科博士後期課程修了．同年同大学院特任助教．2013年熊本大学大学院自然科学研究科助教．2016年より同大学大学院先端科学研究部助教．博士(情報科学)．ソフトウェア工学，特にソフトウェアの再利用，オープンソースライセンス，ソフトウェアリポジトリマイニングの研究に従事．情報処理学会，ACM，IEEECS各会員．