wiki:pne-merge-license
 ここの情報は古いです。ご理解頂いた上でお取り扱いください。

Version 1 (modified by tejimaa, 12 years ago) (diff)

--

>>> これだと、php.netに連絡してね。。と言うような文面なので
>>> ずっとOpenPNEのライセンスとして使っていくのは難しいと思っています。
>>>
>>> 修正BSDライセンスでOpenPNEのライセンスを新たに作り直す必要があるなかなぁ
>>> と思うのですが、なにぶん詳しくない物で、わかりません。

 私の結論から言うと、
 修正BSDライクなライセンスを使えばいいのだと思います。
 手っ取り早いのは、同様の内容を持つApacheライセンス2.0を適用するとか。

 修正BSDライクな新しいライセンスを作るとしたら、
 PHPライセンスを書き直すよりも、
 Apacheライセンス2.0を元にしたほうが簡単そうです。

 現在のPHP3.1ライセンス(http://www.php.net/license/3_01.txt)も、
 実質修正BSDライセンスみたいなもののような気がします。





 メールを読んでみて、3つのポイントがあると考えました。

 A.修正BSDライクなライセンスを探すこと
 B.ライセンス文書の主筆者の変更
 C.Apache Foundationのような組織運営


 もう少し詳しく説明します。


 ●A.修正BSDライクなライセンスを探すこと

 ご存じのとおり修正BSDライセンスは、とてもシンプルで使いやすいライセンス
 です。
 ・日本語訳
 http://sourceforge.jp/projects/opensource/wiki/licenses%2Fnew_BSD_license
 ・英語 http://opensource.org/licenses/bsd-license.php



 実は、ほぼ同様の内容のライセンスがいくつかあります。

 ・MITライセンス
 http://opensource.org/licenses/mit-license.php
 http://sourceforge.jp/projects/opensource/wiki/licenses%2FMIT_license

 ・Apacheライセンス 2.0
 http://opensource.org/licenses/apache2.0.php
 http://sourceforge.jp/projects/opensource/wiki/licenses%2FApache_License_2.0

 ・PHPライセンス 3.0
 http://opensource.org/licenses/php.php
 http://sourceforge.jp/projects/opensource/wiki/licenses%2FPHP_License

 ほかにもあるかも知れませんが、とりあえずここでは、
 この3つでいいでしょう。

 MITライセンスは、分かりやすいと思います。
 修正BSDライセンスからソースとバイナリの区別をのぞいたもの。


 Apacheライセンス2.0は、けっこうややこしい書き方になっています。
 でも、前半の定義を読み飛ばし、特許・ソフトウェア名の扱い・ライセンスバー
 ジョンの扱いなどをのぞけば、言っていることは修正BSDライセンスと同じで
 す。つまり、無保証で著作権者名を残せば、再配布していい。
 この記述形式は、MozillaライセンスやEclispeライセンスでも同じなので、ライ
 センス文のような法律文書の一般的な書き方なのだと思います。

 PHPライセンスについては、私よりもよくご存じでしょう。

 PHPライセンスとApacheライセンスを読み比べてみると、前者はPHPというソフト
 ウェア名が繰り返し出てくるのに対して、後者はほとんど出てこないだけで、項
 目とその内容はほぼ同義のようです。

 ですから、Apacheライセンス2.0をそのまま適用するか、これを元にして、新し
 くOpenPNEライセンスを作る(ライセンス名だけ変更する)と話が早い。新しいラ
 イセンス文を作った場合は、付録の部分に、「Apacheライセンス2.0と同じ内
 容」というようなことを記述しておくことで、利用者の理解が早くなるような気
 がします。まったくの新ライセンスを作ると、ビックリされますし。



 ●B.ライセンス文書の主筆者の変更

 主筆者というのは(そんな言葉があるのか分かりませんが)、著作権者ではなく、
 ライセンス文を書いた人という意味です。

 Apacheライセンス2.0は、そもそも主筆者名も修正制限も出てこないので、ライ
 センス名称とか変えても問題ないでしょう。
 まあ一応、ほかのライセンスがどうなっているか説明してみます。


 ライセンス文というと、著作権者に注目が集まりますが、その文書を書いた人
 (以下、主筆者)も登場します。たとえば、GPLv2では、FSFが主筆者になります。
 ちなみに、GPLv2の冒頭には、文を書き直してはいけないと書いてあります。

 ---
 この利用許諾契約書を、一字一句そのままに複製し頒布することは許可する。
 しかし変更は認めない。
 ---
 http://sourceforge.jp/projects/opensource/wiki/licenses%
 2FGNU_General_Public_License




 主筆者が変わっていった例として、Eclipseのライセンスがあります。
 これは、次のように3回変わっています。

 1. IBM_Public_License
 http://sourceforge.jp/projects/opensource/wiki/licenses%2FIBM_Public_License
 http://opensource.org/licenses/ibmpl.php

 2. Common Public License Version 1.0
 http://sourceforge.jp/projects/opensource/wiki/licenses%
 2FCommon_Public_License
 http://opensource.org/licenses/cpl.php

 3. Eclipse_Public_License
 http://sourceforge.jp/projects/opensource/wiki/licenses%
 2FEclipse_Public_License
 http://opensource.org/licenses/eclipse-1.0.php

 これは、3つとも内容的にはほぼ同義(MPLとよく似ているようです)で、主筆者が
 変わっていっています(ちゃんと細部まで追跡していないので、間違っているか
 も知れません)。

 1番目に採用されたIBM_Public_Licenseは、ライセンス名にIBMという社名が出て
 きて、「IBM以外の者に本契約書を修正する権利はありません。」なんて書いて
 あります(7項 全般)。これが、Eclipseの最初のライセンスでした。

 2番目に採用されたCommon Public License Versionは、次のEclispeのライセン
 スとして採用されました。タイトルにも著作権者名にもIBMの社名は出てこな
 い、Commonなものになっています。

 ただし、第7項は、こんなふうになっています。
 ----
 誰でも本契約書をコピーしたりコピーを頒布したりしてかまいませんが、不一致
 が起きないようにするため、本契約書は著作権で保護されており、修正は次に述
 べる方法でのみ行えるものとします。契約書管理人は本契約書の新バージョン
 (改訂も含む)を発行する権利を留保します。契約書管理人以外の者に本契約書
 を修正する権利はありません。IBMが初期契約書管理人です。IBMは契約書管理人
 の役割を適任者に割り当てることができます。本契約書の各新バージョンには識
 別用のバージョン番号が与えられます。プログラム(コントリビューションも含
 む)の頒布は、必ずそれを受け取ったときの契約書バージョンに従って行わなけ
 ればなりません。
 ----

 Common Licenseなので、Eclipse以外のソフトウェアに使うこともできそうです
 (Microsoftが実際に使ってました)。でも、主筆者がIBMなのがクセ物です。その
 ときMicrosoftがどうしたのか、未確認です。

 現在のEclipseは、3番目のEclipse_Public_Licenseを使っています。ここでは、
 主筆者(初期契約書管理人となっていますね)は、Eclipse Foundationになってい
 ます。ソフトウェアの開発元・著作権者・主筆者が一致しており(Eclipse
 foundation)、私企業でないので、他の開発者も参加しやすいでしょう。

 ---
 誰でも本契約書をコピーしたりコピーを頒布したりしてかまいませんが、不一致
 が起きないようにするため、本契約書は著作権で保護されており、修正は次に述
 べる方法でのみ行えるものとします。契約書管理人は本契約書の新バージョン
 (改訂も含む)を発行する権利を留保します。契約書管理人以外の者に本契約書
 を修正する権利はありません。The Eclipse Foundationが初期契約書管理人で
 す。The Eclipse Foundationは契約書管理人の役割を適任者に割り当てることが
 できます。本契約書の各新バージョンには識別用のバージョン番号が与えられま
 す。プログラム(コントリビューションも含む)の頒布は、必ずそれを受け取っ
 たときの契約書バージョンに従って行わなければなりません。
 ---

 PHPライセンスは、著作権者・ソフトウェア名・主筆者が本文中に混ざってい
 て、ややこしい感じを受けました。

 Apacheライセンス2.0は、主筆者名も修正制限も出てこないので、そのまま適用
 しても大丈夫でしょうし、変えちゃっても問題ないでしょう。ただし、ライセン
 ス名を新規に作ると、「なんだコレは」ということになるので、付録あたりに
 「Apacheライセンス2.0と同じ内容」と書くのがいい、というのはさっきも述べ
 たとおりです。



 ●C. Apache Foundationのような組織運営

> 私はApacheプロジェクトを成功例と捉えています。
> 企業から貢献を受ける場合などの処理は
> http://apache.org/
> http://apache.org/licenses/
>
> このあたりを参考にしたいです。
 これも、ちゃんとおっかけていないので、現状と違うところがあるかも知れませ
 んが、Apache foundationは、ゆるいライセンスを持っている変わりに、きちん
 とした組織体が結束の中心になっているという印象を持っています。

 Foudation(財団法人)ですし。

 日本では、Seaserファウンデーション(http://www.seasarfoundation.org/)が、
 それをうまく真似しているような気がします。Seaser Projectが、どんどんサブ
 プロジェクトを増やしていっているところとか(http://www.seasar.org/)。

 メイン開発者の比嘉さんのパーソナリティだけでなく、Foudationの代表理事で
 ある栗原さんとか、立ち上げ時にいた羽生さんとかが、よく考えて組織を立ち上
 げたのではないでしょうか。最初に良いルールを採用したことで、そこから自然
 と良いコミュニティが育っていったということだと思います。「バザールモデル
 は、ゆるい繋がりなんだ。NPOを作るなんて!」という人が混ざっていたりする
 と、なかなかこうは行きませんが(^^

 もともとは、比嘉さん・栗原さん・羽生さんらが、全然別の(オープンソースで
 ない)コミュニティで知り合いで、信頼関係が出来ていたと、栗原さんから聞い
 たことがあります。このあたりは、栗原さんとかに、一度話を聞いてみると面白
 いかも知れませんね。

 ## こういうのが、ソーシャルなフレームワークの参考例になると思うのです。
 ## その点、日本のOpenOffice.orgコミュニティは、良い参考例になりません。