052.2 レッスン 1

リチャード・ストールマンは、MITの開発者であった1983年に、「自由な」オペレーティングシステム（OS）を開発しようと、GNUプロジェクト を開始しました。このプロジェクトで開発したコードを営利企業に持っていかれて不自由にされてしまわないように、法的に保護しなければならないことがすぐに明らかになりました。

そこで、ストールマンは、1985年に、フリーソフトウェア財団（Free Sofware Foundation） を創立しました。「フリーソフトウェアファウンデーション(FSF)は、コンピュータのユーザの自由を促進する世界的なミッションを持つ非営利団体です。わたしたちは、すべてのソフトウェアユーザの権利を守ります。」とFSFのWebサイト（ 日本語版 ）に書かれています。

適用される法律（特に著作権法）を尊重しつつ、自由の概念を法律上明確に位置づけることが、このミッションを達成するための鍵になります。この試みが1989年に GPLv1（GNU General Public License） として結実しました。このライセンスおよびストールマンが書いたたくさんの記事（1992年に書かれた「自由ソフトウェアとは?」など）により、自由ソフトウェア開発者（自由ソフトウェア運動の担い手）の目標と価値観が明らかになりました。

「自由ソフトウェアとは?」 でストールマンが定式化した「四つの基本的な自由」が、今なお自由ソフトウェア運動の核になっています。当初は3項目でしたが、後に最も基本的と考えられる0項が追加されました。

制約を前面に押し出す商用製品のライセンスとは異なり、フリーソフトウェアはユーザーと開発者の自由を最大化することを目標にしています。

GPLの前文では次のように要約されています（訳注：GPLは、八田真行氏によって 「GNU 一般公衆利用許諾書」 というタイトルで日本語に翻訳されています）。

GPLライセンスのソフトウェアは、（ソースコードがオープンにされていて入手可能なので）制約なしに、使用、頒布、改変でき、改変版の頒布もできます。料金を徴収してソフトウェアを販売することもできます（ 日本語版「自由ソフトウェアの販売」 ）。

ここまで自由だとしたら、ライセンスは例えばプロプライエタリな製品に組み込まれることなどから、ソフトウェアをどのように守るのでしょうか。

ここで先ほど申し上げたコピーレフト原則の出番となります。「コピーレフト」という言葉は用いられていませんが、GPLv1からこの原則が盛り込まれています。（訳注： GPLv2 の当該箇所は、GPLv1とまったく同じです。）

つまり、こうした自由は、同じ自由を維持する限り認められるということです。

コピーレフトは、自由を保証するだけでなく、ユーザーがほかの人にも自由を与えることを要求します。これを実現するために、GPLv1以来のコピーレフトライセンスのソフトウェアは、同じ条件で、つまり同じライセンスで公開される限りにおいて、改変や再頒布が許されると規定されています。

自由ソフトウェアの理念、すなわちソフトウェアの共同使用と（改変版などの）さらなる共同開発は、（ソフトウェアを独占的に販売したいといった）個々人が抱くかもしれない願望に優先します。自由を享受する者は、他者にも自由を与えなければなりません。コピーレフトライセンスは、それゆえ、互恵的だと言われることがあります。 GPLv2 こうしたソフトウェアライセンスに対するまったく新しいアプローチは、GPLv1の段階で法的に問題なく適用できることが証明されています。そのため、現代のIT市場が発展してきたこの約40年の間で、大きな改訂は2回しか行われていません。

高速なインターネットへの常時接続が一般的にになるにつれ、ソフトウェアを ASP（Application Service Provider） ベンダーのサーバーにだけインストールして、ユーザーはインターネット越しにサービスを利用する形態が増えてきました。このようなサービスは SaaS（Software as a Service） と呼ばれます。

このような場合に、（サービス提供者がおそらくは改変したであろう）ソースコードを入手可能にしなければならないのかどうかが、GPLv2では不明確でした。GPLv3は、第13条で、FSFが2007年に発行した別のライセンスである GNU AGPLv3 （日本語参考訳） を参照することで、この ASPの抜け穴 を塞ぎました。このライセンスの名前は、先行した2バージョンのAGPLライセンスを作成・公表していたAffero社に由来しています。

