Loading AI tools
自由ソフトウェアライセンス（じゆうソフトウェアライセンス）とは、フリーソフトウェア財団（FSF）が提唱する自由ソフトウェアのソフトウェアライセンスである。
フリーソフトウェア財団（FSF）は、自由ソフトウェアの定義を掲げ、自由ソフトウェアライセンスと名乗ることを承認したソフトウェアライセンスの一覧を保守している[1]。この一覧では、自由ソフトウェアライセンスを、GNU General Public Licenseと互換性があるものとないものに分類している。またこの一覧では、FSFが様々な理由で自由でないとみなしているライセンスも掲載している。
1980年代中ごろ、GNUプロジェクトが個々のソフトウェアパッケージについて自由ソフトウェアライセンスを生み出した。それらが1989年、GNU General Public License (GPL) のバージョン1に全て置換された。1991年のGPLバージョン2は、最も広く採用されているフリーソフトウェアライセンスとなっていった。
1990年代中ごろ以降、企業や新プロジェクトが独自のライセンスを作る風潮が始まった。このようなライセンスの氾濫という傾向は、ライセンスの互換性や複雑性という問題を生じさせることとなった[2]。
1990年代、自由ソフトウェアライセンスはそれまで存在しなかった問題であるソフトウェア特許に基づいた訴訟から自由ソフトウェアを守るため、特許報復条項などの条項を含めるようになってきた。この新しい脅威に対応するためもあり、GNU GPL も2006年にバージョン3を起草することになった[3]。
2000年代にはTiVo化という新たな脅威が生じ、現行の自由ソフトウェアライセンスの一部はその脅威から利用者を守れないという状況になっている[4]。
GNU GPL バージョン2は、まずドイツ、次いでアメリカ合衆国で法廷で合法性が問題にされたことがある。どちらの場合もGNU GPLは合法なライセンスで遵守すべきであるとの判決が下っている。ドイツの事例は gpl-violations.org、ifrOSS (Institut für Rechtsfragen der Freien und Open Source Software) によるもので、アメリカの事例はMySQLによるものである。
自由ソフトウェアの使用・学習・修正・再配布の自由を守るため、多くのフリーソフトウェアライセンスは配布者に適用されるべき要求と制約を条項に含んでいる。自由ソフトウェアのコミュニティでは、自由を守る制約と自由を制限してしまう制約の線引きをどこにすべきかについて、盛んに議論が行われている。
使用についての制約
ソフトウェアの利用について用途を制限することは、一般に自由ソフトウェアライセンスでは許容されない。例えば、軍事目的、ベンチマークや比較目的、倫理的に問題のある目的[5]、営利目的[6]での利用を制限するなどである。このため、そのようなライセンスはFSFでもOSIでもDebianでもBSD系ディストリビューションでも、公認ソフトウェアライセンスとはみなされない。
FSFの自由ソフトウェアの定義ではさらに、開発と配布についても制約を課してはならないとしている[7]。したがって、自由ソフトウェアを商品として販売することも許容されており、一般的になってきている。
コピーレフト
→詳細は「コピーレフト」を参照
リチャード・ストールマンが1980年代中ごろに書いたフリーソフトウェアライセンス群は、コピーレフトという概念のさきがけである。コピーレフト条項では、自由ソフトウェアの改変版を配布する際に元のソフトウェアと同じ条件下で配布されなければならないことを述べている。したがってコピーレフトのソフトウェアに対する全ての改良や機能追加もまた、自由ソフトウェアとして配布されなければならない。これを "share and share alike"（均等分配）あるいは "quid pro quo"（代償）などと呼ぶこともある。
製品にGPLのコードを使う開発者は、たとえそのオブジェクトコードが対価を要求する製品であっても、そのソースコードを誰でも入手可能にしておかなければならない。その場合、そのソースコードにはその開発者が加えた全ての改変を含める必要がある。GPLのコードを使ったとしても、それを何らかの形で配布するのでなければ、改変部分を他者に明らかにする必要はない。したがって、開発者や組織が私的目的（つまり、そのコードやプロジェクトが販売や配布を目的としていない場合）でGPLのコードを改変した場合、その改変の内容を公けにすることは要求されない。
GPL支持者は、派生著作物もフリーであり続けるよう命じることで、自由ソフトウェアの成長を促進し、全ての利用者の参加を要求することになると主張している。
特許報復条項
1990年代末以降に書かれた新しい自由ソフトウェアライセンスには、特許報復条項が含まれているものが多い。これは、ライセンス対象のソフトウェアに対して特許権を行使しようとした場合、場合によってはそのライセンスに基づく権利（再配布する権利など）を停止するなどの規定である。例えば、Apple Public Source License では、特許侵害訴訟を起こした場合にそのユーザーのそのライセンス下の権利を停止することがあるとしている。特許報復条項は、ソフトウェア特許の濫用への対策として生まれた。
TiVo化
→詳細は「TiVo化」を参照
GNU GPL のバージョン3には、特定のケースでデジタル著作権管理 (DRM) によって制限を加えようとすることを防ぐ文言を含んでいる。そのようなDRMの利用を「TiVo化」と呼ぶ。
帰属、免責、注意事項
自由ソフトウェアライセンスの多くは、改変されたソフトウェアを改変していないと主張しないことを要求している。一部のライセンスは著作権表示を要求する。例えば、GNU GPL バージョン2がそれで、保証やライセンスに関する情報を表示する対話型プログラムに改変を加えて再配布する場合は、それらの表示を除去しないことを要求している。
ライセンスの互換性
→詳細は「ライセンスの互換性」を参照
ソフトウェアパッケージ群のそれぞれのライセンス間で要求に矛盾があると、それらのソースコードをまとめて新たなソフトウェアパッケージを作ることはできない[8]。
例えば、あるライセンスで「改変版では、広告で開発者に言及しなければならない」とし、別のライセンスでは「改変版には追加の帰属条項を含めてはならない」とある場合、両方のライセンスのソフトウェアをまとめようとすると、両方の要求を同時に満たすことができないため、再配布できないことになる。したがって両者のライセンスは非互換である[9]。
ライセンスの氾濫
→詳細は「ライセンスの氾濫」を参照
ライセンスの氾濫はライセンスの非互換問題を複雑化させる。ソフトウェア開発者やディストリビュータは、読まなければならない法律文書が増え、負担を強いられる。ライセンスの氾濫は1990年代末ごろその動きが見られるようになり、2000年代初めにさらに増大した。2005年にはこの現象が問題として認識されるようになり、新たなライセンスを作ることは不適切と言われるようになった。
ライセンス感染
→詳細は「ライセンス感染」を参照
一部のコピーレフト条項を含むフリーソフトウェアライセンスは、そのコピーレフト条項に従い、二次著作物のソフトウェアライセンスに原著作物と同一もしくは同等のライセンスを課することを要求する[10]。原著作物のソフトウェアライセンスの制約によっては、ソフトウェアのソースコードの開示や、二次著作者の広告条項の義務、連携ソフトウェアへのライセンス適用などの必要性が生じる。
BSDライセンス
BSD系オペレーティングシステムのユーザーや開発者は、ライセンスに対してGNUなどとは異なる立場をとっている。大きな違いは、GNU General Public License (GPL) のようなコピーレフト型ライセンスは無駄に複雑で制約的だと考える点である[11]。GPLでは、GPLのコードを改変したものもGPLでリリースすることを要求するが、BSDライセンスではそうではない。基本的にBSDライセンスの唯一の必要条件は原著者への謝意を表明することであり、ソースコードをどう使うかについては何の制限も設けていない。結果としてBSDのコードはプロプライエタリソフトウェアでも使え、単に原著者を表示しさえすればよい。実際、WindowsやmacOSのインターネット・プロトコル・スイートの実装は、BSDライセンスのソフトウェアから派生したものである。
BSDライセンスの支持者は、ソースコードについてあらゆる権利を認めているという点でGPLよりも自由であり、パブリックドメインの次の自由だと主張する。このため、BSDライセンスのコードは商用ソフトウェアで広く使われている。一方GPLの支持者は、自由ソフトウェアから他者が自由でないソフトウェアを作る自由は、必要な自由というよりも権力の不公平さの形式の一種だと主張している[12]。しかし、あるソフトウェア製品が全てオープンソースであっても、それらのライセンスがGPLと互換性がないために、GPLでライセンスされたコードを取り込むことができないということがある。
BSDのような許容型フリーソフトウェアライセンスでライセンスされたコードは、コピーレフト型（例えばGPL）のプロジェクトに取り込むことができる。このとき原作者の承諾を得る必要は全くない。対照的に、GPLのコードをBSDライセンスに変更するには、著作権者全員の承諾を得る必要がある。したがって、この2つのライセンスはある意味で互換性があるが、それらを組み合わせた全体を配布する場合、許容型ライセンスではなくGPLにしなければならない。
BSD系の既存のフリーソフトウェアは、中核部分にGPLのコードを含めないようにしており、他に選択肢がない場合やGCCのように圧倒的に機能差がある場合のみGPLのものを採用している。OpenBSDプロジェクトでは、GPLライセンスのツール群を排除するためにBSDライセンスの代替ツールを採用しようとしており、新たにツールを開発したり、古いコードを再利用しようとしている。
Debianライセンス
→「Debianフリーソフトウェアガイドライン」も参照
Debianプロジェクトでは、Debianフリーソフトウェアガイドライン (DFSG) という判定基準を採用している。Debianとフリーソフトウェア財団が合意していないケースとして、Artistic License と GNU Free Documentation License がある。Artistic License については、Debianは承認しているが、FSFは承認していない。しかし Artistic License は通常 GNU General Public License とのデュアルライセンスの形で使うことが多いため、あまり問題にはなっていない。
GNU Free Documentation License については、Debianはディストリビューション内の文書についてもDFSGを適用すると決めた。FSFは、文書はソフトウェアとは質的に異なるため、要求も異なってしかるべきだとしている。長い議論の末、Debianプロジェクトでの投票が行われ[13]、改変できない部分（GFDLではこれを "invariant section" と呼ぶ）を含まない場合に限ってGFDLをフリーと認めることになった。GNU文書の多くは invariant section を含んでいる。
オープンソースライセンス
→詳細は「オープンソースライセンス」を参照
1998年に発足した Open Source Initiative (OSI) も承認したライセンスの一覧を保守している。OSIとFSFは、広く使われている自由ソフトウェアライセンスについては全て一致して承認している。両者の一覧に不一致が見られるのは、Open Source Initiativeがパブリック・ドメイン相当のライセンス (CC0、WTFPLなど) の承認していないため、フリーソフトウェア財団がソースコードを個人目的利用時には必要としないなどの現密には自由ではないライセンスの承認していないためである。
その他のライセンス
自由ソフトウェアのほとんどは誰が見ても自由ソフトウェアライセンスと呼べるライセンスを採用している。しかし、自由ソフトウェアライセンスと呼べるかどうか議論の絶えない例も多い。
例えば、Apple Public Source License のバージョン1.xはOSIが認めたものの、FSFやDebianは認めなかった。RealNetworks Public Source License は、OSIとFSFは認めたが、Debianは認めていない。2007年、Common Public Attribution LicenseをOSIだけが承認した[14]。
Wikiwand in your browser!
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.
