Latest topics > オープンソースなライセンスやコピーレフトなライセンス、クリエイティブコモンズについて、他のライセンスとどう組み合わせられるのかを図にしてみた

オープンソースなライセンスやコピーレフトなライセンス、クリエイティブコモンズについて、他のライセンスとどう組み合わせられるのかを図にしてみた - Apr 02, 2008

オープンソースなライセンスとかコピーレフトなライセンスとかたくさんありすぎて違いがよく分かってなかった（自分で使ってるのに……）。特に、それぞれどう組み合わせることができてどういう組み合わせはアウトになるのか、どういう使い方は許されててどういう使い方は許されないのか、というあたりがボンヤリとしか分かってなかった（詳しい人にツッコまれたらその時対処しよう……という考え）。なので、可知さんの書かれた記事とかを読んで改めて調べてみた。

とりあえず大前提として、以下の説明はあくまでソフトウェアを作る側が開発から頒布までの過程でコードを使う、著作権法上の「利用」にあたる範囲の話で、そのソフトウェアで商売したり作品を作ったりという、著作権法上の「使用」の範囲には言及していません。つまり完全に開発者向けの文章。以下、混乱を招きそうなので「利用」の文脈の時は全て「利用」と書くことにします。

あと、この理解が間違ってる場合はブクマコメントとかでこっそり書くんじゃなくてこのエントリのコメントで指摘しておいてもらえると、このエントリをウッカリ見てしまった人がこのエントリの内容を信用しないで済むので、そうしてもらえるとうれしいです。

GPL

まず一番有名なGPL。GPLは感染力が強いことで有名で、GPLのコードを利用するときは、元々GPLだった部分がほんの少しであったとしても、ソフトウェア製品全体をGPLにしないといけない。 詳しくは後述するけど、もし既存のコードをこの中に含めたいのなら、そのコードのライセンスがGPLと矛盾しないもの（※1）でないといけない。

GPLのライブラリを、GPLと矛盾する（※2）ライセンスのライブラリと組み合わせて利用することはできないし、ソースコードのファイル単位で混ぜることも、行単位で混ぜることもできない。

※1：GPLに無い追加の制限をそのライセンスが含んでおらず、同時に、GPLで定められているような制限をそのライセンスに追加で課すことが許されているということ。後述のMITライセンス（著作権表示があって、利用は自己責任と明示してありさえすれば、後は無制限）などがこれにあたる。

※2：例えば、GPLはGPLで定められた制限以外の制限を追加で課すことを禁じているが、そのライセンスにはGPLにない制限事項が含まれている、といったライセンス。具体的には、後述するMPLや、GPLにはない「広告条項」を含んでいる「旧BSDライセンス」などがこれにあたる。

LGPL

LGPLは、最初の頃は「GNU Library General～」の略だったということからも伺えるように、ライブラリ単位で適用されるGPLという感じのライセンスだ。

LGPLのコードを利用してソフトウェアを開発する場合も、自分で開発した部分も含めてソフトウェア全体をLGPLにすることは当然可能。 この時も、既存のコードをこの中に含めるには、そのコードがLGPLと矛盾しないライセンスで公開されている必要がある。

また、GPLとは違って、それが静的にリンクされていないのであれば（＝別々のバイナリになっているのなら）、全体をLGPLで統一しなくても、LGPLの部分はLGPL、LGPLと矛盾する他のライセンスのライブラリはそのライセンスのままで、組み合わせて一つのソフトウェア製品として頒布することができる。

でもLGPLで許されるのはここまで。最終的に一つのバイナリになるソースファイル群において、ソースファイル一つ一つの単位でLGPLと矛盾するライセンスのコードと組み合わせたり、行単位でそういうコードと混ぜ合わせるようなことは、やっぱりできない。

なお、LGPLとGPLは矛盾するため、両者のコードを混在できない。後述するとおり、デュアルライセンス、トリプルライセンスで両者を併記するのは可能。

