Home > Latest topics

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

宣伝1。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能! シス管系女子って何!? - 「シス管系女子」特設サイト

宣伝2。Firefox Hacks Rebooted発売中。本書の1/3を使って、再起動不要なアドオンの作り方のテクニックや非同期処理の効率のいい書き方などを解説しています。既刊のFirefox 3 Hacks拡張機能開発チュートリアルと併せてどうぞ。

Firefox Hacks Rebooted ―Mozillaテクノロジ徹底活用テクニック
浅井 智也 池田 譲治 小山田 昌史 五味渕 大賀 下田 洋志 寺田 真 松澤 太郎
オライリージャパン

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

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

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

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

GPL

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

GPLのライブラリを、GPLと矛盾する(※2)ライセンスのライブラリと組み合わせて利用することはできないし、ソースコードのファイル単位で混ぜることも、行単位で混ぜることもできない。 (図:一部のライブラリだけがGPLでそれ以外がGPLと矛盾するのはNG) (図:一部のファイルだけがGPLでそれ以外がGPLと矛盾するのもNG) (図:一部の行だけがGPLでそれ以外がGPLと矛盾するのもNG)

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

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

LGPL

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

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

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

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

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

MPL、CPL、EPL

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

まず、自分で開発した部分も含めてソフトウェア全体をMPLにすることは当然可能。また、LGPLと同様にライブラリ単位での適用も可能。 (図:全体がMPLならOK) (図:一部のライブラリだけがMPLで、他はMPLと矛盾するライセンス、というのもOK)

MPLの場合はその上さらに、ソースコードのファイル単位での適用が可能になっている(MPLのFAQより)。言い換えると、ソースコードの状態で別のファイルに分けてあれば、自分で新しく書いたコードにはMPLと矛盾するライセンスを適用してもいい。らしい。 (図:例え最終的に一つのバイナリになるとしても、ファイル単位でわかれていれば、MPLのコードとMPLに矛盾するコードを混在してもOK)

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

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

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

MITライセンス(X11ライセンス)、修正BSDライセンス

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

MITライセンスのコードを組み込んだソフトウェアは、全体をMITライセンスにしてもいいし、ライブラリ単位でMITライセンスにして他のライセンスと混ぜてもいいし、ファイル単位で混ぜても構わないし、それどころか行単位で利用しても構わない。 (図:全体がMITライセンスまたはその互換ライセンスならOK) (図:ライブラリ単位での混在もOK) (図:ファイル単位での混在もOK) (図:行単位での混在もOK) これらのライセンスは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の「継承」オプションの性質を理解するには、日本の著作権法において二次的著作物の権利がどういう扱いになっているかを理解しておかないといけない。

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

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

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

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

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

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

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

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

「継承」オプションが採用されていた場合、元作者が二次的著作物・三次的著作物などの派生物に対して自動的に同条件での利用を許諾する、ということに加えて、二次的著作物の作者、三次的著作物の作者も同じ条件での利用を自動的に許諾することになる(図:二人とも自動的にOK) 元の作品に「継承」が採用されていた場合、二次著作者には同じ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, , , , , 時刻:14:55 | Comments/Trackbacks (17) | Edit

Comments/Trackbacks

CCは

「ソフトウェアに限らず著作物一般を対象にしたライセンス」ですから、理論的にはソフトウェアにも適用できますが、CC側では推奨してません。

CCライセンスをソフトウェアにも使えますか?
http://www.creativecommons.jp/faq/3cc/post_31/

アイコンやスロバーの扱いは悩むところですが、Mozilla的には「ソースコードとロゴは別物」という見解ですよね。
http://www.mozilla-japan.org/foundation/trademarks/faq.html

Commented by 池田 at 2008/04/02 (Wed) 20:53:47

no title

情報ありがとうございます。早速追記しました。

ロゴマーク等は、著作権とは別に商標による縛りも発生するので、それもまた理解を難しくする理由ですね……

Commented by Piro at 2008/04/03 (Thu) 01:59:49

絵で表すという方法

CCのそれぞれがどんな事を許可しているのかを絵で表したものとして、こんなものもあります。

http://www.commonsphere.jp/feature/content/nishijima/comocomo.php

ライセンスをキャラ化とか擬人化すると、概要は伝わりやすいかも。
細かいところまで正確に伝わるかは微妙ですが。

Commented by かめい at 2008/04/03 (Thu) 06:55:01

CC「継承」

興味深いエントリ、ありがとうございます。CCの 「継承」についてコメントします。

>例えば、元々「CC 表示」だったアイコン画像を埋め込んだ作品を著作権を放棄して公開したら、三次的著作者はそのソフトウェア製品から画像を抜き出して、クレジット表示をする必要もなく好き勝手に利用できる。

