Placebo Effect > OSS 

知って役立つOSSのライセンス

可知 豊 http://www.catch.jp/


license
 本テキストは、クリエイティブ・コモンズ・ライセンス(表示-継承 2.1 日本 の下でライセンスされています。


2007-05-21 Web公開

OpenDocument版は、こちら

 この文書は、技術評論社のSoftware Design 20072月号の「特集2:プログラマよ立ち上がれ! OSS開発者への道」という記事の「Appendix2:知って役立つOSSのライセンス」の一部を加筆訂正したものです。掲載時の原稿では、分量の関係で削除した部分も復活させました。これまでに、同じような内容の文章を我ながらいくつか書いていますが、今回は特集に合わせてプログラマ向けの内容になっています。

 この面白そうな文書を書く機会を与えてくださったSoftware Design編集部に感謝します。

 なお、同時期に、ソフトバンクのオープンソースマガジン20071月号でもオープンソース特集が組まれました。こちらでは、八田真行 さん・たかはしもとのぶさん・まつもと ゆきひろさんらが解説しています。合わせて参考にして頂くといいでしょう。特に、まつもとさんの記事では、「フリーソフトウェアライセンス診断」をアップデートしています。

2008-07-28:CPLに関する記述を修正


特集プログラマよ立ち上がれ! OSS開発者への道

App2:知って役立つOSSのライセンス


 オープンソースについて調べていくと、ライセンスに関する説明が目に付きます。ここでは、それをOSSのライセンスがどのようなものか、どのような種類があるか、どのように適用するか、といった基本的なノウハウを解説します。


1.OSSライセンスって何?

「これは、誰でも自由に利用できるソースコードである」と宣言するのが、オープンソースソフトウェア(以下、OSS)のライセンスの働きです。オープンソースの定義は、OSSのライセンス(以下、OSSライセンス)がどのような条件を満たしているかを述べています。このようなライセンスは、著作権の働きにより効果を与えます。

1.1著作権を知ろう

 OSSに限らずソフトウェアのライセンスは、著作権の仕組みの上で働いています。著作権というフレームワークの上に実装されていると考えると、分かりやすいでしょう。

著作権とは

 著作権とは、ひじょうに大ざっぱに言えば、作品をどのように公開するか、どのように利用するかを作者が決定する権利です。この権利は、どこかに申請したり登録したりしなくても、自動的に発生するとされています。

利用と使用を区別する

 著作物の利用とは、印刷したり録音したり、それを配布するといった使い方を指します。例えば、本誌のような雑誌であれば、印刷・出版することが利用になります。

 ところが、本を読むことは利用にはあたりません。著作権の考え方では、このような使い方を使用として区別します。使用については、著作権者の許可は必要なく自由に行えます。また、利用についても、教育や引用などの特定の用途であれば自由に行えます。

 著作権の話題となると、「勝手に使ってはいけない」という禁止の話になりがちですが、自由に使える部分もあるということを覚えておいてください。

copyright

ライセンスは利用許可

 著作物を利用するには、作者から著作権の一部を譲り受けるか、著作権者の利用許可が必要になります。

 この著作物の利用許可が"ライセンス"です。ドライバーライセンスと言えば、自動車免許です。殺しのライセンスを持つのは、ジェームズ・ボンドです。

 著作物に対するライセンスとは、"一定の条件に従えば、その著作物を指定の範囲で利用してもいい"という利用許可です。たとえば、"お金を支払えば"とか"1万部まで印刷可"といった条件があり得ます。


1.2ソフトウェアライセンス

 ソフトウェアは、著作権法上の著作物に当たります。それを利用する場合に、著作権者の許可が必要になります。

ソフトウェアライセンスの働き

 ソフトウェアでは、複製・配布・改変について利用許可が必要になります。

 ソフトウェアの複製は、CD-Rに焼いたり、インターネットからダウンロード(サーバーからクライアントへのコピー)に当たります。ソフトウェアの配布は、そのCD-Rを販売したり、インターネットで公開することに当たります。ソフトウェアの改変は、機能を変更したり追加することに当たります。

 一般的なソフトウェアライセンスでは、このような許可を与えるために、代金を請求したり、使用の一部を制限したりしています。Microsoftは、Windowsなどの自社製品を販売するとき、代金と引き替えに一定の複製を許可します。そのおかげで、パソコンにインストールできますが、改変は許可されていません。また、本来自由にできるリバースエンジニアリングなどを制限します。

 このような利用許可は、ソフトウェアのインストール時に表示されます。利用者が「同意する」ボタンをクリックすると、インストールが完了します。

term


では、OSSのライセンスは?

 では、OSSのライセンスは、どのような条件を備えているのでしょうか。これをまとめたのが、Open Source InitiativeOSI)が定めた「オープンソースの定義」(Open Source Definition)です。

 ここには、3つの権利と6つの条件が書かれています。ここで重要なのは、次の3つの権利です。