MPL、CPL、EPL

MPLはFirefox等で使われているライセンスで、「GPLやLGPLよりもさらに制限が緩い」という風に説明されることがある。僕がよく分かっていなかったのは、これが具体的にはどういう風に「緩い」のかってことで、今回調べた事も主にこの部分の話。

まず、自分で開発した部分も含めてソフトウェア全体をMPLにすることは当然可能。また、LGPLと同様にライブラリ単位での適用も可能。

MPLの場合はその上さらに、ソースコードのファイル単位での適用が可能になっている（MPLのFAQより）。言い換えると、ソースコードの状態で別のファイルに分けてあれば、自分で新しく書いたコードにはMPLと矛盾するライセンスを適用してもいい。らしい。

でも、GPLやLGPLと同様、MPLの場合も、矛盾するライセンスのコードを行単位で切り貼りして組み合わせることはできない。

可知さんの記事によると、CPLやEPLも、MPLと同様の混ぜ方ができるそうだ。ただし、MPLとCPLとEPLではこれ以外の部分（特許を含んでいる場合はそれを明示しないといけない、とかなんとか）でちょっとずつ違いがあるようなので、そこは注意が必要。

また、前述した通り、MPLとGPLは矛盾するため混在できない。これもLGPLとGPLの関係と同様で、デュアルライセンス、トリプルライセンスといった形で併記することはできる。

MITライセンス（X11ライセンス）、修正BSDライセンス

MITライセンス（別名、X11ライセンス）は、MPLよりもさらに制限が緩い。MITライセンスは「自己責任で利用することと、著作権者名を表示すること」だけを条件に定めた非常に簡素なライセンスだ。修正BSDライセンスもまた、これと同様の条件を定めたライセンスで、MITライセンスと修正BSDライセンスはお互いに互換性がある。

MITライセンスのコードを組み込んだソフトウェアは、全体をMITライセンスにしてもいいし、ライブラリ単位でMITライセンスにして他のライセンスと混ぜてもいいし、ファイル単位で混ぜても構わないし、それどころか行単位で利用しても構わない。 これらのライセンスはGPLやLGPL、MPLの定める制限と矛盾しないため、それらのライセンスのコードの中に混ぜ込んで利用しても全く問題ない。

デュアルライセンス、トリプルライセンス

GPLとLGPL、MPLとGPLとLGPL、という風に、お互いに矛盾する制限条項を含んでいる複数のライセンスを併記する事もできて、こういうのはデュアルライセンス（ライセンスが2つの場合）とかトリプルライセンス（ライセンスが3つ）とか呼ばれる。

デュアルライセンスやトリプルライセンスのソフトウェアを改造したり、逆に、そういったソフトウェアを組み込んで新しいソフトウェアを開発したりした場合、付けられるライセンスは「元のデュアル（トリプル）ライセンスをそのまま引き継ぐ」か、「元のデュアル（トリプル）ライセンスに書かれていた物のうちどれか一つのライセンスを選んでそれを適用する（トリプルライセンスなら、そのうち二つを選んでデュアルライセンスにするというのもあり得る？）」か、のどちらかになる。すでにあるソフトウェアに、デュアルライセンスやトリプルライセンスのソフトウェアを組み込む場合も、「デュアル（トリプル）のまま引き継ぐ」か「どれかを選ぶ」かのどちらかにしないといけない。

ライセンスの混在時は、全体のライセンスは最も強いライセンスに引きずられる、という原則

「全体をGPLにしないといけない」「既存のコードを含めるなら、そのコードのライセンスがGPLと矛盾しないものでないといけない。」という風に前述したが、これについて、ライセンス同士の力関係（影響力の強さ）という観点から補足説明をしておく。

