技術/OSSライセンス/勉強メモ (v2)

id: 1278 所有者: msakamoto-sf 作成日: 2014-04-25 08:55:20
カテゴリ: License

[ Prev ]
[ Next ]
[ 技術 ]

OSSライセンスについて勉強したメモです。
最終的には日米間での著作権法の違いにまで話が及んでしまう「解釈」の問題になってしまう部分が多いので、特にGPLについてはそのソフトウェアの開発元に、「これこれこういう利用形態で使いたいんだけどライセンスどうなる？」と尋ねるのが一番確実なようです。

日本語での分かりやすい資料

IPAによる調査資料：

『ビジネスユースにおけるオープンソースソフトウェアの法的リスクに関する調査調査報告書［平成 17 年 2 月］』独立行政法人情報処理推進機構 (以降、本記事では [BOLR2014] と表記)
- http://www.ipa.go.jp/about/jigyoseika/04fy-pro/open/2004-741d.pdf
  - 著作権の話や、GPLが「契約」なのか「ライセンス」なのか、それにより日米でどういう法的解釈の違いが生じるのかなど、OSSのライセンスについて丹念に、かつ分かりやすく解説されている。
  - 後述のOSSモデルカリキュラムの「法務分野に関する知識」でも参考資料として使われているので、信頼性は高いと思われる。

IPA 独立行政法人情報処理推進機構：OSSライセンス関連情報
- http://www.ipa.go.jp/osc/osslegal.html
  - GPLを中心としたライセンスの解説・啓蒙資料やOSSライセンス周辺の係争事例の資料などが充実している。

OSSライセンスの比較、利用動向および係争に関する調査
- http://ossipedia.ipa.go.jp/doc/203/
- 係争に関する調査もさることながら、比較調査の内容も以下の点が他の資料と比べ、異彩を放っている。調査に相当の労力が注ぎ込まれたであろう、力作。
  - それぞれのライセンスの作成に関わったメンバーにインタビューした内容が書かれているため、そのライセンスが作られた意図や他の類似ライセンスと異なるポイントが明確になっている。
  - 原型となるライセンスから、そのバリエーションでどこが変更されたか、という順序で紹介されている。類似したライセンスの作者たちが、既存のライセンスに対して何を不満に思い、どういう意図で新しいライセンスを作るに至ったのかが分かる紹介順になっている。

IPA 独立行政法人情報処理推進機構：オープンソフトウェア：OSS人材育成：OSSモデルカリキュラムV2
- https://www.ipa.go.jp/software/open/ossc/oss_jinzai/curriculum_v2.html
  - このなかの「法務分野に関する知識（基本レベル）」と「法務分野に関する知識（応用レベル）」が、『ビジネスユースおける～』を分かりやすく講義形式にまとめられている。
  - 「OSSモデルカリキュラムV1」というのもある。 : http://www.ipa.go.jp/software/open/ossc/seika_0605_2.html

OSC2009でのNECの人の発表資料：

オープンソースをライセンス的に正しくつかうための11のチェックポイント - builder by ZDNet Japan
- http://builder.japan.zdnet.com/tool/20387156/1/
  - 「オープンソースカンファレンス2009 Sendai」での NEC OSSプラットフォーム開発本部エキスパートの姉崎章博氏による講演「OSSをライセンス的に正しく使う／プロプラだけの製品とするための11のチェックポイント」の紹介記事。
  - 発表スライド : http://jpn.nec.com/oss/osslc/doc/OSC20090124SendaiBassui.pdf

OSSライセンスについて精力的に啓蒙活動を行われている可知豊氏のコンテンツ：

オープンソース・ライセンスの談話室 | ギークもスーツも、お気楽に。
- http://www.catch.jp/oss-license/
知る、読む、使う！オープンソースライセンス - 達人出版会
- http://tatsu-zine.com/books/osslicense
オープンソースライセンスの基礎と実務
- http://www.slideshare.net/YutakaKachi/ss-8616029
  - 2014-01の最新版。
知って役立つOSSのライセンス
- http://www.catch.jp/oss/oss_license_sd/
  - "技術評論社のSoftware Design 2007年2月号の「特集2：プログラマよ立ち上がれ! OSS開発者への道」という記事の「Appendix2：知って役立つOSSのライセンス」の一部を加筆訂正したもの"