オープンソースの権利

 OSSのライセンスには、このような権利が備わっています。利用者は、一定の条件に従えば、ソースコードを自由に利用(複製・配布・改変)できるのです。

 その条件は、ライセンスごとに異なっていますが、オープンソースの定義では、最低でも次の条件を備えるとしています。

「個人もしくは団体を差別しない」ので、特定の国で利用禁止とはできません。「使用分野に対する差別をしない」ので、戦争には利用禁止とできません。「再配布時には追加ライセンスを必要としない」ので、別のライセンスを購入しないと利用不可とはできません。

 OSSライセンスは、ソースコードの再利用と共同開発を促進するために、できる限りソースコードの複製・配布・改変を制限しないようになっているのです。


2.OSSライセンスの種類とその特徴

 OSSライセンスの詳細は、ライセンスの種類ごとに異なっています。ここでは、代表的な3つのライセンスについて、その特徴と理解のポイントを説明します。

 オープンソースについて知ろうとすると、GPLについて真っ先に説明されることが多いようですが、これは一番長文かつ複雑で理解が難しいと思います。ここでは、最も単純な修正BSDライセンスから説明していきます。

 各ライセンスの代表的なソフトウェアを表1に示します。

表1:各ライセンス代表的なソフトウェア

修正BSDライセンス

FreeBSDNetBSDOpenBSD

MPL

FirefoxThunderbird(ともにMPL/LGPL/GPLのトリプルライセンス)

GPL

Linuxカーネル、GIMP

LGPL

GTK+OpenOffice.org


2.1修正BSDライセンス

 このライセンスは、著作権表示と免責条項を含めれば、自由に複製・配布・改変できるとするライセンスです。改変したソフトウェアを商用ライセンスなどの異なるライセンスを適用して公開しても構いません。単に、BSDライセンスと呼ばれる場合もあります。

 同様の内容を持つライセンスに、MIT/X11ライセンスがあります。

ライセンス条項

 以下のようなシンプルな条項を持っています。

 これは、OSG-jpOSI承認ライセンス 日本語参考訳をもとに、読者の理解を助けるために一部書き換えを行ったものです。短い文なので、じっくりと読んでみてください。

プログラム名

Copyright 制作年著作権者 All rights reserved.

   1. ソースコード形式であれバイナリ形式であれ、変更の有無にかかわらず、以下の条件を満たす限りにおいて、再配布および使用を許可する。
         1. ソースコード形式で再配布する場合、上記著作権表示、本条件書および第2項の責任限定規定を必ず含める。
         2. バイナリ形式で再配布する場合、上記著作権表示、本条件書および下記責任限定規定を、配布物とともに提供される文書および/または他の資料に必ず含める。
   2. 本ソフトウェアは無保証である。自己責任で使用する。
   3. 著作権者の名前を、広告や宣伝に勝手に使用しない。


利点と欠点

 元々、修正BSDライセンスは、カリフォルニア大学バークレー校で、UNIX互換OSの配布用に作られたライセンスです。制約が少ないことから、大学などの研究成果によく利用されます。

 しかし、改変版のソースコードを異なるライセンスで配布できるため、他のプログラム中に独占的に取り込まれてしまう可能性があります。

削除された広告条項

 元々のBSDライセンスには、1-3項として広告に関する条項が含まれていました。この広告条項には、「改変したソースコードを利用した製品の広告に初期開発者名を表示すること」という条件を持っていました。

 現在、その条項は削除されています。修正BSDライセンスとは、この広告条項を削除したバージョンのことです。


2.2Mozilla Public License(MPL)

 Netscape社とMozilla Organizationにより作成されたOSSライセンスです。Netscape社がオープンソースにしたWebブラウザのために作成されました。

 同様の内容を持つライセンスとして、Common Public License(CPL)Eclipse Public License (EPL)があります。CPLは、特定のソフトウェア名や企業名が出てこないよう記述してあるので、このようなライセンスを採用する場合には、CPLを選択すると良いでしょう。