AGPLv3は基本的にGPLv3に対応しており、第13条「リモートネットワークインタラクション」でASP問題について明確に規定しています。さらに、GPLv3とAGPLv3ライセンスを制約なしに結合させることができることも明確に述べられています。

要するに、AGPLは、ローカルマシンにインストールせずネットワーク越しにサービスを利用する形態のソフトウェアにコピーレフトを適用することで、GPLを補完しているのです。

フリーソフトウェアは、ほかの人の作品をスタート点として開発を進めることで発展していきます。ほかの人が書いたコードを統合、改変、共有します。改変したコードと新しく書いたコードが全部同じライセンスなら、法的なややこしい問題は生じません。例えば全部GPLv3なら、ソフトウェア全体もGPLv3にするというように、同じライセンスで公開します。

ソフトウェアが異なるライセンスの部品から構成されていると話がややこしくなります。考えなければならないことがいくつかあります。

フリーソフトウェアはさまざまな状況下で改造されます。ちょっとしたエラーの解決から、数百万行に及ぶ複雑なコードを追加するプロジェクトまであります。規模に関わらず、ライセンスに関しては、結合 と 派生 を区別します。結合は改変を伴いませんが、派生は改変を伴います。

例えば、ある機能がプロジェクトAに必要だとしましょう。その機能をゼロから開発せず、ちょうどその機能を備えているプロジェクトBのコードを結合させるのは理に適っています。プロジェクトBのコードを変更せずにそのままプロジェクトAに追加します。これが結合です。AとBが同じコピーレフトライセンスであれば、全体を同じライセンスにすれば問題ありません。

AとBが異なるコピーレフトライセンスなら注意が必要です。AとBが結合して一つの作品になっているとしたら、どのライセンスにすればよいでしょうか。あるいは、AとBを別々のままに保つことでライセンスの衝突を避けられるでしょうか。

プロジェクトAが、プロジェクトBのコードを統合してBの機能を利用する派生作品の場合はさらにやっかいです。この場合は新しい派生作品が生み出され、別々のままに保つことはできません。

コピーレフトは派生作品に影響を及ぼします。例えば、AがGPLv3ライセンスなら、互恵性の原則から、新しく生み出された派生作品もまたGPLv3ライセンスにしなくてはなりません。しかし、Bが別のライセンスだったらどうなるでしょうか。BがコピーレフトライセンスでGPLv3と互換性があるかもしれませんし、コピーレフトライセンスではないけれどもライセンスを変更して公開できるかもしれません。あるいは、AとBのライセンスには互換性がないかもしれません。

あらゆる組み合わせとその結果をリストアップすることがこのレッスンの目的ではありません。ここでの主眼は、異なるライセンスを組み合わせることから生じる問題の複雑さを指摘することです。

技術的には、ソフトウェアの各部（先ほどの例で言うところのAとB）がどのように協働しているかをまず明らかにします。各部を切り離すことができるのか、それともどちらかに帰属するのかはっきりと区別できない実行プロセスがあるのかということです。

法的には、AとBのライセンスの関係が問題になります。互換性があるのか、一部に互換性があるのか、一方向だけに互換性があるのか、ライセンスの変更が可能かといったことです。

ここでは問題の複雑さを指摘するにとどめ、解決法は示しません。解決には法的な知識が求められます。したがって、特に派生作品のライセンスをどうするかは、開発の初期に法的な助言を受けて慎重に 決定するのが望ましいことになります。

コピーレフト、特にGPLv2とGPLv3は、過去数十年にわたり極めて堅固に機能してきました。しかし、技術的な要件の変化により、FSFは何度かライセンスの調整を迫られました。一つは先に触れたAGPLで、もう一つはLGPL（GNU Lesser General Public License）です。以下ではLGPLについて述べます。