ライセンス、著作権、特許

ライセンス、著作権、特許あなたが選ぶライセンスは、それがオープンソースである限り、プロジェクトで採用するにあたって大きな影響を与えないはずです。ユーザーは、ソフトウェアを機能や質を見て選ぶことが一般的で、ライセンスの詳細を見て選んだりはしません。それでも、プロジェクトが採用するライセンスが目的に確実に合ったものにすることと、ライセンスに関する決定を他の人と議論できるようにするために、フリーソフトウェアのライセンス問題に関する基本的なことがらはやはり理解する必要があります。しかしながら私は法律家ではないですし、この章の内容も、法的なアドバイスを正式に受けて書いているわけではないことに注意してください。そうするには、法律家を雇うか、あなた自身が法律家になる必要があるでしょう。使用する用語オープンソースライセンスについて議論するときにまず明らかになることは、同じ意味を持つ異なる単語がたくさんあるらしいということです。たとえばフリーソフトウェア、オープンソース、FOSS、 F/OSS、そして FLOSS です。ここでは、そうした用語を他の言葉と一緒に整理することにしましょう。フリーソフトウェアソースコードを自由に共有し、かつ変更を加えることができるソフトウェアのことです。この用語はリチャード・ストールマンがはじめに作り、 GNU General Public Licence (一般公衆利用許諾契約書、以下 GPL) に盛り込みました。そして Free Software Foundation (フリーソフトウェア財団、以下 FSF、) を設立してこの概念を広めたのです。「フリーソフトウェア」という用語は、ソフトウェアの範疇では「オープンソース」とほとんど同じ意味です。しかし、とりわけ FSF は前者を好みます。なぜなら、「フリーソフトウェア」の方が、自由という考え方や、技術的な流行ではなくて何より社会運動としての、自由に再配布可能なソフトウェア、という考えを強調しているからです。 FSF は、「フリー」という単語が — 「自由」ではなく、「コストがかからない」、と解釈され得るという意味で — 曖昧なものだと認めています。しかしながら色々考えてみて、フリーという単語がやはり一番だと考えていますし、他の英単語にも曖昧な部分があるとも考えています。 (本書では、「フリー」という単語を「コストがかからない」という意味ではなく、「自由」という意味で使っています。) オープンソースソフトウェアフリーソフトウェアの別名です。しかしながら、この名前の違いは重要な哲学の違いを反映しています。「オープンソース」という単語は、Open Source Initiative (オープンソース・イニシアティブ、以下 OSI。 ) が社会運動よりはむしろ開発の方法論としての意味を強調することで、フリーソフトウェアをより企業が受け入れやすくするために作りました。 OSI は「フリー」という言葉を使うことで、低品質に違いないと思われてしまう点も克服したかったのかもしれません。フリーなライセンスはオープンソースでもあり、 (2,3 の小さな例外を除き) 逆も同じことが言えますが、人々はひとつの用語を取り上げてそれに固執しがちです。一般的に、「フリーソフトウェア」を好む人たちは「フリー」が持つ意味について、哲学的、または道徳的な立場を好むのに対して、「オープンソース」を好む人たちはそれが「自由」に関する問題だとは考えませんし、「フリーソフトウェア」を好む人の考え方を広めることにも興味がありません。この二つの用語に関する分裂の歴史については、のを参照してください。 FSF は — 私の完全な主観ですが、微妙ながら極めて公平という意味で — これらの二つの用語について優れた解釈をで示しています。OSI は、自らの解釈を2ページに分けて紹介しています。: とです。 FOSS, F/OSS, FLOSS 二つあるものが三つになる。これは「フリーソフトウェア」という用語で起こっていることと全く同じです。学問の世界では、言葉の上っ面の美しさよりも正確さと包括性を求めて、 "Free / Open Source Software" を表す FOSS や F/OSS に移っているようです。勢いがある別の表現として、 "Free / Libre Open Source Software" があります。 (libreフランス語で「自由な」という意味。という単語は、多くの言葉に存在していながら、「フリー」が持つ曖昧な意味がありません。詳しくはを参照してください。) これらの用語は全て、本質的には同じ意味です。改造し、万人が配布できますが、時に — 必ずしも常にそうであるわけではないですが — 派生したものについては、オリジナルの配布条件と同条件で自由に配布することを求めることがあるソフトウェアのことなのです。 DFSG 互換の ... Debian フリーソフトウェアガイドライン (以下 DFSG、) と互換性があるライセンスのことです。 DFSG 互換かどうかは、特定のライセンスが本当の意味でのオープンソース (フリー、自由) かどうかを確認する基準として広く使われています。 Debian プロジェクトの任務は、システムの一部または全部を改変、再配布する権利があるかどうかを疑わずにインストールできる、全体がフリーなオペレーティングシステムを維持することです。 DFSG は、Debian にソフトウェアを含める際に、そのライセンスが満たさなければならない基準となります。 Debian プロジェクトは、 DFSG の基準を満たしているかを確認するやり方を考えるのに多くの時間を割いてきました。よって、彼らが考えたガイドラインは非常に堅固で、私が知る限りでは、 FSF からも OSI からも強く異議を唱えられたことはありません。特定のライセンスが DFSG 互換であることがわかれば、 (オリジナルの作者の意に反してでもコードを派生させられること、のような) オープンソースプロジェクトの力学を維持するのに必要なすべての「自由」を、そのライセンスが保証していることになります。この章で議論しているすべてのライセンスは DFSG互換です。 OSIの承認を得た ... OSI が認めたライセンスということです。これは特定のライセンスが、必要とされている自由をすべて満たしているかどうかを確かめるのに広く使われているもう一つの基準です。 OSI が定義しているオープンソースソフトウェアの定義は、 DFSG を基にしており、この定義を満たしているライセンスは、DFSG も満たしています。このことは、長い歴史の中で 2、3の例外はあるものの、その例外はニッチなライセンスや、全く関連のないものだけです。 Debian Project とは異なり、 OSI はこれまで承認してきたすべてのライセンスをで一覧にしています。よって、「OSIが承認する」ことには曖昧さがありません。なぜなら、ライセンスがその一覧にあるかどうかで、 OSIが承認したかどうかが決まるからです。 FSF も、自らが認めたライセンスの一覧をで管理しています。 FSF はフリーであるかどうかだけでなく、 GPL と互換性があるかどうかでもライセンスを分類しています。 GPL と互換性があるかどうかは重要な話題なので、後にあるで扱っています。独占的(プロプライエタリ）な、クローズドソース「フリー」や「オープンソース」とは反対の意味です。コピーひとつ毎にお金を支払うか、オープンソースの力学を妨げるのに充分制限的な条件を適用した、伝統的なロイヤリティベースのライセンスで配布されるソフトウェアのことです。無料で配布されるソフトウェアでも、ライセンスが自由な改変や再配布を認めていない場合には、独占的なソフトウェアになり得ます。「独占的なソフトウェア」や「クローズドソース」は一般的に同じ意味です。しかし、「クローズドソース」は、さらにソースコードを見ることさえできないことも意味しています。ソースコードはほとんどの独占的なソフトウェアで見ることはできませんので、これらを区別することは普通ありません。しかしながら、ソースコードを見るのを許可するライセンスで独占的なソフトウェアをリリースする人もいます。彼らはそれを、「オープンソース」や「オープンソースに近い」などと紛らわしい呼び方をするのですが、これは誤解を招く言い方です。ソースコードが手に入るかどうかの問題ではないのです。重要なのは、それを使って何ができるのか、ということなのです。よって、「独占的なソフトウェア」と「クローズドソース」の違いはほとんど無意味ですから、これらは同じ意味として扱われるのです。「商用の」という言葉が、「独占的なソフトウェア」の別名として使われることがあります。しかし、正確に言うと、これらは同じではありません。フリーソフトウェアも商用にすることができます。結局、買う人がコピーする権利を制限しない限り、フリーソフトウェアは売ることもできるのです。フリーソフトウェアは他のやり方、たとえばソフトウェアのサポートや、ソフトウェアを使ったサービスや、資格を売ったりすることで、商用にすることができるのです。フリーソフトウェアを使って巨万の富を築いた企業も存在します。よって、フリーソフトウェアは商用にできないわけではありませんし、企業が使えないわけでもありません。一方で、フリーソフトウェアは本質的に独占的なソフトウェアとは相容れないものです。それこそが、コピーする毎にお金が必要な、伝統的なライセンスモデルと異なる重要な点なのです。パブリックドメイン著作権を持っている人がいないことです。つまり、ソフトウェアのコピーを制限する人がいないということです。パブリックドメインであることは、作者がいないことと同じです。どんなソフトウェアにも作者がいますが、その作者が書いたものをパブリックドメインにすることを選んだとしても、特定の人が書いたという事実を動かすことはできません。ソフトウェアがパブリックドメインに置かれた場合、その構成要素は著作権があるソフトウェアに組み込むことができ、組み込まれた部分のコピーにも、組み込んだソフトウェアの著作権が適用されます。しかし、それによって元のソフトウェアが利用できなくなるわけではなく、パブリックドメインのままです。よって、リリースしたものをパブリックドメインに置くことは、ほとんどのフリーソフトウェアを認定している組織のガイドラインに照らして、技術的に「フリー」にする方法の一つです。しかしながら、たとえフリーソフトウェアであっても、パブリックドメインに置くよりは何らかのライセンスを採用した方がよい理由があります。ソフトウェアの著作権を持つ人だけでなく、それを受け取る人たちに対しても、制限を課せば役に立つ場合があるからです。こうした側面については、次のセクションで明らかにしていきます。コピーレフト伝統的な著作権と反対の結果を得るために、著作権に関する法律を利用しているライセンスのことです。この意味は、この章で議論している自由を認めたライセンスのこともあれば、もっと狭義では、その自由が伝播していくことを義務付けることで、自由を認めるだけでなく強制もしているライセンスのことです。 FSF は後者の定義だけを使っていますが、それ以外の場合は5分5分です。つまり、多くの人々は FSF と同じ使い方をしていますが、それ以外は — 主流となっているメディアの記事を書く人たちは — 前者の定義を使う傾向があります。この用語を使っている人たちが、区別すべき使い方があるのを知っているのかはわかりません。後者の意味での標準的な使い方の例や、厳密な定義としては、派生物のライセンスを同じライセンスにすることを義務付けている GPL があります。詳しくは、後にあるを参照してください。ライセンスの特徴多くのフリーソフトウェアライセンスが利用できますが、それらが述べている重要な点はすべて同じです。つまり、誰もがコードを改造でき、オリジナルのままでも、改造を加えた形でも再配布できること、そして著作権を持つ人、そしてソフトウェアの作者はいかなる保証もしない (無保証であること、責任を回避することは、特にソフトウェアが改変されたことを知らないで実行する人がいる可能性を考えると特に重要です) ことです。それぞれのライセンスの違いは、以下のよく起こる問題に集約できます。独占的なライセンスとの互換性フリーなライセンスの中には、それが適用されるコードを独占的なプログラムで使うことを認めるものがあります。これは独占的なプログラムのライセンス条件に影響を与えません。独占的なプログラムはそのままで、独占的でないソースコードがいくらか混入するだけです。 Apacheライセンス、Xコンソーシアムライセンス、 BSDスタイルのライセンス、そして MITスタイルのライセンスは、すべて独占的なライセンスと互換性があるライセンスの例です。他のフリーなライセンスとの互換性ほとんどのフリーなライセンスはお互いに互換性があります。つまり、あるライセンスが適用されたコードは、別のライセンスが適用されたコードと組み合わせることができます。組み合わせた結果できたものは、それぞれのライセンス条件を破ることなく再配布することができます。このことの重要な例外は、GPL (GNU General Public License) です。 GPL は、 GPL で配布されたコードを使ったいかなる派生物も、 GPL として配布しなければならず、かつ GPL が必要とすること以上の制限をつけてはならない、ことを要求しています。 GPL と互換性があるライセンスもあれば、ないものもあります。詳しくは、後の方にあるで議論しています。クレジットの強制フリーなライセンスの中には、それが適用されたソースコードを使ういかなるコードにも、注意書きを記すことを強制するものがあります。注意書きの位置や内容も決まっているのが普通です。内容はコードの作者や著作権を持つ人へのクレジットです。こうしたライセンスでも、独占的なライセンスと互換性があるものがあります。なぜなら、派生物がフリーであることを要求するのではなく、フリーなコードに対してクレジットを与えることだけを要求しているからです。商標の保護クレジットを強制するやり方の変形として、商標で保護されたライセンスは、オリジナルのソフトウェア (またはその著作権を持つ人や組織など) の名前を、事前の書面での許可なく派生物で使ってはいけないと定めています。クレジットを強制するやり方は、ある名前をどこかで使うことを求めますし、商標で保護するやり方は、使わないことを求めますが、どちらも同じ要求を表しています。つまり、オリジナルのソースコードへの敬意を払い、それを伝播させたいけれども、どこからもそうした敬意を傷つけられたくないのです。特許からの防衛 GPL バージョン3 や Apache Software Licence バージョン2 には、(著作権に関する法律で)ライセンスが与えている権利を特許を使って奪うことを防ぐための文言が含まれています。これらのライセンスは、成果物とそれに付随した特許ライセンスを与えることを貢献する人に要求します。この特許ライセンスには、彼らの貢献によって(または、貢献がソフトウェアに取り込まれることで)侵害されるあらゆるライセンス可能な特許が含まれます。その上で、GPL バージョン3 や Apache Software License バージョン2 はさらにその一歩先を行っています。つまり、これらのライセンスによって配布されているソフトウェアのユーザーが、そのソフトウェアに含まれている特許を侵害したと主張して第三者に訴訟を起こした場合、そのユーザーはソフトウェアのライセンスによって与えられていた特許の全てを自動的に失います。さらに GPL バージョン3 の場合は、ライセンスに基いてソフトウェアを配布する権利もなくなってしまいます。「ソースコードの完全性」を保護するライセンス (たとえば、プログラミング言語 Perl で実装されたソフトウェアで最も人気がある Artistic License や、Donald Knuth の TeX License) によっては、オリジナルのコードと改変した部分を区別できるやり方で、改変と再配布を行うように要求するものがあります。こうしたライセンスは、本質的に他のフリーなライセンスと同じ自由を認めていますが、オリジナルなコードの完全性を容易に確認できるようにするために、ある制限を課しています。これらのライセンスは特定のプログラム以外では受け入れられていません。よってこの章でも議論しません。ただ、完全を期すためにここで触れています。これらの条件は、相互に排他的なものではありませんし、ライセンスによっては複数の条件を含むものがあります。共通しているのは、ソフトウェアを受け取る人が、それを使ったり再配布するのを認めるのと引き換えに、ライセンスが義務を課すというものです。たとえば、自分たちの名前とコードへの敬意を、コードで伝播させたいと願って、クレジットや商標について条件を課すプロジェクトが存在します。条件から出てくる負担によっては、面倒だと考えて制限が緩いライセンスを採用したパッケージを選ぶユーザーが出てくるかもしれません。 GPL とライセンスの互換性ライセンスをくっきりと分ける境界線は、独占的なライセンスと互換性があるか、ないかです。つまり、GPL (GNU General Public License) とそれ以外全てです。 GPL の第一の目的はフリーソフトウェアを広めることなので、 GPL を書いた人は、意図的に独占的なコードと GPL のコードを混ぜることができないようにしました。特に GPL が要求していること (全文はを参照してください) は以下の二つです。すべての派生物 — つまり、GPL が適用されたコードを含んだあらゆるプログラム — は、それ自体も GPL で配布しなければならない。オリジナルでも、派生物であっても、それを再配布する場合には制限を追加してはいけない。 (原文の該当箇所を以下に引用します: 「あなたは、このライセンスが与えた、または認めた権利を行使することに関して、これ以上他のいかなる制限も課してはならない。」) これらの条件によって、GPL は自由を伝播させることに成功しています。いったんプログラムが GPL で保護されると、再配布の条件が伝染するのです — つまり、取り込んだコード以外のあらゆる部分にその条件を適用させ、かつ GPL を採用したコードをクローズドソースなプログラムで使うのを不可能にしているのです。しかしながら、これらの条項は他のフリーなライセンスと GPL を非互換にするものでもあります。通常は、他のライセンスが追加の条件を課したときに非互換が起きます — たとえば、何らかの方法でオリジナルの作者へのクレジットを要求する場合です — これは、GPL の「あなたは、これ以上他のいかなる制限も課してはならない ...」という文言に反しています。こうした二次的な結果は、望ましいものか、少なくとも悪いことではない、というのが FSF の見解です。 GPL はあなたのソフトウェアをフリーな状態に保つだけでなく、他のソフトウェアにも自由を強制する媒体にもするのです。この手法がフリーソフトウェアを広める優れた手段なのかどうかは、インターネット上でずっと続いている宗教論争 ( のを参照してください) のひとつであり、ここでは深く触れません。重要なのは、 GPL と互換性があるかどうかがライセンスを選ぶ際に重大な問題になるということです。GPL は非常に重要なオープンソースライセンスです。ある時点での Freecode 上では、GPL が 68% を占めており、次に高いのは 6% ですかつて、ライセンスに関する統計情報が Freecode.com にありました。まだ Freshmeat.net と呼ばれていた頃のものです。しかし 2008 年に彼らはプロジェクトを自由にタグ付けできるように切り替えました。その結果、信頼できるライセンス統計を取得するのが難しくなりました。に、統計情報を取得する方法についての議論があります。。 GPL で保護されたコードと自分のコードを混ぜた上でフリーにしたいのなら — GPL なコードがたくさんあるのだから — GPLと互換性があるライセンスを選ぶべきです。 GPL と互換性があるオープンソースライセンスのほとんどは、独占的なライセンスとも互換性があります。よって、そうしたライセンスを採用したコードは、 GPL なコードでも使うことができますし、独占的なプログラムでも使うことができるのです。もちろん、そうやってコードを混ぜた結果生じたものは相互に互換性がありません。なぜなら、一方は GPL となり、一方はクローズドソースなライセンスが適用されるからです。問題が及ぶのは派生物に対してのみであり、はじめに配布したオリジナルなコードは影響を受けません。ありがたいことに、FSF は GPL と互換性があるライセンスと、互換性がないライセンスの一覧をで示してくれています。この章で議論しているすべてのライセンスがこのリストにありますが、GPL と互換性があるものもあれば、ないものもあります。ライセンスを選ぶプロジェクトに適用するライセンスを選ぶときは、できる限り新しいものを作らずに既にあるものを使うようにしましょう。有り物を使う理由はふたつあります。ライセンスが既に知られているからです。あなたが人気のあるライセンスのうちのひとつを使えば、コードを使う人が法律用語をわざわざ読む必要はないと思うでしょう。ずっと以前に読んだことがあるからです。ライセンスの質が保たれているからです。自分の思い通りになる弁護士のチームがいなければ、法的に隙がないライセンスを生み出すことはできないでしょう。この章で触れているライセンスには、多くの人々の経験や思考が詰まっています。つまり、あなたのプロジェクトに本当に変わった要求がない限り、さらに行動する必要はないということです。プロジェクトにライセンスを適用するには、のを参照してください。 MIT/X Window System ライセンス自分のコードをできる限り多くの開発者と派生物で使ってもらい、かつ独占的なコードで使われるのを気にしないのならば、 MIT/X Window System ライセンス(以下 MIT/X ライセンス) (マサチューセッツ工科大学がオリジナルの X Window System のコードをこのライセンスでリリースしたので、そう呼ばれています) を選びましょう。このライセンスが言っているのは基本的に「あなたはこのコードを自由に、無料で使うことができますよ」ということです。このライセンスは GNU GPL と互換性があり、短く、簡単で、理解しやすいものです。 Copyright (c) <year> <copyright holders> 以下に定める条件に従い、本ソフトウェアおよび関連文書のファイル（以下「ソフトウェア」）の複製を取得するすべての人に対し、ソフトウェアを無制限に扱うことを無償で許可します。これには、ソフトウェアの複製を使用、複写、変更、結合、掲載、頒布、サブライセンス、および/または販売する権利、およびソフトウェアを提供する相手に同じことを許可する権利も無制限に含まれます。上記の著作権表示および本許諾表示を、ソフトウェアのすべての複製または重要な部分に記載するものとします。ソフトウェアは「現状のまま」で、明示であるか暗黙であるかを問わず、何らの保証もなく提供されます。ここでいう保証とは、商品性、特定の目的への適合性、および権利非侵害についての保証も含みますが、それに限定されるものではありません。作者または著作権者は、契約行為、不法行為、またはそれ以外であろうと、ソフトウェアに起因または関連し、あるいはソフトウェアの使用またはその他の扱いによって生じる一切の請求、損害、その他の義務について何らの責任も負わないものとします。 (原文はにあります。日本語訳についてはから引用させて頂きました。) GPL あなたのプロジェクトが、自分達が作ったものが独占的なプログラムで使われるのを望まなかったり、少なくともそうしたことを気にしないのであれば、GPL (GNU General Public License) () を選ぶとよいでしょう。 GPL はおそらく、現在世界でもっとも広く使われているフリーソフトウェアライセンスです。認知度が高いことが、それ自体 GPL の主な利点のひとつです。他のプログラムの一部として使われるライブラリを書いている場合は、あなたのプロジェクトの目標に照らして、GPL の制限を注意深く考える必要があります。場合によっては — たとえば、自分達のライブラリと同じことをしている独占的なプログラムのシェアを奪おうとしている場合 — あなたがたとえ望まなくても、独占的なプログラムで使えるようにするやり方で、プログラムをライセンスするのが戦略として優れているかもしれません。 FSF は、こうした場合のために GPL とは別の選択肢を用意しました。それが GNU Library GPLであり、後にGNU Lesser GPL と改称されたものです。 (ほとんどの人はその頭文字をとって、LGPL という用語を使います) LGPL は GPL よりも制限が緩く、フリーでないコードと容易に混ぜることができます。しかしながら、LGPL はちょっと複雑で理解するのに少し時間がかかります。よって、GPL を使うつもりがないなら、MIT/X スタイルのライセンスを使うことを私は勧めます。 GNU Affero GPL: サーバサイドにあるコード向けの GNU GPL 2007年、FSF は GPL の派生ライセンスとして、GNU Affero GPL () と呼ばれるライセンスをリリースしましたこのライセンスと名前の歴史はちょっと複雑です。このライセンスのはじめのバージョンは Affero, Inc. によってリリースされ、 GPL バージョン2 (GPLv2) を基にしたものでした。これは通常 AGPL と呼ばれていました。のちに FSF はこのライセンスの考え方を採用することを決めましたが、それより前に GPL のバージョン3 (GPLv3) をリリースしていたのです。よって、FSF は AGPL に基づいて自分たちのライセンスを作り、それを "GNU AGPL" と呼んだのです。現在、Affero, Inc. が作った古いライセンスは事実上推奨されていません。もしあなたが Affero のような条件を望むなら、GNU AGPL を使うべきです。曖昧にならないように、このライセンスを "AGPLv3" とか、"GNU AGPL"、もしくは最大限正確を期すために "GNU AGPLv3" と呼びます。。 GNU AGPLv3 が示したやり方は、通常の GPL を採用した上で「ネットワーク越しにリモートとやりとりする際の」条件を加えたことです。この条件は、次のようなものです。「... このプログラムを改変した場合、あなたが改変したバージョンはすべてのユーザーに目立つやり方で、コンピューターネットワーク越しにアクセスできるようにしておかなければならない ... 無償で、ソフトウェアのコピーを容易にする通常の手段を使って ... あなたが改変したバージョンに相当するソースコードをユーザーが受け取る機会を与えなければならない」このように GPL を拡張したことで、アプリケーションサービスを提供する人たちの世界に GPL の強制力が及びます。 FSF は通常ネットワーク越しに実行されるあらゆるソフトウェアに対して GNU AGPLv3 を使うことを推奨しています。 AGPLv3 は、GPLv2 とは直接の互換性がないことに注意してください (ただし、GPLv3 とはもちろん互換性があります)。しかし、 GPLv2 でライセンスされた殆どのソフトウェアには「GPLv2 以降のバージョンで」という条件が入っています。よって、この場合に GPLv2 のコードと AGPLv3 のコードを混ぜたければ、単純に GPLv3 に移行すればよいのです。しかし、GPLv2 だけが厳格に適用されるプログラム (つまり、「GPLv2 以降のバージョンで」という文言が入ってない場合) は、 AGPLv3 のプログラムと混ぜることができません。 AGPLv3 の歴史はちょっと複雑ですが、ライセンスそのものは単純です。なぜなら、これは GPLv3 の条項に、ネットワーク越しでやりとりする際の追加条件を加えただけのものだからです。 AGPLv3 については、Wikipedia の記事が秀逸です。 GPL はフリーなライセンスなのか? GPL を選んだ結果、プロジェクトがコードに対してできることを制限された場合 — すなわち他のライセンスでコードを配布できなかった場合 — GPL が本当の意味で「フリー(自由)」なのかどうかに関する論争がプロジェクトで起こるかもしれません — これが起こる可能性は小さいですが、ゼロとはいえません。人によっては、他のライセンスでコードを配布できないという制限が、 MIT/X ライセンスのような制限の緩いライセンスよりも GPL が「自由度が低い」ように映るのです。もちろん、こうした主張が行き着くところは、「自由度は低いより高い方がいいに決まっている」というものですが (自由であることに賛成しない人がいるでしょうか?)、これに従うと、制限の緩いライセンスが GPL よりも優れているということになります。この手の議論は、宗教論争 ( のを参照してください) になるお題のひとつです。少なくも公開されているフォーラムでは、これに参加しないようにしましょう。 GPL が他のライセンスより自由度が高いとか、低いとか、同じだとか、そういうことを証明しようとしてはいけません。そうではなくて、あなたのプロジェクトがなぜ GPL を選んだのかを強調するようにしましょう。ライセンスの認知度が高いことが理由なら、そう言えばいいのです。派生物に同じ条件を強制するのが理由なら、それも伝えましょう。しかし、GPL のやり方がコードの「自由度を高くするのか、低くするのかどうか」という議論には絶対にしないでください。「自由とは何か」というお題は複雑なものですし、「自由」という言葉が本質を隠すために使われる限り、語るに値しないものです。この本はメーリングリストではありませんが、それでも敢えて言えば、私は「GPLはフリーなライセンスではない」という主張は全く理解できません。 GPL が課している制限は、GPL が課す以上の制限をしてはいけない、ということだけです。この制限こそがライセンスの自由度を下げているという主張は、奴隷制度を違法化することが自由度を下げていると言っているように聞こえます。なぜなら、GPL は特定の人が奴隷を所有することを防ぐものだからです。 (おっと、あなたがこの手の議論に巻き込まれたのなら、人を怒らせるような例え話をして危険な目にあわないようにしてくださいね。) BSDライセンスはどうなの? かなりの数のオープンソースソフトウェアが、BSD ライセンス (または BSD スタイルのライセンスと呼ばれることもあります) で配布されています。オリジナルのBSDライセンスは、カリフォルニア大学バークレー校がUnixの実装としてリリースした Berkeley Software Distribution (BSD) のライセンスとして使われていました。このライセンス (原文はの 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ライセンスを使いたいと思ったら、雛型はに置いてあります。著作権の保有と譲渡多くの人の貢献によって成り立っている、フリーなコードやドキュメントの著作権をうまく扱う方法は3つあります。ひとつめは、(私はお勧めしませんが) 著作権にまつわる問題をすべて無視してしまうことです。ふたつめは、contributor license agreement (貢献者ライセンス同意書、以下 CLA) をプロジェクトで働く人達から集め、個人が行った貢献をプロジェクトが使う権利を明示的に与えてもらうことです。ほとんどのプロジェクトは通常これで十分です。また、裁判の管轄区域によっては、 CLA は電子メールで送ることができるのも優れています。三つめは、プロジェクト (通常は非営利な法的主体) が全ての著作権を保持するために、貢献する人から著作権を実際に譲ってもらうことです。これがもっとも法的には隙のない方法ですが、貢献する人にとってはもっとも厄介です。よって、この方法を求めてくるプロジェクトはわずかです。著作権を一ヶ所に集めたとしても、コードここから私は、「コード」という言葉を「プログラムとドキュメント両方」という意味で使います。はフリーのままであることに注意してください。なぜなら、オープンソースライセンスは、著作権を持つ人にコードのコピーを過去に遡って独占的なコードにする権利を認めていないからです。よって、たとえ法的な主体としてのプロジェクトが突然方針を転換し、すべてのコードを制限が強いライセンスで配布し始めたとしても、そんなことはコミュニティーにとって決して問題になりません。他の開発者は単に最新のフリーなコードをコピーして新しいプロジェクトを始め、何事もなかったかのように開発は続くでしょう。そうできることを知っているからこそ、貢献する人達のほとんどは CLA へのサインや、著作権の譲渡を求められたときに協力するのです。何も対処しないほとんどのプロジェクトは、貢献する人から CLA を集めたり、著作権を譲ってもらったりはしません。そのかわり、貢献する人のプロジェクトに取り入れてもらいたいという意志が、適度に明確である場合にはいつでもコードを受け入れています。通常の状態ではこれで構いませんが、誰かが自分こそが問題となるコードの真の持ち主であり、自分たちはそのコードをオープンソースライセンスの下で配布することを認めないと主張して、著作権法違反で裁判を起こすかもしれません。たとえば、SCO グループはこれと似たようなことを Linuxカーネル開発プロジェクトに対して行いました。詳しくは、を参照してください。こんなことが起きてしまうと、プロジェクトは貢献した人から正式にコードを使う権利を得ていることを証明する文書がありません。こうなると、法的な防御が難しくなるかもしれません。貢献者ライセンス同意書(CLA) CLA はおそらく、法的な安全性と利便性のトレードオフを解決する最良のものでしょう。 CLA は開発者が内容を記入し、プロジェクトに送付する電子的な書式が典型的なものです。多くの裁判の管轄地域では、電子メールで送付すれば十分です。安全な電子署名が必要な場合もあります。どの方法があなたのプロジェクトに合っているかを知るには、弁護士に相談してください。多くのプロジェクトではふたつのちょっと異なる CLA を使います。ひとつは個人用、そしてもうひとつは企業用のものです。しかしどちらであっても、中心となる文言は同じです: 貢献する人(組織) はプロジェクトに "... あなたの貢献を複製したり、派生物を準備したり、公に表示したり、公に実行したり、サブライセンスするために、「半永久的で、全世界規模で、非独占的で、無償で、ロイヤリティーがなく、取り消すことができないライセンス」" を与える。というものです。繰り返しますが、どんな CLA を受け入れる場合でも弁護士に相談すべきです。しかし、あなたがこれらの文言に慣れていれば、おそらく問題はないでしょう。 CLA へのサインを、貢献する人に頼むときは、実際に著作権を譲渡するよう求めているわけではないことを必ず強調するようにしましょう。実際、多くの CLA はサインする人にこのことを念押しする文言で始まります。

これはライセンスに同意するだけの文書です。つまり、著作権を譲渡したり、あなたの貢献を他の目的に使うためにあなたの権利を変更したりしません。

以下にいくつか例を示します: 個人向けの CLA: 企業向けの CLA: 著作権の譲渡著作権の譲渡とは、貢献する人が、自分が行った貢献の著作権をプロジェクトに譲り渡すことです。これは書面を郵送するか、ファックスすることで行うのが望ましいです。プロジェクトによっては、著作権を完全に譲渡するよう求めるところがあります。これは、すべてのコードの著作権をひとつの法的主体が持っていた方が、オープンソースライセンスの条件に違反した人を訴える場合に便利だからです。著作権を譲ってもらうときにどの程度の厳密さを求めるのかは、組織によって異なります。公開されているメーリングリストで「私はここで、このコードの著作権をプロジェクトに譲り、このコード以外のものと同じライセンスを適用させます。」と言うことと同じ効果がある、非公式な声明を集めるだけのところもあります。私が話をした弁護士のうち少なくともひとりは、これで十分だと述べています。おそらくこれは、著作権の譲渡が通常期待される状況下で行われていること、そしてプロジェクトが開発者の本当の意志を確定させようとする努力が本物であることを表しているからだと思われます。一方で、フリーソフトウェア財団 (FSF)は、全く逆の立場をとっています。彼らは著作権を譲渡する正式な声明文が書かれた一枚の紙切れに直接サインし、郵送 (あるいは FAX) することを求めてきます。たった一度貢献しただけでもFSFはこれを要求することがあります。また、現在、そして将来するであろう貢献に対して要求することもあります。対象となる開発者が雇われていた場合、雇用主もサインを求められます。 FSF が潔癖なのは理解できます。仮に誰かが FSF のソフトウェアを独占的なプログラムに組み込んで GPL の条件に違反した場合、FSF は裁判で争う必要が出てきます。そうした事態になったときに、 FSFは自らが持つ著作権を全く隙がない状態にしたいからです。 FSF は多くの人気があるソフトウェアの著作権を持っているので、彼らはこうした可能性が実際にあり得ることだと考えています。あなたの組織が同じように細心の注意を払うべきかは、弁護士に相談してから決めるようにしましょう。一般的には、著作権を完全に譲ってもらう理由がなければ、 CLA を使うようにします。なぜなら、皆が扱いやすいからです。デュアルライセンスの仕組みプロジェクトによっては、お金を稼ぐためにデュアルライセンスの仕組みを使うところがあります。これは独占的な派生物については、コードを使う権利を得るために著作権者にお金を払ってもらう一方で、オープンソースプロジェクトで使う目的ならコードをフリーのままにしておく、というものです。これは当然、単独のアプリケーションよりはライブラリのコードと相性がよい仕組みです。正確な条件は場合によって異なります。オープンソースプロジェクトで使う場合のフリーなライセンスは GNU GPL がよく使われます。なぜなら、 GPL は著作権者の許可なく独占的な製品にコードを取り込むことを既に禁止しているからですが、これと同じ効果を持つ独自のライセンスが使われることもあります。前者の例は MySQLのライセンスであり、に説明があります。後者の例は Sleepycat Software が採用しているライセンス戦略で、に説明があります。こんな疑問があるかもしれません「GNU GPL が、制限が緩い方法でコードを利用させるように要求していたとしたら、著作権者はどうやってお金と引換えにライセンスを与えればいいの？」これに対しては「GPL の条件は、著作権者が他人に課すものです。よって、著作権者には GPL の条件を課さずに独占的な条件のみを課す自由もあるのです。」というのが答えになります。これについては、著作権者がソフトウェアのコピーを無限に在庫として持っていると考えるとよいでしょう。彼らはソフトウェアのコピーを一つ取り出して世に送り出すたびに、どのライセンスを付けるか、つまり GPL なのか、独占的なライセンスか、それ以外かを決めることができるのです。ライセンスを選んで決める権利は、 GPL や他のオープンソースライセンスが課しているものではありません。単に著作権に関する法律が与えたものなのです。デュアルライセンスの魅力は、フリーソフトウェアプロジェクトに安定した収入の道を開くことです。不幸なことに、これがオープンソースプロジェクトの通常の力学を妨げてしまう可能性があります。問題なのは、コードを提供するボランティアたちが、フリーなバージョンのものと、独占的なものの、全く別なふたつのバージョンに貢献するようになることです。貢献するボランティアたちは、フリーなバージョンには喜んでコードを提供するでしょう。なぜなら、提供したコードをフリーにするのがオープンソースプロジェクトでは普通だからです。しかし、他の人が半ば独占的なやり方で利益を得るのに加担するのはおかしいと感じるかもしれません。このジレンマは、デュアルライセンスを採用した場合に、独占的なやり方で得た利益からボランティアがロイヤリティを請求することを防ぐために、著作権者が彼らのコードの著作権を自らに譲渡する契約にサインするよう求めてきたときにさらに大きくなります。こういう契約書にサインさせるプロセスは、ボランティア達に、自分が誰かを儲けさせるために動いているという事実をいやがおうでも突きつけることになります。ボランティア全員がこの問題で悩むとは限りません。結局、提供したコードはオープンソースなバージョンにも取り込まれるわけで、それこそが彼らの関心事かもしれないからです。それにも関わらずデュアルライセンスは、著作権者がプロジェクトの他のメンバーが持っていない特別な権利を、自らに与えるものです。それゆえに、ボランティアの中にはある時点で著作権者と対立してしまう人が必ずいます。デュアルライセンスを採用したソフトウェアを基盤にしている企業では、ボランティアの開発コミュニティーと本当の意味で平等な関係を築いているわけではないようです。彼らは小規模なバグ修正やコードを整理する修正プログラムは外部に依存するものの、難しい仕事はほとんど内部でこなしてしまうのです。たとえば、MySQL のマーケティング部門副社長の Zack Urlocker は、活発なボランティアは結局企業が雇ってしまうのが一般的だと述べています。それゆえに、MySQL そのものは GPL でライセンスされたオープンソースソフトウェアですが、開発そのものは多かれ少なかれ企業がコントロールしています。 (可能性は極めて小さいものの) 誰かが企業のソフトウェアの扱いに不満を持ってしまうと、プロジェクトが分裂してしまう可能性も孕んでいます。こうした懸念がどの程度企業の方針に影響しているのかはわかりませんが、いずれにせよ、MySQLという企業は、オープンソースの世界に留まるか、そうでないかは問題視していないようです。特許ソフトウェア特許は、フリーソフトウェアの世界で現在注目されている問題です。なぜなら、フリーソフトウェアのコミュニティーが防ぐことができない、現実的な唯一の脅威となっているからです。著作権と商標の問題はいつでも回避することができます。仮にあなたのコードが他の人のコードと似ていて、誰かの著作権を侵害していたとしても、あなたはその部分を書き直せばよいのです。また、誰かがあなたのプロジェクトの名前に対して商標権を持っていたとしても、最悪プロジェクトの名前を変えれば済みます。プロジェクト名の変更は一時的には不便かもしれませんが、長い目で見れば問題にならないでしょう。なぜなら、コードそれ自体はいつも通り動くからです。しかし、特許はあるアイディアを実装することに対して一律に適用されるものです。誰がコードを書くかは関係ありませんし、どのプログラミング言語を使うかさえ関係ないのです。誰かが特許を侵害していると主張してフリーソフトウェアプロジェクトを訴えた途端、プロジェクトは特定の機能の実装をやめるか、カネと時間がかかる裁判をしなければなりません。このような裁判を起こすのは、十分な資力がある企業なのが普通です — つまり、はじめから特許を買収する資金があり、そうする傾向がある組織です — ほとんどのフリーソフトウェアプロジェクトは特許を買い取る余裕はありませんし、対象となる特許が法廷で拘束力がないと強く思っていたとしても、すぐに降伏しなければならないのです。こういう状況をはじめから防ぐには、フリーソフトウェアプロジェクトがコードを用心深く書いて、たとえ最良かつ唯一の解決策であったとしても、特許になっているアルゴリズムをあらかじめ使わないようにすることですサン・マイクロシステムズと IBM は、この問題に対して少なくとも別の方向性を打ち出しています。彼らは大量のソフトウェア特許 — それぞれ 1600 と 500 個 — をオープンソースコミュニティーが使えるようにフリーにしました。私は法律家ではないので、これらの特許が付与されたことがどれくらい有用なのかを評価できません。しかしたとえこれらがすべて重要な特許であり、特許を付与する条件をオープンソースプロジェクトが使うために本当にフリーなものにしたとしても、それは氷山の一角に過ぎないでしょう。。調査や事例が示す通り、これは大多数のオープンソースプログラマーだけでなく、すべてのプログラマーの多くが、ソフトウェア特許を全面的に廃止すべきだと考えています調査の一例として、以下を参照してください。。オープンソースプログラマーは、特に強くそう感じており、ソフトウェア特許を集めたり、強制することに強く関係しすぎているプロジェクトで働くのを拒否するかもしれません。あなたの組織がソフトウェア特許を集めているのなら、オープンソースプロジェクトに特許を適用しないこと、そして別の組織が特許違反の裁判を起こした場合の、防御の手段としてのみ特許を使っていることを取り消せないやり方で明確にしておきましょう。これが唯一の正しい手段ではありません。オープンソースプロジェクト同士が連携することもよいことです。たとえば RedHat は、オープンソースプロジェクトは特許に違反しないことを約束しています。を参照してください。不幸なことですが、法的な防御を目的として特許を集めるのは合理的な行動です。現在の特許の仕組みはその本質上、少なくともアメリカでは軍拡競争です。つまり、競争相手がたくさんの特許を取得した場合、最良の防御方法は、特許違反で訴えられたときに逆に訴え返せるように、多くの特許を取得することです — こうしておけば、お互いがお金を払わないで済むよう、双方が机についてクロスライセンスの取引をするのが普通です。もちろん知的財産権専門の法律家には払わないといけませんが。しかし、ソフトウェア特許がフリーソフトウェアに及ぼす害は、コードの開発に及ぼすものよりも陰湿なものです。ソフトウェア特許はファームウェアの設計者達に秘密主義の雰囲気を助長しています。彼らは自分たちが設計したインターフェイスの詳細を公にすると、特許違反で訴えるためにあら探しをしている競争相手を技術的に助けてしまうのではないかと心配しているのです。これは単なる机上の空論ではありません。たとえばビデオカード業界で明らかに起きてきたことなのです。多くのビデオカードメーカーは、高速に動くオープンソースなデバイスドライバを作るのに必要なプログラミング仕様を公にしてきませんでした。よって、そうしたカードの機能を完全にサポートするフリーなオペレーティングシステムを作るのが不可能になっているのです。なぜメーカーはそんなことをするのでしょうか？ソフトウェアをサポートすることに反対することは理にかなっていません。なぜなら、多くのオペレーティングシステムで動くことが、ビデオカードの売り上げにつながるからです。しかし、あるときは故意に、あるときは偶然、こうしたメーカーすべてがデザインルームの裏で互いに特許を侵害していることが明らかになってきています。よって、メーカーは敢えて完全なインターフェイス仕様を公開しないのです。公開することで、特許を侵害していることが競争相手にわかりやすくなってしまうからです。 (もちろん、こういった性質のことは一次情報源から許可を得て書けることではありません。私はこのことを個人的なやりとりで知りました。) フリーソフトウェアライセンスの中には、ソフトウェア特許と戦ったり、もしくは拒絶するための特別な文言を入れているものがあります。たとえば、GNU GPL は次のような文言を含めています。 7. 特許侵害あるいはその他の理由(特許関係に限らない)から、裁判所の判決あるいは申し立ての結果としてあなたに(裁判所命令や契約などにより)このライセンスの条件と矛盾する制約が課された場合でも、あなたがこの契約書の条件を免除されるわけではない。もしこの契約書の下であなたに課せられた責任と他の関連する責任を同時に満たすような形で頒布できないならば、結果としてあなたは『プログラム』を頒布することが全くできないということである。例えば特許ライセンスが、あなたから直接間接を問わずコピーを受け取った人が誰でも『プログラム』を使用料無料で再頒布することを認めていない場合、あなたがその制約とこの契約書を両方とも満たすには『プログラム』の頒布を完全に中止するしかないだろう。 [...] 特許やその他の財産権を侵害したり、そのような権利の主張の効力に異議を唱えたりするようあなたを誘惑することがこの節の目的ではない。この節には、人々によってライセンス慣行として実現されてきた、フリーソフトウェア頒布のシステムの完全性を護るという目的しかない。多くの人々が、フリーソフトウェアの頒布システムが首尾一貫して適用されているという信頼に基づき、このシステムを通じて頒布される多様なソフトウェアに寛大な貢献をしてきたのは事実であるが、人がどのようなシステムを通じてソフトウェアを頒布したいと思うかはあくまでも作者/寄与者次第であり、あなたが選択を押しつけることはできない。 GNU General Public License バージョン 2 のもの。より引用。 Apache License バージョン 2.0 () も特許に反対する条件を含めています。まず第一に、このライセンスでコードを配布する人は、自分が保有している特許で、配布するコードに適用できるものについては、ロイヤリティーがかからない特許ライセンスを与えなければなりません。二つめに、配布したコードを根拠に特許侵害の訴えを起こした時点でその特許ライセンスを自動的に終了させることで、そうした人を巧みに排除しています。 3. 特許ライセンスの付与本ライセンスの条項に従って、各コントリビューターはあなたに対し、成果物を作成したり、使用したり、販売したり、販売用に提供したり、インポートしたり、その他の方法で移転したりする、無期限で世界規模で非独占的で使用料無料で取り消し不能な（この項で明記したものは除く）特許ライセンスを付与します。ただし、このようなライセンスは、コントリビューターによってライセンス可能な特許申請のうち、当該コントリビューターのコントリビューションを単独または該当する成果物と組み合わせて用いることで必然的に侵害されるものにのみ適用されます。あなたが誰かに対し、交差請求や反訴を含めて、成果物あるいは成果物に組み込まれたコントリビューションが直接または間接的な特許侵害に当たるとして特許訴訟を起こした場合、本ライセンスに基づいてあなたに付与された特許ライセンスは、そうした訴訟が正式に起こされた時点で終了するものとします。オープンソースグループ・ジャパン wiki より引用。このように、フリーソフトウェアライセンスに特許から防御するための仕掛けをしておくのは、法的にも政治的にも役に立つものです。しかし最終的には、フリーソフトウェアに対する特許違反裁判の脅威がもたらす、萎縮的効果を払拭するには不十分です。それができる唯一の手段は、国際的な特許法の本質や解釈を変更することです。この問題について、そしてこの問題と人々がどう戦ってきたのかをさらに知るには、を訪れるとよいでしょう。 Wikipedia の記事 () にも、ソフトウェア特許に関する有益な情報が多くあります。私自身も、ソフトウェア特許に反対する議論をまとめたエントリをブログに載せています。さらなる情報源この章は、フリーソフトウェアに関するライセンス問題をさわりだけ紹介したに過ぎません。この章の説明が、オープンソースプロジェクトをはじめるための十分な情報源になることを願っていますが、真面目にライセンス問題を調べようとすると、すぐに紙面が尽きてしまうでしょう。以下には、オープンソースライセンスに関するさらなる情報源を一覧で示します。 Understanding Open Source and Free Software Licensing Andrew M. St. Laurent著。出版: O'Reilly Media、2004年8月初版。ISBN: 0-596-00581-4. この本は、オープンソースライセンスに関する複雑な問題全般を余すところなく記した本です。詳細はを参照してください。 Make Your Open Source Software GPL-Compatible. Or Else. David A. Wheeler作。 . これは、たとえあなたがGPLを採用しない場合でも、なぜGPLと互換性があるライセンスを使うことが重要なのかについて、詳細にうまく書かれた記事です。この記事は、他のライセンスに関する疑問についても触れており、密度の濃い優れたリンク集も提供しています。クリエイティブコモンズは、これまでの伝統的な著作権が推し進めてきたものよりも、多様、かつ柔軟で、リベラルな著作権を広めている組織です。彼らはソフトウェア向けのライセンスだけでなく、文章、芸術、音楽向けのライセンスも提供しています。これらのライセンスは、使いやすいライセンス選択システムによって全てが使えるようになっています。これらのライセンスの中には、コピーレフトのものもありますし、コピーレフトではありませんが、フリーなものもあります。また、伝統的な著作権の仕組みを持つライセンスでありながら、その制限をいくらか緩めただけのものもあります。クリエイティブコモンズのウェブサイトは、ライセンスがどんなものなのかを極めて明快に説明しています。フリーソフトウェア運動が持つ、哲学的で幅広い意味合いを示しているサイトを私がひとつあげるとすれば、このサイトを選ぶでしょう。