先月中旬の話になるが、マイコミジャーナルで紹介されていた「事例に学ぶ オープンソース知財セミナー2010」というセミナーに参加してきた。（主催はオージス総研）サブタイトルは「オープンソースに潜む法的リスクとその対策のヒント」という謳い文句であり、オープンソース独特の法的リスクの話が聞けるかも知れないと思い申し込んだ。だが、結果は見事に裏切られた！
ひとことで言うと、今回のセミナーはオープンソースのセミナーではなかった！というのが拙者の正直な感想である。あまりにも酷い内容だったと言って差し支えない。酷かったのは各々のプレゼンの質などではなく、その欺瞞に満ちたメッセージである。そのようなメッセージを放置すると、オープンソースに対する誤った知識が広まる恐れがあるので、本エントリにて批判させて頂こうと思う。
ちょっと硬派なコンピュータフリークのBlogです。
カスタム検索
2010-12-02
2010-10-29
無料のソフトウェアをフリーソフトと呼んではイケない理由
俺のようにフリーソフトウェア＝自由なソフトウェアだという、リチャード・ストールマン支持者は当然のごとくそのような誤ちを犯してはならないのだが、そうではない全ての人にとっても無料のソフトウェアをフリーソフト（もしくはフリーウェア）と呼ぶべきではない理由がある。
2010-09-22
2010-05-31
EclipseのプラグインをGPLで公開する
今回の記事には、Eclipse界の人からすると「お前は何を言っているんだ？」と思われるようなタイトルかも知れない。Eclipseのライセンス=Eclipse Public LicenseとGPL=GNU General Public Licenseには互換性がなく、両者のライセンスを組み合わせることが出来ないのはいわば常識化している話題のひとつである。両者のライセンスが非互換であることは、フリーソフトウェア財団のライセンスページにも、EclipseのFAQページにも書かれている。
GPLには、システムライブラリはライセンスの適用範囲と見なさないという例外規定があり、プロプラエタリなOSの上でもGPLなソフトウェアが実行できるようになっている。しかし、Eclipseのようなプラットフォームに対してそのような例外は存在しない。なので、Eclipseのプラグインは、EPLとGPLの非互換性のため、GPLを適用することが基本的には出来ないのである。「基本的には」と書いたのは、GPLを適用するための裏ワザがあるからに他ならない。
GPLには、システムライブラリはライセンスの適用範囲と見なさないという例外規定があり、プロプラエタリなOSの上でもGPLなソフトウェアが実行できるようになっている。しかし、Eclipseのようなプラットフォームに対してそのような例外は存在しない。なので、Eclipseのプラグインは、EPLとGPLの非互換性のため、GPLを適用することが基本的には出来ないのである。「基本的には」と書いたのは、GPLを適用するための裏ワザがあるからに他ならない。
2010-04-21
真の自由とは？フリーソフトウェアにおける究極の選択。CopyleftかPermissiveか。
オープンソースソフトウェアにとって、ライセンスが何であるかというのは非常に大切なことである。なぜならば、ソフトウェアのライセンスの種類によっては、組み合わせることができるものと、そうでないものがあるからだ。ソフトウェアの利用制限がない「自由なライセンス」として有力なものの中には、Copyleftと呼ばれる種類のものとPermissiveと呼ばれる種類のものがある。いずれも、フリーソフトウェアライセンスとして定義されているライセンス形態であり、Copyleftで代表的なものにはGPL（GNU Public License）、Permissiveの代表格としてはBSDLやMIT Licenseなどが挙げられる。これらは一体全体どちらが真に自由をもたらすソフトウェアライセンスなのであろうか？
2009-09-08
GPLの境界線
GPLを利用するにあたって度々議論されるのが「プログラムの境界」という問題である。GPLソフトウェアを改良または組み込んで別のソフトウェアを作成すると、頒布する際に新しく作成したソフトウェアのライセンスもGPLにしなければならない。ここで注意しなければいけないのは、どこまでがそのソフトウェアの「境界」なのかということである。言い換えると、どこまでが「GPLソフトウェアを組み込んだ」状態なのかということである。自分のソフトウェアをGPLで頒布しようと考えている人にとっては、境界線はあまり意識しなくてもいいテーマである。優れたGPLソフトウェア資産は利用し放題のワンダーランドである。しかしGPL以外のライセンスを利用したいと考えている人にとっては、どこまでならGPLのソフトウェアを利用しても構わないのか？ということを明確に把握していないと、後で著作権法違反で訴えられることになってしまうので注意が必要である。そのような問題があるとなるとGPLソフトウェアを毛嫌いするようになって、極端な人は「コンピュータ内でひとつでもGPLソフトウェアが動いていればそのコンピュータ全体をGPLにしなければいけないのか？」と考えてしまう人も出てくるだろう。GPLについての知識が乏しく、「得体の知れない恐ろしいライセンス」だと考えている人はそのような誤解をしてしまうかも知れないが、しかし実際はそのようなことはない。そのように恐怖してしまうのはGPLについてよく知らないからであり、GPLについて正しい知識を身につければ無闇に恐れることもなくなるだろう。より多くの人にGPLソフトウェアを利用して貰い、時には他のライセンスを用いて上手にGPLとつきあい、時にはGPLでソフトウェアをリリースして社会に貢献することができるよう、今日はGPLの境界線について説明しようと思う。
ズバリ、境界線はプロセス
多くのOSにはGPLソフトウェア、例えばGNU tarやGCC、gdb、bash、GNOME、MySQLなどがバンドルされている。商用ライセンスのもの、例えばMac OS X Serverなどである。GPLソフトウェアをバンドルするとOS全体をGPLにしてソースコードを公開しなければいけないんじゃないか？と思うかも知れないが、そのようなことはない。GPLにおいて、「ソフトウェアを一部に取り入れた」と見なされるのはプロセスまでである。従って、GPLと同一のプロセスで動作するようにしなければ、ライセンスをGPLにしなくても良いのである。いくらMySQL Serverをバンドルしていようが、Mac OS X ServerをGPLにしなくても良いのはこのためである。
同一のプロセスとして動作するということは、
のいずれかをするということである。それ以外の場合は、安全にGPLと他のソフトウェアを組み合わせて利用することが出来るのである。
ここはMPLやCDDLなどのライセンスと大きく異なる点である。MPLやCDDLにおけるソフトウェアの境界線は「ソースコード」である。ライブラリをリンクしようが何しようが、元のソースコードに手を加えなければライセンスをMPLまたはCDDLにしなくても良い。このため、これらのライセンスはGPLとは非互換であり、コピーレフトの強制力はずっと緩い。（コピーレフトの観点からしても、互換性の点からしてもダメライセンスなのである。）
ネットワーク経由で利用する場合
GPLのサーバープログラムへネットワークを介して接続するクライアントプログラムを作成する場合、そのクライアントはGPLにしなければいけないのか？答えはNo!!である。上記の通りGPLソフトウェアの境界線はプロセスであり、ネットワークを介して接続する場合にはGPLの強制力は働かない。どのようなライセンスを採用するかは自由である。MPLでも、Apacheライセンスでも、プロプラエタリでも問題ない。
だったらMySQL Serverに接続するクライアントプログラムもGPL以外のライセンスを自由に採用してもいいのか？！と思うかも知れないが、ここには注意すべき点がある。クライアントプログラムがlibmysqlclientやConnector/J（JDBCドライバ）を利用する場合、これらのライブラリがGPLであるためリンクするとGPLの強制力が働いてしまう。MySQL Serverへ接続するプログラムをGPL以外のライセンスでリリースしたければ、これらのライブラリを利用せず自分で接続用のドライバを開発するか、libmysqlclientやConnector/Jの商用ライセンスを購入する必要がある。
インタープリターは？
もしインタープリターのライセンスがGPLだった場合はどうだろうか？実はGPLにはインタープリター上で動くプログラムに対する強制力はない。インタープリターがGPLであっても、インタープリター上で動くプログラムはGPLにしなくても良い。
ただし、インタープリターに拡張モジュールを追加した場合には注意が必要である。もしインター上で動くプログラムが拡張モジュールを利用するようであれば、そのプログラムはGPLにしなければいけない。この点はとても理解に苦しむ点かも知れない。何故ならばインタープリターがGPLでもGPLの強制力はないのに、そのインタープリターにGPLの拡張モジュールを追加した場合は強制力が働いてしまうからだ。
このようなややこしいルールが設定されている理由は明確で、それは抜け穴を塞ぐためである。もし、拡張モジュールとしてGPLのライブラリを利用しても良いのであれば、GPLのライブラリはインタープリターを介せばGPLの強制力が失われてしまうことになり、プロプラエタリな製品で利用し放題になってしまう。これではGPLの意義は失われてしまうだろう。優れたGPLライブラリがあり、そのライブラリを拡張モジュールとしてインタープリター上で動くプログラムで利用したければ、そのプログラムはGPLにしなければならないのである。
PHPやPerl、RubyなどでMySQL Serverへ接続するためのプログラムをGPLにしなければいけないのはこの制約があるからであり、これらのプログラムがMySQL Serverへ接続するための拡張モジュール（mysql拡張、mysqli拡張、DBD::mysql、MySQL/Rubyなど）はlibmysqlclientのバインディングになっているのである。GPLのlibmysqlclientを利用するため、例えインタープリター上で動くプログラムであってもGPLにしなければならないのである。
ズバリ、境界線はプロセス
多くのOSにはGPLソフトウェア、例えばGNU tarやGCC、gdb、bash、GNOME、MySQLなどがバンドルされている。商用ライセンスのもの、例えばMac OS X Serverなどである。GPLソフトウェアをバンドルするとOS全体をGPLにしてソースコードを公開しなければいけないんじゃないか？と思うかも知れないが、そのようなことはない。GPLにおいて、「ソフトウェアを一部に取り入れた」と見なされるのはプロセスまでである。従って、GPLと同一のプロセスで動作するようにしなければ、ライセンスをGPLにしなくても良いのである。いくらMySQL Serverをバンドルしていようが、Mac OS X ServerをGPLにしなくても良いのはこのためである。
同一のプロセスとして動作するということは、
- 元のGPLソフトウェアを改造
- GPLのライブラリをリンク
のいずれかをするということである。それ以外の場合は、安全にGPLと他のソフトウェアを組み合わせて利用することが出来るのである。
ここはMPLやCDDLなどのライセンスと大きく異なる点である。MPLやCDDLにおけるソフトウェアの境界線は「ソースコード」である。ライブラリをリンクしようが何しようが、元のソースコードに手を加えなければライセンスをMPLまたはCDDLにしなくても良い。このため、これらのライセンスはGPLとは非互換であり、コピーレフトの強制力はずっと緩い。（コピーレフトの観点からしても、互換性の点からしてもダメライセンスなのである。）
ネットワーク経由で利用する場合
GPLのサーバープログラムへネットワークを介して接続するクライアントプログラムを作成する場合、そのクライアントはGPLにしなければいけないのか？答えはNo!!である。上記の通りGPLソフトウェアの境界線はプロセスであり、ネットワークを介して接続する場合にはGPLの強制力は働かない。どのようなライセンスを採用するかは自由である。MPLでも、Apacheライセンスでも、プロプラエタリでも問題ない。
だったらMySQL Serverに接続するクライアントプログラムもGPL以外のライセンスを自由に採用してもいいのか？！と思うかも知れないが、ここには注意すべき点がある。クライアントプログラムがlibmysqlclientやConnector/J（JDBCドライバ）を利用する場合、これらのライブラリがGPLであるためリンクするとGPLの強制力が働いてしまう。MySQL Serverへ接続するプログラムをGPL以外のライセンスでリリースしたければ、これらのライブラリを利用せず自分で接続用のドライバを開発するか、libmysqlclientやConnector/Jの商用ライセンスを購入する必要がある。
インタープリターは？
もしインタープリターのライセンスがGPLだった場合はどうだろうか？実はGPLにはインタープリター上で動くプログラムに対する強制力はない。インタープリターがGPLであっても、インタープリター上で動くプログラムはGPLにしなくても良い。
ただし、インタープリターに拡張モジュールを追加した場合には注意が必要である。もしインター上で動くプログラムが拡張モジュールを利用するようであれば、そのプログラムはGPLにしなければいけない。この点はとても理解に苦しむ点かも知れない。何故ならばインタープリターがGPLでもGPLの強制力はないのに、そのインタープリターにGPLの拡張モジュールを追加した場合は強制力が働いてしまうからだ。
このようなややこしいルールが設定されている理由は明確で、それは抜け穴を塞ぐためである。もし、拡張モジュールとしてGPLのライブラリを利用しても良いのであれば、GPLのライブラリはインタープリターを介せばGPLの強制力が失われてしまうことになり、プロプラエタリな製品で利用し放題になってしまう。これではGPLの意義は失われてしまうだろう。優れたGPLライブラリがあり、そのライブラリを拡張モジュールとしてインタープリター上で動くプログラムで利用したければ、そのプログラムはGPLにしなければならないのである。
PHPやPerl、RubyなどでMySQL Serverへ接続するためのプログラムをGPLにしなければいけないのはこの制約があるからであり、これらのプログラムがMySQL Serverへ接続するための拡張モジュール（mysql拡張、mysqli拡張、DBD::mysql、MySQL/Rubyなど）はlibmysqlclientのバインディングになっているのである。GPLのlibmysqlclientを利用するため、例えインタープリター上で動くプログラムであってもGPLにしなければならないのである。
2009-05-25
Wikipediaのライセンスがクリエイティブコモンズになった。
ITMediaのニュースで報じられているように、WikipediaのライセンスがGFDL - GNU Free Document Licenseからクリエイティブコモンズライセンスに変更された。クリエイティブコモンズライセンスって何？と思う人も多いだろう。実は、以前からオトコのコンピュータ道にはクリエイティブコモンズライセンスを適用している。（ページ右上のCC-BY-NC-SAというのがそれである。）クリエイティブコモンズに関しては、以前の投稿で紹介したので詳しくはそちらを見て欲しい。
ここで概要を簡単に説明すると、クリエイティブコモンズはAll rights reservedではなくSome rights reservedのライセンス、つまり著作権を全て主張するのではなく、著作権の一部を主張するために考案されたライセンスである。著作権で守られたドキュメントや画像、写真、楽曲やその他著作物は再配布や二次利用が自由に出来ないが、クリエイティブコモンズライセンスによって許諾された著作物であれば可能なのである。クリエイティブコモンズライセンスでは、どのような利用方法が可能であるかを、4つの属性によって定義している。そして、その4つの属性を組み合わせることで、その著作物にどのようなライセンスが与えられているかが分かるのである。その4つの属性とは次の通り。
この度、Wikipediaで採用されることになったのは、CC-BY-SAである。明確に著作者のクレジットを表示し、なおかつ派生物に同じライセンスを与えれば、ドキュメントの改変や再配布を自由に行えるのである。CC-BY-SAははGFDLに近いが、GFDLよりライセンスが簡単で運用も楽なのである。
さて、Wikipediaのライセンスがクリエイティブコモンズになって何が変わるのだろうか？GFDLとCC-BY-SAは近いライセンスなので、実質的にはあまり変わらないというのが実情だろう。ただし、これまでCC-BY-SAでドキュメントを公開してきた人には朗報である。自由にWikipediaの文書を自らの著作物の中で利用することが出来るからである。逆に、Wikipediaで自分の文書を使われる可能性もあるが、その場合は明確にクレジット表示が残るというメリットがある。
CC-BY-SAと他のライセンスの互換性はどうか？という疑問が沸いてくることだろう。答えは、無し！！である。CC-BY-SAを用いた派生物は、CC-BY-SAライセンスでなくてはならない。ちなみに、このブログではCC-BY-NC-SAを用いているが、CC-BY-SAとは互換性がない。従って、Wikipediaの文書をこのブログで用いたり、逆にこのブログの文書がWikipediaで用いられるということはないのである。
と思った人は、クリエイティブコモンズのFAQを見るといいだろう。互換性が表にまとめられている。このブログでも引用したい。（ちなみに、引用元はCC-BYなのでライセンス的にはOKである。）
つまり、WikipediaではCC0、CC-BY、CC-BY-SAでライセンスされたドキュメントを自由に使っていいが、その他のライセンスのドキュメントは使えない。このブログでは、CC0、CC-BY、CC-BY-NC、CC-BY-NC-SAライセンスのドキュメントを使えるわけである。しかし、Wikipediaのコンテンツを流用したい場合には、CC-BY-SAライセンスを利用しなければならない。このブログのコンテンツはCC-BY-NC-SAで利用出来る。
というわけで、CC-BY-NC-SAは少々悩ましいライセンスである。Wikipediaと互換性があったほうが多くの人にとってメリットがあるのは明白なので、NCを取ろうかどうしようか考え中である。
本来なら、ブログのようなコンテンツにはCC-BY-NDが望ましいだろう。ブログのコンテンツは一つのストーリーになっているので、勝手に改変されるのは困る場合があるからだ。（自分が上海に行ったと書いた日記が改変され、北京に行ったことにされた文書が流布してしまっては困るだろう。）しかし、このブログには技術的な内容を書いており、技術的なものは加工してまとめたり内容を修正したり加筆したりすることに意味があるので、あえてNDではなくSA属性をつけている。多くの人がお互いに技術文書を改編し合って、文書の質を高められたら素晴らしいことじゃないか。
クリエイティブコモンズライセンスは元々、著作物を二次利用（再配布・改変など）する場合に生じる種々の面倒で不便な問題点を解決するために考案されたライセンスであり、そのような不便を解消して、著作活動にさらなる創造性をもたらすものである。もし、ブログなどの文書を公開する場合に、まだどんなライセンスにするかが決まっていない場合には、ぜひクリエイティブコモンズライセンス（のどれか）を選択して欲しい。
ここで概要を簡単に説明すると、クリエイティブコモンズはAll rights reservedではなくSome rights reservedのライセンス、つまり著作権を全て主張するのではなく、著作権の一部を主張するために考案されたライセンスである。著作権で守られたドキュメントや画像、写真、楽曲やその他著作物は再配布や二次利用が自由に出来ないが、クリエイティブコモンズライセンスによって許諾された著作物であれば可能なのである。クリエイティブコモンズライセンスでは、どのような利用方法が可能であるかを、4つの属性によって定義している。そして、その4つの属性を組み合わせることで、その著作物にどのようなライセンスが与えられているかが分かるのである。その4つの属性とは次の通り。
- BY・・・原作者の氏名（クレジット）を明記すること。
- NC・・・商用利用不可。（Non-Commercial）
- ND・・・改変不可。（No Derives）
- SA・・・改変したときは同じライセンスを与えること。（Share Alike）
- BY
- BY-NC
- BY-NC-SA
- BY-ND
- BY-NC-ND
- BY-SA
この度、Wikipediaで採用されることになったのは、CC-BY-SAである。明確に著作者のクレジットを表示し、なおかつ派生物に同じライセンスを与えれば、ドキュメントの改変や再配布を自由に行えるのである。CC-BY-SAははGFDLに近いが、GFDLよりライセンスが簡単で運用も楽なのである。
さて、Wikipediaのライセンスがクリエイティブコモンズになって何が変わるのだろうか？GFDLとCC-BY-SAは近いライセンスなので、実質的にはあまり変わらないというのが実情だろう。ただし、これまでCC-BY-SAでドキュメントを公開してきた人には朗報である。自由にWikipediaの文書を自らの著作物の中で利用することが出来るからである。逆に、Wikipediaで自分の文書を使われる可能性もあるが、その場合は明確にクレジット表示が残るというメリットがある。
CC-BY-SAと他のライセンスの互換性はどうか？という疑問が沸いてくることだろう。答えは、無し！！である。CC-BY-SAを用いた派生物は、CC-BY-SAライセンスでなくてはならない。ちなみに、このブログではCC-BY-NC-SAを用いているが、CC-BY-SAとは互換性がない。従って、Wikipediaの文書をこのブログで用いたり、逆にこのブログの文書がWikipediaで用いられるということはないのである。
ちょっと待て!!クリエイティブコモンズライセンスの互換性について分からなくなってきた!!
と思った人は、クリエイティブコモンズのFAQを見るといいだろう。互換性が表にまとめられている。このブログでも引用したい。（ちなみに、引用元はCC-BYなのでライセンス的にはOKである。）
| 二次的著作物 | |||||||||
| 利用される著作物 | CC -BY | CC -BY -NC | CC -BY -NC -ND | CC -BY -NC -SA | CC -BY -ND | CC -BY -SA | CC0 | ||
| CC0 | |||||||||
| CC-BY | |||||||||
| CC-BY-NC | |||||||||
| CC-BY-NC-ND | |||||||||
| CC-BY-NC-SA | オトコ | ||||||||
| CC-BY-ND | |||||||||
| CC-BY-SA | Wiki- pedia | ||||||||
つまり、WikipediaではCC0、CC-BY、CC-BY-SAでライセンスされたドキュメントを自由に使っていいが、その他のライセンスのドキュメントは使えない。このブログでは、CC0、CC-BY、CC-BY-NC、CC-BY-NC-SAライセンスのドキュメントを使えるわけである。しかし、Wikipediaのコンテンツを流用したい場合には、CC-BY-SAライセンスを利用しなければならない。このブログのコンテンツはCC-BY-NC-SAで利用出来る。
というわけで、CC-BY-NC-SAは少々悩ましいライセンスである。Wikipediaと互換性があったほうが多くの人にとってメリットがあるのは明白なので、NCを取ろうかどうしようか考え中である。
本来なら、ブログのようなコンテンツにはCC-BY-NDが望ましいだろう。ブログのコンテンツは一つのストーリーになっているので、勝手に改変されるのは困る場合があるからだ。（自分が上海に行ったと書いた日記が改変され、北京に行ったことにされた文書が流布してしまっては困るだろう。）しかし、このブログには技術的な内容を書いており、技術的なものは加工してまとめたり内容を修正したり加筆したりすることに意味があるので、あえてNDではなくSA属性をつけている。多くの人がお互いに技術文書を改編し合って、文書の質を高められたら素晴らしいことじゃないか。
クリエイティブコモンズライセンスは元々、著作物を二次利用（再配布・改変など）する場合に生じる種々の面倒で不便な問題点を解決するために考案されたライセンスであり、そのような不便を解消して、著作活動にさらなる創造性をもたらすものである。もし、ブログなどの文書を公開する場合に、まだどんなライセンスにするかが決まっていない場合には、ぜひクリエイティブコモンズライセンス（のどれか）を選択して欲しい。
2009-05-12
FOSS License Exception
MySQLにはFOSS License Exceptionという制度がある。そのような制度があることはあまり知られていないし、名前を知っていても内容はよく知らない、または誤解しているという人が結構居る。そこで、FOSS License Exceptionについて改めてここで紹介したい。
MySQL FOSS License Exception
http://www.mysql.com/about/legal/licensing/foss-exception/
知っての通り、MySQLはデュアルライセンスだ。無料で公開されているMySQL Community ServerはGPLv2でライセンスされており、その他に有料のコマーシャル・ライセンス版が存在する。コマーシャル・ライセンス版はソースコードを公開したくないユーザー向けのライセンスで、俗にOEM版とも呼ばれる。
さて、FOSS License Exceptionが対象とするのは、GPLv2版のMySQLサーバーである。GPLv2のソフトウェアをバンドル（正式にはリンク）したソフトウェア、または改変したソフトウェアは、ライセンスをGPLv2にしなければならない。多くのオープンソースプロジェクトの場合、GPLv2は最も良く利用されているライセンスであるので、自分が作成したソフトウェアをGPLv2にすることが問題になることはさほどないだろう。だが、GPLv2と互換性のないライセンスのライブラリを利用したい場合にはそうは問屋が卸さない。例えばApacheライセンスなどだ。
とあるApache 2.0ライセンスのライブラリがとても有用で、どうしてもそのライブラリを利用したいとする。だが一方でGPLv2版のMySQLも利用したい。しかしGPLv2とApacheライセンスは互換性がないので同時に利用することができない。はてさてどうしたものか？！
というわけで、そこで登場するのがFOSS License Exceptionという制度なのだ。これは、MySQL（サン・マイクロシステムズ）が許可したオープンソース・ライセンスに限って、GPLv2版のMySQLを利用した場合でもそのソフトウェア全体のライセンスをGPLv2にしなくてもいいですよという制度なのだ。そうすると、上記のような場合は、その作品にApache 2.0ライセンスを適用すれば、GPLv2版のMySQLの利用とApache 2.0ライセンスのライブラリのリンクを同時に行う事が可能になる。
FOSS License Exceptionで認められているライセンスの全リストは、上記のページに載っているので参照して欲しい。先に挙げたApache 1.0/1.1/2.0ライセンスやBSDライセンス、PHPライセンスなどがリストアップされている。
当然のことであるが、プロプラエタリなソフトウェアにはこの制度は適用されない。GPL違反をすると、MySQL（サン・マイクロシステムズ）は違反者を法的に訴えることが出来るので注意しよう。（そしてコマーシャル・ライセンスを買って貰ってライセンス料を頂いたりする。）しかし、オープンソース・ソフトウェアに対してそのようなことをしてもナンセンスである。なぜなら、オープンソース・ソフトウェアは無料で配布されていることが多いからだ。MySQLはオープンソースを支持しているので、自身はGPLv2であるが他のオープンソース・ソフトウェアで利用できるようにFOSS License Exceptionのような仕組みがあるのだ。
一点注意しなければならないのは、FOSS License Exceptionを適用した場合でも、バンドルされるMySQLは依然としてGPLv2として残るということだ。つまり、作品全体はGPLv2ではないオープンソース・ライセンスであったとしても、その一部にGPLv2のコンポーネントが含まれることになる。そのソフトウェアを利用して別の新たなソフトウェアをリリースする場合には、再度GPL違反にならないように注意しなければならない。例えば、PHPはPHPライセンスでリリースされているが、MySQLとの接続をサポートしている場合（つまりlibmysqlclient.soとリンクしている場合）にはFOSS License Exceptionが適用されているわけである。（そうでなければPHPはGPLv2ライセンスを適用しなければならない。）その場合、MySQLとの接続を前提にしたPHPソフトウェアを頒布する場合にば、GPLv2ライセンスまたはFOSS License Exceptionの対象になるオープンソース・ライセンスだけを適用することが出来るわけである。
MySQLを利用してプロプラエタリなソフトウェアをリリースしたい場合には、やっぱりコマーシャル・ライセンスが必要なのである。
MySQL FOSS License Exception
http://www.mysql.com/about/legal/licensing/foss-exception/
知っての通り、MySQLはデュアルライセンスだ。無料で公開されているMySQL Community ServerはGPLv2でライセンスされており、その他に有料のコマーシャル・ライセンス版が存在する。コマーシャル・ライセンス版はソースコードを公開したくないユーザー向けのライセンスで、俗にOEM版とも呼ばれる。
さて、FOSS License Exceptionが対象とするのは、GPLv2版のMySQLサーバーである。GPLv2のソフトウェアをバンドル（正式にはリンク）したソフトウェア、または改変したソフトウェアは、ライセンスをGPLv2にしなければならない。多くのオープンソースプロジェクトの場合、GPLv2は最も良く利用されているライセンスであるので、自分が作成したソフトウェアをGPLv2にすることが問題になることはさほどないだろう。だが、GPLv2と互換性のないライセンスのライブラリを利用したい場合にはそうは問屋が卸さない。例えばApacheライセンスなどだ。
とあるApache 2.0ライセンスのライブラリがとても有用で、どうしてもそのライブラリを利用したいとする。だが一方でGPLv2版のMySQLも利用したい。しかしGPLv2とApacheライセンスは互換性がないので同時に利用することができない。はてさてどうしたものか？！
というわけで、そこで登場するのがFOSS License Exceptionという制度なのだ。これは、MySQL（サン・マイクロシステムズ）が許可したオープンソース・ライセンスに限って、GPLv2版のMySQLを利用した場合でもそのソフトウェア全体のライセンスをGPLv2にしなくてもいいですよという制度なのだ。そうすると、上記のような場合は、その作品にApache 2.0ライセンスを適用すれば、GPLv2版のMySQLの利用とApache 2.0ライセンスのライブラリのリンクを同時に行う事が可能になる。
FOSS License Exceptionで認められているライセンスの全リストは、上記のページに載っているので参照して欲しい。先に挙げたApache 1.0/1.1/2.0ライセンスやBSDライセンス、PHPライセンスなどがリストアップされている。
当然のことであるが、プロプラエタリなソフトウェアにはこの制度は適用されない。GPL違反をすると、MySQL（サン・マイクロシステムズ）は違反者を法的に訴えることが出来るので注意しよう。（そしてコマーシャル・ライセンスを買って貰ってライセンス料を頂いたりする。）しかし、オープンソース・ソフトウェアに対してそのようなことをしてもナンセンスである。なぜなら、オープンソース・ソフトウェアは無料で配布されていることが多いからだ。MySQLはオープンソースを支持しているので、自身はGPLv2であるが他のオープンソース・ソフトウェアで利用できるようにFOSS License Exceptionのような仕組みがあるのだ。
一点注意しなければならないのは、FOSS License Exceptionを適用した場合でも、バンドルされるMySQLは依然としてGPLv2として残るということだ。つまり、作品全体はGPLv2ではないオープンソース・ライセンスであったとしても、その一部にGPLv2のコンポーネントが含まれることになる。そのソフトウェアを利用して別の新たなソフトウェアをリリースする場合には、再度GPL違反にならないように注意しなければならない。例えば、PHPはPHPライセンスでリリースされているが、MySQLとの接続をサポートしている場合（つまりlibmysqlclient.soとリンクしている場合）にはFOSS License Exceptionが適用されているわけである。（そうでなければPHPはGPLv2ライセンスを適用しなければならない。）その場合、MySQLとの接続を前提にしたPHPソフトウェアを頒布する場合にば、GPLv2ライセンスまたはFOSS License Exceptionの対象になるオープンソース・ライセンスだけを適用することが出来るわけである。
MySQLを利用してプロプラエタリなソフトウェアをリリースしたい場合には、やっぱりコマーシャル・ライセンスが必要なのである。
2009-04-30
中国によるソースコード開示要求・・・変更
中国、ＩＴ情報強制開示制度の導入発表…適用は来年５月
http://www.yomiuri.co.jp/atmoney/news/20090429-OYT1T00633.htm
というわけで、
開示制度を施行するにあたっては、次の点について明確にしないといけないと思う。
http://www.yomiuri.co.jp/atmoney/news/20090429-OYT1T00633.htm
というわけで、
- ソースコードの開示制度の導入は1年間延期
- 適用範囲は中国市場全体から政府調達へ縮小
開示制度を施行するにあたっては、次の点について明確にしないといけないと思う。
2009-04-25
中国によるソースコード開示要求についての考察 - その2
中国によるソースコードの開示要求に従ってソースコードを公開しても、「知財」と呼ばれるもの、即ち「著作権」「特許」「商標」のいずれについても失われることはないということは、昨日の記事で書いた通りである。権利という側面だけから見ると、諸外国の企業は失うものがないどころか、逆に中国企業が深刻なダメージを受ける可能性が高い。（こっそりGPLのソースコードを流用している企業はたちまちビジネスを停止する羽目になるだろう。）
2009-04-24
中国によるソースコード開示要求についての考察
中国、ＩＴソースコード強制開示強行へ…国際問題化の懸念
http://www.yomiuri.co.jp/atmoney/news/20090424-OYT1T00053.htm
SunがOracleに買収され、草なぎが脱ぎ、驚きのニュースが続くなあと思っていたら、今度は中国からビックリなニュースの到来である。なんと、中国で販売するIT製品はソースコードを開示しなければいけなくなるというのだ。これは一見すると、俺のようなフリーソフトウェア支持者またはオープンソース支持者にとって歓迎のニュースのように思えるだろう。しかし果たしてそうだろうか？
多くのニュースサイトで見られるのが「知財流出」という表現。知財という言葉は、多くの内容を包括しているのでどうしても意味がぼやけてしまう。実は「知財」という観点からすると、ソースコードをオープンにするだけでは何も失わない可能性すらある。なぜか？
http://www.yomiuri.co.jp/atmoney/news/20090424-OYT1T00053.htm
SunがOracleに買収され、草なぎが脱ぎ、驚きのニュースが続くなあと思っていたら、今度は中国からビックリなニュースの到来である。なんと、中国で販売するIT製品はソースコードを開示しなければいけなくなるというのだ。これは一見すると、俺のようなフリーソフトウェア支持者またはオープンソース支持者にとって歓迎のニュースのように思えるだろう。しかし果たしてそうだろうか？
多くのニュースサイトで見られるのが「知財流出」という表現。知財という言葉は、多くの内容を包括しているのでどうしても意味がぼやけてしまう。実は「知財」という観点からすると、ソースコードをオープンにするだけでは何も失わない可能性すらある。なぜか？
2009-04-01
GPLに対するオトコの個人的見解
なぜ自分がMySQL関係の仕事をしているのか？もちろんMySQLが技術的に面白いということや、MySQLの優れた性能に惹かれているという部分はあるが、それよりも何よりもライセンスがGPLだということが一番の理由である。なぜGPLがいいのか？それは最も自由なライセンスだからである。
2008-03-30
クリエイティブ・コモンズ考察。
クリエイティブ・コモンズというライセンスがある。日本ではまだそれほどメジャーではないが、非常に有用なライセンスなので紹介しようと思う。（個人的にもこれから使っていこうと考えている。）ライセンスは星の数ほどあるのになぜクリエイティブ・コモンズなのか？
まず、参考になる文献の紹介から。荒川 靖弘さんの『「クリエイティブ・コモンズ」について』
http://www.alles.or.jp/~spiegel/docs/cc-about.html
まず、参考になる文献の紹介から。荒川 靖弘さんの『「クリエイティブ・コモンズ」について』
http://www.alles.or.jp/~spiegel/docs/cc-about.html
登録:
投稿 (Atom)