ライセンスの特徴

 このライセンスの元で公開されているソースコードを改変した場合には、同じライセンスで公開する義務があります。ただし、新規に開発した追加モジュールは、その限りではありません。そのため、プラグインなどを異なるライセンスで公開できます。

 また、このライセンスの元で公開されるソースコードに特許が含まれている場合には、それを明示する必要があります。

利点と欠点

 MPLは、非常にバランスの取れたOSSライセンスだと思います。どのような改変を行ったときに、同一のライセンスの元で公開する必要があるか明確になっており、それが実用的な範囲にとどまっています。

 また、特許についても明示する必要があり、サブマリン特許のような問題を回避できます。


2.3GNU General Public License(GPL)GNU Lesser General Public License(LGPL)


 自由に利用可能なソフトウェアに適用されるライセンスとして、フリーソフトウェア財団(以下、FSF)が作成したライセンスです。

 LGPLは、GPLと比較して派生物の範囲を狭めたライセンスです。派生物とは、ソースコードの改変物を指す訳語です。

 なお、現在のGPLは、ほとんどの場合1991年に改訂されたGPLv2を指します。

ライセンスの特徴

 GPLでは、「派生物も同じライセンスで配布すること」という“コピーレフト”の考え方を適用しています。つまり、GPLのソフトウェアを改変したら、その改変版もGPLで公開する必要があります。

 GPLでは、派生物についての「著作権上の派生物」(derivative work under copyright law)とだけ記されており、リンクしたファイルなどが派生物にあたるかは書かれていません。一方、LGPLには、次の記述があります。


あるライブラリがあるプログラムとリンクされる場合、それが静的にリンクされるか共有ライブラリとして利用されるかは 問わず、両者の結合したものは法的に言って結合著作物、すなわち元のライブラリの派生物となります。このような場合、通常の一般公衆利用許諾書では、全体 としての結合物がライセンスの規定する自由の基準に適合する場合のみそのようなリンクを許可しています。いっぽう劣等一般公衆利用許諾書では、ライブラリ を他のコードとリンクする許可に関して、より緩い基準で評価します


 すなわち、GPLでは、静的/動的を問わずリンクしたファイルも派生物になると解釈できます。

 LGPLでは、ライブラリを呼び出す側のプログラムは、派生物とならず公開は不要です。なお、現在FSFは、このライセンスをライブラリに適用することを奨励していません。

利点と欠点

 GPLが適用されたプログラムでは、その派生物にも同じくGPLが適用されるので、他のプログラム中に独占的に取り込まれることはありません。

 しかし、BSDライセンスと比べて条項が複雑なので、利用者にとって理解しにくいと言われています。

※コラム:経済産業省の報告書を参考に

 経済産業省は、GPLの適用と運用について、「オープンソース・ソフトウェアの導入検討ガイドライン」を公表しています。これは、経産省の企画の下で、情報処理推進機構(IPAInformation-technology Promotion Agency)による「電子商取引関連基盤技術開発・実証事業」の一環として、ソフトウェア情報センター(SOFTIC)の研究会がまとめたもので、PDFファイルで公開されています。

産経省

オープンソースソフトウエアの利用状況調査/導入検討ガイドラインの公表について

http://www.meti.go.jp/kohosys/press/0004397/


2.4OSSライセンスを理解するポイント

 では、OSSライセンスを理解するポイントをいくつか解説します。

無償とは限らない

 OSSライセンスには、「代金を請求してはいけない」と書いてありません。OSSの利点として、無償で配布できることが強調されがちですが、有償でも良いのです。

 ただし、有償で販売したものを購入者が再配布できるので、何か付加価値を付けないとビジネスにならないでしょう。

改変の範囲

 オープンソースでは、元のソースコードを改変した場合に、その改変版を公開しなければならないとする「コピーレフト」の考えを持っているものがあります。

 ソフトウェアの改変として、一般的に次のような作業を上げることができます。



 どの作業を改変と見なすかは、ライセンスごとに次のようになります。


:どのような作業を改変と見なすか

ライセンス名

修正

追加

静的リンク

動的リンク

GPL

LGPL

×

MPL

×

×

=改変,×=改変ではない

 GPL/LGPL/MPLが適用されたソースコードでは、改変となるソースコードを公開する必要があります。ただし、改変版を配布しないのであれば、公開する必要はありません。