例えば画像編集ツールを開発（仮に、gplAppという名前のソフトウェアだとする）して、そのコードにGPLを適用したとする。そこに、修正BSDライセンスで開発・公開されているとある画像表示ライブラリ（仮に、bsdLibという名前のライブラリだとする）を組み込むとしよう。先に述べた通り、この両者のライセンスは矛盾しないので、問題なく組み合わせられる。だが、こうして生まれた新しいソフトウェア、gplApp + bsdLibのライセンスはどうなるかというと、それぞれの部分で異なるライセンスとはならず、全体がGPLになる。

また、今度は逆に、開発した画像編集ツール（仮に、bsdAppという名前にしたとする）のコードに修正BSDライセンスを適用した上で、そこに、GPLで開発・公開されているとある画像表示ライブラリ（仮に、gplLibという名前のライブラリだとする）を組み込むとしよう。こうして生まれた新しいソフトウェア、bsdApp + gplLibのライセンスはどうなるか？　この場合もやはり、全体がGPLになる（いわゆる「GPL汚染」）のである。

これは何故かというと、GPLと修正BSDライセンスでは、GPLの方が制限が厳しいからだ。

修正BSDライセンスでは、ライセンスが適用されたソフトウェアを利用する際の条件として、「自己責任で使用すること」「著作権者名を表示すること」を求めており、これらを満たせない場合は利用を許可しないとしている。GPLにもこれと同様の制限条項がある。

修正BSDライセンスではこれ以上の制限は特に無いが、GPLではこの後さらに「派生物にも同一のライセンスを適用しなければならない」「GPLのコードを含める場合は、全体にGPLを適用しなければならない」などの追加の制限条項が並んでいる。しかし修正BSDライセンスには「そのような追加の制限条項を付けてはならない」という風な決まりはない。よって、「GPLに則っているならば修正BSDライセンスにも則っている（十分条件）」と言える。これが、「修正BSDライセンスはGPLに対して矛盾しない」ということである。

その上で、「GPLのコードを含める場合は、全体にGPLを適用しなければならない」という条件が適用されるので、GPLと修正BSDライセンスを組み合わせたソフトウェアは、全体がGPLになる。元々修正BSDライセンスで提供されていた部分に求められていた再配付条件（著作権者名表示と、自己責任での使用）は、GPLの同様の条件によって満たされているので、修正BSDライセンスの代わりにGPLが適用されても何ら問題ない。

これが、GPLのコードと修正BSDライセンスのコードを組み合わせて利用してもよくて、且つ、その場合は全体がGPLとして扱われるようになる、ということの理屈だ。矛盾しない二つのライセンスが組み合わさった時は、どちらのライセンスのソフトウェアが主体になっているか（どっちのコードの量が多いか、どっちが主でどっちが従か）には関係なく、あくまで影響力が強い方のライセンスが生き残るということに注意して欲しい。

なお、こうしてbsdApp + gplLibというソフトウェアが誕生してGPLで公開されるようになったとしても、元作者がbsdAppを修正BSDライセンスで提供し続けている限り、bsdAppはあくまで修正BSDライセンスのソフトウェアとして存在し続ける。修正BSDライセンスの「bsdApp」というソフトウェアと、GPLの「bsdApp + gplLib」という二つのソフトウェアが平行して存在することになるとも言える。

これと同様に、先の「gplApp + bsdLib」の場合も、「gplApp + bsdLib」として取り込まれる前のbsdLib自体は修正BSDライセンスのソフトウェアとして存在し続けることになる。だから、例えばGPLと矛盾するMPLのもとでmplAppを開発している人も、MPLと矛盾しない修正BSDライセンスのbsdLibを組み込んで、MPLの「mplApp + bsdLib」を作ることができるし、その場合もやはり取り込まれる前のbsdLibは修正BSDライセンスのまま存在し続けて、他の開発プロジェクトに役立てられることになる。

