プロジェクトに適用するライセンスを選ぶときは、 できる限り新しいものを作らずに既にあるものを使うようにしましょう。 有り物を使う理由はふたつあります。
ライセンスが既に知られているからです。 あなたが人気のあるライセンスのうちのひとつを使えば、 コードを使う人が法律用語をわざわざ読む必要はないと思うでしょう。 ずっと以前に読んだことがあるからです。
ライセンスの質が保たれているからです。 自分の思い通りになる弁護士のチームがいなければ、 法的に隙がないライセンスを生み出すことはできないでしょう。 この章で触れているライセンスには、多くの人々の経験や思考が詰まっています。 つまり、あなたのプロジェクトに本当に変わった要求がない限り、 さらに行動する必要はないということです。
プロジェクトにライセンスを適用するには、 2章さあ始めましょう の 「ライセンスを適用する方法」 を参照してください。
自分のコードをできる限り多くの開発者と派生物で使ってもらい、 かつ独占的なコードで使われるのを気にしないのならば、 MIT/X Window System ライセンス(以下 MIT/X ライセンス) (マサチューセッツ工科大学 がオリジナルの X Window System のコードをこのライセンスでリリースしたので、 そう呼ばれています) を選びましょう。このライセンスが言っているのは基本的に 「あなたはこのコードを自由に、 無料で使うことができますよ」ということです。 このライセンスは GNU GPL と互換性があり、短く、簡単で、理解しやすいものです。
Copyright (c) <year> <copyright holders> 以下に定める条件に従い、本ソフトウェアおよび関連文書のファイル（以下「ソフトウェア」）の複製を取得するすべての人に対し、ソフトウェアを無制限に扱うこと を無償で許可します。これには、ソフトウェアの複製を使用、複写、変更、結合、掲載、頒布、サブライセンス、および/または販売する権利、およびソフトウェアを提 供する相手に同じことを許可する権利も無制限に含まれます。 上記の著作権表示および本許諾表示を、ソフトウェアのすべての複製または重要な部分に記載するものとします。 ソフトウェアは「現状のまま」で、明示であるか暗黙であるかを問わず、何らの保証もなく提供されます。ここでいう保証とは、商品性、特定の目的への適合性、およ び権利非侵害についての保証も含みますが、それに限定されるものではありません。作者または著作権者は、契約行為、不法行為、またはそれ以外であろうと、ソフト ウェアに起因または関連し、あるいはソフトウェアの使用またはその他の扱いによって生じる一切の請求、損害、その他の義務について何らの責任も負わないものとし ます。
(原文は http://www.opensource.org/licenses/mit-license.php にあります。日本語訳については http://sourceforge.jp/projects/opensource/wiki/licenses%2FMIT_license から引用させて頂きました。)
あなたのプロジェクトが、自分達が作ったものが独占的なプログラムで使われるのを望まなかったり、 少なくともそうしたことを気にしないのであれば、GPL (GNU General Public License) (http://www.fsf.org/licensing/licenses/gpl.html) を選ぶとよいでしょう。 GPL はおそらく、現在世界でもっとも広く使われているフリーソフトウェアライセンスです。 認知度が高いことが、それ自体 GPL の主な利点のひとつです。
他のプログラムの一部として使われるライブラリを書いている場合は、 あなたのプロジェクトの目標に照らして、GPL の制限を注意深く考える必要があります。 場合によっては — たとえば、自分達のライブラリと同じことをしている独占的なプログラムのシェアを奪おうとしている場合 — あなたがたとえ望まなくても、独占的なプログラムで使えるようにするやり方で、 プログラムをライセンスするのが戦略として優れているかもしれません。 FSF は、こうした場合のために GPL とは別の選択肢を用意しました。 それが GNU Library GPLであり、 後にGNU Lesser GPL と改称されたものです。 (ほとんどの人はその頭文字をとって、LGPL という用語を使います) LGPL は GPL よりも制限が緩く、フリーでないコードと容易に混ぜることができます。 しかしながら、LGPL はちょっと複雑で理解するのに少し時間がかかります。 よって、GPL を使うつもりがないなら、MIT/X スタイルのライセンスを使うことを私は勧めます。
GPL を選んだ結果、プロジェクトがコードに対してできることを制限された場合 — すなわち他のライセンスでコードを配布できなかった場合 — GPL が本当の意味で「フリー(自由)」 なのかどうかに関する論争がプロジェクトで起こるかもしれません — これが起こる可能性は小さいですが、ゼロとはいえません。 人によっては、他のライセンスでコードを配布できないという制限が、 MIT/X ライセンスのような制限の緩いライセンスよりも GPL が「自由度が低い」ように映るのです。 もちろん、こうした主張が行き着くところは、「自由度は低いより高い方がいいに決まっている」 というものですが (自由であることに賛成しない人がいるでしょうか?)、 これに従うと、制限の緩いライセンスが GPL よりも優れているということになります。
この手の議論は、宗教論争 (6章コミュニケーション の「宗教論争を回避する」 を参照してください) になるお題のひとつです。 少なくも公開されているフォーラムでは、これに参加しないようにしましょう。 GPL が 他のライセンスより自由度が高いとか、低いとか、同じだとか、 そういうことを証明しようとしてはいけません。 そうではなくて、あなたのプロジェクトがなぜ GPL を選んだのかを強調するようにしましょう。 ライセンスの認知度が高いことが理由なら、そう言えばいいのです。 派生物に同じ条件を強制するのが理由なら、それも伝えましょう。 しかし、GPL のやり方がコードの「自由度を高くするのか、 低くするのかどうか」という議論には絶対にしないでください。 「自由とは何か」というお題は複雑なものですし、 「自由」という言葉が本質を隠すために使われる限り、語るに値しないものです。
この本はメーリングリストではありませんが、それでも敢えて言えば、 私は「GPLはフリーなライセンスではない」という主張は全く理解できません。 GPL が課している制限は、GPL が課す以上の 制限をしてはいけない、ということだけです。 この制限こそがライセンスの自由度を下げているという主張は、 奴隷制度を違法化することが自由度を下げていると言っているように聞こえます。 なぜなら、GPL は特定の人が奴隷を所有することを防ぐものだからです。
(おっと、あなたがこの手の議論に巻き込まれたのなら、 人を怒らせるような例え話をして危険な目にあわないようにしてくださいね。)
かなりの数のオープンソースソフトウェアが、BSD ライセンス (または BSD スタイルのライセンス と呼ばれることもあります) で配布されています。オリジナルのBSDライセンスは、 カリフォルニア大学バークレー校がUnixの実装としてリリースした Berkeley Software Distribution (BSD) のライセンスとして使われていました。 このライセンス (原文は http://www.xfree86.org/3.3.6/COPYRIGHT2.html#6 の 2.2.2 にあります) の考え方は MIT/X ライセンスと似ていますが、 以下の一節だけは異なっています。
このソフトウェアの機能や、このソフトウェア自体を使っていることを言及する広告媒体には、必ず以下の謝辞を記載しなければならない。「この製品にはカリフォルニア大学バークレー校と、ローレンスバークレー研究所が開発したソフトウェアが含まれています。」
この一節こそが、オリジナルのBSDライセンスを GPL と非互換にしてしまっているばかりか、 危険な先例を作ってしまっています。つまり、他の組織も似たような宣伝条項を — 「カリフォルニア大学バークレー校と、ローレンスバークレー研究所」の部分を自分の組織の名前に置き換えることで — 自分達の フリーソフトウェアに付け加えてしまいます。 ソフトウェアを再配付する人達にとっては、 記載しなければならない謝辞が増え続けることが負担になってしまいます。 幸運なことに、このライセンスを使っていた多くのプロジェクトがこの問題に気付き、 この宣伝条項を削除していました。そして1999年には、カリフォルニア大学もこの条項を削除したのです。
この結果生まれたのが、修正BSDライセンスと呼ばれるものです。 これはオリジナルのBSDライセンスから宣伝条項を削除したものです。 しかしながら、こうした歴史的な経緯が「BSDライセンス」 という言葉をちょっと曖昧にしています。「BSDライセンス」と言ったとき、 オリジナルのBSDライセンスを指すのでしょうか？ それとも修正BSDライセンスを指すのでしょうか？ この曖昧さから、私は MIT/X ライセンスの方が好みです。 MIT/X ライセンスとBSDライセンスは本質的には同じものですし、 MIT/X ライセンスには、こうした言葉の上での曖昧さがないからです。 しかし、MIT/X ライセンスより修正BSDライセンスが好ましい理由がひとつだけあります。 それは、BSDライセンスには以下の一節が含まれているからです。
書面による特別な許可なく、本ソフトウェアから派生した製品を宣伝するために <組織> の名前、または本ソフトウェアに貢献した人の名前を使用してはならない。
この条項がなければ、ソフトウェアを受け取った人が、 ライセンスを与えた人(組織) の名前を使う権利があるかどうかがはっきりしませんが、 そうした疑いをこの条項が払拭しています。よって、 商標の管理に関心がある組織にとっては、 修正BSDライセンスが MIT/X ライセンスよりも好ましいものとなります。 しかし一般的には、 自由主義的なライセンスだからといって、それが商標を自由に使ったり、 商標の価値を弱める権利を与えることにはなりません。 — 著作権に関する法律と商標に関する法律は全く異なるものだからです。
もし修正BSDライセンスを使いたいと思ったら、 雛型は http://www.opensource.org/licenses/bsd-license.php に置いてあります。
[39] このライセンスと名前の歴史はちょっと複雑です。 このライセンスのはじめのバージョンは Affero, Inc. によってリリースされ、 GPL バージョン2 (GPLv2) を基にしたものでした。これは通常 AGPL と呼ばれていました。 のちに FSF はこのライセンスの考え方を採用することを決めましたが、 それより前に GPL のバージョン3 (GPLv3) をリリースしていたのです。 よって、FSF は AGPL に基づいて自分たちのライセンスを作り、それを "GNU AGPL" と呼んだのです。現在、Affero, Inc. が作った古いライセンスは事実上推奨されていません。 もしあなたが Affero のような条件を望むなら、GNU AGPL を使うべきです。 曖昧にならないように、このライセンスを "AGPLv3" とか、"GNU AGPL"、 もしくは最大限正確を期すために "GNU AGPLv3" と呼びます。