English [en]   français [fr]   日本語 [ja]   русский [ru]  

BREAKING: Knocking Down The HACIENDA

GNU hackers opened the GHM by revealing the offensive HACIENDA global surveillance program for TWD, and how to knock it down with stealth TCP services! Watch it now! [more]

原文は英語で、これはその翻訳です。

あなた自身の作品にライセンスを選択する方法

This page is maintained by the Free Software Foundation's Licensing and Compliance Lab. You can support our efforts by making a donation to the FSF. Have a question not answered here? Check out some of our other licensing resources or contact the Compliance Lab at licensing@fsf.org.

はじめに

人々は、かれらのプロジェクトにとって、わたしたちが推奨しているライセンスのどれを使うのがよいか、よく尋ねます。以前、これについて公式に書いたことがありましたが、情報は、いろいろな論説、FAQの項目、そしてライセンスについての注釈に散らばっていました。この小論では、すべてのそれらの情報を集めて一つにまとめ、人々が学び、後で参照するのが容易となるようにしています。

この推奨は実用的な仕事をするよう設計された作品向けです。それは、ソフトウェア、文書、およびそのほかのものを含みます。芸術や見解を示す作品については、異なった問題です。GNUプロジェクトでは、そのような作品がどのようにリリースされるべきかについての一般的な立場はありません。一つだけ、すべて、それらは不自由なソフトウェアなしで(特に、DRMなしで)利用できるべきである、ということはあります。しかし、あなたは、特定のプログラムとともにある芸術作品のために、これらの推奨に従おうと考えることがあるかもしれません。

この推奨はあなたが作った作品のライセンシングに適用します。それが既存の作品の改変か、新しいオリジナルの作品のどちらでも。この推奨は、異なるライセンスの既存のものを組み合わせる問題については扱いません。この問題に関してなにか助けを探している場合、わたしたちのGPL FAQを確認ください。

ここに、わたしたちが推奨しているものを読んだ後、助言を得たい場合、<licensing@gnu.org>宛に連絡することができます。応答があるまで、おそらく数週間かかると思います。一ヶ月経っても回答がない場合、再度連絡してください。

すでにあるプロジェクトに貢献する

すでにあるプロジェクトに貢献する場合、通常は、改変したバージョンをオリジナルの作品と同一のライセンスの元でリリースするべきです。プロジェクトのメンテナと協力することはよいことで、改変に対し異なるライセンスを使うことは、まま協力をとても難しくします。それを正当化する強い理由がある場合にだけ、それをすべきです。

異なるライセンスを使うことが正当化できる一つのケースは、あなたが主要な変更をコピーレフトでないライセンスの作品に行った時です。あなたが作成したバージョンが、オリジナルよりもとりわけ有用である場合、わたしたちがコピーレフトを通常推奨する理由とまったく同じ理由で、あなたの作品をコピーレフトとすることに意義があるでしょう。あなたがこの状況にある場合、下記の新しいプロジェクトのライセンシングの推奨に従ってください。

理由が何であれ、あなたの貢献を異なるライセンスでリリースすることを選択した場合、あなたの選択したライセンスのものに対する使用を、オリジナルのライセンスが許すことをきちんと確認しなければなりません。ほかへの影響を最小にするため、作品のどの部分がどのライセンスかを明らかに示しましょう。

ソフトウェア

わたしたちは、およそソフトウェアの目的に応じて、異なるプロジェクトには異なるライセンスを推奨します。一般的には、その目的を妨げない、もっとも強いコピーレフトのライセンスを使うことを推奨します。わたしたちの論説「コピーレフトって何?」では、コピーレフトの概念をより詳細に、なぜ、一般的にそれがもっともよいライセンスの戦略なのかを説明します。

どのようなコピーレフトも、まったく有するべきではないと、わたしたちが考えるプロジェクトの種類は、ただ数種に過ぎません。第一は、とても小さいプロジェクトです。わたしたちは300行を基準としています。ソフトウェアパッケージのソースコードがそれよりも小さいとき、コピーレフトによる利益は通常とても小さく、ライセンスのコピーがソフトウェアとともにあるように確実にする不便を正当化することは難しいでしょう。

第二は、Ogg Vorbis (MP3と競います)やWebM(MPEG-4と競います)のような、プロプライエタリの標準と競う、自由の標準を実装するプロジェクトです。これらのプロジェクトにとっては、コードの広範な使用が、自由ソフトウェアの運動を前進するために、きわめて重大であり、プロジェクトのコードがコピーレフトとされるよりも、よりよいと考えられます。

コピーレフトが適さないような特別の状況では、Apacheライセンス2.0をわたしたちは推奨します。これは甘い(コピーレフトではない)ソフトウェアのライセンスで、貢献者と配布者が特許侵害について訴訟を起こすことを妨げる条項があります。これは、ソフトウェアを特許の脅威から免れるようにはしませんが、特許保持者が、自由の条項でソフトウェアをリリースしておきながら、受け取った人にロイヤリティやほかの特許ライセンスの不自由な条項を要請するという「おとり商法」を設定することを防ぎます。