ソフトウェア製品の作者はアイコン画像の「二次著作者」に相当しないと考えられます。二次的著作物とは「著作物を翻訳し、編曲し、若しくは変形し、又は脚色し、映画化し、その他翻案することにより創作した著作物をいう」と定義されているのですが(著作権法およびCC)、上記の事例の場合、アイコン画像そのものに対する創作は行われていないと判断されると思います。(第三者が「画像を抜き出せてしまう」という事実からも)

「CC 表示」では、創作性の認められる二次著作物に対してライセンス変更は可能ですが、単に複製・配布していると判断される場合にはライセンスの変更は認められないと思います。

さて、ソフトウェア製品として考えると、これ全体を「著作権を放棄して公開」することはできないように思います。「著作権を放棄するけどアイコン部分は例外」とか「自作部分はMITライセンス、アイコン部分はCC」みたいなライセンス形態になるんじゃないでしょうか?「ソフトウェア製品から画像を抜き出して利用する人」も、CC に従った利用が求められると思います。

Commented by マツザワ at 2008/04/03 (Thu) 15:02:53

あとは

素晴らしい記事です。
あとは Apache License と CDDL があればいいなぁと思います。
CDDL と CPL/MPL/EPL の関係は微妙なので...。

Commented by p2 at 2008/04/03 (Thu) 22:28:08

LGPL

どうもはじめまして。LGPLについて気になる点があったのでコメントさせていただきます。

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

全体をLGPLで統一しない場合でも、どんな他のライセンスとでも組み合わせることができる、というわけではないと思います。LPGLの第6節をみるかぎり、著作物の改変とリバースエンジニアリングを許可するようなライセンスである必要があるっぽいです。
また、静的にリンクする場合でも、他のライセンスと組み合わせることができます。その場合は上記に加えて、非LGPL部のソースコードかオブジェクトコードを配布しなければならないのであまり現実的ではないですが…。

>なお、LGPLとGPLは矛盾するため、両者のコードを混在できない。

これはそんなことないと思います。LGPLでライセンスされたライブラリのコピーはGPLで再配布してもいいので、全体にGPLを適用すれば問題なく混在できます。あまり意味はありませんが、一部分だけLGPLで残りがGPLというのも可能だと思います。

Commented by nall at 2008/04/04 (Fri) 09:03:33

CC-GPL

CCの枠組みでGPLを使うという試みは実はあったりします。
http://creativecommons.org/license/cc-gpl
GPLにCCのタグ付けただけですが。

Commented by 和泉 at 2008/04/04 (Fri) 13:18:10

http://homepage1.nifty.com/emk/

> 「この作品単体で鑑賞(使用)してください」と宣言するに等しい(これに「非営利」オプションが加われば「無料でだったら、配ったり上演したりしてもいいですよ」という意味になる)。

念のためですが、「非営利」が付かない「改変禁止」は「改変しなければ、有料でも配ったり上演したりしてもいいですよ」という意味で、「非営利」のほうが制限は強いです。

「継承」関連の説明が大嘘過ぎて指摘する気すらなくなりかねない勢いですが、わざわざemでマークアップしてまで書かれている嘘を放置して拡大再生産されたら迷惑きわまりないので説明しておくと、「継承」では最初の著作者は三次、四次以降の著作者にも自動的に「継承」を条件にした利用許諾を与えることになってます。cc-by-sa-2.1 jpのライセンスの第4条をお読みください。というか読んでいたらこんな珍妙な結論に到達するはずがないと思うのですが、読まないで机上の空論を練り回していたのですか?

> このエントリをウッカリ見てしまった人がこのエントリの内容を信用しないで済むので、そうしてもらえるとうれしいです。

何が間違っているのか自分で見つけられないことがわかっているならエントリの公開を即刻中止することを強くおすすめします。何を書くとセキュリティホールになるのか理解しないまま拡張機能を公開しているようなもので危険きわまりないです。すでに

> 素晴らしい記事です。

という反応が返っていることをどうお考えですか。

ご参考:
http://slashdot.jp/developers/article.pl?sid=08/04/01/0451222

Commented by えむけい at 2008/04/05 (Sat) 13:09:11

えむけいさんへのご回答

> わざわざemでマークアップしてまで書かれている嘘を放置して拡大再生産されたら迷惑きわまりないので説明しておくと、

と書かれていたので見直してみたんですが、emでマークアップしている箇所があるのは見出しで 『「継承」オプションの有無』と『表示 - 非営利 - 継承』の箇所だと思うんですけど、どっちもご指摘の内容に反することは書いていないと思います。