各種ライセンス文書

オープンソースライセンス - Open Source Group Japan Wiki - Open Source Group Japan - SourceForge.JP
- http://sourceforge.jp/projects/opensource/wiki/licenses
  - 原文へのリンクもあるので、まずはここからがオススメ。

その他ライセンス毎の日本語訳やWikiページ、FAQ

ざっくりとした分類

よく見かけるライセンスについて：

コピーレフト性が無いか、スゴイ弱い : BSD/MIT/Apache Software License
コピーレフト性はあるが、他のライセンスと組み合わせることもできる : MPL/EPL/CDDL/LGPL
コピーレフト性が強く、他のライセンスとの組み合わせに注意が必要 : GPL

※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を利用するケースを除く）。

GPLとASPサービスとAGPL

ASPサービスなど、ネットワーク経由で使われるソフトウェアの場合、利用者の手元にソフトウェアが「頒布」されるわけではない。
この場合、GPLについては利用者がソースコードを入手できるようにする必要はない。
これはGPLの抜け道として知られており、利用者へのソースコード公開を義務付けた、さらにコピーレフト性が強くなった
http://ja.wikipedia.org/wiki/Affero_General_Public_License

クラウド向けサービスとGPL

ASPサービスではGPLの抜け道を使って、GPLでライセンスされたライブラリを、独自開発のプログラムにリンクして実行し、ASPサービスとして利用してもらうことが可能だった。
しかし、クラウド利用で利用者に直接VMイメージをコピーして、利用者自身のクラウド環境で使用してもらうような場合、少なくともオブジェクトファイルのコピーが発生する、つまり「頒布」に相当すると考えられないだろうか？
そうなるとGPLの伝播性、コピーレフトの影響を考え無くてはならない、と思われる。

JavaScriptとGPL

（調査中）

JavaScriptライブラリがGPLでライセンスされていた場合、そのライブラリを使ったJavaScriptもGPLになるのだろうか？
そのJavaScriptをscirptタグでロードするHTMLページをレンダリングするサーバサイドプログラムもGPLになるのだろうか？

観点1 : JavaScriptはブラウザ上にDLされて実行されるとすれば、「頒布」に相当するのか？
観点2 : JavaScriptライブラリをscriptタグでロードしているHTMLファイルは、そのJavaScriptライブラリにリンクしている派生物とみなされるのか？
観点3 : 上記HTMLファイルをサーバサイドで生成している場合、サーバサイドのプログラムも、そのJavaScriptライブラリが無ければ製品として成立しないようなケースではリンクしている派生物とみなされるのか？

参考：

GPLなJavaScriptのコードは、非フリーなソフトウェアに使えるのか — ありえるえりあ
- http://dev.ariel-networks.com/Members/inoue/gpl-and-javascript/
GPLとJavaScriptとWeb Loophole - snippets from shinichitomita’s journal
- http://d.hatena.ne.jp/shinichitomita/20080514/1210770020
オープンソースライセンスのGPLにおけるリンクの扱いについて、J.. - 人力検索はてな
- http://q.hatena.ne.jp/1210785986

その他参考資料

ライセンスまとめ - present
- http://tnakamura.hatenablog.com/entry/20090612/license
各種ソフトウェアライセンスについて大雑把にまとめて始めました。 - 片っ端から忘れていけばいいじゃない。
- http://0xc000013a.blog96.fc2.com/blog-entry-99.html
漢(オトコ)のコンピュータ道: 受託開発とGPL
- http://nippondanji.blogspot.jp/2010/06/gpl.html
Android アプリに Apache License, Version 2.0 のライブラリを組み込むときにしなければならないこと - ひだまりソケットは壊れない
- http://vividcode.hatenablog.com/entry/license/android-app-with-apache-license-2.0
@IT 「ビジネスとオープンソースライセンス」(2000年の記事でさすがにちょっと古いか？)
- 前編 : http://www.atmarkit.co.jp/flinux/special/opensource/opensource01.html
- 後編 : http://www.atmarkit.co.jp/flinux/special/opensource/opensource02.html