9月末にソフトバンククリエイティブから、「ソフトウェアライセンスの基礎知識」という本を出します。単にオープンソースのことを解説するのではなく、オープンソースライセンスについて詳しく解説しています。今までも、オープンソースの概略を紹介する読み物的な本を2冊出して来ました。その中で、ライセンスについて解説した章は、コンパクトでありながら割と評価を頂いてきました。それを一冊の本として、重要なポイントまでしっかりと解説しています。
- 著者: 可知 豊
- サイズ: A5/1色
- 頁数: 296ページ
- 価格: 2415円(税込み)
- 出版社: ソフトバンククリエイティブ (2008/9/25)
- ISBN-10: 4797347368
- ISBN-13: 978-4797347364
- 発売日: 2008/9/25
- 「ソフトウェアライセンスの基礎知識」サポートページ
この企画をいただくまでは、オープンソースの普及を考えるとき、ライセンスのことはあまり強調しないほうが良いのかなぁ、と考えていました。しかし、ソフトバンククリエイティブの編集者である白川さんから、オープンソースのライセンスに特化した本を書きませんかという、まったく逆の提案を頂きまして。それは、ほかにないオリジナリティのあふれる本になりそうだ、ということで引き受けました。
著作権の解説からスタートして、オープンソースライセンスの仕組み、代表的なオープンソースライセンスの内容まで幅広く解説しています。さらに、オープンソースソフトウェアを作っている人(Matzさん、Mozilla Japan)、利用している企業(NTTデータ、NRI、楽天)に、その取り組みについてインタビューしています。お忙しい中、ご協力頂いた皆様に感謝します。なかなか活字にならない、つっこんだ話を伺うことができましたし、いずれも本気でオープンソースで取り組んでいることがあらためて確認できて感動しました。
本書では、オープンソースライセンスの理解をふまえて、そのビジネスモデルについても説明しています。これは、前著にあたる「オープンソースでビジネスが変わる」という本へのコメントを踏まえたものです。OSSを活用してビジネスしたいと考えている企業にも、役に立つんじゃないかと思います。
皆様のご意見ご感想なども承っております。このページにコメントしてください。今回は、内容が内容だけに、サポートページも用意しています。アップデート情報は、そちらに集約していきます。
本書が、読者の皆様のお役に立てば幸いです。
ピンバック: Placebo Effect » 書籍プレゼント:ソフトウェアライセンスの基礎知識
ピンバック: Placebo Effect » 拙著をご紹介頂きました。
ピンバック: Placebo Effect » Re:ソフトウェアライセンスの基礎知識 in kozawa のたまに気になること
ピンバック: Placebo Effect » ソフトウェアライセンスの基礎知識 in and feel
ピンバック: Placebo Effect » ソフトウェアライセンスの基礎知識 in marsのメモ
ピンバック: Placebo Effect » プレゼント発送しました for ソフトウェアライセンスの基礎知識
オープンソースライセンスについて非常に分かりやすくまとめられており、大変興味深く読まさせていただきました。
ただ、一点、よく分からないことがありましたので、教えてください。
P130において、「GPL/LGPLでは「元と同じ条件で利用可能」にすればいため、…。たとえば、追加モジュールを修正BSDライセンスで公開してもよい。」と書かれていますが、この「元と同じ条件で利用可能」はGPLの第2条の「あなたが同じ部分を『プログラム』を基にした著作物全体の一部として頒布するならば、全体としての頒布物は、この契約書が課す条件 に従わなければならない。」を指していますでしょうか。
また、実際に追加モジュールを修正BSDライセンスで公開しているOSSはありますでしょうか。
typoを一つ見つけました
P3 Iniciative -> Initiative
mizkazさん >>
拙著について、お褒めの言葉を頂きありがとうございます。
また、TYPOのご指摘も御礼申し上げます。
ご質問の件は、確認しておきます。
少々お待ちください。
mizkazさん >>
質問への回答です。
—
P130において、「GPL/LGPLでは「元と同じ条件で利用可能」にすればいため、…。たとえば、追加モジュールを修正BSDライセンスで公開してもよい。」と書かれていますが、この「元と同じ条件で利用可能」はGPLの第2条の「あなたが同じ部分を『プログラム』を基にした著作物全体の一部として頒布するならば、全体としての頒布物は、この契約書が課す条件 に従わなければならない。」を指していますでしょうか。
—
P.130における「GPL/LGPLでは「元と同じ条件で利用可能」にすればいいため、…。たとえば、追加モジュールを修正BSDライセンスで公開してもよい。」という記述は、”モジュールを追加して配布する”場合について説明しています。
GPL/LGPL適用時にモジュールの利用条件は、GPL v2 FAQの「GPLで保護されたモジュールに対してあるモジュールを追加する場合、私のモジュールにもライセンスとしてGPLを適用しなければなりませんか?」http://www.gnu.org/licenses/gpl-faq.ja.html#GPLModuleLicenseを参考に記述しています。
ご回答有り難うございます。
「追加モジュール」と「ライブラリとリンクするプログラム」の違いがよく分からなくなってきました。
「ライブラリとリンクする」の最後、
「GPL/LGPLでは、「モジュールを追加して配布する」と同じである。」というのは、すなわち、追加モジュールと同じくGPLと矛盾しないライセンスであればよいという意味でしょうか。
そうなると、http://www.gnu.org/licenses/gpl-faq.ja.html#IfLibraryIsGPL の回答と矛盾しませんか。
私の理解では、GPLの場合、リンクするのであればGPLで提供、独立的に作ったモジュール(GPLのモジュールとはリンクしない)を分けて頒布する場合はライセンスは全くの自由、分けずにGPLプログラムの全体の一部として頒布する場合はGPL互換のライセンスでなければならない、です。
>「追加モジュール」と「ライブラリとリンクするプログラム」の違いがよく分からなくなってきました。
ああ。
私が”追加モジュール”という言葉を、曖昧に使ってしまっているのかも。
ちょっと整理してみます。
面白かったです。とても参考になります。
組込みソフトウェアが専門なので、そのままでは使えないかもしれませんが、この知識をベースにさらに調べてみたいと思います。
で、Typoっぽいところがありました。
P.114「Artstic」→「Artistic」
タイトル「Licence」→「License」
タイトル以外は「License」で統一されているっぽいのですが、、
mmmさん
コメントありがとうございます。
また、Typoのご指摘、感謝します。
どちらも、痛いトコロでした。
mizkazさん>>
>「追加モジュール」と「ライブラリとリンクするプログラム」の違いがよく分からなくなってきました。
私見ですが、特定モジュールへのリンクと、ライブラリへのリンクの違いを理解するカギは、”その役割に汎用性があるかないか”ではないでしょうか。リンクすること自体には違いはありません。ただ、特定モジュールへのリンクを避けたいなら、特定モジュールそのものを実装し直すという選択肢があります。それに対して汎用な機能を持つライブラリへのリンクを避けるために実装しなおすのは、いろいろ大変そうです。
>「ライブラリとリンクする」の最後、
「GPL/LGPLでは、「モジュールを追加して配布する」と同じである。」というのは、すなわち、追加モジュールと同じくGPLと矛盾しないライセンスであればよいという意味でしょうか。
そういう意味で書いていますが、記述として踏み込み過ぎなので、改訂では削除したいと思います(改訂できるか不明ですが)。また、追加モジュールに関する記述も、参考リンクとしてGPL2FAQを追記します。どちらも正誤表に反映しました。
さて、拙著の記述だけでなく、GPL2FAQの二つの項目に、すでに差異がありますね。ただ、矛盾はしていないように思いました。
◎GPLで保護されたモジュールに対してあるモジュールを追加する場合、私のモジュールにもライセンスとしてGPLを適用しなければなりませんか?
GPLでは、結合されたプログラムの全体はGPLの下で公開されなければならないとしています。ですから、あなたのモジュールは**GPLの下での利用が可能**でなければなりません。
http://www.gnu.org/licenses/gpl-faq.ja.html#GPLModuleLicense
◎ライブラリが(LGPLではなく)GPLの下で公開されている場合、そのライブラリを利用するプログラムにはGPLが適用されていなければならないのでしょうか?
はい。なぜなら、実際に実行されるプログラムはライブラリを含んでいるからです。
http://www.gnu.org/licenses/gpl-faq.ja.html#IfLibraryIsGPL
前者では、”GPLの下での利用が可能でなければならない”としています。後者では、”ライブラリを利用するプログラム”は”GPLを適用しなければならない”としています。”ライブラリを利用するプログラム”というのは、”ライブラリとリンクするモジュール”だけでなく、”ライブラリとリンクしたモジュールを含むプログラム全体”も表しているように思います。
前者の場合、GPLedなモジュールAがあって、それとリンクするモジュールBとすると
– モジュールBを単体で配布 >> GPLの下での利用が可能にする
– モジュールAとBを同梱したパッケージ全体 >> GPLを適用(なぜなら、モジュールAを含んでいるから)
となります。
後者の場合、GPLedなライブラリがあって、それとリンクするモジュールCとすると
– GPLedなライブラリとモジュールCを含むプログラム全体 >> GPLを適用(なぜなら、ライブラリを含んでいるから)
となると思います。
では、このモジュールCを単体で配布する場合は、どうなるんでしょう?
単なる追加モジュールと考えれば、”GPLで利用可能”にすれば良いと理解していますが、具体的な記述がないので、私の説明が踏み込みすぎだと思います。
とはいえ、先にも書いたように、GPLが適用された汎用ライブラリを何かで置き換えるのは、いろいろ大変そうです。すでに代替品があれば別ですが、その場合は戦略的にLGPLを適用していそうです。
関連:
GPLの下で公開されていたプログラムがプラグインを使うとして、プラグインのライセンスにはどのような条件がありますか?
http://www.gnu.org/licenses/gpl-faq.ja.html#GPLAndPlugins
フリーではないプログラム向けのプラグインにGPLを適用することはできますか?
http://www.gnu.org/licenses/gpl-faq.ja.html#GPLPluginsInNF
独占的なモジュールを、私のGPLで保護されたライブラリと指定したインターフェースの下でのみリンクすることを許可するにはどうしたらよいでしょうか?
http://www.gnu.org/licenses/gpl-faq.ja.html#LinkingOverControlledInterface
あなたの次のライブラリにはライブラリGPLを適用するべきでない理由
http://www.gnu.org/licenses/why-not-lgpl.ja.html
回答してくださっていたんですね。気付くのが遅れてしまいました。
さて、「汎用性」の差というのは違うと思います。「汎用性」があるかないかは主観的な部分が多々あるので法的文書には不適切な気がします。
やはり「追加」と「リンク」は別のことだと思います。
「追加」の場合は「GPLの下での利用が可能」でなければならないので、GPLでなくてもGPLと矛盾しないライセンスであればよく、
「リンク」の場合は、「GPLを適用」しなければならない、
のだと思います。
「追加」というのが具体的にどういうものかイメージしにくいのですが、たとえばプログラムを起動するためのシェルとかでしょうかね。
コメントありがとうございます。
>「追加」というのが具体的にどういうものかイメージしにくいのですが、たとえばプログラムを起動するためのシェルとかでしょうかね。
ここまでくると、私が説明に使っている言葉では、やらないほうがいいのかも知れません。GPL2では、「派生プログラム」にコピーレフトを適用するとしています。そして、どのような行為を派生プログラムと見なすかは、はなはだ曖昧です。その曖昧な部分を説明するため”追加”という言葉を使っていますが、間違っている可能性はあります。
さて、GPL2では、派生プログラムと見なさない物の例として次のように説明しています。
—
逆に、パイプやソケット、コマンドライン引数は通常二つの分離したプログラムの間で使われるコミュニケーションメカニズムです。ですからそれらがコミュニケーションのために使われるときには、モジュールは通常別々のプログラムです。しかしコミュニケーションのセマンティクスが親密であったり、複雑な内部データ構造を交換したりする場合は、それらも二つの部分がより大規模なプログラムに結合されていると考える基準となりうるでしょう。
—
http://www.gnu.org/licenses/gpl-faq.ja.html#MereAggregation
ご参考になれば幸いです。
ああ。スミマセン。読み直したら大きな間違いをしていました。
>GPL2では、「派生プログラム」にコピーレフトを適用するとしています。
「派生プログラム」->「派生物」です。
派生物とはなんぞ、というのは、経済産業省の報告書が詳しく解説しています。
http://www.meti.go.jp/kohosys/press/0004397/
はじめまして。
「ソフトウェアライセンスの基礎知識」を購入させていただきました。
大変わかりやすく、ためになりました。
質問させていただきたいのですが、Movable TypeやWord Pressといったブログを設置するソフトはテンプレートというものがあり、それは当然変更して使用するわけですが、これはソースの改変に該当するのでしょうか。そうなった場合は改変点を公開しなくてはならないことになりますよね。
お手数ですがご教授いただけないでしょうか。
よろしくお願いいたします。
Yukihiroさん、コメントありがとうございます。
> これはソースの改変に該当するのでしょうか。
一般的に、ソースの改変に該当すると思います。
> そうなった場合は改変点を公開しなくてはならないことになりますよね。
改変版を公開する必要があるかどうか、テンプレートのライセンス次第だと思います。オープンソースでもいろいろなライセンスがありますから、改変版を公開しなくても良い場合もあります。
まずは、テンプレートの利用条件を確認してはいかがでしょうか。
catch様
なるほど。
僕のイメージですとソースコードが吐き出した生成物なので、ソースには該当しないとの解釈でした。
テンプレートの利用条件などを改めて調べてみたいと思います。
ご回答いただきありがとうございました。
Yukihiroさん、何度もありがとうございます。
テンプレートと呼んでいるのは、WordPressだったらTheme(テーマ)という奴ですよね。場合によってはスキンと呼ぶのでしょうか、ブログの見栄えを変える奴。
これは、WordPressが吐き出す(自動的に生成する)のではなく、デザイナーさんがコーディングした成果物かと思っていました。であるならば、Wordpressのライセンスには影響を受けないと考えたのです。
いかがでしょうか。
ブログ及び「ソフトウェアライセンスの基礎知識」
で色々勉強させていただいております。
さて、本について1点質問があります。
P102 のCPL/EPLのライセンスに関する記述で
「ソースコードを改変した場合には、同じライセンスで公開する義務がある」
と書かれています。
一方で、IBMの「Common Public License (CPL) に関するFAQ」
(http://www.ibm.com/developerworks/jp/opensource/library/os-cplfaq.html)
の Q16 では、
「CPL の下でライセンスされたプログラムを変更せずにコンパイルし、
そのコンパイルしたものを CPL の条項に従って商用ライセンスで
頒布することができます」
とあります。
「改変プログラム」と「変更せずにコンパイルした物」という
違いがありますが、上記の2つの記述は矛盾しているように
読み取れてしまうのですが、当方の勘違いでしょうか?
# CPLのプログラムを改変した物はCPLで頒布しなくてはいけないが
# そのリリースされたプログラムをそのままコンパイルした物は
# 商用ライセンスで頒布できる。
# つまり、改変したプログラムを商用ライセンスで頒布したい
# 場合は、一度、CPLで頒布した後でそれを商用ライセンスに
# しなくてはいけないのか?という疑問が生じたため
# 質問させていただきました。
# 貴著の記述を読む前までは、改変プログラムを
# (CPLの第3条に従った)ライセンスで公開すればよいと
# 考えていました。
また、お手数でなければ
「ソースコードを改変した場合には、同じライセンスで公開する義務がある」
の根拠となる条文を教えていただけるとうれしいです。
(第3条の「a) 本契約書の条項に従い」の部分?)
以上よろしくお願いします。
k164さん、拙著をお読みいただきありがとうございます。
私の理解では、「CPLでは、コンパイル(コンピュータによる実行形式への変換)は、”プログラムの変更”(改変プログラム)ではない」ということだと思います。
第1条にあるとおり、
プログラムの派生物であるもの
・プログラムへの変更
・プログラムへの追加
プログラムの派生物でないもの
・別モジュール
・プログラムへの変更・追加でないもの
となります。このとおりに明記されていませんが、論旨を読みとると
こうなると理解しています。
一方、k164さんは「コンパイル = プログラムへの変更」を前提にしているように、
私には見えます。
>「ソースコードを改変した場合には、同じライセンスで公開する義務がある」
>の根拠となる条文を教えていただけるとうれしいです。
>(第3条の「a) 本契約書の条項に従い」の部分?)
第1条で、コントリビューションとは、プログラムへの変更と追加(別モジュールと派生物でないものは除く)と定義されています。そして、第3条で、コントリビュータの取ってよい行動が示されていますが、その対象は、第1条にあるとおりコントリビューションとなります。
私見ですが、コントリビューションとコントリビュータは、それぞれ「提供物」「提供者」という意味になると思います。提供物を提供する者が提供者で、提供者が提供する物が提供物という関係です。
参考になれば幸いです。
回答ありがとうございます。
ご指摘の通り、「コンパイルした物」であったり、
コンパイル結果である、実行モジュール(CPL上の表現では
オブジェクトコード)の扱いが私には理解できていないようです。
<1点目>
私が、「貴著の記述とIBMのCPLのFAQに矛盾があるのでは?」
と質問した点に関しては、
可知さんの「”プログラムの変更”(改変プログラム)ではない」
という解説ですっきりしました。ありがとうございます。
<2点目>
質問
>「ソースコードを改変した場合には、同じライセンスで公開する義務がある」
>の根拠となる条文を教えていただけるとうれしいです。
回答
>第1条で、コントリビューションとは、プログラムへの変更と追加
>(別モジュールと派生物でないものは除く)と定義されています。
>そして、第3条で、コントリビュータの取ってよい行動が示されていますが、
>その対象は、第1条にあるとおりコントリビューションとなります。
に関しては少し理解ができませんでした。
第3条では、「オブジェクトコード形式のプログラムを独自のライセ
ンス契約に基づいて頒布することができます。」
とあります(その後に記述されている1回目の a b の条件を守る必要がありますが)。
で、ソースコードの開示要求があった場合には、
第3条の2回目の a で定められている通り、ソースコードは
本契約書(CPL)で利用できるようにする義務があると解釈しました。
つまり、貴著の
「ソースコードを改変した場合には、同じライセンスで公開する義務がある」
という文章は
「ソースコードを改変した場合には、(ソースコードに関しては)同じライセンスで公開する義務がある」
という風に解釈してよろしいでしょうか?
それともオブジェクトコードの頒布の時点でCPLとする必要があるのでしょうか?
k164さん、こんばんは。
>それともオブジェクトコードの頒布の時点でCPLとする必要があるのでしょうか?
これは、私の説明が間違っていますね。
「3. 要件
コントリビューターは以下の条件をすべて満たす限りにおいて、オブジェクトコード形式のプログラムを独自のライセンス契約に基づいて頒布することができます。
a) 本契約書の条項に従い、 」
とあります。つまり、”CPLと同じライセンス”に限らず、”CPLと互換性のあるライセンスで公開する”ということになると思います。
如何でしょうか。
お忙しい中、再び回答をいただきありがとうございます。
> つまり、”CPLと同じライセンス”に限らず、”CPLと互換性のあるライセンスで公開する”ということになると思います。
という部分が少し理解できませんでした。
CPLのプログラムAを私が改変してプログラムBを作って、そのオブジェクトコードのみを頒布する場合。第3条の第1段落の「a) 本契約書の条項に従い」は、
「(プログラムBのライセンスが)本契約書の条項に従い」
ではなく、
「(私がプログラムAを使う時に)本契約書の条項に従い」
という文書だと解釈できると思います。
理由1:第3条の第1段落に「b) そのライセンス(=独自のライセンス契約)契約が」とわざわざ、ライセンスの話と別に a 記載されている点。
理由2:第3条の第1段落 b に「iii) 本契約書と異なる条項を含んでいる場合は、(略)」とあるということはCPLと違う条項を含まれる可能性を想定している。
従いまして私の解釈では、プログラムBのオブジェクトコードのみ頒布する場合は、
・独自のライセンスを適用することができる(=CPLとの互換性は無関係)
・但し、独自のライセンスは 第3条の第1段落 b の i ~ iv を満たす必要あり。
という状況だと考えております。
なので、例えば「(私が頒布した)プログラムBのオブジェクトコードは再頒布禁止」とかしても良いのだと思っています。
一方で、第3条の第1段落 b の iv でソースコードの開示を義務付けられていて、そのソースコードはCPLで頒布しないといけないので、誰かがプログラムBのソースコードを要求してそれをコンパイルして頒布することはできてしまいます。なので、プログラムBのオブジェクトコードを頒布する道は残ってしまうので「違う条件を付けてもあまり意味がない」という状況になるのだと考えています。
以上が私の解釈になるのですがいかがでしょうか?
k164さん。
回答が遅くなり失礼しました。
>CPLのプログラムAを私が改変してプログラムBを作って、そのオブジェクトコードのみを頒布する場合。第3条の第1段落の「a) 本契約書の条項に従い」は、
>「(プログラムBのライセンスが)本契約書の条項に従い」
>ではなく、
>「(私がプログラムAを使う時に)本契約書の条項に従い」
>という文書だと解釈できると思います。
なるほど。賛成できる部分と、意見が異なる部分があります。
まず、対象と、その頒布条件を、再確認してみました。
CPLで登場する対象は
・初期コントリビュータによる頒布(1. 定義 a項)
・後続の各コントリビューターによる頒布(1. 定義 b項、改変あり)
・受領者:単なる再頒布(改変なし)
ですね。
そして第3条で、「コントリビューター」による頒布条件を説明しています。コントリビュータとは、第1条先で定義されていて、対象の1番目と2番目です。なので、k164さんが書いた「CPLのプログラムA」と「改変してプログラムB」の両方となります。
そして、第3条ではオブジェクトコードの配布の場合として
・a) 本契約書の条項に従い、しかも
・b-i、b-ii 免責条項
・b-iii:ライセンスを変更する場合、対象の限定
・b-iv:ソースコードの入手保証
となっています。
a項に「しかも」がついているので、a項とb項はAND(両方を満たす)です。
となると、コントリビュータ(初期 or 後続の改変有り)がオブジェクトコードを配布する場合、「CPLに互換性があり」かつ「b項」を満たす条件で配布する、ということではないでしょうか。
度重なる長文の質問に対する回答ありがとうございます。
残念ながら今回の回答に関しては私の納得できる回答ではありませんでした。
一方で、私の状況としては「違うライセンスで頒布する」ことが目的ではなく「CPLで頒布するにあたり自分で使うライセンスを正しく理解してから使いたい」ということが目的であり、この件については、「私はこう思う。けど、違う考えをする人もいる」というのを結論として十分な状態にあります。
可知さんもお忙しいと思いますので、この辺でこの質問は打ち切りとさせていただこうかと考えております(議論を続けた方がよければ、コメントいただければ続きを書かさせていただきますが)。
色々勉強になりましたありがとうございました。
> 色々勉強になりましたありがとうございました。
こちらこそ、貴重なご意見をありがとうございました。
機会がありましたら、またよろしくお願いします。