なお、これはコンパイルしてバイナリになったものを頒布する場合の話で、ライセンスによっては、コンパイルされていないソースコードだけを頒布する場合はこの話は適用されない。例えばここまでの所でGPLは物凄く強い感染力を持っているという風に書いてきたけど、ソースコードのまま配布するなら問題ないそうだ。実際、PostgreSQLは一部のコードだけがGPL、それ以外は修正BSDライセンスという形を取っていて、ソースコードの状態で配布された物については、修正BSDライセンスの部分を取り出して、GPLではなく修正BSDライセンスのコードとして再利用することができる。

クリエイティブコモンズ（CC）

CCは、ここまでで名前が挙がったライセンスとは性質が異なる。ここまでに挙げたライセンスはソフトウェアを頒布するためのライセンスだけど、CCはソフトウェアに限らず著作物一般を対象にしたライセンスだ。ただし、前提として音楽や映像、イラストレーションなどの「コンテンツ」を対象にしたライセンスとしての性格が強いので、単純な著作物とは異なる性質を持つソフトウェアには適用しづらい部分がある。クリエイティブコモンズ（団体の方）もCCライセンスをソフトウェアに適用することは推奨していない。とはいえ、実際にCCライセンスでコード片を公開している人もたまにいるので、そういうコードを利用したくなった時のためにも、考察をしておきたい。

CCでは「表示」「非営利」「改変禁止」「継承」の4つのオプションを自由に組み合わせて適用することができる。よって実際には、「クリエイティブコモンズかどうか」ということ以上に「クリエイティブコモンズの、どのオプションが採用されているか」ということの方に注意しないといけない。

また、CCにはソフトウェア開発に特有の「静的リンクと動的リンクの違い」や「ソースコードとバイナリの違い」といった考え方が無いので、CCが適用された部分を少しでも含んで同梱・再配付していたら、そのソフトウェア製品全体が一つの著作物としてCCの影響下に入るものと（僕には）思われる。

「改変禁止」オプションの有無が採用されている場合

このオプションが採用されている物は、自作ソフトウェアの中で素材として利用することはできない。

「改変禁止」オプションを採用する著作物というのは、具体的には、それ単体で完成していてそれ以上手を加えることが許されていない、映像作品や音楽作品などが該当する。このオプションを指定するということは、「これでこの作品は完成していますよ」「これ以上誰も手を加えないでください」「この作品単体で鑑賞（使用）してください」と宣言するに等しい（これに「非営利」オプションが加われば「無料でだったら、配ったり上演したりしてもいいですよ」という意味になる）。

だから、例えば画像の一部を切り取ってアイコンにすることも、映像の一部を切り取ってThrobber（Firefoxのウィンドウの右上でくるくる回るアレ）に利用することもできない。プログラムであれば、それをライブラリとして組み込んで利用することもできない。

「継承」オプションの有無

これは解釈の仕方が難しいんだけど、素直に文字通り受け取ると、「継承」オプションが採用されていない素材を「利用する」というのは、その素材を利用して新たな著作物を作り公開するまでの事を指し、その公開時には、必ずしも同一の条件を提示する必要はない同一の条件は提示されない、というふうに考えられる。言い換えると、CCライセンスで決められた条件を守らないといけないのは二次的著作者となる自分自身だけであって、その二次的著作物をさらに「利用」する人達（三次的著作者、四次的著作者、以下続）には影響しない、つまりCCによる縛りは一旦完全に消滅してしまう、ということになると考えられる。

ただし、「CCによる縛りが一旦消滅する」というのは「著作権の縛りが無くなる」ということを意味しない。むしろその逆で、CCによって「解放」されていた「自由な利用」の権利が消滅する、つまり、CCの縛りがなくなることによって、元の作者は二次的著作物の再頒布の条件に口出しする権利を取り戻すということだ。

具体的にCC日本版の基本ライセンスでいうと、「継承」無しで「表示」オプションのみが採用されていたら、