コピーレフトは必須ではない

 オープンソースについてのよくある勘違いとして、「ソースコードを改変したら必ずオープンソースにしなければならない」と考があります。

 しかし、このような条件を持っているのは、オープンソースライセンスの一部です。このような条件は、一般的に「コピーレフト」と呼ばれ、ソースコードを改変したり、独自に開発したプログラムに組み込んだ場合に、改変版プログラムを同じライセンスで公開するとしています。

 修正BSDライセンスのようにコピーレフトを条件として持っていない場合は、改変版のプログラムのライセンスを変更して、非オープンソースソフトウェアとして販売できます。


デュアルライセンス

 いくつかのOSSでは、デュアルライセンス(Dual License)を採用しています。これは、複数のライセンスを提示して、ユーザにそれを選択させるという方式です。多くの場合、GPLとそれよりも制限の緩いライセンスの選択方式になっています。たとえば、MySQLでは、GPLと商用ライセンスのデュアルライセンスになっています。

dual license


英語が正文

 ほとんどのOSSライセンスでは、英語のライセンス文は正文となっています。日本語は、参考訳という位置づけです。インターネットのおかげで、公開したソースコードは、世界中で利用される可能性があります。そのため、できるだけ多く人が理解可能な言語が選ばれています(欧米中心ということかも知れませんが)


3.OSSライセンスを適用する

 ここでは、OSSのソースコードを利用するとき、ライセンスをどのように適用するか、オープンソースプロジェクトと関わるには、といった実践的な内容を解説します。

3.1利用の実際

 まずは、OSSのソースコードを改変したり、自作のソフトウェアをオープンソースにする場合、どのようにライセンスを適用するのか説明します。

ライセンスを確認する

 OSSのソースコードを利用するのであれば、まずはそのライセンスを確認しましょう。もしも、身近にOSSのソースコードがあれば、そのソースファイルを開いてみてください。ほとんどの場合、モジュールファイルの冒頭にライセンス文かライセンスの宣言文を記述してあります。

 修正BSDライセンスまたはMPLのソースコードでは、ライセンス文自体がソースコードの冒頭に記述してあります。GPL/LGPLでは、ライセンスの宣言文がソースコードの冒頭に記載してあります。また、ライセンスの全文がソースコードのアーカイブに同梱してあります。

ソースコードを改変したら

 ソースコードを改変したら、修正版を公開するかどうかを判断します。前述の「改変の範囲」を参考にしてください。オリジナルと同じライセンスにしておくのが、手堅い選択だと思います。

 なお、改変ソフトウェアを配布せず、自社内で使うだけの場合は公開する必要はありません。たとえば、改変したLinuxWebサーバーのOSとして用いる場合には、公開しなくても構いません。

自作コードのライセンスを決める

 自分が開発したソースコードを公開する場合には、ライセンスを選択しなくてはなりません。

 では、どのようにライセンスを選択すべきでしょうか。Rubyの開発者であるまつもとゆきひろさんは、自身のブログで「フリーソフトウェアライセンス診断」を公開しており、いくつかの質問によりライセンスを選択できるとしています。これを要約すると次のようになります。

0. やらない方がいいこと:自分用に新しいライセンスを作る  → サポートが大変
1.商用ソフトウェアに組み込まれて販売されては嫌か? → GPLを選択
2.フリーソフトウェア運動に心から賛同しているか? → GPLを選択
3.特定のOSSに組み込まれたいか → そのOSSと同一のライセンスを選択

以上に当てはまらない場合は、修正BSDライセンスを選択する。


 まつもとさんの診断方法は、タイトルからも分かるように"フリーソフトウェア"を対象としています。これは、オープンソースとは微妙に異なるものです。(まつもとさんは、ソフトバンクのオープンソースマガジン20071月号に掲載されたオープンソース特集で、この「フリーソフトウェアライセンス診断」をアップデートしています)

 企業が自社ソフトウェアをオープンソースにする場合には、デュアルライセンスやCPLについて検討すると良いでしょう。

自作コードにライセンスを適用する

 自作コードをOSSにするには、次のような作業を行います。


  1. ソースコードの各ファイル冒頭にライセンス宣言文を挿入する

  2. ライセンス全文をソースコードのアーカイブに含める

  3. ソースコードをWebサイトなどに置き、入手可能な状態にする

  4. 自慢する

 修正BSDライセンスとMPLの場合、ライセンス宣言文には、ライセンス全文を使います。GPL/LGPLの場合には、ライセンス全文の末尾に宣言文の雛形が用意してあるので、これを使います。

