OSSライセンスについて勉強したメモです。
最終的には日米間での著作権法の違いにまで話が及んでしまう「解釈」の問題になってしまう部分が多いので、特にGPLについてはそのソフトウェアの開発元に、「これこれこういう利用形態で使いたいんだけどライセンスどうなる?」と尋ねるのが一番確実なようです。
IPAによる調査資料:
OSC2009でのNECの人の発表資料:
OSSライセンスについて精力的に啓蒙活動を行われている可知豊氏のコンテンツ:
その他ライセンス毎の日本語訳やWikiページ、FAQ
よく見かけるライセンスについて:
※CDDL(Common Developement and Distribution License)は、GlassFish系のOSSで見かけた。
ヒントとなる単語:
「派生物 (Derived Work, Derivative Works)(CDDLでは「拡大制作物」"Larger Work")」・「リンク」・OOPでの継承やインターフェイスの実装
OSSを使って商用製品を開発する、あるいは、使っているOSSライブラリとは別のOSSライセンスを自分が作成したコードに適用する、等の場合に問題となるが、「派生物」の範囲となる。
なぜかというと、GPL系はもとより、MPL/EPL/CPL/CDDL系についても派生物の場合はそのソースコードを利用者が入手できるように、との記載があるためである。このため、自分達自身で作成したコードがどういった場合にOSSプログラムから見て派生物とみなされるのかは、死活問題となる。
例えば、少なくともGPLv2においては、GPLv2でライセンスされたライブラリに対して、動的・静的関わらず「リンク」しているプログラムにもGPLv2が適用されてしまうという強いコピーレフト性を持っている。非常に便利なGPLv2でライセンスされたOSSのライブラリがあるとして、これを商用製品の開発でリンクして用い、製品を独自のライセンスで提供したいケースでは、相当の注意が必要となる。
[BOLR2014]でも「2.1 伝播性のリスク」についてどこまでを派生物とみなすか、の説明がある。ただ面白いことに、その説明の中では特にライブラリのリンクについて Debian / RedHat / MySQL という比較的大きな開発組織のリーダやCTOで、それぞれ見解が異なっている。法的にも解釈の余地が残っている状態らしい。
他にも、GPLv2のFAQによると、2つのプログラムが結合され、事実上一つのプログラムの2つの部分となるなら、派生物とみなされるようだ。
http://ja.wikipedia.org/wiki/%E6%B4%BE%E7%94%9F%E7%89%A9
より確度の高い資料として以下がある。これはLGPLとJavaについて書かれたもので、結論としてはJavaの場合、ライブラリにアクセスするクライアント側のコードは、ライブラリの「派生物」とみなす、と書かれている。ただしLGPLの話なので、クライアント側のJavaコードについてはリバースエンジニアリングを許可するのであればLGPL以外のライセンスを適用できる、とも書かれている。
https://www.gnu.org/licenses/lgpl-java.html
一方で、EPL(Eclipse Public License)のFAQでは、以下の様な回答が記載されている。
For clarity, merely interfacing or interoperating with Eclipse plug-in APIs (without
modification) does not make an Eclipse plug-in a derivative work.
Eclipseは大部分がJavaで開発され、Eclipseプラグインはプラグイン用のAPIでEclipseと「リンク」していることになるが、単にインターフェイスを使っているだけであれば派生物とはみなされないようだ。
http://www.eclipse.org/legal/eplfaq.php#EXAMPLE
Javaについては以下も参照:
http://programmers.stackexchange.com/questions/224161/gpl-writing-an-exception-for-a-plugin-interface-under-section-7-of-gplv3
http://www.law.washington.edu/lta/swp/law/derivative.html
[BOLR2014]に戻ると、Javaのような動的リンクが行われるケースでは、標準インターフェイスを介しているかどうかが分かれ目のようである。
例えばServletAPIを使ったWebApplicationでは、確かに、デプロイされるコンテナがGPLで開発されたものであろうと、非GPLで開発されたものであろうと関係ない(コンテナに依存するような独自のAPIを利用するケースを除く)。
ASPサービスなど、ネットワーク経由で使われるソフトウェアの場合、利用者の手元にソフトウェアが「頒布」されるわけではない。
この場合、GPLについては利用者がソースコードを入手できるようにする必要はない。
これはGPLの抜け道として知られており、利用者へのソースコード公開を義務付けた、さらにコピーレフト性が強くなった
http://ja.wikipedia.org/wiki/Affero_General_Public_License
ASPサービスではGPLの抜け道を使って、GPLでライセンスされたライブラリを、独自開発のプログラムにリンクして実行し、ASPサービスとして利用してもらうことが可能だった。
しかし、クラウド利用で利用者に直接VMイメージをコピーして、利用者自身のクラウド環境で使用してもらうような場合、少なくともオブジェクトファイルのコピーが発生する、つまり「頒布」に相当すると考えられないだろうか?
そうなるとGPLの伝播性、コピーレフトの影響を考え無くてはならない、と思われる。
(調査中)
JavaScriptライブラリがGPLでライセンスされていた場合、そのライブラリを使ったJavaScriptもGPLになるのだろうか?
そのJavaScriptをscirptタグでロードするHTMLページをレンダリングするサーバサイドプログラムもGPLになるのだろうか?
観点1 : JavaScriptはブラウザ上にDLされて実行されるとすれば、「頒布」に相当するのか?
観点2 : JavaScriptライブラリをscriptタグでロードしているHTMLファイルは、そのJavaScriptライブラリにリンクしている派生物とみなされるのか?
観点3 : 上記HTMLファイルをサーバサイドで生成している場合、サーバサイドのプログラムも、そのJavaScriptライブラリが無ければ製品として成立しないようなケースではリンクしている派生物とみなされるのか?
参考:
コメント