著作権の保有と譲渡

多くの人の貢献によって成り立っている、 フリーなコードやドキュメントの著作権をうまく扱う方法は3つあります。 ひとつめは、(私はお勧めしませんが) 著作権にまつわる問題をすべて無視してしまうことです。 ふたつめは、contributor license agreement (貢献者ライセンス同意書、以下 CLA) をプロジェクトで働く人達から集め、 個人が行った貢献をプロジェクトが使う権利を明示的に与えてもらうことです。 ほとんどのプロジェクトは通常これで十分です。また、裁判の管轄区域によっては、 CLA は電子メールで送ることができるのも優れています。 三つめは、プロジェクト (通常は非営利な法的主体) が全ての著作権を保持するために、貢献する人から著作権を実際に譲ってもらうことです。 これがもっとも法的には隙のない方法ですが、貢献する人にとってはもっとも厄介です。 よって、この方法を求めてくるプロジェクトはわずかです。

著作権を一ヶ所に集めたとしても、 コード[39] はフリーのままであることに注意してください。 なぜなら、オープンソースライセンスは、 著作権を持つ人にコードのコピーを過去に遡って独占的なコードにする権利を認めていないからです。 よって、たとえ法的な主体としてのプロジェクトが突然方針を転換し、 すべてのコードを制限が強いライセンスで配布し始めたとしても、 そんなことはコミュニティーにとって決して問題になりません。 他の開発者は単に最新のフリーなコードをコピーして新しいプロジェクトを始め、 何事もなかったかのように開発は続くでしょう。そうできることを知っているからこそ、 貢献する人達のほとんどは CLA へのサインや、著作権の譲渡を求められたときに協力するのです。

何も対処しない

ほとんどのプロジェクトは、貢献する人から CLA を集めたり、 著作権を譲ってもらったりはしません。そのかわり、 貢献する人のプロジェクトに取り入れてもらいたいという意志が、 適度に明確である場合にはいつでもコードを受け入れています。

通常の状態ではこれで構いませんが、誰かが自分こそが問題となるコードの真の持ち主であり、 自分たちはそのコードをオープンソースライセンスの下で配布することを認めないと主張して、 著作権法違反で裁判を起こすかもしれません。 たとえば、SCO グループはこれと似たようなことを Linuxカーネル開発プロジェクト に対して行いました。 詳しくは、http://en.wikipedia.org/wiki/SCO-Linux_controversies を参照してください。 こんなことが起きてしまうと、 プロジェクトは貢献した人から正式にコードを使う権利を得ていることを証明する文書がありません。 こうなると、法的な防御が難しくなるかもしれません。

貢献者ライセンス同意書(CLA)

CLA はおそらく、法的な安全性と利便性のトレードオフを解決する最良のものでしょう。 CLA は開発者が内容を記入し、プロジェクトに送付する電子的な書式が典型的なものです。 多くの裁判の管轄地域では、電子メールで送付すれば十分です。 安全な電子署名が必要な場合もあります。 どの方法があなたのプロジェクトに合っているかを知るには、弁護士に相談してください。

多くのプロジェクトではふたつのちょっと異なる CLA を使います。 ひとつは個人用、そしてもうひとつは企業用のものです。 しかしどちらであっても、中心となる文言は同じです: 貢献する人(組織) はプロジェクトに "... あなたの貢献を複製したり、派生物を準備したり、公に表示したり、公に実行したり、 サブライセンスするために、「半永久的で、全世界規模で、非独占的で、 無償で、ロイヤリティーがなく、取り消すことができないライセンス」" を与える。というものです。 繰り返しますが、どんな CLA を受け入れる場合でも弁護士に相談すべきです。 しかし、あなたがこれらの文言に慣れていれば、おそらく問題はないでしょう。

CLA へのサインを、貢献する人に頼むときは、 実際に著作権を譲渡するよう求めているわけでは ない ことを必ず強調するようにしましょう。 実際、多くの CLA はサインする人にこのことを念押しする文言で始まります。

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

以下にいくつか例を示します:

著作権の譲渡

著作権の譲渡とは、貢献する人が、自分が行った貢献の著作権をプロジェクトに譲り渡すことです。これは書面を郵送するか、ファックスすることで行うのが望ましいです。

プロジェクトによっては、 著作権を完全に譲渡するよう求めるところがあります。 これは、すべてのコードの著作権をひとつの法的主体が持っていた方が、 オープンソースライセンスの条件に違反した人を訴える場合に便利だからです。 著作権を譲ってもらうときにどの程度の厳密さを求めるのかは、 組織によって異なります。 公開されているメーリングリストで 「私はここで、このコードの著作権をプロジェクトに譲り、 このコード以外のものと同じライセンスを適用させます。」 と言うことと同じ効果がある、非公式な声明を集めるだけのところもあります。 私が話をした弁護士のうち少なくともひとりは、 これで十分だと述べています。おそらくこれは、 著作権の譲渡が通常期待される状況下で行われていること、 そしてプロジェクトが開発者の本当の意志を確定させようとする努力が 本物である ことを表しているからだと思われます。一方で、 フリーソフトウェア財団 (FSF)は、全く逆の立場をとっています。 彼らは著作権を譲渡する正式な声明文が書かれた一枚の紙切れに直接サインし、 郵送 (あるいは FAX) することを求めてきます。 たった一度貢献しただけでもFSFはこれを要求することがあります。 また、現在、そして将来するであろう貢献に対して要求することもあります。 対象となる開発者が雇われていた場合、雇用主もサインを求められます。

FSF が潔癖なのは理解できます。 仮に誰かが FSF のソフトウェアを独占的なプログラムに組み込んで GPL の条件に違反した場合、FSF は裁判で争う必要が出てきます。 そうした事態になったときに、 FSFは自らが持つ著作権を全く隙がない状態にしたいからです。 FSF は多くの人気があるソフトウェアの著作権を持っているので、 彼らはこうした可能性が実際にあり得ることだと考えています。 あなたの組織が同じように細心の注意を払うべきかは、 弁護士に相談してから決めるようにしましょう。 一般的には、著作権を完全に譲ってもらう理由がなければ、 CLA を使うようにします。なぜなら、皆が扱いやすいからです。



[39] ここから私は、「コード」という言葉を「プログラムとドキュメント両方」 という意味で使います。