ただ、見出し『「継承」オプションの有無』に対応する本文は『「継承」オプションが無い場合』の話を書いているのに対して、その前項の見出し『「改変禁止」オプションの有無』に対応する本文が『「改変禁止」オプションがある場合』の話を書いていたので、前項と続けて斜め読みすると、見出し『「継承」オプションの有無』に対応する本文も『「継承」オプションがある場合』の話を書いているように誤読しかねないな、とは思いました。ですので念のため、本文は変えずに見出しだけ表現を改めてみました。

もし僕が勘違いをしていて、これ以外の箇所で継承条項の有無に関して大嘘を書いている箇所があるということでしたら、もしよかったら再度改めてご指摘を頂けると嬉しいです。

>という反応が返っていることをどうお考えですか。

正しいことを理解してる人がもっと正しい記事を書いて、それが500件とか1000件とかのブクマ数を集めるような人気を博して、それに「素晴らしい記事です。」という反応が付けばいいと自分は思っていますし、そういう記事があるのなら、この記事からリンクしてそちらに誘導したいと思っています。

このエントリに書かれた情報を求めている人というのは、僕は、GPLその他のライセンスが付与されているコードを、どんな時なら利用してよくて、どんな時なら利用してはならないのか、ということについて明確な答えを欲している人だと思っています。また、自分自身がそういう答えを欲していたので、このように書きました。

なので、そういうニーズに応えたという意味において、そういう反応が返ってくるのはおかしいこととは思っていません。

ただ、それは「正確な情報が書かれているから素晴らしい」のではなく「俺のモヤモヤに答えを出したから素晴らしい」という意味でのことに限られるべきで、「正確だから素晴らしい」という意味でそのコメントをした人が書いたのだとしたら、それは誤解されてるなあ、と思います。

>何が間違っているのか自分で見つけられないことがわかっているならエントリの公開を即刻中止することを強くおすすめします。

という指摘を受けて昔一部のコンテンツを丸ごと削除した(公開を取り消した)ことがありましたが、その時のコンテンツは完全に静的なコンテンツであったのに対して、今のこのエントリは動的にコメントをつけることができ、こうしてえむけいさんのように本文の誤りを見つけた人が付けた指摘のコメントを閲覧者も見ることができるので、公開を即刻中止するほどの必要はないと僕は考えています。

Commented by Piro at 2008/04/05 (Sat) 17:24:54

no title

継承オプションがない場合の話をしていることは気づきませんでした。
しかし、cc-by-2.1 jpの第4条にもまったく同じ条文が書かれているので結論は変わりません。三次、四次以降の著作者もcc-by-2.1 jpによる利用許諾を自動的に与えられます。気づかなかったのは継承があってもなくても結論は変わらないからです。
cc-by-sa-2.1 jpを読みなさいと言われたからって他の部分は全く見ようともしないのですか。

>「正確だから素晴らしい」という意味でそのコメントをした人が書いたのだとしたら、それは誤解されてるなあ、と思います。

でははてなブックマークのコメントから引用。

> 仕事資料に使えるレベル。これを公開したブログ主に感謝します

モヤモヤが解消できれば正確でなくても仕事に使っていいのですか。piroさんがどういう意図でエントリを公開していようが、鵜呑みにする人は必ず現れます。

> 公開を即刻中止するほどの必要はないと僕は考えています。

では今後誤りを見つけても指摘しないことにします。もしかしたらすでに見つけたかもしれません。他の親切な方が見つけてくださるといいですね。

Commented by えむけい at 2008/04/06 (Sun) 04:36:28

ぇぇぇぇぇぇ

>しかし、cc-by-2.1 jpの第4条にもまったく同じ条文が書かれているので結論は変わりません。三次、四次以降の著作者もcc-by-2.1 jpによる利用許諾を自動的に与えられます。気づかなかったのは継承があってもなくても結論は変わらないからです。

な、なんだってー、と思ってリーガルコードを読んでみました。
確かに書いてある。

> http://creativecommons.org/licenses/by/2.1/jp/legalcode
> あなたが本作品をこの利用許諾に基づいて利用する度毎に、許諾者は本作品又は本作品の二次的著作物の受領者に対して、直接、この利用許諾の下であなたに許可された利用許諾と同じ条件の本作品のライセンスを提供する。

でも、だとすると「継承」って何を「継承」させるためにあるんだろう。

Commented by Piro at 2008/04/06 (Sun) 05:22:32

やっとわかった……?

つまりこういうこと?

