OSSライセンスが求める条件とは？：企業技術者のためのOSSライセンス入門（2）（1/2 ページ）
この連載では、企業がオープンソースソフトウェアとうまく付き合い、豊かにしていくために最低限必要なライセンス上の知識を説明します。（編集部）
いまや、企業が何らかのソフトウェアを開発するときに、オープンソースソフトウェア（OSS）との付き合いを考えずには済まない時代になりつつあります。私は、企業の製品開発者向けにOSSライセンスコンプライアンスに関するコンサルティング・サービスを行っていますが、その中から得られた経験を踏まえながら、OSSとうまく付き合い、コミュニティに還元していくために重要と考えられるポイントを紹介していきたいと思います。
そもそも順守しなければならない事柄は何か？
前回「訴訟が増えている!? OSSライセンス違反」では、「許諾にかかわる利用方法および条件がライセンス条文、つまり許諾要件」であることを説明しました。
そもそもOSSライセンスでの許諾条件には、どのようなものがあるのでしょうか？ ピンとこない方のために、1つ例を挙げて解説してみましょう。
許諾条件とはライセンス条文そのものですから、正確を期するにはライセンス条文を読む必要があります。しかも、多くは英文ですが、その原文を読む必要があります。一例として、「とても制限が緩い」といわれているPostgreSQLのBSDライセンスには、以下のような項目が書かれています（画面1）。
（a）Copyrightの著作権表示
（b）再頒布の条件
（c）免責条項（損害責任の否認）
Copyrightの著作権表示（a）は、よく見掛ける著作権表示、つまり著作権者が誰であるかを示す表記です。
免責条項（損害責任の否認）（c）は、著作権者であるカリフォルニア大学の損害賠償責任の否認およびプログラムを「as is」＝「そのまま」で利用してほしいこと、つまり、改修などの義務を負わないことを宣言した免責条項です。
日本でオープンソースがバブル的に注目された1999年ごろは、この免責条項や瑕疵担保責任の否認があることを理由に、「オープンソースは業務には使えない」とする意見を聞いたことがありました。しかし、たいていの商用プログラムのライセンスでも同様の条文が存在しており、そう違いはありません。
しかも、瑕疵担保責任は一般に有償契約に認められるものとされています（日本国民法第570条、第634条）。そのため、無償で提供することが多いオープンソースには、ライセンス条文に書かれていなくても、もともと瑕疵担保責任は存在しないといえます。
OSSの瑕疵担保責任については、日本OSS推進フォーラムで2005年にまとめた「ビジネスユースにおけるオープンソースソフトウェアの法的リスクに関する調査」の「2.5.1 瑕疵担保責任」あたりの記述が参考になるかと思います。
さて、ライセンスごとに大きく異なるところが再配布の条件（b）です。多くのBSDライセンスと同様に、以下の3点セットが「すべての複製物（all copies）に表示（appear）されること」が指定されています。
- 著作権表示（the above copyright notice）
- ライセンス条文（this paragraph）
- 免責条項（損害責任の否認）（the following two paragraphs）
これは、通常のライセンスファイル（COPYRIGHT）に書かれている3項目そのものです。そのため、OSSを利用したデジタル家電製品のマニュアルにさえ、このような英文のライセンス条文が掲載されていることが珍しくありません。
70種類以上もあるOSSライセンス
PostgreSQLのBSDライセンスが、「上記3点セットの掲載」をポイントとする一方、前回「改変したプログラムも派生物としてGPLのライセンスで頒布することが条件になっています」と紹介したGPL（GNU General Public License）は、「ソースコードの開示」が焦点になるライセンスです。
このほかに、Open Source Initiative（OSI）が承認したOSSライセンスだけでも、70種類以上70種類以上が挙げられています（画面2）。前出の「法的リスクに関する調査」資料をまとめた2004年時点では50種類強でしたが、その後も増え続けています。
そこで当時から「OSSライセンスが増え過ぎている」という認識がありました。そうした削減を求める声に応えてか、2005年9月、サン・マイクロシステムズはオフィススイート「OpenOffice.org」で使用していた独自ライセンス「Sun Industry Standards Source License（SISSL）」の使用を停止しました（OpenOffice.orgはGNU LGPLとのデュアルライセンスだったので、LGPLに一本化されました）。
とはいえ商用製品のライセンスでも、会社ごと、製品ごとに数種類ずつライセンスがあったりします。いったい世の中にどれだけの商用ライセンスがあるか想像もつきませんから、「ライセンスが増え過ぎている」というのはOSS特有の話でもありません。
ありがたいことに、オープンソースグループ・ジャパン（OSG-JP）により、ほとんどのOSI承認OSSライセンスの日本語参考訳が公開されていますので、大変参考になります。
しかし、サイトの前書きに書いてあるように「頒布条件としては英語版テキストで指定されているもののみが有効です」ということに注意してください。これは、多くのライセンスでは、原文が英語だからです。そのため、日本製の大型テレビなど、デジタル家電の日本語の説明書にも英文のライセンス原文が掲載されていたりします。
ところで、OSI承認ライセンスとは、OSIが「オープンソースの定義（The Open Source Definition：OSD、日本語訳）に準拠したライセンスである」とOSI認定マークで証明したライセンスのことをいいます。
OSDは、「オープンソース」（OSS）という言葉の意味が正確性を失いつつある状況を改善するため、OSSの定義として活用する目的で、OSIが規定したものです。しかし順序としては、多数のOSSが現実に登場してきた後にまとめられた定義ですから、各ライセンスは必ずしも、その定義に従って記載されているわけではありません。この定義は現在10項目ありますが、個々のOSSライセンスに該当するすべての項目が必須となるわけではなく、定義と矛盾した条項がなければ認定されているようです。現状ではそういう柔らかな定義であることに注意してください。
なお中には、OSS自体はメジャーでもライセンスはマイナーなOpenSSLなどのように、OSI承認ライセンスに挙がっていないものもあります。従って、現実の開発の場では、意識しなければならないOSSライセンスはさらに多く存在することになります。
このようにライセンス数が多くなると、全体像がよく見えなくなってきます。OSIでも「Licenses by Category」でOSSライセンスをカテゴリ分けして掲載していますが、「ポピュラーまたは有力なコミュニティのライセンス」「特殊用途のライセンス」「その他雑多なライセンス」「不要になったライセンス」「再利用不可能なライセンス」「取って代わられたライセンス」「自主的に廃棄されたライセンス」「カテゴライズされないライセンス」……という具合で、私が知りたいカテゴリとは違うようです。
そこで、企業の製品開発者向けに役立ちそうなカテゴリ分けを検討しました。
Copyright © ITmedia, Inc. All Rights Reserved.