• ソフトウェア製品のクレジットに素材の作者名を表示すれば、素材として利用できる。その上で、そのソフトウェアを有償無償を問わず頒布できる（「非営利」オプションが採用されていないから）。
• 二次的著作者である自分は、そのソフトウェア製品自体に好きなライセンスを設定できる。
• 例えば、元々「CC 表示」だったアイコン画像を埋め込んだ作品を著作権を放棄して公開したら、三次的著作者はそのソフトウェア製品から画像を抜き出して、クレジット表示をする必要もなく好き勝手に利用できる。
• 逆に、すべての権利を保持したまま公開したら、三次的著作者はどんな用途であれそのソフトウェア製品の一部を勝手に抜き出して素材として利用することはできない。
• しかし、そのソフトウェアを頒布するにあたっては、「これを手に入れた人もさらに加工して再頒布していいですよ」という条件を課すことはできない。なぜなら、CCによって提供されていた「加工して自由に再頒布していい」という権利はこの時点ですでにあなたによって消尽されているおり、あなたが創出したわけではない「元はCCだった部分」について再び「もう一度加工して再頒布していい」という許可を出せるのは、あなたではなく、その素材を作った元作者だけだからである。
• よって、そのソフトウェアを入手した人は、それを再頒布することはできない。そのソフトウェアの中から「元はCCだった」素材の部分を取り出して加工して自分の作品に利用して頒布する、という事もできない。

ということになり、「継承」無しの「表示-非営利」であれば、

• ソフトウェア製品のクレジットに素材の作者名を表示し、且つ、そのソフトウェア製品を無償で頒布するのであれば、素材として利用できる。その上で、そのソフトウェアを無償でのみ頒布できる（「非営利」オプションが採用されているから）。
• 二次的著作者である自分は、そのソフトウェア製品自体に好きなライセンスを設定できる。
• 例えば、元々「CC 表示-非営利」だったアイコン画像を埋め込んだ作品の著作権を放棄して無償で公開したら、三次的著作者はそのソフトウェア製品から画像を抜き出して有償のソフトウェアに埋め込み、好き勝手に利用できる。
• 逆に、すべての権利を保持したまま無償で公開したら、三次的著作者はどんな用途であれ、そのソフトウェア製品の一部を勝手に抜き出して素材として利用することはできない。
• しかし、そのソフトウェアを頒布するにあたっては、「これを手に入れた人もさらに加工して再頒布していいですよ」という条件を課すことはできない。理由は先と同じ。
• そのソフトウェアを入手した人は、再頒布も、素材として利用することもできない。これも先と同じ。

……ということになると思うんだけど、いまいち自信がない。

この解釈が正しければ、「CC 表示」「CC 表示-非営利」の素材はMITライセンスや修正BSDライセンスの素材と同じようにソフトウェア製品に組み込んで（「非営利」が付くときは、自分自身が一時配布する際は無償でないといけないことになるけど）利用できる、ということになる？　のか？

ということでどちらの場合も、「元はCCだった部分」について元の作者に「こういう条件で公開したいんだけど、いいですか？」と確認を求めて、元作者がOKを出さない限りは、それ以上の広がりを勝手に作ることは許されないと考えられる。

逆に、元作者の立場に立った言い方をすれば、素材を利用して作品を作った人が現れる度に「こういう条件で公開したいんだけど」といちいち確認を求められる煩わしさから解放されたい場合に、「ああもういちいち確認しなくてもいいよ、同じ条件でだったら配っていいよ」とあらかじめ宣言しておくというのが、「継承」オプションの意味だと言えるだろう。

CCの「継承」オプションの性質を理解するには、日本の著作権法において二次的著作物の権利がどういう扱いになっているかを理解しておかないといけない。

日本の著作権法では、ある作品を創出した場合はその作者が著作権者となる。それがゼロからの創出だった場合には、その著作権者が全ての著作権を持つことになる。ここまでは分かりやすい。