GPLのライセンス宣言文雛形

 あなたが新しいプログラムを開発したとして、公衆によってそれが利用される可能性を最大にしたいなら、そのプログラムをこの契約書の条項に従って誰でも再頒布あるいは変更できるようフリーソフトウェアにするのが最善です。

 そのためには、プログラムに以下のような表示を添付してください。そ の場合、保証が排除されているということを最も効果的に伝えるために、それぞれのソースファイルの冒頭に表示を添付すれば最も安全です。少なくとも、「著 作権表示」という行と全文がある場所へのポインタだけは各ファイルに含めて置いてください。


one line to give the program's name and an idea of what it does.

Copyright (C) yyyy name of author

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of

MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.

訳=====
ここに、プログラムの名前と、それが何をするかについての簡単な説明を記述する。

Copyright (C) 西暦年 作者の名前

このプログラムはフリーソフトウェアです。あなたはこれを、フリーソフトウェア財団によって発行された GNU 一般公衆利用許諾契約書(バージョン2か、希望によってはそれ以降のバージョンのうちどれか)の定める条件の下で再頒布または改変することができます。

このプログラムは有用であることを願って頒布されますが、*全くの無保証* です。商業可能性の保証や特定の目的への適合性は、言外に示されたものも含め全く存在しません。詳しくはGNU 一般公衆利用許諾契約書をご覧ください。

あなたはこのプログラムと共に、GNU 一般公衆利用許諾契約書の複製物を一部受け取ったはずです。もし受け取っていなければ、フリーソフトウェア財団まで請求してください(宛先は the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA)。
=====

GNU 一般公衆利用許諾契約書より
Free Software Foundation, Inc.,
八田真行訳


3.2ライセンス選択の注意点

 ソースコードを改変したり、新しくライセンスを選択するときには、次の点に注意します。

既存のライセンスを書き換えない

 既存のOSSライセンスを選択するとき、その一部を勝手に書き換えて、元と同じ名称で用いるべきではありません。利用者にとって混乱の元になりますし、ライセンスによってはそれを禁止している場合があります。

ライセンスの種類は変更できるか

 ライセンスの種類によっては、次のように適用ライセンスを変更できます。

ライセンスの混在に注意する

 ソースコードを利用するときには、異なるライセンスのソースコードを混在させていないか注意しましょう。ライセンスの組み合わせによっては、混在が禁止されている場合があります。

 たとえば、単独でGPLまたはMPLを適用しているソースコードは、単独で他方を適用しているソースコードに追加したりリンクしたりできません。MPLGPLが、矛盾する追加項目を備えているためです。ただ、MPLGPLのデュアルライセンスを適用しているソースコードであれば、GPLを適用しているソースコードを追加・リンク可能です。


4.OSSライセンスの現在と将来

 最後に、OSSライセンスの現状と課題について、いくつかの話題を紹介しましょう。

4.1ライセンス以外の要素

 ライセンスの適用や運用を考えるとき、ライセンス以外の要素も考慮しておくといいでしょう。

プロジェクトにフィードバックする場合

 ソースコードの改変をプロジェクトにフィードバックしたい人は、各プロジェクトがどのような手順でフィードバックを受け付けているか確認しておきましょう。

 OSSのソースコードを利用して、バグを発見した場合を考えてみましょう。自分で使うプログラムにパッチを当てるだけでなく、それを他の人にも役立ててもらおうと公開すると、喜ばれるかも知れません。さらに、他の利用者がいちいちパッチをあてるのは面倒なので、開発元のOSSプロジェクトでソースコードにパッチを統合してもらうと良いでしょう。

 しかし、開発元のOSSプロジェクトでは、誰でも自由にソースコードを追加できる訳ではありません。誰でも追加できるとしたら、ウィルスやバックドアを仕掛けられて、それが公式版として配布されてしまうといった可能性があるからです。

 OSSは、自由に複製・配布・改変できますが、その改変をフィードバックしたとき、開発元が受け入れてくれるかどうかは別の問題です。

 フリーのオフィススイートであるOpenOffice.orgでは、フィードバックする開発者に対して、イニシャル・デベロッパーであるSun Micorsystemsと共同著作権管理契約(JCA:Joint Copyright Assignment)を結ぶよう求めています。モジュールごとに著作権者が違っていると、全体のライセンスの管理が煩雑になりますが、この契約を一種の委任状とすることで、SunOpenOffice.orgのライセンスを独自に変更できるようになっています。