・著作物の利用許諾条件は著作者が決められる。
・二次的著作物の利用許諾条件は、元の著作者と二次著作者の許諾内用の二つの許諾のANDとなる。
・継承条件があってもなくても、元の著作者は二次的著作物・三次的著作物に対してCCの条件での許諾を自動的に出したものと見なされる。しかし二次著作者・三次著作者にはCC以外の条件での許諾を出す権利が留保される。よって、二次的著作物・三次的著作物はCC以外のライセンスで頒布される可能性がある。
・継承条件が付く場合、元の著作者だけでなく、二次著作者・三次著作者もCCの同じ条件での許諾を自動的に出さなくてはならない。よって、二次的著作物・三次的著作物もCCで頒布されることが保証される。

Commented by Piro at 2008/04/06 (Sun) 07:37:20

no title

はい、意図的に罠を仕掛けたつもりはなかったのですがそれに自分で気づけるなら冒頭の文章はいつもの自虐ネタか謙遜であると判断できるので、公開を取り下げるべきだという主張は撤回します。

些細な点ですが「どのオプションを採用しても」は正しくありません。第4条の「本作品又は本作品の二次的著作物」という部分は、「改変禁止」オプションが付いているlegalcodeの条文では「本作品」になっています。つまり二次的著作物に対して自動的な許諾は与えられません(改変禁止なのだから当たり前ですが)。

また「改変禁止」と「継承」は(これまた当然ながら)両立できないので、「CC-表示-非営利-改変禁止-継承」というオプションはありません。

Commented by えむけい at 2008/04/06 (Sun) 18:24:09

難しい

> 素晴らしい記事です。
と書いた者です。

私は、CC の部分は読んでいませんでした。なので、その部分の誤りは気がつきませんでした。私が概ね把握したのは CC の前までです。その部分に関しては、私の理解していた内容と、ここで説明されていた内容が一致しており、私の理解は恐らく間違っていないだろうと思いました。
「オープンソース」「フリーソフトウェア」という言葉から、「無料」であるという誤った解釈がされている人が多くいるように見受けられますが、「オープンソース」の本質は「自由」を与えるものであり、それを担保するために、ライセンスによっては色々と制限を付けています。そういう中で比較的、わかりやすく解説していると感じたので「素晴らしい記事」と評しました。

尚、私が CC を読まなかったのは興味がなかったからです。ソースコードに関しては、CC ではなく、それ以外のライセンスを付与すべきだと思っているからです。今のところ、私が興味あるソフトで CC なコードは存在していなかったので...。

何か物事を理解したい場合、複数の出典をあたらないとろくなことはないと思うのですが、これは自明なことではないですね。

Commented by p2 at 2008/04/16 (Wed) 22:50:11

no title

CC-BYの写真素材など、特許などとは無関係のCCコンテンツであればGPLソフトウェア内で使用できると思うのですが、その辺りはいかがでしょう。

Commented by kick at 2008/05/24 (Sat) 08:20:51

no title

ソフトウエアでCCLのファイルを利用した場合に何が起きるのかずっと疑問だったので、とても参考になりました。

1つのソフトウエア作品の中に、GPLコードと継承オプション付きのCCL画像ファイルを混在できないらしい、というのは驚きです。
というか、CCL同士でも継承オプション付きで非営利かどうかが異なるオプションを選択している場合は、1つの作品に混在できないのか・・・。

Commented by asdfg at 2009/03/09 (Mon) 12:40:17

修正BSDライセンス&MITライセンスの説明に関して

修正BSDライセンス&MITライセンスについて書かれている部分で
「自己責任で使用すること」「著作権者名を表示すること」
の2つの条件だけについて言及されていますが、この部分には
「利用許諾表示(=ライセンス本文)を記載すること」
も明記しておいたほうが良いのではないでしょうか?

この記述がないと、記事を読んだ方に
「MITライセンスのライブラリを含んだGPLソフトウェアには
MITライセンスの利用許諾は添付しなくても良いんだな」
という誤解を与えてしまうのではないかと思います。

Commented by Dice at 2009/03/23 (Mon) 09:06:56

TrackBack ping me at


の末尾に2014年1月19日時点の日本の首相のファミリーネーム(ローマ字で回答)を繋げて下さい。例えば「noda」なら、「2008-04-02_license.trackbacknoda」です。これは機械的なトラックバックスパムを防止するための措置です。

Post a comment

writeback message: Ready to post a comment.

2014年1月19日時点の日本の首相のファミリーネーム(ひらがなで回答)

Powered by blosxom 2.0 + starter kit
Home

カテゴリ一覧

過去の記事

1999.2~2005.8

最近のつぶやき

オススメ

Mozilla Firefox ブラウザ無料ダウンロード