GPL再考

注意・免責事項
本記事は情報の提供のみを目的としています。
本記事の内容を実行・適用・運用したことで何が起きようとも、それは実行・適用・運用した人自身の責任であり、著者や関係者はいかなる責任も負いません。

誤り、ご指摘等がある場合は、コメント欄にコメントいただけると幸いです。

GPLライセンスの基礎

オープンソースソフトウェアの世界では、多様なライセンスが存在しますが、中でもGeneral Public License(GPL)は重要な存在です。

GPLとは？

アメリカ合衆国のプログラマーであったリチャード・ストールマンは、1983年にGNUプロジェクトを、その推進組織としてFree Software Foundation（FSF）を1985年に設立し、フリーソフトウェア運動を提唱し始めました。GPLは、1989年にリチャード・ストールマンらによって、GNUプロジェクトのソフトウェアの配布を目的に作られたライセンスです。

GPLはソフトウェアの自由な改変、および再配布を保証することを目的としたライセンスです。このライセンスの下で配布されるソフトウェアは、誰もがソースコードにアクセスし、それを自由に変更し、変更した形で再配布することができます。

GPLの重要な特徴は以下の通りです。

• ソースコードの提供
  GPLの下で配布されるソフトウェアは、そのソースコードも一緒に提供されなければなりません。これにより、ユーザーはプログラムを自由に改変することができます。
• コピーレフト
  GPLのソフトウェアを再配布、改変または新しく作成するプログラムに含めて配布する場合、GPL（またはGPLと両立するライセンス）の下で公開することが義務付けられています。これにより、ソフトウェアの改良が共有され、コミュニティ全体が恩恵を受けることができます。

他のライセンスとの大きな違い

MITライセンスやBSDライセンスのような「パーミッシブ・ライセンス」は、改変または新しく作成するプログラムに含めて配布する場合、原著作者のソースコードを同じライセンスで公開する必要はありません。

ライセンスは著作権の許諾である

GPLを含むオープンソースライセンスは、根本的には著作権法に基づいた許諾と考えられています¹。著作権法により、ソフトウェアの作成者は自動的にそのソースコードの著作権を保持します。これにより、作成者は他人がそのソースコードを複製したり、改変して配布したりすることを制限する権利を有します。オープンソースライセンスは、これらの権利の一部を利用者に許諾することで、ソフトウェアの自由な改変および配布を可能にします。 GPLは、このような許諾を通じて、ソフトウェアが自由かつ公正に利用されることを促進することを目的としています。

プログラムの結合

以上はプログラマであれば知っている方も多いと思います。ここからはもう少しGPLの理解に踏み込んでみます。

まず、GPLの感染についてです。あるソフトウェアがGPLで提供されている場合、そのソフトウェアを改変したり、そのソフトウェアを「含む」新しいソフトウェアを作成したりすると、その改変版や新しいソフトウェアを配布する際には、それらもGPLの下で配布する必要があります。GPLのこの特性が、GPLでないソフトウェアにGPLの条件の適用を強制させるという点で「感染」という言葉が使われます（この表現は否定的なニュアンスを含むことがあるため、好ましくないとされることがあります）。

自社で開発しているソフトウェアがGPL感染した場合、それを配布しようとするとソースコードを公開しなければなりません。ソースコードの公開に伴い、企業の技術的優位性を失う可能性があり、ビジネス的に不利になる場合があります。

そこで気になるのは、GPLのソフトウェアを「含めて」新しいソフトウェアを作成したとき、どのような形態だとGPL感染するのかということです。つまり、「含める」とはどういうことなのか明らかにしたくなります。

GPLのFAQでは、GPLのソフトウェアと自分が開発したプログラムに含めてひとまとまりにするようなことを「結合(combined)」という用語で説明しています。FAQの「「集積物」とそのほかの種類の「改変されたバージョン」の違いは何ですか?（What is the difference between an “aggregate” and other kinds of “modified versions”?）」を参照すると、次のように記載されています。

二つの別々のプログラムと二つの部分の一つのプログラムを分ける線はどこにあるでしょうか? これは法的な問題であり、最終的には裁判官が決めることです。わたしたちは、適切な基準はコミュニケーションのメカニズム(exec、パイプ、rpc、共有アドレス空間での関数呼び出し、など)とコミュニケーションのセマンティクス(どのような種の情報が相互交換されるか)の両方によると考えています。

（日本語訳から抜粋）

つまり、どのような形態だと自分のソフトウェアにGPLのソフトウェアを「含む」のかどうかについては、最終的には裁判で裁判官が判断するということです。なんてこった。 このため、事前に自分のソフトウェアがGPLソフトウェアを「含んで」いるのか完全には判別できません。