しかしゼロからの創出でなかった場合はどうなるか。例えば、手塚治虫が漫画で描いたブラックジャックというキャラクターを、田口雅之が手塚治虫（または彼の著作物の著作権を管理している人）の許可を得て自分の漫画で描いた場合、その作品の権利者は誰になるのか。日本の著作権法では、このような派生的著作物を「二次的著作物」と呼んでいて、これの著作権は元の作者と派生物の作者の両方が持つことになっている。先の例で言えば、手塚治虫と、新作漫画を描いた田口雅之の二人が権利者となる。

さて、ここで新たに別の人が、田口雅之の描いたブラックジャックを利用して新しい作品、例えばアニメ版を作ろうと思ったとする。これは二次的著作物の派生物、言うなれば三次的著作物ということになる。この場合、アニメ版を作りたい彼は誰に許可を得ればいいのか。

通常の著作物であれば、権利者は一人だけなのでその人に許可を得ればよい。しかし二次的著作物の場合、権利者が複数人いる。つまり、複数人で共同で作った著作物と同じ事になり、権利者全員の許可を得なければ、三次的著作物を頒布することはできない。アニメ版ブラックジャック・ネオを作りたければ、手塚治虫と田口雅之の二人に許可を得ないといけないということだ。

以上を踏まえて、CCの機能を考えてみよう。

CCは実は、「改変禁止」以外はどのオプションを採用しても（「継承」を採用しなくても）、元の作者は二次的著作物・三次的著作物などの派生物についても同じCCライセンス（または、それに矛盾せず、もっと条件が厳しいライセンス）での利用を許諾したものとみなされる。よって、「表示」オプションだけが採用された作品を利用して二次的著作物を作った場合でも、あなたや三次的著作物を作ろうとしている人がわざわざ確認を求めるまでもなく、元作者はすでに（一定の条件下で）三次的著作物への利用を許可していることになる。

しかし前述の通り、二次的著作物の権利は、元作品の作者だけでなくその二次的著作物の作者も持っている。よって、これだけでは勝手に二次的著作物を利用することはできない。この二次的著作物を利用したければ、二次的著作物の作者に別途許諾を求めなくてはならない。 別の言い方をすれば、二次的著作物の作者は、二次的著作物をCCにしないでおくことができるということでもある。もちろん言うまでもなく、二次的著作物もCCにすれば、三次的著作物を作りたい人は別途許諾を得なくてもよくなる。

ただし、その場合もどんなライセンスでも自由に指定していいというわけではない。元作者が選択していたCCの条件よりゆるい条件を指定したければ、改めて元作者に許諾を得なくてはならない。例えば、CC-表示-非営利で配布されていた素材を利用して新しい著作物を作った時、その新しい二次的著作物には同じ条件の「CC-表示-非営利」、またはそれより厳しい（オプションが増えた）「CC-表示-非営利-改変禁止」「CC-表示-非営利-継承」「CC-表示-非営利-改変禁止-継承」は指定できるが、元より緩い（オプションが減った）条件の「CC-表示」や「CC-表示-改変禁止」「CC-表示-継承」を指定することはできない。

「継承」オプションが採用されていた場合、元作者が二次的著作物・三次的著作物などの派生物に対して自動的に同条件での利用を許諾する、ということに加えて、二次的著作物の作者、三次的著作物の作者も同じ条件での利用を自動的に許諾することになる。 元の作品に「継承」が採用されていた場合、二次著作者には同じCCライセンスで公開する以外の選択肢はない。「継承」が無い場合と異なり、より厳しいライセンスを設定することも許されない。言い換えれば、あなたが作った二次的著作物の利用形態をコントロールしたい場合は、「継承」オプションを採用した素材を利用してはいけない。

以上の話を踏まえて、ここまでで紹介したソフトウェア用のライセンスとの混在について考えてみる。

