アートワークとフリーソフトウェアのライセンス問題
この問題のポイントは、上記に挙げたような非ソフトウェアであるアートワークが、フリーソフトウェアであるアプリケーション/オペレーティングシステムの中で一風変わった立場にあることだ。アートワークはコードではないが、システムの中に密に統合されている。アートワークの作者はアートワークを独立した作品として作成することが多いが、そのようなアートワークは、便宜上、ソフトウェアのパッケージやディストリビューション（その多くがFSFのGPL（GNU一般公衆利用許諾契約書）の下にある）にバンドルされている。
クリエイティブ・コモンズのライセンスの種類
CCには、アーティストにとって魅力的である、非ソフトウェアの作品のための様々なライセンスがある。CCライセンスは、アートワークの作者だけでなくその他のアーティストにも利用されていて、Flickrのようなソーシャルネットワークサイトのツールにも統合され利用されている。CCライセンスは、「上演」、「複製」、「翻案」といったしかるべき用語を用いて、アーティストが重視する事柄を明示的に取り扱っている。
CCでは現在、6つのライセンスが定められている。それらのライセンスには共通する条項もあるが、表示/非営利/改変禁止/継承という4つの要素を含むか含まないかという点でそれぞれ異なっている。
数学が得意な人であれば、4つの要素の組合わせには2の4乗＝16通りがあることに気付くだろう。したがって明らかに、すべての組み合わせが扱われているわけではない。具体的に言うと、まず現在のライセンスはどれも「表示」要素を含んでいる。また「改変禁止」要素と「継承」要素の規定内容が重複しているため「表示-改変禁止-継承」というライセンスや「表示-非営利-改変禁止-継承」というライセンスはない。
現在の6つのライセンスは以下の通りだ。
- 表示-非営利-改変禁止（CC-BY-NC-ND）
- 表示-非営利-継承（CC-BY-NC-SA）
- 表示-非営利（CC-BY-NC）
- 表示-改変禁止（CC-BY-ND）
- 表示-継承（CC-BY-SA）
- 表示（CC-BY）
CCライセンスの改訂はFSFのライセンスの改訂よりもずっと頻繁に行なわれるので、ややこしい状況になっている。CCライセンスバージョン2.0では、CCライセンス作品から派生した作品に対して、元のライセンスの、より新しいバージョンを使用してもよいということを規定した条項が導入された。またバージョン2.5では、「表示」の規定に複数の変更が加えられた。なお現在のCCライセンスはバージョン3.0で、2007年2月にリリースされたものだ。
さらにややこしいことに、CCライセンスの各バージョンについて、様々な司法管轄区域用の異なるバージョンが存在する。これらのバージョンの違いは使用言語だけではなく、扱っている権利や責任についての実質的な変更点もある。
例えばヨーロッパの司法管轄区ではCCライセンスに著作者人格権条項が含まれている。つまり、作品の派生物によって自分の名誉や評判が傷付けられていると作品の原著作者が感じた場合には、著作者人格権条項によって、派生物から自分のクレジットを削除することを要求したり、ライセンスを打ち切ったりする権利が原著作者に与えられる。一方、米国やカナダの司法管轄区では、CCライセンスにそのような条項は含まれていない。
CCライセンスとGPL
幸いにも、GPLソフトウェアと組み合わせることを許可するCCライセンスを選ぶのであれば、選択肢はずっと少なくなる。
「非営利」要素と「改変禁止」要素はどちらもFSFのフリーソフトウェアの定義と相容れないため、「非営利」と「改変禁止」のどちらかを含むライセンスにはGPLとの互換性がない。
「非営利」要素は、ライセンスされた作品を商用目的で使用するユーザの権利を制限するので、フリーソフトウェアの定義の「第0の自由」、すなわち、目的を問わずプログラムを実行する自由と矛盾する。また「改変禁止」要素は、ライセンスされた作品を変更するユーザの権利を制限するので、「第1の自由」（「必要に応じて修正を加え」る自由）と「第3の自由」（「プログラムを改良し、コミュニティ全体がその恩恵を受けられるようあなたの改良点を公衆に発表する自由」）に矛盾する。
残るライセンスは「表示-継承」（CC-BY-SA）と「表示」（CC-BY）で、フリーソフトウェアの定義を満たす要素だけを使用している。しかしGPL互換であるためには、ライセンスはコピーレフトライセンスである必要もある――つまり、作品が一度一般に公開された後に、再び非フリーソフトになることがないということを保証しなければならない。「表示」ライセンスにはそのような規定はないため、コピーレフトではなく、GPLとは非互換となっている。
以上の結果、名目上は要素がフリーソフトウェアの定義とコピーレフトの定義を満たしている、「表示-継承」（CC-BY-SA）だけが残ることになる。そして実際に、kde-look.org、gnome-look.org、DeviantArtのようなアイコン/壁紙サイトや、themes.wordpress.net、Internet Archive、Open Clip Art Libraryのような様々なデジタルレポジトリが、「表示-継承」（CC-BY-SA）ライセンスを選んでいる。ところがFSFは、「表示-継承」（CC-BY-SA）ライセンスもGPL非互換であると主張している。
「表示-継承」（CC-BY-SA）ライセンスがGPL互換ではない理由
FSFのライセンスのページには「（CC-BY-SA）はGNU GPLと非互換のため、ソフトウェアや文書に対して使用しないようにして下さい…」としか書かれていなかったので、CCとFSFに非互換性の詳細について尋ねてみた。
FSFのライセンス担当エンジニアであるBrett Smith氏によると、CC-BY-SAのコンポーネントとGPLのコンポーネントとを組み合わせて単一の作品にすることを妨げる問題点がいくつかあるのだという。「おそらく最も分かりやすい問題点は、どちらもコピーレフトのライセンスであるということだ。つまりどちらのライセンスも作品の全体をそのライセンス規定の下にリリースすることを要求しているので、両方を満たすことはどうやってもできない」。
CC臨時最高顧問弁護士のThinh Nguyen氏も同じ意見だが、さらに、CC-BY-SAバージョン3.0に追加された新たな「互換性」条項についても指摘した。その第4条項 (b)(iv) では、CC-BY-SAライセンス作品の翻案が「Creative Commons Compatible License（クリエイティブ・コモンズ互換ライセンス）」の下にあるのであれば、その配布や公衆の面前での上演を許可するということが規定されている。CCバージョン3.0のリリースアナウンスによると、そのような互換ライセンスのリストがCCのウェブサイト上に掲載される予定となっているが、現時点ではまだ認定されたライセンスはないようだ。
Nguyen氏は、CCがクリエイティブ・コモンズ互換としていくつかのライセンスを認定しようとしていることは事実だが、特定のライセンスについての詳細を述べることはできないとした。一方Smith氏はFSFとCCがGNU FDL（フリー文書利用許諾契約書）の認定を検討していることを認めたが、GPLについてのそのような議論については聞いたことがないとした。
Smith氏は、コピーレフトとの衝突のほかにも、CC-BY-SAにはGPLとは相容れない細かい点がいくつかあると考えている。「例えばCC-BY-SA 3.0の第4条項 (a) には、作品が翻案されたり作品集に含められたりした場合に、作者がクレジットの削除を要求することができることを規定している。GPLにはそのような規定はないので、GPLの作品に対してこのような条件を科すことは、『あなたは本許諾書の下で授与された、あるいは確約された権利の行使に対して、本許諾書が規定する以上のさらなる権利制限を課してはならない』とする（GPLの）第10条項を違反することになるだろう」。
また著作者人格権のある司法管轄区においては、CC-BY-SA 3.0の「著作者人格権」条項も、GPLの第10条項と相容れない制限だ。しかしSmith氏は、この条項は「著作者人格権」が法律として既に成立している地域のバージョンのライセンスにだけ存在するため、本質的な問題ではないとした。「第4条項 (d) は、EUの大部分など特定の司法管轄区内で存在する『著作者人格権』という概念を反映させるためのものだ。詳細な点まで精通しているわけではないがその基本的な考え方を説明すると、作品を特定の形で使用する権利を与えられたとしても、明らかに作品の原作者に対してダメージを与えるような形でその権利を行使することはできないということだ」。
「これらのことが互換性の判断とどう関係するのかというと、法律で決められていることを規定しているだけの条項を持つライセンスを今までGPL非互換だとはFSFがみなしてこなかったということがある。例えばいくつかのフリーソフトウェアライセンスには『このライセンスは、ライセンサーの商品名、商標、サービス名、製品名を使用する許可を与えるものではない…』というような内容を規定する条項を持つものがある（この例はApache License 2.0から引用）。GPLv2には同様の規定はないが、あるライセンスにこのような条項があるからというだけでGPL非互換だとFSFが判断したことはない。というのも、そのようなことがライセンスに規定されていなかったとしても、商標などを使用することができるわけではないので、実質的にライセンシーに対して新たな法的負担を負わせるものではないからだ。CC-BY-SA第4条項 (d) も同様の扱いになる可能性はある。とは言え、判断は慎重に行なう必要があるだろう」。
GPLを非ソフトウェアの作品に適用する
アートワークをGPLソフトウェアと組み合わせることが可能であるCCライセンスが無いと判断した場合、よくある手段としては、その作品自体をGPLの下に置くということがある。FSFはこのことが可能であることを示唆しているが、その一方で、ライセンスされる作品の「ソースコード」に当たるものが何なのかがはっきりとしていなければならないとも警告している。
CCライセンスとは対照的にGPLやLGPL（GNU劣等一般公衆利用許諾契約書）では、「インターフェース」や「頒布」や「下流」といったソフトウェアの用語が使用されている。
この違いは表面的なものだけではない。例えば音楽に対してGPLを適用すれば、GPLが規定する定義や権利や制限をすべて、言い換えたり解釈し直す必要が出てきてしまう――そのような言い換えや解釈のし直しを行なうとなれば、理にかなった考えをする人同士であっても、どうしても意見の不一致が生じやすい。その結果として音楽の利用形態によっては（再録音など）現在、グレーゾーンになっているものもある。例えば楽曲の順番というのは、GPLで言うところの音楽の「ソースコード」の一部であると考えられるのか、それとも「パッケージング」の一部に過ぎないのだろうか？
Smith氏は、用語の違いが問題となる恐れがあることを認めている。「音楽をGPLの下で公開したいというアーティストにとっては、知っておくべきことを学ぶために長い時間がかかるだろうということは事実だ。けれどもそのような人々にGPLを勧めるのが良くないことだというわけではないと思う。むしろ、その反対だと思う。より多くのアーティストがGPLを使用して、GPLが作品にどのように作用するのかを理解するようになるにつれて、彼らはその知識を友だちや仲間と分かち合うようになり、次の人はもっと簡単に理解できるようになるだろう」。
結局のところ、アートワークに対してGPLを使用することは、アーティストが保証したい利用形態がフリーソフトウェアに統合することだけである場合にのみ、心配がなく確実な方法だと言える。アイコンなどの一部の作品は一般的にはソフトウェア以外では使用されないが、音楽やデスクトップ用背景画像などの作品はそうとも限らない。
解決法1：アーティストが複数のライセンスを使用する
CCライセンスがアーティストの間で人気があることにはもっともな理由がある。またFSFのライセンスがソフトウェア開発者の間で人気があるということにも、同じくらいもっともな理由がある。したがってフリーソフトウェアの世界に参加しようというアーティストが、他のアーティスト仲間にとっても、フリーソフトウェア開発者にとっても、どちらにとっても便利になるように作品をライセンスするための唯一の方法は、GPLとCCライセンスの両方のライセンスの下で作品をリリースすることだ。
このことは、両方のライセンスを付けたパッケージをリリースするということではない。矛盾する2つのライセンスを付けるということは自己矛盾であり、現実的には役に立たない。そうではなく、それぞれのライセンス用のパッケージを計2つ用意しよう。
確かに、厳密に言えばパッケージングの段階で2倍の手間がかかるということだ。しかしそもそもパッケージングの実際的な手間はほとんどゼロなので、2倍になったところで大したことではない。大規模な作品集の場合には、広く行なわれている賢明な手として、作品集全体に1つのファイル（COPYINGかREADME）を付けてライセンスすると良い。
派生作品や翻案の中の素材の一部を再使用する人は、著作権表示を追跡しなければならないが、アーティストが複数のライセンスの下で作品を利用可能にしておけば、利用者がプロジェクト内で複数のライセンスを追跡する手間を省いてあげられることになる。
CCは現在、特定のファイルのライセンスを簡単に追跡することができるようにするためのliblicenseという名前の興味深いプロジェクトを進めている。また、これにGUIのライセンスセレクタを統合して、作業を簡単にしようとしている。
解決策2：ソフトウェア開発者がライセンスの落とし穴を避ける
CC-BY-SAとGPLなど、非互換のライセンスの下にある2つの作品を組み合わせることはできない。しかしソフトウェア開発者は、少なくとも著作権法という観点からは画像やそれ以外のデータが別々の切り離された形のままであるように、アプリケーションを開発すれば良い。
Smith氏によると「このことに関する判例法はまだあまりない。またソフトウェア開発者が切り離された画像集を使用するという方法は比較的最近になって行なわれ始めたことだ。したがってコミュニティにとっての最良のやり方というのは今のところはまだ完全には分かっていない。現時点ではまだ、個々のケースについて詳しい情報をすべて考慮したうえで、ケースバイケースの判断を下すのが最も良い方法であると思う」とのことだ。
Unix系のオペレーティングシステムでは、アプリケーションは通常、アイコン、効果音、起動画面などのリソースデータをアプリケーションとは切り離して/usr/shareディレクトリ階層の中に保存する。ソフトウェア開発者は、そのようなリソースに何通りもの方法でアクセスするようにアプリケーションを作成すれば良い。
Smith氏は、アイコンの場所をハードコードしてしまうと、著作権法が単一の組み合わされた作品だとみなすものにおそらく該当することになるとしている。そしてそのような場合には、アイコンのライセンスがGPL互換であることを確かめておくように勧めている。
とは言え、コードとデータを明確に切り離すための仕組みも存在する。「グラフィカルなツールキットのほとんどでは、アプリケーションが（例えば『拡大』用のアイコンなどの）既存のアイコンを要求すれば、ユーザのテーマなどの設定に基づいて、ツールキットが特定の画像を読み込んで表示するというようになっている」。
Smith氏によると「この程度の抽象化のレベルで十分なので、スタックの一番上にあるアプリケーションと、一番下にあるアイコンとの間のライセンスの互換性について特に懸念する人はこれまでにはいなかった」とのことだ。
まず手始めには、Freedesktop.orgのアイコンの命名方法についての仕様を読むと良いだろう。この仕様では、コンテキストごとの標準的なアイコン名が定義されている。またアイコンテーマの仕様には、アプリケーションがインストールされているアイコンを検索したり独自のアイコンをインストールしたりするための方法や、ユーザの現在のテーマの中には存在しないアイコンをアプリケーションが要求した場合にどうなるかなどについて詳細に書かれている。
GTK+やQtなどの最近のツールキットはアイコンテーマの仕様のAPIをそれぞれ実装しているので、ソフトウェア開発者は詳細な点についてはそれらの文書を調べるか、Freedesktop.orgプロジェクトのページを参考にすると良いだろう。
将来的に、GPLのようなFSFのソフトウェア用ライセンスと、CCのようなコンテンツ用のライセンスとの間の互換性が認定されれば、このような問題はなくなるかもしれない。しかし現在のところは、他のアーティストやフリーソフトウェア開発者に対して作品を利用可能にしたいアーティストは、それぞれのグループの人々が受け入れることのできるライセンスを提供するようにする必要がある。またフリーソフトウェア開発者は、Freedesktop.orgの仕様を利用するコードを書くことによって、問題をやわらげることができる。そうすれば、エンドユーザは最善の結果を得ることになる――つまり、優れたフリーソフトウェアとともに、素晴らしい見掛けのアートワークを利用することができるようになる。
