GNU Affero GPLv3 (AGPLv3)の著作権的考察
GNU Affero GPLv3 (以下、AGPLv3)は、従来のOSSライセンスに比べ、かなり特殊なOSSライセンスです。
何が特殊なのかお話します。従来のソース開示が必要なOSSライセンス(GPLタイプ、LGPLタイプ、MPLタイプ、前記事参照)は、バイナリ形式の頒布に伴って、そのバイナリを改善・改変可能なように、ソース開示(ソースの添付またはソース提供する旨の申し出の添付)の条件が付与されていました(これが、本来のコピーレフトの意味合いです)。それに対して、AGPLv3では、バイナリ形式が頒布されていないネットワークサービス利用者にもソース開示する条件がGPLv3の条件に追加されています。つまり、受領したバイナリを改善・改変可能なように、という目的から逸脱しています。そこが特殊です。
- AGPLv3の追加条件-第13条
- GPLの抜け穴(loophole) 2-1. Tivoization 2-2. Novell-Microsoftの取引
- SaaSの抜け穴(loophole)
- 『ライセンス』とは
- 法的根拠の考察 5-1. 第13条が許諾する『利用』は翻案権か? 5-2. 第13条が許諾する『利用』
- さいごに
1. AGPLv3の追加条件-第13条
その特殊な条件は、第13条に記載されています。
- リモートネットワークインタラクション、および GNU 一般公衆利用許諾書との利用
本許諾書に含まれる他の条件に関わらず、あなたが『プログラム』を改変した場合、改変したバージョンは、そのバージョンとリモートでコンピュータネットワークを介し対話的にやりとりする(あなたのソフトウェアがそのようなインタラクションをサポートしている場合)すべてのユーザに対して、ネットワークサーバから、あなたのバージョンに『対応するソース』にアクセスする手段を、無償、かつソフトウェアのコピーを円滑に行う上で標準的、慣習的に用いられる方法で提供することにより、ユーザが『対応するソース』を受け取る機会を明示的に与えなければ
なければならない。ここでいう『対応するソース』には、次の段落に従って取り込まれた、GNU 一般公衆利用許諾書のバージョン3で保護されるすべての作品も含まれる。本許諾書に含まれる他の条件に関わらず、あなたには、『保護された作品』を GNU 一般公衆利用許諾書バージョン3の下で許諾された作品とリンクまたは結合して単一の結合物とし、その結果物を伝達する許可が与えられる。本許諾書の条項は『保護された作品』である部分に関してはそのまま適用されるが、結合された側の作品は、GNU 一般公衆利用許諾書のバージョン3によって保護され続ける。
agpl.ja.html (opensource.jp)
GPLv3では第13条は下記のようになっており、上の二つのパラグラフの内、後半のパラグラフが、GPLv3の第13条の内容を逆の立場で書いたものです。つまり、前半のパラグラフがAGPLv3として、GPLv3に追加になった条件の記述です。
13. GNU Affero 一般公衆利用許諾書との利用
本許諾書に含まれる他の条件に関わらず、あなたには、『保護された作品』を GNU Affero 一般公衆利用許諾書バージョン3の下で許諾された作品とリンクまたは結合して単一の結合物とし、その結果物を伝達する許可が与えられる。本許諾書の条項は『保護された作品』である部分に関してはそのまま適用されるが、結合物それ自体としては、GNU Affero 一般公衆利用許諾書の第13項が規定する、ネットワークを介したやりとりに関する特殊な条件も適用されることになる。
gpl.ja.html (opensource.jp)
GNU AGPLv3でも提供されているプログラムにiText社のiText PDFなどがあります。MongoDB社の初期のMongoDBもAGPLv3でした。ライセンス名の元となったAGPLv1を作成したのもAffero社です。つまり、企業が自社のプログラムを商用ライセンスとのデュアルライセンスでAGPLv3で提供することが多いようです。
iText PDFで明細書をPDFで発行するEC(買い物)サイトを構築したとします。このときiText PDFに改変を加えたとします。具体的には、iTextPDFをライブラリとして取り込んだECサイトアプリケーションを開発した場合を想定するとよいでしょう。そうすると、この改変したiText PDFのバージョン(ECサイトアプリケ-ション)は、ECサイトとやりとりする全ての買い物客に対して、「あなたのバージョンに『対応するソース』にアクセスする手段を、無償、かつソフトウェアのコピーを円滑に行う上で標準的、慣習的に用いられる方法で提供することにより、ユーザが『対応するソース』を受け取る機会を明示的に与えなければなければならない」という条件です。
買い物客は、当該プログラムのバイナリを受け取っていないにも関わらずです。
2. GPLの抜け穴(loophole)
ここで、AGPLv3ができた背景と思われる話に触れておきます。
それまで(主にGPLv2でしょうが)GPLの(?)「抜け穴(loophole)」と呼ばれる行為がいくつか挙げられていました。何の抜け穴かというと、プログラムを自由ソフトウェアでいうところの自由にしない行為です。
あるプログラムが自由ソフトウェアであるとは、そのプログラムの利用者が、以下の四つの必須の自由を有するときです:
自由ソフトウェアとは? - GNUプロジェクト - フリーソフトウェアファウンデーション
- どんな目的に対しても、プログラムを望むままに実行する自由 (第零の自由)。
- プログラムがどのように動作しているか研究し、必要に応じて改造する自由 (第一の自由)。ソースコードへのアクセスは、この前提条件となります。
- ほかの人を助けられるよう、コピーを再配布する自由 (第二の自由)。
- 改変した版を他に配布する自由 (第三の自由)。これにより、変更がコミュニティ全体にとって利益となる機会を提供できます。ソースコードへのアクセスは、この前提条件となります。
元々、これらの自由を持ったプログラム(自由ソフトウェア)に何かをして、どれかの自由を亡くす行為を「抜け穴(loophole)」と呼んだようです。例えば、GPLv3(AGPLv3ではなく)では、二つの行為による抜け穴を塞いだようです。
- Tivoization
- Novell-Microsoftの取引
2-1. Tivoization
Tivoizationとは、コンピュータ(「電化製品」と呼ばれています)が、GPLで保護されているのに変更不可能になっているソフトウェアを含んでいる、という意味です。そういった電化製品は、ソフトウェアが修正されたことを検知すると停止してしまうのです。
GPLv3にアップグレードする理由 - GNU プロジェクト - フリーソフトウェアファウンデーション
これは、第零の自由「どんな目的に対しても、プログラムを望むままに実行する自由」を奪う行為です。
GPLv3では、「第6条 ソース以外の形式における伝達」において、「改変されたバージョンを、インストール、実行するために必要な手法、手順、認証キーやその他の情報」を『インストール用情報』(Installation Information)と呼んで、「『対応するソース』は『インストール用情報』と共に提供されなければならない」と明記して、上記の自由を奪う行為の対策をしています。
元々、GPLでソース開示を求めるのは、改変のためですから、GPLv2の時でも、開示するソースコードには当然、そういう情報も含まれるという暗黙の認識があったわけですが、GPLv3では、それを明文化したという形です。
2-2. Novell-Microsoftの取引
Microsoftは、所有している何千もの特許を利用して、GNU/Linux利用者にその権利分を支払わせようとしており、Novell-Microsoftの取引でそれを実現しようとしました。この取引によって、Novellの顧客には、Microsoftが保有する特許の限定的な保護が与えられます。
GPLv3にアップグレードする理由 - GNU プロジェクト - フリーソフトウェアファウンデーション
これは、プログラムを利用できる、つまり、頒布先をNovellの顧客に限定させることにより、第二の自由「ほかの人を助けられるよう、コピーを再配布する自由」や第三の自由「改変した版を他に配布する自由」を奪う行為です。
GPLv3では、第11条で、「あなたが授与した『パテントライセンス』は…すべての受領者にまで自動的に拡大される」と規定して、限定されないことを前提としています。
ある一対一の取引や協定に基づき、あるいは関連して、あなたが『保護された作品』の伝達、または伝達によって引き起こされる普及を行い、その際『保護された作品』を受領した一部の当事者に対して、『保護された作品』の特定のコピーの利用、普及、改変、または伝達を正式に許可するような『パテントライセンス』を授与するならば、あなたが授与した『パテントライセンス』は『保護された作品』やそれを基にした作品のすべての受領者にまで自動的に拡大されることになる。
gpl.ja.html (opensource.jp)
加えて、Novell-Microsoftの取引のような「差別的」な『パテントライセンス』の場合、「あなたは『保護された作品』を伝達してはならない」と禁止しています。
ある『パテントライセンス』が「差別的」(discriminatory)であるとは、本許諾書の下で明確に認められた一つかそれ以上の権利を、『パテントライセンス』がカバーする範囲内に含まなかったり、そうした権利の行使を禁じたり、あるいは権利を行使しないことを条件として課すようなものである場合を指す。あなたを一方の当事者とし、ソフトウェアの頒布を生業とする第三者との間で、あなたは第三者に対し、作品を伝達する活動の程度に基づいて支払いを行う一方、第三者は、あなたから『保護された作品』を受領したすべての当事者に対して「差別的」な『パテントライセンス』を、(a) あなたが伝達した『保護された作品』のコピー(またはそうしたコピーから作成されたコピー)に対して、または(b) 『保護された作品』を含む特定製品や編集物を、主要な、あるいは関連した対象として授与する、というような協定を結んでいる場合、あなたは『保護された作品』を伝達してはならない。ただし、あなたがそのような協定を締結したり、『パテントライセンス』を授与されたのが2007年3月28日より以前である場合は本節の例外とする。
gpl.ja.html (opensource.jp)
これは新たな規定なので、不遡及の原則に則ってか「2007年3月28日より以前である場合は本節の例外とする」となっています。
3. SaaSの抜け穴(loophole)
もう一つ、GNU GPLv3では塞がれなかった抜け穴が「SaaSの抜け穴」です。「SaaS」は、「クラウド」であったり、昔流に言えば「ASP」であったりしました。これは、いろいろあるのかもしれませんが、一つは、クラウド(ASP)サービスで、GPLv3のプログラムが使われていても、著作権行使されていないので、そのソースコード、特に、改変されたソースコード、さらに、それを使ったアプリのソースコードが開示されない、ことを不都合と考え、抜け穴と言ったようです。
あなたが通常のGNU GPLで自由なプログラムを開発し、リリースしたとしましょう。ある開発者Dがプログラムを改変してリリースした場合、GPLはかれのバージョンもGPLで配布することを、かれに要求します。ですから、あなたがかれのバージョンのコピーを得た場合、あなたはあなたのバージョンにかれの変更を一部、もしくはすべて取り込むことが自由にできるのです。
しかし、プログラムが主にサーバで有用なものだとしましょう。Dがプログラムを改変した時、かれ自身のサーバでかれがそれを実行するけれどもコピーをリリースしないことは十分ありうることでしょう。その時、あなたはかれのバージョンのソースコードのコピーを得ることができず、かれの変更をあなたのバージョンに含める機会がないかもしれません。そして、あなたはその結果を好まないかもしれません。
GNUアフェロGPLの理由 - GNUプロジェクト - フリーソフトウェアファウンデーション
これは、別に、自由ソフトウェアの自由を無くす行為ではありません。なぜなら、自由うんぬんを問うプログラムを手にしていないからです。
我々のコンピュータにはそのプログラムがないわけで、要するにフリーソフトウェアと所有権の問題は、我々自身のコンピュータ上にあり、そこで動作するソフトウェアに関して(のみ)生じるのです。ソフトウェアの複製を手にしたら問題となるのが、我々はこの複製を使って何をしていいのか、ということです。単に実行させていいだけなのか、それともそのプログラムでできる他の有益なことに使ってもよいのか。もしそのプログラムが他の誰かのコンピュータ上で動作しているなら、この問題は生じません。私は Amazon のコンピュータ上にあるプログラムをコピーしてもよいでしょうか? もちろん、それはできません。私はそのプログラムを持ってないので、そのせいで道徳的に問題がある立場に置かれることもないわけです。
Open Source Licenses are Obsolete 日本語訳 (yamdas.org)
そのため、GPLv3でこの抜け穴を塞ごうという試みはあったものの、明らかに再頒布の条件が変わります。「ウェブを通じて提供されるアプリケーションは、あまりにも多くの人々にとって重要なので、今更その馬を納屋に連れ戻すことはできない」と思う人も多かったと思います。その結果、逆に、「正式に GPL の対象外」という認識の確認に至ったようです。
FSF は Affero GPL の成立を支援し、それを GPL3 の初期ドラフトに統合しようとした。しかし、その目論見は裏目に出てしまい、FSF は GPL をサービスとして提供されるソフトウェアに拡張しようとする文章を削除するだけに留まらず、「著作物を「伝達(convey)」する」というのが実際どういう意味か明確にすることともなった。
コンピュータネットワークを通じて、複製を転送することなくユーザとただやり取りをするのは伝達ではない。
言い換えれば、サービスとして提供されるソフトウェアは、今や正式に GPL の対象外なわけである。
…
ウェブを通じて提供されるアプリケーションは、あまりにも多くの人々にとって重要なので、今更その馬を納屋に連れ戻すことはできない。
The GPL and Software as a Service 日本語訳 (yamdas.org)
では、なぜ、このようなGPLの対象外のことを不都合と考えたのか、推測してみます。
GPLの説明において、昔は、ずいぶん偏った説明を耳にしたことがあります。「ソース公開しなければならない」理由として、自由ソフトウェアと商用ソフトウェアの対立かのように、商用ソフトウェアを排除するためかのように語られることもありました。また、開発者へ使わせてもらう返礼としてフィードバックするためだ、という説明もありました。そのためか、GPLなどのライセンスを「互恵型ライセンス」 (reciprocal license)と呼ぶ人もいます。それに対して、BSDなどのライセンスは「寛容型ライセンス」 (permissive license)と呼ぶようです。別に、ソース開示が条件に入っていないのは、寛容だからって訳では無いでしょうに。
そう思っている人達にとっては、「OSSを使っていて、その改造結果を(ソース公開という形で)フィードバックしないのは、互恵的ではない。ただ乗り(free ride)だ」と思って不満だったのでしょうね。
確かに、フィードバックを求める気持ちはわからなくはないですが、これについて、Richard Stallman氏は、GNU Emacsを出した1984年には既に過ちだったと認めていたようです。
GNU Emacs ライセンスを作るにあたって、ストールマンはかつての Emacs コミューンの非公式な主義に大きな変更を一つ加えた。かつてはコミューンメンバーに彼らが書いたらすべての変更を送るように要求したところで、 今やストールマンは、プログラムの再配布を選択したら必ずソースコードと自由を告知することのみを要求した。言い替えれば、自家用の修正を Emacs に加えただけのプログラマは、もうストールマンにソースコードの変更を送り返す必要がなかった。自由ソフトウェアの教義のめったにない変更にあたって、ス トールマンは、自由ソフトウェアの値段を切り下げることにした。どのコピーにも
free_as_in_Freedom2.0_ja.pdf (catch.jp) (111/203)
所持者がコピーをさらに開発して再配布する許可が付いている限り、ユーザー は肩越しに覗くストールマンぬきでイノベーションをすることができ、彼らが望むときにだけ彼らの修正版を再配布してよいことになった。
この変更は、初期の Emacs コミューンの社会契約のビッグブラザー的側面に自分自身満足していなかったことが原因だった、とストールマンは言う。 変更を彼に送るのは全員にとって有益だとは分かっていたが、これを要求することは不平等だと感じるようになった。「みんなにすべての変更を発表するように求めるのは間違っていました」とストールマンは言う。
「一人の特権的な開発者に変更を送るように求めるのは間違いでした。そんな集権化と一人のための特権は、全員が平等の権利を持つ社会とは調和しないんです。」
ですから、GNU GPLv1ができた1989年時点では既にフィードバックを求めるような考えはなかったはずです。しかし、この40年以上前のEmacsコミューンでの慣習が、なぜか、GPLの考え方かのように一人歩きしてしまって、「GPLはフィードバックを求めるライセンスだ」と思い込んでいる人がいまだにいらっしゃるようです。
それにも関わらず、このような、従来のGNU GPLとは基本的な考え方が違うものが、GNU AGPLv3として成立したことには、なかなか意外でした。それだけ、SaaSの抜け穴を閉じたい、そのただ乗りを許せないと思う人が多かったのでしょう。勘違いから、そう思った人も少なくない気もしますが…。
4. 『ライセンス』とは
ここで、そもそもライセンスとは、という話を確認しておきたいと思います。
OSSライセンス、というかGNUの話をするときは、自由ソフトウェアライセンスと言った方が適切ですが、これが、EULAなどの商用ソフトウェアのライセンスと同じ「ライセンス契約」であれば、「改変したら」「リモートでコンピュータネットワークを介し対話的にやりとりしたら」という条件で契約することも可能でしょうが、GPLなど自由ソフトウェアライセンスは契約ではありません。
ほとんどの自由ソフトウェアのライセンスは、著作権を元にしています。そして著作権によって課することができる要求には制限があります。
自由ソフトウェアとは? - GNUプロジェクト - フリーソフトウェアファウンデーション
GNUがこう言っていても、「著作権法を元にしているのなら、なおさら、契約と考えないといけない」と言う人がいます。ある企業の技術者から聞いたのですが、「『契約』は『守らなければならないもの』とだけ考えていた」そうです。たぶん、同じ感覚なのでしょう。本来、契約は字のごとく、(これからの)「約束を契る」わけですから二者の合意(agreement)により成立するものです。では、自由ソフトウェアのライセンス、例えば、GNU GPLは、合意を求める契約でしょうか?これについて、GNU GPLの作者であるRichard Stallman氏は、以下のように述べています。
ほとんどの自由ソフトウェアのライセンスは、著作権法と、正当な理由によりに基づいている:つまり、
Don't Let “Intellectual Property” Twist Your Ethos - GNU Project - Free Software Foundation
著作権法は、国家間で、契約法や他のありうる選択より、非常に均質である。
契約法を使わないもう一つの理由は、コピー提供前に契約へのユーザーの正式な同意を得ることをあらゆる頒布者に要求すること。のサインを最初にすることなく誰かにCDを手渡すことは、禁じられている。うんざりする!
作者が「契約法を使わない」と述べているのに、我々が契約として扱って正しく扱えるはずがありません。
元々、「ライセンス」という言葉は、「許可もしくは同意」または許諾という意味です。
ライセンス(license)はラテン語で許可もしくは同意といった意味を表す ”licentia”という言葉が起源とされる。
金子宏直. Section 1 ライセンス概論. ページ2 ビジネス法務大系Ⅰ ライセンス契約. 日本評論社.(2007).
その許諾内容について、二者が合意などすれば、「ライセンス契約」が成立するでしょうが、少なくともGPLは、本来の「ライセンス」の「許可」「許諾」の意味で使われています。
Licenses are not contracts: ライセンスは契約ではない
Enforcing the GNU GPL - GNU Project - Free Software Foundation
a license is a unilateral permission, not an obligation, ライセンスは一方的な許可であり、義務ではありません
GPLv3 - Transcript of Eben Moglen from the third international GPLv3 conference, Barcelona; 2006-06-22 - FSFE [58m 23s]
5. 法的根拠の考察
自由ソフトウェアライセンスが、契約法ではなく、著作権法に基づくならば、「著作権によって課することができる要求には制限があります」ということです。それは、「契約内容の自由の原則」のように、公序良俗に反しなければ、二者でどのような内容の合意も可能、というわけにはいかない、ということです。
第七節 権利の行使
著作権法 | 国内法令 | 著作権データベース | 公益社団法人著作権情報センター CRIC
(著作物の利用の許諾)
第六十三条 著作権者は、他人に対し、その著作物の利用を許諾することができる。
著作権者に著作物の利用の許諾権があるということは、逆に、他人が著作物を利用することを禁止しているということです。プログラムの著作物である「自由ソフトウェア」(またはOSS)も、著作権者の許諾がなければ、複製権の行使である「頒布」することができません。
第一節 通則
著作権法 | 国内法令 | 著作権データベース | 公益社団法人著作権情報センター CRIC
…
(定義)
第二条 この法律において、次の各号に掲げる用語の意義は、当該各号に定めるところによる。
…
十九 頒布 有償であるか又は無償であるかを問わず、複製物を公衆に譲渡し、又は貸与することをいい、
各国著作権法で禁止されているからこそ、それを許諾するライセンスが付けられて自由ソフトウェアは公開されているのです。ライセンスが添付されていることにより、再頒布の自由が確保されるということです。自由ソフトウェアとかオープンソースとか自称するだけでは、誰も再頒布できない、つまり、著作権侵害となるわけです。そのライセンスの許諾条件として書かれているのが、BSDライセンスなら「著作権表示」「ライセンス本文」「免責条項」などが受領者に渡ることでしょうし、GPLならば、それに加えて、バイナリ形式の場合、ソースコードが受領者に渡ることなどになるわけです。
5-1. 第13条が許諾する『利用』は翻案権か?
それでは、GNU AGPLv3の第13条が許諾する(著作物に対する)『利用』の支分権とは何でしょう?
第13条の該当部分をもう一度見てみましょう。
- リモートネットワークインタラクション、および GNU 一般公衆利用許諾書との利用
本許諾書に含まれる他の条件に関わらず、あなたが『プログラム』を改変した場合、改変したバージョンは、そのバージョンとリモートでコンピュータネットワークを介し対話的にやりとりする(あなたのソフトウェアがそのようなインタラクションをサポートしている場合)すべてのユーザに対して、ネットワークサーバから、あなたのバージョンに『対応するソース』にアクセスする手段を、無償、かつソフトウェアのコピーを円滑に行う上で標準的、慣習的に用いられる方法で提供することにより、ユーザが『対応するソース』を受け取る機会を明示的に与えなければ
なければならない。ここでいう『対応するソース』には、次の段落に従って取り込まれた、GNU 一般公衆利用許諾書のバージョン3で保護されるすべての作品も含まれる。…
agpl.ja.html (opensource.jp)
「リモートでコンピュータネットワークを介し対話的にやりとりする」行為は、何ら支分権の行使ではありません。
では、「『プログラム』を改変した」行為でしょうか?
確かに、支分権には、翻訳権・翻案権というものがあります。
(翻訳権、翻案権等)
第二十七条 著作者は、その著作物を翻訳し、編曲し、若しくは変形し、又は脚色し、映画化し、その他翻案する権利を専有する。(二次的著作物の利用に関する原著作者の権利)
著作権法 | 国内法令 | 著作権データベース | 公益社団法人著作権情報センター CRIC
第二十八条 二次的著作物の原著作物の著作者は、当該二次的著作物の利用に関し、この款に規定する権利で当該二次的著作物の著作者が有するものと同一の種類の権利を専有する。
コンピュータ・プログラムやデータベースに単なる修正増減を超える創作的な変更を加えることも翻案権の対象となり得ます。
加戸守之. 著作権法逐条講義 六訂新版. 公益社団法人 著作権情報センター. P213
しかし、この第27条の翻訳権、翻案権等は、他の支分権と少々違う扱いがされているようです。
本条は、前条までの著作物の直接的利用に関する権利とは趣を異にし、…
加戸守之. 著作権法逐条講義 六訂新版. 公益社団法人 著作権情報センター. P212
ですから、第27条の規定は、第28条と一体に読んで利用の許諾を得る必要があるわけであります。…社会的実態としても、第27条に根拠を持つ翻訳権と第28条に根拠を持つ翻訳出版権とを込みにした権利として翻訳権という用語が用いられておりますが、法律的には二重の権利構造になっているということにご注意ください。
加戸守之. 著作権法逐条講義 六訂新版. 公益社団法人 著作権情報センター. P215
ですから、素人考えのイメージですが、テレビで公衆送信権の行使を許諾したドラマでも、作者に無断で、テレビ局が脚色したドラマを放送できない、といった権利、つまり、公衆送信権や複製権などの利用の局面で付加的に有効となるような権利と考えるとわかりやすい気がします。
また、プライベートユース、「私的使用のための複製」が第30条で権利の制限がされており、第47条の六で「翻訳、翻案等による利用」も権利の制限がされています。そのため、私的使用目的外に利用した場合にしか翻訳、翻案権があまり表に出てこない印象があります。
第五款 著作権の制限
(私的使用のための複製)
第三十条 著作権の目的となつている著作物(以下この款において単に「著作物」という。)は、個人的に又は家庭内その他これに準ずる限られた範囲内において使用すること(以下「私的使用」という。)を目的とするときは、次に掲げる場合を除き、その使用する者が複製することができる。
…(翻訳、翻案等による利用)
第四十七条の六 次の各号に掲げる規定により著作物を利用することができる場合には、当該著作物について、当該規定の例により当該各号に定める方法による利用を行うことができる。一 第三十条第一項、第三十三条第一項(同条第四項において準用する場合を含む。)、第三十四条第一項、第三十五条第一項又は前条第二項 翻訳、編曲、変形又は翻案
著作権法 | 国内法令 | 著作権データベース | 公益社団法人著作権情報センター CRIC
さて、企業内での業務目的の複製は、私的使用のための複製とは言いがたいため、これは適用されませんが、「プログラムの著作物の複製物の所有者による複製等」は、第47条の三で権利制限され、第47条の六で「翻訳、翻案等による利用」も権利の制限がされています。
(プログラムの著作物の複製物の所有者による複製等)
第四十七条の三 プログラムの著作物の複製物の所有者は、自ら当該著作物を電子計算機において実行するために必要と認められる限度において、当該著作物を複製することができる。ただし、当該実行に係る複製物の使用につき、第百十三条第五項の規定が適用される場合は、この限りでない。2 前項の複製物の所有者が当該複製物(同項の規定により作成された複製物を含む。)のいずれかについて滅失以外の事由により所有権を有しなくなつた後には、その者は、当該著作権者の別段の意思表示がない限り、その他の複製物を保存してはならない。
(翻訳、翻案等による利用)
第四十七条の六 次の各号に掲げる規定により著作物を利用することができる場合には、当該著作物について、当該規定の例により当該各号に定める方法による利用を行うことができる。…
著作権法 | 国内法令 | 著作権データベース | 公益社団法人著作権情報センター CRIC
六 第四十七条の三第一項 翻案
また、米国に目を向けてみると、物の本によると、頒布されるなどして外部から確認できなければ、著作権侵害として主張は難しそうなので、外部に見える利用を伴わない翻案権の行使は問題視されないことが多そうです。
第13章 著作権侵害の認定方法
- 著作権侵害の要件と侵害認定方法
(1)著作権侵害の要件
山本隆司. アメリカ著作権法の基礎知識 第2版. 太田出版. 2008年. P192
著作権侵害訴訟においては、原告は、第1に、原告が著作物に対して著作権を保有(前述のとおり独占的使用許諾を含む)していること、第2に、被告が当該著作物を違法に複製したことを、主張・立証しなければならない。
以上のことから、GNU AGPLv3の第13条が許諾する(著作物に対する)『利用』の支分権は、翻案権では無さそうです。
また、著作権の観点ではなく、GPLの観点で見ても、翻案権を対象にしていると見るには、二点ほど不自然なところがあります。
まず、一点目です。AGPLv3は、第13条の追加条項以外は、GPLv3と全く同じです。では、GPLv3では、翻案権つまりプログラムの改編は許諾されていなかったのでしょうか?許諾されていなかったものをAGPLv3の第13条の追加条項で許諾したのかというと、そうではないでしょう。GPLv3に限らず、全ての自由ソフトウェア、OSSで改変は許諾されています。そうでなければ、自由ソフトウェア/OSSと呼べません。すでに許諾されている改変に新たに条件を課すことは可能なのかもしれませんが、不自然さは拭えません。
二点目は、GPLなどで維持しようとしている自由ソフトウェアの自由の一つが前掲したように、「改変した版を他に配布する自由 (第三の自由)。これにより、変更がコミュニティ全体にとって利益となる機会を提供できます。ソースコードへのアクセスは、この前提条件となります」というものです。この「コミュニティ全体にとって利益となる」変更の最たる物は、バグFIXやセキュリティFIXです。もっと大きな機能変更や機能追加もあり得るでしょうが、数は少なく、大元に受け入れるかどうかは微妙な問題になってきます。
ここで著作権法を再度見てみます。
(同一性保持権)
著作権法 | 国内法令 | 著作権データベース | 公益社団法人著作権情報センター CRIC
第二十条 著作者は、その著作物及びその題号の同一性を保持する権利を有し、その意に反してこれらの変更、切除その他の改変を受けないものとする。
2 前項の規定は、次の各号のいずれかに該当する改変については、適用しない。
…
三 特定の電子計算機においては実行し得ないプログラムの著作物を当該電子計算機において実行し得るようにするため、又はプログラムの著作物を電子計算機においてより効果的に実行し得るようにするために必要な改変
バグFIXやセキュリティFIXは、「プログラムの著作物を電子計算機においてより効果的に実行し得るようにするために必要な改変」でしかないことが多いかと思います。しかし、その行為は、同一性保持権も侵害しない、つまり、翻案権の行使ではありません。翻案は、以下のように見ることができるようです。
翻訳・編曲・変形・翻案の4つの法的利用行為は、いずれも二次的著作物を作成する行為、すなわち①既存の著作物(原著作物)に新たな創作性を付与する行為で、かつ、②原著作物の本質的特徴を直接感得しうるものを作成する行為である。したがって、まず、既存の著作物に新たな創作性を付与しない場合には、単なる複製や上演等、つまり、21条から26条の3に規定された法的利用行為に該当しうるにすぎない。また、既存の著作物を前提としても、それに新たな創作性を過大に付加した結果、もはやそれから原著作物の本質的特徴を直接感得しえない場合には、別の新たな創作と評価され著作権侵害にはあたらない。
島並良・上野達弘・横山久芳. 著作権法入門. 有斐閣. 2009. P153
つまり、「既存の著作物に新たな創作性を付与しない」バグFIXやセキュリティFIXを施した頒布は、「単なる複製」であり、翻案権の行使に当たらないし、大きな機能変更をして、「もはやそれから原著作物の本質的特徴を直接感得しえない場合には、別の新たな創作と評価され著作権侵害にはあたらない」という、改変が少なすぎても多すぎても該当しないという扱いが微妙な権利と言えます。この翻案権をキーに第13条を追加規定したとは、どうもしっくりきません。不自然さを感じます。
そのため、GNU AGPLv3の第13条は、「著作権に基づくのではなく、契約と勘違いした人達によって作成されたのではないだろうか?それをどうしてGNUで認めたのだろうか?」と長らく疑問でした。
5-2. 第13条が許諾する『利用』
GPLv2の都市伝説に「改変したらソース公開しなければならない」というものがありました。ですが、前述のように、改変しただけでは著作権の行使にならない場合が多く、非常に根拠に乏しい言い回しでした。もう少し別の言い方で表現すれば、「GPLのプログラムを含む二次的著作物を頒布する際には、二次的著作物全体がこの許諾書の条件、つまり、ソース開示しなければならない」と言った方が妥当ですが、これが過度に省略されて都市伝説化したのでしょう。
この誤解を解くためか、GPLv3/AGPLv3で『改変』の定義がされています。
0. 定義
agpl.ja.html (opensource.jp)
…
ある作品の「改変」(modify)とは、その作品の全体ないし一部を、『コピーライト』の許可を必要とするようなやり方で複製ないし翻案することを意味する。ただし、完全に同一なコピーを作成する場合は除く。改変の結果出来た作品は、以前の作品の「改変されたバージョン」(modified version)、または、以前の作品を「基にした」(based on)作品と呼ばれる。
「『コピーライト』の許可を必要とするようなやり方で複製ないし翻案すること」という表現で、単に改変する行為はなく、それを頒布する行為を指すことを明確にしたように見受けられます。
ここで、3章「SaaSの抜け穴」で紹介した「ただ乗り」と思うケースを思い出してみましょう。Amazoneの名前が挙がっていたように、その当初から、高価なUnixサーバに代わり、多数の安価なIAサーバにLinuxを乗せ、Webサービスに特化したチューニングを施して、業績を伸ばしてきたように見受けられていたにも関わらず、その改変内容が出てこないことに不満を持たれていたようです。サーバが多いほど、ただ乗り感を強く感じたのかもしれません。そうすると、この第13条で許諾する著作権の『利用』は、今までの自由ソフトウェアやOSSの多くの著作権者が黙認していた企業内での社内頒布を限定的に黙認せずに条件付けて許諾したと考えられないでしょうか。
その黙認していることを示す解説がIPA(情報処理推進機構)発行の『GPLv3逐次解説』に、SFLC具体的にはEben Moglen教授へのヒアリングの内容として記載されています。
2.2.6. 第6 パラグラフ
GPLv3 逐条解説(第1 版). 独立行政法人情報処理推進機構. 2010 年5 月26 日 GPLv3_cmtr_v1_r1.79.pdf. P26-27(38-39/258)
本パラグラフは、「プロパゲート」(propagate)について定義している。
プロパゲートは、次パラグラフの「コンベイ」とともに、GPLv3 で新たに導入された概念であり、GPLv3 を理解する上で重要な用語である。
「プロパゲート」とは、準拠法国[29]の著作権法上、権利者の許諾を得ないでその行為をした場合に、権利侵害に基づく直接又は間接の責任を負うこととなる行為を指す。わが国著作権法でいえば、著作権法21 条〜28 条の支分権や同法18 条〜20 条の著作者人格権に関する行為を指すと解される。
…
重要な例外として、著作物をコンピュータ上で実行する行為と内部的な改変行為は「プロパゲート」に含まれない。そのため、GPLv3 プログラムの使用形態が実行と内部的な改変のみに限られるのであれば、受領者はGPLv3 が定めるソースコードの配付義務や特許非係争義務などの義務を負うことはない。SFLC によれば、ここでいう「内部的」(private)とは、家庭内での個人的な行為だけでなく、企業内、企業グループ内、あるいは公共団体等の組織内での行為も含む。
したがって、企業が対象著作物を入手(受領)して、それをそのままあるいは改変して自社内で使用する行為は、それがインターネット上でサービスを提供するようなシステムであっても、対象著作物を利用者がダウンロードできるようになっていなければ、プロパゲートに該当せず、GPLv3 の定める各種の義務を負うことなく対象著作物を使用することができることになる。
また、SFLC によれば、同一企業グループ間での行為も「内部的」とみなされる。例えば、グループ内のシステム開発子会社がGPLv3 プログラムを改変したソフトウェアを開発し、それを親会社やグループ内の他の企業に配付して、グループ企業が使用するような場合も、「内部的」な改変に当たり、プロパゲートに該当しない。政府の複数の省庁間でのプログラムの授受も同様に「内部的」な行為であり、プロパゲートに該当しない。
この「企業内、企業グループ内、あるいは公共団体等の組織内での」頒布行為を、「改変した上で、リモートでコンピュータネットワークを介し対話的にやりとりする」プログラムに限って黙認せず、条件付で許諾したのがAGPLv3の第13条と解すると、それがAGPLv3が追加的に著作権行使を許諾する『利用』と考えるのが妥当ではないかと考えます。
6. さいごに
かなり複雑な考察で、少々無理のある論理と思いますが、GNU AGPLv3はそこを無理に探し出して生み出したライセンスなのかもしれません。ただ、自由ソフトウェアの自由を阻害する行為を防ごうとしたものとは考えにくいので、従来の自由ソフトウェアライセンス/OSSライセンスから見れば、かなり異質かと思います。
AGPLの命名の元になったAfferoは、Eラーニングシステムを販売し、AGPLv1でも提供していた企業ですので、AGPLv3も企業製の商用プログラムがデュアルライセンスで提供される形で使われることが多いようです。
そういう現状から、「AGPLv3のプログラムは、商用ライセンスのプログラムのお試し版として、提供されているに過ぎない、本番運用ではお試し版ではなく商用版を購入して使用する」という位置づけで捉えた方が良さそうに個人的には思います。
2024/07/31 姉崎章博