そのほかのすべてのケースでは、わたしたちはなんらかのコピーレフトを推奨します。あなたのプロジェクトがライブラリであり、不自由なライセンスか緩く甘いライセンスでリリースされた確立された代わりのライブラリを開発者がすでに使っている場合、GNU劣等一般公衆ライセンス(LGPL)を使うことを推奨します。プロジェクトが標準を実装するという上述のケースと異なり、ここでは、それ自身のための採択は何の目標を達成することもないでしょう。ですから、全面的にコピーレフトを避ける理由はまったくありません。しかし、あなたのライブラリを使っている開発者に、かれらの作品を完全なコピーレフトでリリースしてと頼んだ場合、かれらは単に利用可能な代替物の一つを使うでしょうから、わたしたちの運動を前進させることにもなりません。劣等GPLはこれらのケースの中間を埋めるように設計され、プロプライエタリのソフトウェア開発者が劣等GPLの及ぶライブラリを使うことを許しますが、そうしたときにユーザを利するような弱いコピーレフトを提供します。これらのケースでの、わたしたちの考察についてもっと知りたい場合は、「あなたの次回のライブラリには劣等GPLを使うべきでない理由」をご覧下さい。

ほかの人が改良した後、プロジェクトがサーバで実行され、ネットワーク上でユーザとやりとりすることがありそうな場合で、結果としてリリースされたバージョンに貢献する開発者が少なくなる懸念があるのならば、わたしたちは GNUアフェロ一般公衆ライセンス (AGPL)を推奨します。AGPLの条項はGPLのそれとほとんど同一です。一つだけの重要な違いは、ソフトウェアをネットワーク上で使う人々が、そのソースコードを入手することができることを確実にするよう配慮された特別の条件があるということです。この条件は、ユーザがサーバでコンピューティングを行う際に起こりうるすべての問題を扱うことにはなりません。ユーザがサービスとしてのソフトウェアに害されることを止めることはできないでしょう。しかし、ライセンスができることはできるだけ達成しています。これらの問題について詳しく知るには、「なぜアフェロGPLなのか」をご覧ください。

そのほかのすべての場合には、わたしたちは最新のバージョンのGNU一般公衆ライセンス(GPL)を使うことを推奨します。その協力なコピーレフトはすべての種類のソフトウェアに適切で、ユーザの自由のたくさんの保護を含んでいます。

文書

わたしたちはGNU自由文書ライセンス (GFDL)をチュートリアル、リファレンス・マニュアルやそのほかの大きな文書の作品に推奨します。これは、教育作品のための、強いコピーレフトのライセンスで、当初は、ソフトウェアのマニュアルのために書かれました。作品が配布され、改変された時に起こる共通の問題を特に扱った条項を含んでいます。

短いものや二次的な文書作品、リファレンス・カードのような、には、GNU全面的に寛容なライセンスを使う方がよいでしょう。なぜならGFDLの複製は(長くて)リファレンス・カードには適さないからです。CC-BYを使わないようにしましょう。これはGFDLと両立しません。

manページには、ページが長い場合にはGFDLを推奨します。短い場合はGNU全面的に寛容なライセンスを推奨します。

ある文書はソフトウェアのソースコードを含みます。たとえば、プログラミング言語のマニュアルには、読者が試してみる例が含まれるでしょう。あなたは、マニュアルにはFDLの条項でソースコードを含むようにし、同時に、ソフトウェアのために適切な別のライセンスでソースコードをリリースするべきです。このようにすることで、ほかのプロジェクトにそのコードを使うことを容易にする助けになります。小さなコードの部分をCC0を使ってパブリック・ドメインにすることを、わたしたちは、推奨します。より大きな部分は関係するソフトウェアプロジェクトが使うのと同じライセンスで配布することを推奨します。

プログラムのそのほかのデータ

この節は、ソフトウェアに含めるかもしれない、実用のすべてのそのほかの作品について論じます。例をあげれば、アイコンや機能するあるいは有用な画像、フォント、地理のデータなどです。芸術についてもそれらに習うことができますが、そうしなくても、わたしたちはあなたを批判しないでしょう。

あるソフトウェア・プロジェクトで特に使うために作品を作る場合、ソフトウェアと同じライセンスで作品をリリースすることを一般的に推奨します。わたしたちが推奨しているライセンスにはそうすることに何の問題もありません: GPLv3, LGPLv3, AGPLV3とGPLv2は、すべてが、どのような種類の作品にも適用できます。ソフトウェアに限らず、著作権を設定でき、改変のための望ましい形態がはっきりとしているものであれば問題ありません。ソフトウェアと同じライセンスを使うことはディストリビュータにとって適合性を確認することを容易にする助けとなり、潜在的な両立性の問題についての疑念を避けることができるでしょう。ほかの自由プロジェクトとの協力関係など、特定の実用上の利益があるばあい、異なる自由ライセンスを使うことは適するでしょう。

特定のソフトウェアプロジェクトでの使用のために作品が作られたのではない場合、もしくは、そのプロジェクトと同じライセンスを使うことが適さないかもしれない場合、作品に適したコピーレフトのライセンスを選択することだけを、わたしたちは推奨します。こちらに、わたしたちのライセンスリストにあげられたものがあります。どのライセンスも特に適するように思えない場合、Creative Commons Attribution-ShareAlikeライセンスは、いろいろな異なる種類の作品に使われ得るコピーレフトです。

[FSFロゴ]「わたしたちのミッションは、コンピュータ・ソフトウェアを利用、研究、コピー、改変、再配布する自由を維持、保護、促進し、自由ソフトウェアの利用者の権利を擁護することです。」

フリーソフトウェアファウンデーションはGNUオペレーティング・システムの主な組織的スポンサーです。GNUとFSFを支持しよう: マニュアル、関連グッズを買う賛助会員となってFSFに参加する、もしくは寄付をする(直接FSFへまたはFlattrで)。

先頭へ戻る