前述した通り、CCの「継承」オプションは「全く同一の条件のライセンスを付けての利用」だけを許可するものだ。よって、「継承」オプションを採用した素材を利用した著作物には同じCCライセンスしか設定できない。「CC表示-継承」の画像をGPLのコードと組み合わせることもできない。

ただしその逆に、より緩い条件で頒布されている素材やコードを「継承」オプション付きのCCライセンスの作品に取り込むことはできる。例えば「CC表示-継承」のソフトウェアに「CC表示」のライブラリを組み込んでも、MITライセンスや修正BSDライセンスのコードを組み込んでも、問題はない（ただし、その結果できあがったソフトウェアのライセンスは同じライセンス、ここでは「CC表示-継承」になる）。

表示-継承

CCの基本ライセンスのうち「表示-継承」という組み合わせは、GPLと互換性があるGPLに性質が似ていると考えられる。なぜなら「著作権者名を必ず表示しないといけない」「同一の条件を適用しないといけない」「自由に改変できないといけない（「改変禁止」オプションが採用されていないから）」「用途を限定してはならない（「非営利」オプションが採用されていないから）」それに加えて、暗黙的に「素材として作品の一部でも利用したら、同じ条件が新しい著作物全体に適用される」という条件も含んでいると解釈できるからだ。

その逆に、GPLの素材を利用して作る著作物にCCを適用したければ「表示-継承」以外は選択できないとも考えられる。

――ブクマコメントで書いている人がいたので訂正。CCにはGPLにはない縛りがあるため、GPLとはお互いに矛盾するライセンスとなっているようだ。なので、CCのコードと組み合わせられるのはMITライセンスや修正BSDライセンスあたりのコードだけということになりそう。

「非営利」オプションが採用されている場合

その素材が「CC 表示-非営利」「CC 表示-非営利-継承」のライセンスで公開されている物であった場合、GPL、LGPL、MPLなどのライセンスのコードとは絶対に組み合わせられないことになると考えられる。なぜかというと、これらのライセンスはいずれも用途を限定しないという条件を含んでいるからだ。

仮に「CC 表示-非営利-継承」で公開されていた画像をアイコンとして利用したソフトウェアを公開するとなると、二次的著作者にあたる自分自身は当然、そのソフトウェアを無償で公開しないといけない。それだけでなく、そのソフトウェアを改造して再配布する人や、一部分だけを抜き出して自分のソフトウェアに組み込みたいという人など、三次的・四次的著作者にあたる人達までも、そのソフトウェアを無償で公開しないといけないことになる。これが、GPLやMPLなどの認めている権利すなわち「お金を取って配ってもいい」と衝突してしまうわけだ。

また、「継承」オプションがない「CC表示-非営利」であった場合も、前述の「継承」オプションの話で述べた通り、元の素材の作者が出している許可は「非営利での利用に限定して」ということになるため、GPL、LGPL、MPLなどのようにその点において緩い（「非営利」オプションを外すに等しい）ライセンスにすることはできないと思われる。

ということで、「非営利」オプションがあるCCライセンスと共存できる（混在できる）のは、MITライセンスや修正BSDライセンス、あるいは「利用目的を制限してもいい」という性質を持つ他のライセンスを採用したコードだけ、ということになりそう。

なお「非営利」オプションでは実費すらも求めてはいけないことになっているので、本当に無償で配る場合しか許容されない。ソフトウェアの場合はあまり関係ないが、CCで頒布されている画像をブログに貼り付けるなどの場合、アフィリエイトバナーが貼られているブログで利用するのはライセンス違反になるのかどうか、ということは多くの人が気にしていた点で、これについてはアフィリエイトバナーと「非営利」オプションとは衝突しない（アフィリエイトバナーがあるブログでも「非営利」の素材を問題なく利用できる）という見解がレッシグ教授によって示されている。

特別な許可を得たのなら、ここまでの話は忘れてOK

