当方は、javamail-android http://code.google.com/p/javamail-android/ を
使ったAndroidアプリをリリースしています。上記ページのProject Informationを
読んで、ライセンスがGPLだと思い込んでいたのですが、ページを見返したら、
ページの右欄にライセンスが、GPL-2.0、CDDL-1.0、BSDのトリプルライセンスに
なっていることに気づきました。
以下に理由を詳しく書きますが、javamail-anroidがBSDライセンスを取り得ることに
疑問を感じます。
GPLもCDDLもソースコード開示義務が生じるのですが、BSDでは生成物、改変物の
ソースコードの開示義務はありません。
GPLのFAQの一部を引用します。
--- 引用開始 ---
どうしてオリジナルのBSDライセンスはGPLと矛盾するのですか?
オリジナルのBSDライセンスはGPLには無い特定の要件を課すからです。その要件とは、プログラムの宣伝に関するものです。GPLでは:
You may not impose any further restrictions on the recipients' exercise
of the rights granted herein.
(訳: あなたは受領者に、ここで認められた権利の行使に関して更なる制限を課し
てはならない。)
オリジナルBSDの宣伝条項はまさしくそのような「更なる制限」を提供しており、よってGPLと矛盾します。
改訂BSDライセンスには宣伝条項がありませんから、問題ありません。
--- 引用終了---
この記述に関しては解釈と書いてあって、仮に正しいとしたら、GPLと改訂BSDは両立し得ると
考えられます。ただし、解釈なので、賛否は分かれると思います。
一方、GPL wikipedia http://ja.wikipedia.org/wiki/GNU_General_Public_Licenseには
次の記述があります。
--- 引用開始 ---
集積物の別の部分と見なされるパッチ [編集]
前述のセクションの実例を挙げる。GPLソフトウェアへのパッチを提供した場合は、そのパッチが「適用したGPLソフトウェアとは別の著作物」とみなされる可能性も含んでいる。これは、前述の通り、
GPLv2の第2節後半部分 These requirements [...] do not apply to those
sections when you distribute them as separate works.
や
GPLv3第5項最終段落 Inclusion of a covered work in an aggregate does not
cause this License to apply to the other parts of the aggregate.[102]
に規定されている。即ちGPLソフトウェアを含む「集積物(aggregate)の他の部分」と認められれば、GPLに反しない、言い換えればGPLより緩やかなライセンスでパッチを公開しても良い[注釈
12]。例えばパッチが単なる修正ではなく、単体で再利用可能な全く別種の機能強化と見なされればそれは集積物の別の部分と規定でき、そのパッチのみに対しGPLと矛盾せずかつGPL以外のライセンス(BSDライセンスやzlib
Licenseなど)を適用する事も可能である。一例をあげると、MySQLは、「リンク例外条項付きGPLv2」と商用ライセンスとでデュアルライセンシングされている。これに対しGoogleはMySQL向けのパッチをBSDライセンスで提供していた[103]。このパッチはオリジナルのMySQLに由来しないコードのため、GPLで保護されたMySQLの「集積物とは別の部分」となる。BSDライセンスは独占的なライセンスであろうとも両立するので、結果的にこのパッチは、MySQLをGPLで利用するライセンシーと共に商用ライセンスで利用する者も適用可能である[104][105]。また同時にそのパッチからサブルーチンのみを取り出し、BSDライセンスされたソフトウェアにも同様のルーチンを導入する事も可能となる[105]。
--- 引用終了 ---
この記述の注釈 104および105には次の記述があります。
104の記述 http://nippondanji.blogspot.jp/2009/10/gplmysqlbsd.html
--- 引用開始 ---
GPLが適用されているソフトウェア=MySQLのパッチをBSDライセンスでリリースする。
Googleがリリースしている有名なMySQL
5.0用パッチは、なんとBSDライセンスで提供されている。MySQLは周知の通りGPLでリリースされているが、GPLソフトウェアはその性質上、改変するとそのソフトウェアもGPLでリリースしなければいけない。だったら何故そのパッチをBSDライセンスで提供することが出来るのか?!ホントにそんなこと出来るのか?!Googleは何か間違ってるんじゃないか?!などと疑問に思われることだろう。
結論から言うと、Googleは何らライセンスの間違いを犯しているわけではなく、GPLソフトウェアにGPL互換のライセンスでパッチを書くことが出来るのは、GPLの条文そのものにしっかりと書いてあるのである。
以下、GPLv2の日本語訳より抜粋。
http://sourceforge.jp/projects/opensource/wiki/licenses/GNU_General_Public_License
以上の必要条件は全体としての改変された著作物に適用される。著作物の一部が『プログラム』から派生したものではないと確認でき、それら自身別の独立
した著作物であると合理的に考えられるならば、あなたがそれらを別の著作物として分けて頒布する場合、そういった部分にはこの契約書とその条件は適用されない。しかし、あなたが同じ部分を『プログラム』を基にした著作物全体の一部として頒布するならば、全体としての頒布物は、この契約書が課す条件
に従わなければならない。というのは、この契約書が他の契約者に与える許可は『プログラム』丸ごと全体に及び、誰が書いたかは関係なく各部分のすべてを保護するからである。
よって、すべてあなたによって書かれた著作物に対し、権利を主張したりあなたの権利に異議を申し立てることはこの節の意図するところではない。むしろ、その趣旨は『プログラム』を基にした派生物ないし集合著作物の頒布を管理す
る権利を行使するということにある。
つまり、パッチとしてオリジナルのGPLソフトウェアから完全に切り離された部分に関しては、GPLが適用されないわけである。ただし、そのパッチをGPLソフトウェアに適用するためには、そのパッチはGPL互換のライセンス(例えばBSDライセンスなど)でリリースしなければならない。そして、それをオリジナルのGPLソフトウェアと合体した時点でGPLが適用される。つまり、
GPLソフトウェア + BSDLパッチ = 改変されたGPLソフトウェア
という関係が成り立つわけである。従って、件のGoogleパッチがBSDLでリリースされているのは、一切問題はないというわけであり、Googleパッチに含まれるソースコードはBSDライセンスで利用することが可能である。
なぜ上記のような条項がGPLに盛り込まれているのか?と疑問を持たれることだろう。もし上記の条項がなければ、全ての変更はGPLを適用したソフトウェアで行わなければならず、従って他のライセンスでリリースされた優秀なソフトウェアやライブラリをGPLソフトウェアと組み合わせて利用することが出来ないという事態になってしまう。例えそれがFSFが作成した他のライセンス、例えばLGPLなどを適用したソフトウェアであっても!である。上記の条項があれば、ライセンス上は安全に他のGPL互換のライセンス(BSDライセンスなど)のソフトウェアとGPLライセンスのソフトウェアを組み合わせて別のソフトウェアを開発することが可能になる。
まったくもってややこしい話であるが、オープンソースソフトウェアに携わる人間としてライセンスの組み合わせは避けて通ることが出来ない問題であり、数あるオープンソースライセンスの中でも最もシェアが多いのはGPLなので、GPLの互換性に関する知識は身につけておく必要があるだろう。GPLが嫌いな人は「GPL汚染」などと揶揄してとかくGPLソフトウェアに対して脊髄反射的な嫌悪を示すことが多いのだが、それはきっと未知なるものに畏怖の念を抱くのは人間の性だからであり、しっかりライセンスを読んでよく理解すれば何も恐れる必要はないのである。
--- 引用終了 ----
105の記述 http://nippondanji.blogspot.jp/2009/11/gplbsd.html
--- 引用開始 ---
GPLソフトウェアのパッチをBSDライセンスで提供することの意義
先日の投稿「GPLが適用されているソフトウェア=MySQLのパッチをBSDライセンスでリリースする。」では、GPLが適用されているソフトウェアにBSDライセンスのパッチを提供することが出来るということを書いた。ただし、それが出来ることによってどのような意義があるのかということについては触れていなかった。その結果、
単独で動かないパッチに元のと違うライセンスをつける感覚がよくわからない。
という疑問が生じたらしい(ブコメ参照)ので、パッチをBSDライセンスで提供するということはどういうことなのかを説明しようと思う。
まず第一に、パッチ自身はBSDライセンスなので、BSDライセンスに従う限り他のプログラムへ流用することが出来る。パッチといえども、それが何かの機能を追加する類のものであれば巨大なプログラムになり得るだろう。事実、Googleが提供するMySQLのパッチもかなりデカイ。パッチの規模がでかくなれば、独立して機能する有益なロジックが多々含まれることになるだろう。パッチのライセンスがBSDライセンスであれば、その機能をGPL以外のライセンスのソフトウェア、例えばBSDライセンスのPostgreSQLなどに追加するということも可能である。つまり、パッチをBSDライセンスにすることで、MySQLとPostgreSQLに同じ機能を追加するということが出来るわけだ。
第二に、MySQLはデュアルライセンスなので、BSDライセンスで提供されたパッチであればGPL版とコマーシャルライセンス版の両方に機能を追加することが出来る。従って、BSDライセンスのパッチはMySQLにとっては都合が良いのである。(MySQLがデュアルライセンスを貫く以上、GPLで提供されたパッチは適用出来ないのである。)
ちなみに、GPLソフトウェアであるMySQL
6.0からforkしたDrizzleも、全てのContributionはBSDライセンスのもとに行われている。(Drizzleに提供された全てのソースコードはBSDライセンスが適用されている。)従って、Drizzleに追加された全ての機能は、GPL版、コマーシャルライセンス版のいずれのMySQLにも取り込むことが出来るのである。また、DrizzleにContributeされたコードは、PostgreSQLなどの他のライセンスのRDBMSソフトウェアにも取り込むことが出来るので、PostgreSQLerの人は是非Drizzleのソースコードを覗いて見ると良いのではないだろうか。ただし、Drizzleでは積極的に外部のライブラリを取り込んで利用しようという方針があるので、外部のGPLが適用されたライブラリに依存した機能については、BSDライセンスによる利用は出来ない点には注意が必要である。(もちろん元のMySQL
6.0から残っているコードはPostgreSQLに取り込むことは出来ないので注意しよう。)
さて、ここまで書くと「GPLよりBSDライセンスの方が優れている」ということを言い出す人が居るかも知れないので、この点について少し捕捉しておく。GPLとBSDライセンスを比較するのはハッキリ言って無意味である。確かにBSDライセンスの方が再利用出来るソフトウェアの範囲が広い。(商用、無償、プロプラエタリ、OSSを問わず利用可能である。)しかし一方で、GPLはソフトウェアの利用者に(それをカスタマイズすることを含めて)未来永劫最大限の自由を約束するライセンスであり、GPLを継承することによって再利用可能な場面が限定されることは、その自由を約束するために必要な措置なのである。つまり、GPLとBSDライセンスはそれぞれ異なる属性を持ったライセンス(かたやCopyleft、かたやPermissive)であり、それぞれのライセンスを適切に使い分けるのが重要だということである。ライセンスに対する理解とそれらの使い分けは、オープンソースに生きる人々にとっては最も重要な嗜みと言えるだろう。
--- 引用終了 ----
以上の引用をざっと読んだ限りでは、もとのGPLソフトを改変しても、パッチをBSDライセンスにする
ことは可能だが、GPLソフトに、BSDライセンスのパッチをあてたものはGPLライセンスでなけらば
ならないのではと思います。
そこで、 javamail-androidはOracle javamailをAndroidにポーティングしてものですが、
Oracle javamailのラインセンスはGPL、CDDLであったので、javamail-android自体はBSDライセンスを
取ることは不可能だと思うのですが、この解釈はどうでしょうか。もちろん、改変のパッチが
BSDライセンスであることは可能だと思います。
ラインセンスに詳しい人に、解釈を頂けると幸です。
> このグループに投稿するには、android-group-ja...@googlegroups.com にメールを送信してください。
> このグループから退会するには、android-group-japan+unsubscribe@googlegroups.com にメールを送信してください。
> 詳細については、http://groups.google.com/group/android-group-japan?hl=ja からこのグループにアクセスしてください。
>