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

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

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

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

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

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

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

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

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

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

ソフトウェア

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

ほとんどのプログラムには、わたしたちは最新のバージョンのGNU一般公衆ライセンス(GPL)を使うことを推奨します。その強いコピーレフトはすべての種類のソフトウェアに適切で、ユーザの自由のたくさんの保護を含んでいます。未来のライセンスの更新を認めるには、“version 3 or any later version”を指定してください。そうすることにより、あなたのプログラムが将来にリリースかもしれないコードと、後継のGPLのバージョンのもとで、ライセンス両立することができます。

こちらが、プログラムをGNU GPLでリリースする方法について、さらなる助言です。

GNU GPLではなく、ほかのライセンスを使った方が良い、例外を挙げます。

小さなプログラム

コピーレフトをほとんどの小さなプログラムに使うのは、トラブルに値しません。わたしたちは300行を基準としています。ソフトウェアパッケージのソースコードがそれよりも小さいとき、コピーレフトによる利益は通常とても小さく、ライセンスのコピーがソフトウェアとともにあるように確実にする不便を正当化することは難しいでしょう。

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

弱い(甘い)ライセンスの中で、Apache 2.0がもっともよいものです。理由はともかく緩く弱いライセンスを使う場合には、わたしたちは、それを使うことを推奨します。

ライブラリ

ライブラリでは、わたしたちは三つの種類の場合分けをします。

あるライブラリは、Ogg Vorbis(MP3と競います)やWebM(MPEG-4動画と競います)のような、制限されたデータフォーマットと競う、自由のデータフォーマットを実装します。自由なフォーマットの成功のためには、多くのプロプライエタリなアプリケーションプログラムがそのフォーマットを扱えるコードにリンクすることを認める必要があります。たとえば、不自由なメディアのプレーヤー、特に機器が、MP3と同じようにOgg Vorbisのコードをを含むようにしたいとわたしたちは考えました。

こういった特別の状況で、もし、プロプライエタリなアプリケーションの開発者をその自由なフォーマットのためのライブラリを使うように説得できるのであれば、そのライブラリを弱いライセンス、たとえばApacheライセンス2.0のもとでライセンスし、それを容易にする必要があるかもしれません。

しかしながら、この戦略はOgg Vorbisでは成功しなかったことを認識しなければなりません。そのライブラリのコードをプロプライエタリなアプリケーションが容易に含むことを許すように著作権のライセンスを変更した後でも、プロプライエタリな開発者は一般的にはそれを含めませんでした。ライセンスの選択になされた犠牲は結局のところなにも勝ち得ませんでした。

ほかのすべてのライブラリには、わたしたちはコピーレフトのどれかを推奨します。開発者が既に確立された代替のライブラリを使っており、それが、不自由なライセンスもしくは緩い甘いライセンスでリリースされている場合、わたしたちはGNU劣等一般公衆ライセンス(LGPL)を推奨します。

ライブラリが倫理的により良い標準を実装するという第一のケースと異なり、ここでは、それ自身のための採択は何の目標を達成することもないでしょう。ですから、全面的にコピーレフトを避ける理由はまったくありません。しかし、あなたのライブラリを使っている開発者に、かれらの作品を完全なコピーレフトでリリースしてと頼んだ場合、かれらは単に利用可能な代替物の一つを使うでしょうから、わたしたちの運動を前進させることにもなりません。劣等GPLはこれらのケースの中間を埋めるように設計され、プロプライエタリのソフトウェア開発者が劣等GPLの及ぶライブラリを使うことを許しますが、ライブラリのコードそれ自身について弱いコピーレフトを提供し、ユーザに自由を与えます。

特別な機能を提供するライブラリで、確立したコピーレフトでない、あるいは不自由な闘いに直面してない場合、通常のGNU GPLを使うことを推奨します。なぜかの理由については、「あなたの次回のライブラリには劣等GPLを使うべきでない理由」をご覧下さい。

サーバのソフトウェア

サーバで実行するように、あなたのプログラムの改良版をほかの人が作り、ほかの誰にも改良版を配布しない、というのがあり得て、これがあなたのリリースしたバージョンに不利な状況となる懸念があるならば、わたしたちは GNUアフェロ一般公衆ライセンス(AGPL)を推奨します。AGPLの条項はGPLのそれとほとんど同一です。一つだけの重要な違いは、ソフトウェアをネットワーク上で使う人々が、そのソースコードを入手することができることを確実にするよう配慮された特別の条件があるということです。

このAGPLの要求は、ほかの誰かのサーバへ、コンピューティングやデータを委託する際、ユーザに起こりうる問題を扱うことにはなりません。たとえば、ソフトウェア代替としてのサービス(SaaSS)がユーザの自由を否定することを止めることはできないでしょう。これらの問題について詳しくは、「なぜアフェロGPLなのか」をご覧ください。

文書

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

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

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

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

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

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

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

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