しかしながら、一定の基準についてはGPLのFAQに、FSFの見解が記載されています。以下はFAQから関係しそうな箇所を抜粋しました（日本語訳から抜粋）。

GPLソフトウェアを「含む」ケース

• モジュールが同じ実行ファイルに含まれている場合、それらは言うまでもなく一つのプログラムに結合されています。(#MereAggregation)
• モジュールが共有アドレス空間でいっしょにリンクされて実行されるよう設計されているならば、それらが一つのプログラムに結合されているのはほぼ間違いないでしょう。(#MereAggregation)
• GPLの及ぶ作品に静的もしくは動的にほかのモジュールとリンクすることは、GPLの及ぶ作品をもとにして結合著作物を作成することです。(#GPLStaticVsDynamic)
• メイン・プログラムがforkやexecでプラグインを呼び出し、複雑なデータ構造を共有することで密接な通信をしたり、複雑なデータ構造をやりとりする場合、単一の結合されたプログラムとなるでしょう。(#GPLPlugins)
• 共有メモリを使い、複雑なデータ構造で通信することは、動的なリンクとほとんど同等です。(#GPLPlugins)
• ライブラリにリンクするソフトウェアモジュールはGPLと両立するさまざまなライセンスであることが可能ですが、全体としての作品はGPLでライセンスされねばなりません。(#IfLibraryIsGPL)

GPLソフトウェアを「含まない」ケース

• パイプ、ソケット、コマンドライン引数は通常二つの分離したプログラムの間で使われるコミュニケーションメカニズムです。ですからそれらがコミュニケーションのために使われるときには、モジュールは通常別々のプログラムです。しかしコミュニケーションのセマンティクスが親密であったり、複雑な内部データ構造を交換したりする場合は、それらも二つの部分がより大規模なプログラムに結合されていると考える基準となりうるでしょう。(#MereAggregation)
• メイン・プログラムが単純なforkやexecを使ってプラグインを呼び出し、密接な通信を確立しないのであれば、プラグインは別のプログラムと言えるでしょう。(#GPLPlugins)
• インストーラとインストールされるファイルは別々の著作物です。結果として、GPLの条項はインストレーション・ソフトウェアには適用されません。(#GPLCompatInstaller)

動的リンクの判例: 任天堂 vs Galoob

Stack Exchange に面白い見解があったので紹介します。

FSFの見解では、プログラムの動的リンクもGPL感染します。しかし、任天堂 vs GaloobのGame Genieに関する訴訟判例は、プログラムの動的リンクがGPLに感染しないのではないかと考えさせる判例になっています。

この訴訟は簡単にまとめると、Galoob社が作成し販売したGame Genieというゲームを改変するツール（日本で有名なもので例えるとプロアクション・リプレイのようなもの）に対し、任天堂が著作権侵害を根拠に訴えたものです。ポイントは、Game Genieはユーザーにゲームを改変させるツールであって、Galoob社がゲームを改変している訳ではなく、二次的著作物もないため著作権侵害には該当しないという点です。

この判例を流用すると、次のようにGPL感染を回避する配布方法を考えることができます。

1. GPLソフトウェアを動的リンクとしてリンクするように自分のソフトウェアを開発し、自分が開発したソフトウェア部分のみをGPLでないライセンスで配布。
2. GPLソフトウェアを別途ダウンロードさせ、実行時に動的リンクさせて機能を使用する。

上記のようにすることで、ソフトウェア作成者はGPLソフトウェアの再配布および二次的著作物の配布をしていないことになり、そもそも著作権を侵害しません。したがって、GPLによる著作権の許諾も不要であり、GPL感染を回避することができるように思えます。

上記の考え方は一般には支持されない考え方ですが、日本の著作権法としては筋が通る部分もあると思いますので、裁判になれば争点の一つになるのではないでしょうか。

ちなみに、GNU Lesser General Public License (LGPL)というライセンスがあり、このライセンスの下ではライブラリを動的リンクする場合に限り、ソフトウェアのソースコード公開義務が発生しません。

GPLと契約: SFC vs VIZIO

動的リンクの判例で重要な点として、GPLがライセンス（著作権の許諾）なのか、契約なのかという点もあります。ライセンスの場合、著作権に根拠があるため、著作権の侵害が争点になると考えられます。GPLがライセンスの場合、ソフトウェア作成者がライセンスに違反したとき、著作権法による制限（配布の差し止めや損害賠償）以上の罰則的事項を強制することができません（例えばGPL違反した作成者にソースコードの開示を要求する等）。一方で、GPLが契約と解釈される場合は、GPL条文に書かれていることが債務となるため、強制力があります。

オープンソースソフトウェアを推進し、フリーソフトウェアのGPLを擁護する非営利団体Software Freedom Conservancy（SFC）は、テレビメーカーVIZIOが「Linux」ベースの「SmartCast」OSでGPLを濫用したとして、同社を提訴しました。SFCは、対VIZIO訴訟をカリフォルニア州オレンジカウンティの上級裁判所に差し戻すことを求める申し立てで勝利しました。米連邦地方裁判所のJosephine L. Staton判事による裁定では、Staton判事はSFCの主張に同意し、GPLは著作権ライセンスと契約の両方として機能すると判断しました。

SFC vs VIZIO の訴訟では、GPLが契約であるという側面も肯定されました。GPLが契約であれば、契約書が重要になってきますので、GPLの条文本文と公開されているFAQあたりが争う際の根拠になってくるのではないでしょうか。著作権に基づかない請求も通るため、動的リンクの判例は流用されず、契約として動的リンクもGPLの適用を強制されると考えられるのではないでしょうか。

以下の記事でもGPLは契約として捉えられるという話があります。

岡村氏は、すべての条項を著作権法理だけで説明するには無理があるとしながらも「著作権侵害成立の回避をGPL適用のトリガとするのであれば、そもそもGPLは著作権法理を中心に構成すべきではないか」と話す。また、FSFの弁護士であるエベン・モグレン氏が「（GPLは）契約ではなくライセンスである」と明言していることを挙げ、GPLは「各条項の順守を条件とする一方的な許諾宣言」であると見解を述べている。
　「とはいえ、日本では著作者人格権や公衆送信権などとの整合性も考えれば、ライセンスであるという考えはしっくりこないため、（GPLは）契約として捉えられることになるだろう」（岡村氏）

GPL回避戦略

GPLソフトウェアを自分のソフトウェアまたはシステムに組み込みつつ、GPL感染を回避する方法について考えてみます。

1. 別ライセンスでのリリースを依頼
   GPLソフトウェアの作者と交渉し、別ライセンスを付与したバージョンをリリースしてもらうことが考えられます。例えば、作者と交渉し、相応のライセンス料を支払うことで、配布時にソースコードを公開しない、かつコピーレフトでないライセンスを適用してもらうことができるかもしれません。しかしながら、権利者が複数いる場合、別ライセンスバージョンのリリースは全員の合意が必要になるので、調整が難しいかもしれません。また、作者がGPLの精神である「フリー」に重きを置いている場合は、交渉は難しいかもしれません。（@tenmyoさんにコメント頂いた点を反映しました）

2. 代替ソフトウェアの選択
   GPLソフトウェアの使用を避け、代わりに同様の機能を有する、異なるライセンスのソフトウェアを使用します。

3. ソフトウェアの分離
   ソフトウェアのアーキテクチャを工夫し、自分が開発したプログラムからGPLのコンポーネントをプラグイン等として分離することも一つの戦略です。この方法では、GPLコンポーネントと商用コンポーネントを独立して動作させ、ソフトウェアの「結合」を避けることで、GPL感染を防ぐことが可能になります。

4. ソフトウェアのサービス化
   GPLライセンスの要件は、ソフトウェアが「配布」された場合にのみ適用されます。したがって、ソフトウェアをサービスとして提供し（例えば、Software as a Service(SaaS)モデル）、エンドユーザーに直接ソフトウェアを配布しない場合、GPLのソースコード公開義務から逃れることができます。
   ちなみに、このようなサービスとしての提供に対してもソースコード公開を要求するライセンスとして、Affero General Public License (AGPL)が存在します。

上記のような回避戦略を取っても、提訴された場合は最終的に裁判官の判断になるので、完全にリスクを排除することはできません。しかし、なるべくリスクを回避するような行動をとることはできると考えられます。

1. 一般に共通した考えに従い、誠実に行動する
   GPLに関して、一般的に受け入れられている利用形態に従う。利用形態について、不審に思われる使い方をしない。適切にソースコードを公開する等誠実に対応する。

2. 和解する
   問題発生時には当該権利者と速やかに話し合い、なるべく和解で解決する。

3. 戦うロジックを用意する
   最悪訴訟で法廷で争うことになった時のために、システムアーキテクチャやソフトウェアの非公開の判断の根拠になった事例やロジック、議論の経緯等を残しておく。

所感・疑問等

• GPLのFAQ的には、PythonではimportしただけでGPL感染すると思われる。
• ソフトウェアを分離する具体的なアーキテクチャとして主要なものは、コマンドラインアプリケーションにしてサブプロセスとして呼び出す、プロセス化してプロセス間通信する、Web API化してHTTP通信するといったところだろうか。

補遺 Creative Commonsについて

GPLと似た理念を共有するクリエイティブコモンズ（Creative Commons, CC）ライセンスは、特に「表示 - 継承」(CC BY-SA) ライセンスです。GPLはソフトウェアに関するもので、ソースコードの自由な共有と改変を促進します。それに対し、クリエイティブコモンズライセンスは、著作物（文章、音楽、写真など）の使用に関するもの で、著作物の自由な共有と、条件に応じた改変や再配布を可能にします。

「表示 - 継承」(CC BY-SA) ライセンスは、GPLと同様に、作品を共有（コピーおよび配布）する自由を与えるとともに、作品が改変された場合、その改変された新しい作品も同じライセンス条項の下で配布することを要求します。これは、GPLがソフトウェアの自由な改変と再配布を保証するのと同じ精神です。

Creative Commonsは著作権法による制限を許諾するライセンスとして活用されることを目的としていると記載されています。

ライセンスする方のための留意事項：
クリエイティブ・コモンズのパブリック・ライセンスは、著作権その他一定の権利により制限されている方法によるマテリアルの利用を公衆に対して許諾する権限を持つ方によって使われることを意図しています。クリエイティブ・コモンズのライセンスは取消すことができません。ライセンスする方は、自分が選択するライセンスを適用する前に、その条項を読み、理解するべきです。また、ライセンスする方は、公衆が期待通りにマテリアルを再利用できるようにするために、本ライセンスを適用する前に、必要となる一切の権利を取得・処理するべきです。ライセンスする方は、本ライセンスの対象とならないマテリアルを明示するべきです。これはクリエイティブ・コモンズ・ライセンスが付与された他のマテリアル、または著作権法上の例外や権利制限に基づいて利用されているマテリアルも含みます。 ライセンスする方のためのより詳細な留意事項はこちらをご覧ください。
引用元：https://creativecommons.org/licenses/by/4.0/legalcode.ja

ソースコードと他の著作物は性質が異なるので、Creative Commonsよりもソースコード用のライセンスを使用したほうが適切です。

ソフトウェアにCCライセンスを付けることはできますか？
可能ですが、お勧めはできません。

CCライセンスは、ソースコードとオブジェクトコードについては、適用の対象として考慮していないからです。Free Software Foundationによって公開されているライセンス（日本語参考訳）や、Open Source Initiativeがリストに挙げているライセンス（日本語参考訳）等、ソフトウェアに適したライセンスが既に他にありますので、そちらのご利用をご検討ください。これらのライセンスは、CCライセンスと異なり、ソフトウェア専用のライセンスとして設計されています。

クリエイティブ・コモンズは法律に関する専門的な知識がなくても簡単に理解することができるコモンズ証（例：CC-BY）と、コンピュータが読み取るメタデータを使って、いくつかのフリー・ソフトウェアやオープン・ソフトウェアのライセンスを取り込んでいます。

例としては、CC-GNU GPL（コモンズ証）、CC-GNU LGPL（コモンズ証）、 CC-BSD（コモンズ証）などです。これらのライセンスを使えば、既に完成されているこれらのソフトウェア・ライセンスを使いつつ、CCライセンスと同じように、人が理解しやすいライセンスの解説（コモンズ証）とコンピュータが読み取るメタデータを表示することができます。

ただし、注意していただきたいのは、クリエイティブ・コモンズは、これらのソフトウェア・ライセンスの代替ライセンスを提供しているわけではありません。単に、元の許諾書と共に人とコンピュータのどちらもが読める説明のあるライセンスを合わせただけです。
引用元：https://creativecommons.jp/faq/

Cyber Agent が2023年5月に日本語LLM（大規模言語モデル）を一般公開しました。 このモデルはCC BY-SA 4.0ライセンスで配布されています。したがってこのモデルもコピーレフト的なライセンスになっています。

Creative Commonsは著作物の許諾なので、配布したソースコードの利用は制限できます。
しかし、日本の著作権的には、モデルのweightは著作物とみなされない可能性が高いので、モデルのweightにはCreative Commonsは適用されないように思わます。これらについて、法務部がどのように検討していたのかは気になるところです。

以上

1. 少なくともGPLに関してはGPLがライセンスであり、契約でないことをFSFの顧問弁護士であるエベン・モグレン氏が明言しているようです。 ↩