商標と特許

 ソフトウェアは、著作権法上の著作物となっています。しか し、ソフトウェアに含まれる権利は、著作権だけとは限らず、商標や特許が含まれる場合があります。著作物としてのソースコードは自由に複製・配布・改変で きますが、商標や特許だけを取り出して、自由に使えないとするのが一般的です。これを利用して、オープンソースのビジネスを展開している企業もあります。

 Red Hat Enterprise Linux(RHEL)は、Redhatの商標を含めたままでは、複製・配布できないとしています。そこで、コミュニティベースで商標部分を削除した、CentOSなどのRHELクローンが登場しました。

 Mozilla財団が開発しているWebブラウザFirefoxでは、その名称やトレードマーク・アイコンの改変を許可していません。そのため、フリーなソフトウェアをボランティアで配布しているDebianプロジェクトでは、FirefoxをベースとするWebブラウザからロゴを削除し、異なる名称で収録する模様です。

ドキュメントのライセンス

 オープンソースが人気を集めてくると、オープンソース以外のコンテンツも誰でも自由に複製・配布・改変できないかと考える人も出てきました。

 この場合、OSSライセンスはそのまま採用できないので、次のようなドキュメントや素材用ライセンスが登場しています。

 GFDLは、GPL/LGPLと同じくFSFが定めたドキュメント用ライセンスです。Wikipediaが採用しています。一方、Debianプロジェクトでは、GFDLは条件が厳しすぎるとして、フリーなドキュメントとして配布していません。

 Creative Commonsは、ドキュメントに限らず、音楽・画像・映像などの創造的な作品に,柔軟な著作権をライセンスで、次のような特徴を持っています。

 特に、商用利用の可否・コピーレフトの可否など柔軟な条件を選択できるところも便利です。新規のドキュメントを公開する場合には、こちらが使いやすいと思います。

4.2GPLのその先へ

 オープンソースは、いろいろな状況に揉まれながら、着実に存在感を増してきました。同時に、コンピュータを取り巻く環境も刻々と変化しており、それに連れてソフトウェア特許やDRM・ライセンスの国際化対応といった新しい課題が注目を集めています。

 FSFは、そのような課題に対応するため、GPLv3への改訂を検討しています。ドラフト120069月に公開され、現在コメントに対応したドラフト2が公開されています。Linuxカーネルの開発者の一人であるリーナス・トーバルズが、このGPLv3に異議を唱えるなど、議論はまだまだ白熱していく模様です。

 とはいえ、ライセンスを選択するのは、著作権者であるソフトウェア開発者です。何となくライセンスを選ぶのではなく、きちんと理解して、作者と利用者の利便性のバランスを取っていくことが欠かせないでしょう。


5.参考

著作権 〜新たな文化のパスワード〜

http://www.bunka.go.jp/1tyosaku/

オープンソースの定義(The Open Source Definition)

http://www.opensource.org/docs/definition.html

オープンソースの定義 日本語訳

http://www.opensource.jp/osd/osd-japanese.html

The FreeBSD Copyright 日本語参考訳

http://www.jp.freebsd.org/www.freebsd.org/ja/copyright/freebsd-license.html

Mozilla Public License 日本語参考訳

http://www.mozilla-japan.org/MPL/MPL-1.1J.html

MPL FAQ

http://www.mozilla-japan.org/MPL/mpl-faq.html

Common Public License 日本語参考訳

http://www.opensource.jp/licenses/cpl.html

GNU General Public License (GPL) 日本語参考訳

http://www.gnu.org/licenses/gpl.ja.html

GNU Lesser General Public License (LGPL) 日本語参考訳

http://www.gnu.org/licenses/lgpl.ja.html

さまざまなライセンスとそれらについての解説

http://www.gnu.org/licenses/license-list.ja.html

BSD ライセンスが抱える問題

http://www.gnu.org/philosophy/bsd.ja.html

フリーソフトウェアライセンス診断

http://www.rubyist.net/~matz/20030608.html#p02

OpenOffice.org Joint Copyright Assignment (JCA) 日本語参考訳

http://openoffice-docj.sourceforge.jp/tr/translated/jca.html

GNU フリー文書利用許諾契約書 日本語参考訳

http://www.opensource.jp/fdl/fdl.ja.html.euc-jp

Creative Commons

http://www.creativecommons.jp/

オープンソース:GNU GPLv3 Discussion Draft 2 日本語訳

http://opentechpress.jp/opensource/article.pl?sid=06/09/26/0422219