当然といえば当然だけど、最初の作者（複数人が関わったコードであるなら、関わった人全員）に直接話をつけて許諾を得られれば、ここまでの話は全部無関係になる。例えばGPLで公開されているライブラリでも、元作者にお願いしてOKさえ貰えれば、営利目的のプロプライエタリな製品に組み込んだって全然問題ない。

ただ、自分自身がソフトウェアを開発して提供する側として考えた時に、もし自分が死んでしまったら、そういった「特別の許可」を与えることは誰にもできなくなってしまう。

ここまでで紹介したような様々なライセンスのいい所は、もし元作者が死んでしまったとしても、ライセンス文で明示された通りの条件に従う限りは、誰でも安心してそのコードを利用し続けられるという点だ。「万が一のことがあった後でも絶対に譲れない一線」というものが自分の中にあるのなら、それに基づいて、熟慮して慎重にライセンスを選ぶといいだろう。

ソフトウェアの著作権と特許、CCとGPLが共存できない一つの理由

クリエイティブコモンズはCCライセンスをソフトウェアに使うことを推奨していない、とか、CCとGPLは矛盾するので混在できない、とか書いたけど、それは何故なのかという理由の一つについて述べておく。

CCは著作物一般に対して適用可能なライセンスだというのは前述した通りで、ソフトウェアも著作物の一種である以上は、ソフトウェアにCCを適用するのは論理的には可能だというのも事実。でもソフトウェアは単なる「著作物」ではなく、「技術」でもある。「技術」ってことは「特許」が関わってくる。著作物としては誰の権利を侵害していなくても、他人の特許を侵害している、という可能性はあり得る。また、特許権の持ち主は「著作物としては無料で利用できても、特許料は別に払わなきゃ駄目」という言い方も、理屈の上ではできる。

実際、GPLにもMPLにもMITライセンスにも「条件に従う限り無償で利用することを許可する」という風な条文が含まれているので、これらのライセンスに基づくコードを利用する限りは、コードの元作者が持っている特許について、特許料を請求されたり特許侵害で訴えられたりする心配はない。また、MPLには「追加されたコードが他人の特許を侵害していた場合」についての規定も別途書かれている。

でも、このような条文を含んでいない、CCのようなライセンスで公開されたソフトウェアである場合、利用すると特許の使用料を請求されたり、訴訟を起こされたりする可能性があると考えられる。修正BSDライセンスにも同様の危険性があるという話もある。

なので、ソフトウェア作者として新たにライセンスを設定するにあたって、ソフトウェアの発展を願ってオープンソースで公開しようという場合には、利用者が無駄に訴訟のリスクに怯えなくてもいいよう、あらかじめ特許権の不行使を約束しているライセンス（GPLとかMPLとか）を選択するべきと言える。

というわけで

長々と自分なりの理解を書いてみたけど、間違ってる可能性もあるので、間違いに気づいた人はコメントで「てめー嘘言ってんじゃねえよ」と指摘してくださるととても助かります。

とかなんとか書いてたら、英語の方のWikipediaにどのライセンスが組み合わせられるかの一覧があるらしいということを知った。足りない頭で俺解釈をする暇があったら、頑張ってこれを読めってことですか……

追記。GPLもLGPLもMPLも、各ライセンスのコードは互換性のあるライセンスのコードとなら混在しても問題ないことについての指摘を受けて、文を修正した。

再追記。矛盾しないライセンス同士のコードを組み合わせたときの事についても説明を追加した。

再再追記。特別な許可についての話も書き加えた。

再再再追記。CCの「継承」条件についての話を、指摘を元に大幅に訂正した。訂正前の物とは結論が真逆になっているので、訂正前の物しか読んでない人は要注意。

再再再再追記。特許についての話を書き加えた。この辺あやふやなので誰かフォローしてくれるととても嬉しいです。

分類：Mozilla > XUL, Firefox, Mozilla, XUL, オープンソース , 時刻：14:55 | Comments/Trackbacks (17) | Edit

ツイート