この連載では、企業がオープンソースソフトウェアとうまく付き合い、豊かにしていくために最低限必要なライセンス上の知識を説明します。(編集部)
いまや、企業が何らかのソフトウェアを開発するときに、オープンソースソフトウェア(OSS)との付き合いを考えずには済まない時代になりつつあります。私は、企業の製品開発者向けにOSSライセンスコンプライアンスに関するコンサルティング・サービスを行っていますが、その中から得られた経験を踏まえながら、OSSとうまく付き合い、コミュニティに還元していくために重要と考えられるポイントを紹介していきたいと思います。
考えてみれば、さまざまなOSSを開発するいろいろな開発者(著作権者)がそれぞれにライセンスを作成するのですから、OSSライセンスの考え方、スタンスは1つではありません。
ところがOSSライセンスのセミナーを実施してみると、意外なことに「OSSライセンスの考え方は1つに限らないことが分かった」という感想をいただきます。商用ライセンスでも企業ごとにライセンスの考え方はいろいろ違うのですから、OSSのライセンスだけが「1つ」と考えられているのは意外でした。
私は、OSSライセンスには主に3種類の考え方があると分類しています。もちろん、現実には以下の3つに分類できないOSSライセンスもあるでしょうし、中には、表面的には同じような要件を備えていても「そんな考え方で作成したライセンスではない」とお怒りになる著作権者(開発者)がいらっしゃるかもしれません。ただ、ここは入門者向けの説明として、こういう分類をお許しください。
|
||||||||||||
表1 OSSライセンスの考え方 |
ここに分類されるのは、前回「BSDタイプ」に分類したOSSライセンスです。それらOSSは、元々主に大学/研究機関で開発されたプログラムを研究成果の一部、または副次的にソースが公開されたことに始まったと思われます。そのため、大学/研究機関の「成果として明示されること」がポイントとなる考え方といえるでしょう。
ここに分類されるのは、前回「LGPLタイプ」と「GPLタイプ」に分類したOSSライセンスです。
以下に示す「ソフトウェアの4つの自由(フリー)」を実現したものを「フリーソフトウェア」と呼び、その「ソフトウェアの自由を守ること」をポイントとする考え方といえるでしょう。
注:正確な定義は、「フリーソフトウェアの定義」を参照してください。
1998年ごろに、GNUの「フリーソフトウェア」という言葉を「オープンソース」という言葉でいい換えて、オープンソースと企業製ソフトウェアとの共存も考慮し、企業へもその輪を広げようとする動きが表れました。
それは、エリック・レイモンド(Eric Raymond)氏がソフトウェアの開発の方法論として「伽藍とバザール」という論文で紹介したことがきっかけとなり、さらに同年、Netscape社のブラウザがオープンソース化された(ソースコードを公開した)ことにより、大きなうねりとなって広がりました。
ここで中心となるのは、多くの人がかかわってソフトウェアが進化していく開発方法論であり、ポイントは「相互扶助」という考え方です。
実は、Linux Conference 2008では「OSSを利用する立場からの話だけでは不十分」という声もいただきました。それを踏まえて、僭越(せんえつ)ながらそれぞれの考えについて少々解説を試みたいと思います。
アカデミック系OSSライセンスのほとんどは、前回の分類ではBSDタイプに属します。つまり、「ソースコードの開示を必須条件としていない」、結果として「バイナリコードのみの頒布」も許可しているライセンスです。
以下のように、多くは大学・研究機関で開発されたOSSのライセンスに用いられているため、「アカデミック系OSSライセンス」と呼ばれています。
などです。
大学がこのような緩いライセンスでプログラムを提供する理由の1つに、「学問の自由(academic freedom)」があるという説があります。
「Academic Free License」というOSSライセンスを書き、OSIの弁護士でもあったLawrence Rosen氏の著書、「Open Source Licensing - Software Freedom and Intellectual Property Law」は、日本の弁護士にも注目されました。現在、別の弁護士の方がボランティアで翻訳案を公開しています。
Rosen氏はこの中で、
大学の先生方は、研究成果を隠ぺいすることより公表されることを奨励される。次に、学生は、それを学び応用し自身の成果として新しいアイデアを生み出すことを期待される。この種の学問の自由を進めるために、大学はしばしば当面の利益を捨てて、社会に彼らの知的財産権を公開して、より大きな利益のことを考えます。もちろん、すべての大学が、常に、この理想を行うわけではないが。
と、大学がこのような緩いライセンスでOSSを公開する動機を紹介しています。
大学・研究機関のこの使命を果たす行為の証しとして、アカデミック系OSSライセンスでは「使命を果たしたのが誰かを明示すること」が第一義となっているのではないでしょうか。
アカデミック系OSSライセンスには名前の付いたライセンスが少なく、OSSごとに異なるライセンスが存在すると考えた方が無難です。しかも、要求される「明示すべき内容」はそれぞれ少しずつ異なります。
例えば、初期のBSDライセンスには「ソフトウェアの機能や仕様について言及している広告媒体には、必ず通知(謝辞)を掲載しなければならない」という条項が存在しました。この条項により、プログラムの改良者の名前が多数追加された結果、広告には掲載できないほどの謝辞の記載が必要になりました。このことは、GNU projectから「BSD ライセンスが抱える問題」で「迷惑窮まりないBSD宣伝条項(advertising clause)」と指摘されたこともありました。
それを解決する目的から、時代が下るに従って四条項→三条項→二条項と簡素化されてきています。しかし、昔のライセンスを用いたバージョンを使用する場合、強いレベルの明示を求める内容が残っているものがありますので、注意が必要です。
明示するレベルを大ざっぱに分類してみると、下図のようなものがあります。
|
||||||||||||||||||||||||||||||
表2 明示レベルの分類 |
次に、(1)から(5)それぞれのレベルで、具体的なライセンスの条文を挙げながら、どのような内容を明示すべきと書かれているのか、1つ1つ確認してみましょう。
Copyright © ITmedia, Inc. All Rights Reserved.