内容に「License」を含む
1〜10件目 / 16件
1 2 次へ

 GPL解説vol.8―定義集― / マルパチ 

前回の記事プロパゲート(propagate)という謎の言葉が飛び出してきました。またGPLv3第11条3パラグラフを読んでみた人はコントリビューター(contributor)や必須特許クレーム(essential patent claims)といったわけのわからない用語に悩まされたかも知れません。
今回はそういった用語の「定義」に関する記事です。

法典(会社法など)や法律文書(ライセンスなど)には一定のフレーズが繰り返し記述されることがあります。しかし同じ文書の中にいちいち同じフレーズを繰り返して書くのはかったるいです。
そこで法律家は定義規定を設けて記述の繰り返しを避けるのです。使い方としてはプログラマーが関数の定義をするようなものだとイメージしていただければ結構です。
法律文書を読んでいて訳のわからない用語が出てきたときは、まず定義規定の存在を疑ってください。定義規定は文書・条項の最初の方に記述するのが暗黙の了解になっています。

上記の「プロパゲート(propagate)」や「必須特許クレーム(essential patent claims)」もGPL(General Public License)の中に定義規定があります。これらの用語はGPLのあちらこちらに顔を見せます。特に「プロパゲート(propagate)」や「コンベイ(conbey)」は頻出です。
どうせいずれ解説することになるでしょうから、この機会に翻訳して簡単な説明もしてしまうことにしました。その都度リンクを貼るので今は無理に読まなくてもかまいません。

「改変(modify)」→GPLv3第0条4パラグラフ
著作物を「改変する」とは、著作物の全体又は一部の複製又は翻案を著作権許諾を必要とする方法ですることを意味する。但し正確な複製を作成することを除く。結果として生じた著作物は先行著作物の「改変されたバージョン(modified version)」、又は、先行著作物に「基づく(based on)」著作物と呼ばれる。
※わかりづらい書き方ですが要は、一部の複製、全体の翻案、一部の翻案の3つが「改変(modify)」である、と言っているのです。全体の複製は「改変」ではなく「プロパゲート」になります。そして「改変されたバージョン(modified version)」と「基づく(based on)」という言葉にも「改変」と同様の意味があると言っています。

「プロパゲート(propagate)」→GPLv3第0条6パラグラフ
著作物を「プロパゲートする」とは、許可を得ずにすることによって、準拠する著作権法に基づく侵害行為による法的責任を直接的又は間接的に発生させる行為を意味する。但し、コンピュータ上での実行、又は、私的複製の改変をのぞく。プロパゲートは複製、配布(改変の有無を問わない)、そして一般公開を含む。さらにある国では他の行為もプロパゲートに含まれる。
※「準拠する著作権法」というのがわからないかと思われます。これはどういう訳かというとつまり、著作権法というのは国や州の数だけあるわけであります。ですからその時その時で適用される著作権法を参照してください、という意味です。GPLはどこの国の人に使われるかわかりませんからね。ちなみにどの著作権法が適用されるのかというのは国際私法の問題であり、本稿では解説しません。

「コンベイ(convey)」→GPLv3第0条7パラグラフ
著作物を「コンベイする」とは、プロパゲートの内、相手方に複製の作成又は受領を可能にさせるものを意味する。コンピューターネットワークを介したほんの意思疎通に過ぎず、複製の受け渡しを伴わない場合は、コンベイではない。

「コントリビューター(contributor)」→GPLv3第11条1パラグラフ
「コントリビューター」は著作権保持者でありこのライセンス(GPL)に基づきプログラム又はプログラムに「基づく(based on)」著作物の使用を許可する者である。このように使用を許可された著作物をコントリビューターの「コントリビューターバージョン(contributor version)」という。

「必須特許クレーム(essential patent claims)」→GPLv3第11条2パラグラフ
コントリビューターの「必須特許クレーム」とは、コントリビューターによって保有又は支配(control)される全ての特許クレームであり、このライセンス(GPL)で許諾されている行為(コントリビューターバージョンの作成・使用・販売)により侵害されうるものである。既に取得されているか以後取得されるかを問わない。但し、コントリビューターバージョンのさらなる改変の結果としてのみ侵害されうるクレームは含まない。この定義において、「支配(control)」にはこのライセンスの要件に合致した方法で特許再実施権を付与する権利を含む。
※いきなり「特許クレーム」とかいわれても困るでしょうが、とりあえず今は特許権のことなんだと思って読んでください。真面目に説明しようとすると特許法の話をだらだらとしなければならなくなるので。

予想以上のボリュームになってしまいました。今回の記事は、いま無理に理解しようとしなくても、今後の記事で用語が出てきたときに読み返せばオッケーです。

次回の記事はちょっと間があいて2月11日になりそうです。
それでは!
2010/02/02(Tue) 18:52:28

 GPL解説vol.7―GPLソフトウェアと作成者の特許権― / マルパチ 

今回からGPL(=General Public License)v3第11条の解説に入りたいと思います。

一昨日の記事で解説したように著作権と特許権は別個の権利です。ですからライセンスも著作権と特許権について別々の許諾をする必要があります。
GPLそれ自体は著作権についてのライセンスです。ですから特許を含むGPLライセンスソフトウェアを利用・改変・再配布してよいのかが問題になりうるのです。

そこでGPLv3はGPLライセンスソフトウェアに含まれている特許についての許諾条項を設けています。それがGPLv3第11条(特許)なのです。
GPLv3第11条3パラグラフは、GPLライセンスソフトウェアの著作権者が有する特許であって、GPLライセンスソフトウェアの利用・改変・再配布により侵害される特許につき、特許の製造・利用・販売・販売申込・インポート(実行・改変プロパゲート)を、非独占的かつ無償にて許諾するとしています。
(ここで「GPLv3第11条3パラグラフを勝手にかみ砕くな!」とツッコミが入りそうですが、大体こんな意味である、ということでご容赦ください。本稿の目的はGPLをわかりやすく解説することにあるので。実際のGPLv3第11条はもっと複雑です。)

ただしここでもう一つの問題が発生します。
GPLv3第11条3パラグラフの許諾する特許が、GPLライセンスソフトウェアの著作権者が有する特許に限られているということです。ちなみになぜ著作権者の有する特許しか許諾しないのかというと、他人の特許を勝手に許諾することが不可能だからです。許諾しないと言うより許諾できないのです。特許権も著作権と同じように支配権であるというわけです。
話が脱線しましたが、とにもかくにもGPLはGPLライセンスソフトウェアに含まれる全ての特許について許諾しているわけではありません。
すると結局、特許権者から警告書が届く恐怖におびえなければならないのではないか?という疑問が生じるかと思われます。

GPLはその恐怖を少しなりとも和らげるための規定を設けています。GPLv3第11条5パラグラフがそれです。
GPLv3第11条5パラグラフによると、ソースコードが他人の特許許諾に依拠するものであることを知りながら再配布する者は、以下の3つの措置のうちのいずれかを講じなければなりません。
すなわち、①ソースコードを公に利用できるネットワークサーバー等を通じて、GPLの規定に基づいて、無償で、誰でもコピーできるようにする、②自らに当該特許ライセンスの利益を与えないようにする、③GPLの条件に適合する方法で特許ライセンスを下流の受領者にまで拡張すること、のいずれかです。

この規定により、あなたが特許の存在に気づかないという危険はグッと減少します。上記①ないし③のいずれかの措置が施されたGPLライセンスソフトウェアなら特許権の存在に嫌でも気づきますからね。理論的には上流の(元の)著作権者が特許権侵害の事実に気がついていないため①ないし③の措置を施していないという危険もあり得るのですが、実際にはちゃんと特許権の存在について認知している場合がほとんどでしょう。ある程度の大きさの企業・団体なら特許権の調査をやりますから。

今回はこの辺で。それでは!
2010/01/30(Sat) 20:21:00

 ソフトウェア特許解説vol.1―特許権と著作権の違い― / マルパチ 

今回はGPL(=General Public License)バージョン3にて新たに追加された条項であるGPLv3第11条(特許)について解説していきたい…と思ったんですがその前に「ソフトウェア特許」について基本的な解説をしたいと思います。

なぜ、GPLは著作権に関するライセンスなのに、特許権に関する条項が必要になるのでしょう。
その理由を知るためには著作権と特許権の違いについて軽く触れなければなりません。

Wikipediaの定義によると著作権とは「著作権(ちょさくけん)とは、言語、音楽、絵画、建築、図形、映画、写真、コンピュータプログラムなどの表現形式によって自らの思想・感情を創作的に表現した者に認められる、それらの創作物の利用を支配することを目的とする権利をいう」のだそうです。
一方の特許権についてWikipediaの定義は「有用な発明を公開した発明者または特許出願人に対し、その発明を公開したことの代償として、一定期間、その発明を独占的に使用しうる権利」なのだそうです。
これらの定義からわかる著作権と特許権の最大の違いは、その保護の対象です。つまり著作権の保護対象が「表現」であることに対し、特許権の保護対象は「発明」なのです。

何が「表現」で何が「発明」なのかは小難しい法解釈の問題になってしまうのですが、わかりやすくするためざっくりと一例を挙げます。
ソフトウェアにおける表現とは、ソースコードやひとまとまりのプログラムであると言える程度にまとまったモジュールなどです。
ソフトウェアにおける発明とは、ハードウェアを制御するためのプログラムであったり、斬新なビジネスモデルを可能にするためのアルゴリズムであったりします。
(上記の発明・表現の分類は日本法におけるものです。合衆国法やEU法では分類が異なります。念のため。)

つまり特許権と著作権は一見全く同じものを対象としているように見えて、実は全く別のものを対象にしているのです。この違いをしっかり意識しておかないと知らない間に他人の知的財産を侵害していたということもあり得ます。
例えばソフトウェアにライセンスが付与されていたから権利関係は大丈夫と思い込んで使用していたら、実はライセンスが著作権に関する許諾しかしておらず、後日になって特許権者から警告書が届いてしまったりします。

このような事故は誰にでも起こりえます。というのも自分のソフトウェアが既存の特許権に抵触するかどうかというのは調査・判断が難しいからです。
著作権の判断は簡単です。著作権の保護対象は「表現」です。ということは自分のコーディングが他人のコーディングの真似でなければ大丈夫ということです。ちゃんと自分で創作したプログラムなら著作権的にはセーフです。
しかし特許権は「発明」を保護対象としているため、アイディアが被っていればアウトです。他人の特許権を全く知らなくてもアウトです。著作権とは違って真似したつもりが無くてもアウトになり得ます。とはいえ膨大な特許権データベースの中から自分のアイディアとよく似た特許を探し出す作業は困難なのです。
ソフトウェアの作成者は、自分のソフトウェアが他人の特許権を侵害していると気づかず、自分の著作権についてのみライセンスで使用許諾をして配布してしまうかも知れません。

大企業に所属しているSE・PGならば特許権の調査・判断は知的財産部・法務部が代わりにやってくれます。しかし知的財産部のない中小企業や個人営業のプログラマーはどうでしょう。特許権の調査ができますか?
特許権調査の参考になるリンクを貼って今回の記事を締めくくりたいと思います。特許庁の特許電子図書館です。それでは!!
2010/01/28(Thu) 15:10:40

 BSDライセンス解説vol.2.5―BSDライセンスシリーズ一覧― / マルパチ 

BSDライセンスにはいくつかのバリエーションがあります。しかもやっかいなことにそれぞれが複数の通称を持っているのです。
以前の記事では一番オーソドックスな3条項BSDライセンスについて解説しましたが、2条項BSDライセンスが適用されるソフトウェアも多いですし、古い4条項BSDライセンスが適用されるソフトウェアもないとも限りません。これらを見誤ると法的に面倒なことになりかねません。

そこでBSDライセンスの種類ごとに、その通称をまとめてみたいと思います。

3条項BSDライセンス
3条項BSDライセンス(3-clause BSD license) = 修正BSDライセンス(modified BSD license/new BSD license)

2条項BSDライセンス
2条項BSDライセンス(2-clause BSD license) = FreeBSDライセンス(FreeBSD license)

4条項BSDライセンス
4条項BSDライセンス(4-clause BSD license) = オリジナルBSDライセンス(original BSD license) = 旧BSDライセンス(old BSD license)

こうして見るとバリエーション自体は3つしかないくせに名前だけはやたらたくさんあることがわかります。
個人的には旧BSDライセンス(old BSD license)とかnew BSD licenseといった名前は悪い名前だと思います。BSDライセンスは作成者であるカリフォルニア大学バークレー校自身が3つもバリエーションを出していますし、第三者がBSDライセンスを真似してMITライセンス等の数多くの亜種が生み出されています。古い新しいといった相対的な言葉で区別しようとすると誤解を招きかねないと思うのです。

BSDライセンスはGPLと比べると簡便でわかりやすいライセンスです。しかしGPLと異なり作成された過程も、作成に関わったメンバーも不明確なライセンスです。また簡便すぎてかゆいところに手が届かないといった問題もあります。
どちらのライセンスが良いかというのは一概に言い切れないのですが、お手軽さやカスタマイズのしやすさを優先したいならBSDライセンス、信頼性や堅牢性を優先したいならGPLといったところでしょうか。
2010/01/25(Mon) 13:41:00

 GPL解説vol.6―GPLの新しいバージョン― / マルパチ 

前回の記事でGPL(General Public License)の古いバージョンの取り扱いについて解説しました。GPLにバージョンがあるということは、今後GPLの新しいバージョンであるバージョン4がリリースされる可能性が高いということです。
前回の記事を読んだmagicienから「新しいバージョンの取り扱い」について質問があったので、今回はこれをテーマにしたいと思います。

GPLv2(=GPLバージョン2)に改訂版に関する第9条があるように、GPLの現行バージョンであるGPLv3(=GPLバージョン3)にも改訂版に関する14条があります。そしてGPLv3第14条2パラグラフは前回説明したGPLv2第9条2パラグラフと同様の規定です。
つまりあなたが自らの開発したソフトウェアに対しGPLバージョン3又は後発の全てのバージョン(="or any later version")によるライセンスをした場合、あなたからソフトを受け取った人にはGPLバージョン4に従うことを選択する権利が発生してしまうのです。

「わざわざ著作権告知に"or any later version"なんて文言を入れやしないよ」と思うかも知れませんが、落とし穴があります。
GPL作成者であるフリーソフトウェア財団(=FSF)はGPLを利用するソフトウェア開発者に対して著作権告知のテンプレートを用意しています。このテンプレートにはしっかりと書いてあるのです。"or any later version"の文言が。
深く考えずにこれをコピペすると、あなたのソフトウェアに「いつの間にかGPLバージョン4が適用されていた」という事態が発生します。

このような事態は回避したいという方も多いでしょう。
あなたが開発したソフトウェアなら、FSFの著作権告知のテンプレートから"or any later version"の文言を削除してバージョン3のみに従うよう指定することで、GPLバージョン4の適用を排除できます。
しかし他人が開発したソフトウェアの著作権告知に既に"or any later version"の文言が入ってしまっている場合、改変者・再配布者であるあなたは"or any later version"の文言を削除することができません。なぜなら第3回及び第4回にて解説したように、あなたには「適切な著作権告知(appropriate copyright notice)」を保持するという条件が課されているからです(GPLv3第4条1パラグラフ及びGPLv3第5条1パラグラフ)。すると「いつの間にかGPLバージョン4が適用されていた」という事態が発生しうるわけですね。

ソフトウェアに適用されるGPLのバージョンが自分では決められない、ということを不安に思われるかも知れません。未だにリリースされていないライセンス文書がソフトウェアに適用されるかもしれないというのは、非常にリスキーです。なぜならライセンス文書がどのような内容になるかわからない以上、あなたに不利益をもたらす条項が挿入されないとも言い切れないからです。
でもGPLに限って言えばそのような法的リスクはありません。仮にGPLバージョン4にあなたの不利益となる条項が追加され、かつ、ソフトウェアにGPLバージョン4が適用されることになったとしてもあなたが困ることは無いでしょう。

そのように言える理由はGPLv3第14条4パラグラフにあります。その翻訳は以下の通りです。
「後発のライセンスバージョンはあなたに追加的許諾、又は、異なった許諾を与えるかも知れない。しかしながら、あなたが後発のバージョンに従うことを選択した結果として、全ての作成者又は著作権者に対して追加的義務が課されることはない。」
このパラグラフが何を言いたいのかというとつまり、GPLバージョン4がGPLバージョン3と比べて作成者・改変者の不利益となる条項を含むものであった場合に、利用者がGPLバージョン4に従うことを選択したとしても、作成者・改変者の不利益となる部分についてのみGPLバージョン4の適用が排除されるということです。
この条項により、GPLのバージョンアップに伴う法的リスクを打ち消しているというわけですね。

そんなわけでGPLのバージョンアップをおそれる必要はありません。あなたが開発したソフトウェアの著作権告示から"or any later version"の文言を削除する必要性も薄いと言えるでしょう。

次回のテーマについてちょっと迷っているんですが、いま「ソフトウェア特許」が熱そうなんでGPLv3第11条(特許)について解説して「ソフトウェア特許」への足がかりにしようかな。
それでは!!
2010/01/24(Sun) 18:35:24

 GPL解説vol.5―GPLの古いバージョン― / マルパチ 

GPL(=General Public License)にはいくつかのバージョンがあります。最新のものは2007年6月29日にリリースされたバージョン3です。これまで本ブログで行ってきたGPLの解説もバージョン3を土台にしています。
ところがネット上で公開されているオープンソースの中にはGPLバージョン2でライセンスされているものも多く残っています。この場合どちらのライセンスに従えばよいのでしょうか?

結論から言ってしまいます。状況によって、バージョン2に従わなければならない場合と、必ずしもバージョン2に従わなくても良いけれどもバージョン3に従う意味がない場合に分けられると思います。だからバージョン2に従うべきです。
理由について説明していきます。

そもそもGPLバージョン2とGPLバージョン3は全く別のライセンスです。GPL作成者のフリーソフトウェア財団(=FSF)はバージョン3をバージョン2のアップグレード版として作成しました。しかし本来、法律文書であるライセンスにはアップグレードなどというものはありません。一度作成したライセンスは何年でも何十年でも効力を持ち続けます。それこそ著作権の保護期間が終了するまで有効なのです。
だからソフトウェアがGPLバージョン2でライセンスされていた場合はGPLバージョン2に従わなければなりません。

しかしFSFはバージョン2発表の時からGPLのバージョンアップについて考えていたようです。バージョン2にはGPLの改訂版についての規定がおかれています。GPLv2第9条2パラグラフがそれです。それによるとGPLバージョン3は以下のように取り扱われます。
①プログラムがライセンスのバージョン番号及び"any later version(後発の全てのバージョン)"を指定している場合に、あなたはそのバージョンまたはFSFにより発行された後発のいずれかのバージョンのどちらかの規定・条件に従うかにつき選択権を持つ。
②プログラムがライセンスのバージョン番号を指定していない場合、あなたはFSFによりこれまでに発行された全てのバージョンを選ぶことが出来る。
つまり①及び②の場合においては必ずしもバージョン2に従わなくても良いわけです。しかし実際にはバージョン3に従うメリットはありません。

バージョン2とバージョン3はその根幹についてほぼ同じです。つまりフリーソフトウェアライセンスであり、かつ、コピーレフトであるということです。
そしてバージョン3はTiVo化DRMといったバージョン2の抜け穴をふさぐための規定を新たに設けています。つまりバージョン2の方が(どちらかと言えば)要求してくる条件の緩いライセンスなのです
緩いライセンスと厳しいライセンスを選べるのなら緩いライセンスを選ぶ人がほとんどでしょう。ですからバージョン3に従う意味がないという結論になるのです。

そんなわけでGPLバージョン2でライセンスされたソフトを使うときはバージョン2に従うべきであるといえます。
2010/01/21(Thu) 16:37:50

 BSDライセンス解説vol.2―MITライセンス― / マルパチ 

jQueryをいじろうとしてjQueryがMITライセンスであることに気づく。だからMITライセンスについて勉強がてら解説を書いてみることにします。前回予告した「古いバージョンのGPL」に関する記事は延期です(笑)

さてMITライセンスはBSDライセンスの亜種なわけですが、どのようなライセンスなのでしょう。

まずMITライセンスの本文を読んでみる。さすがBSDライセンスの亜種なだけあって短い。とにかく短い。
短いので主要部分の翻訳が出来そうな気になってきます。そんなわけで以下はMITライセンスの翻訳です。

<著作権告知省略>
本ライセンスによって、無償で、「このソフトウェアのコピー及び付属の文書ファイル(以下「ソフトウェア」とする)」を取得した全ての者に対し、ソフトウェアを無制限で取り扱う許諾が与えられる。この許諾には使用、コピー、改変、結合、公表、配布、再実施(sublicense)、ソフトウェアのコピーの販売のいくつか又は一つに対する無制限が含まれる。そしてソフトウェアを提供された者に同じ許諾をすることも許諾される。但し以下の条件に従うこと。
上記の著作権告知及び本許諾書は全てのソフトウェアのコピー又は実質的な一部に組み込まれなければならない。
<免責条項省略>

うーん。MITライセンスはBSDライセンスとほぼ同じ法的内容を持ったライセンスのようだ。違うところは言い回しくらいか。
あまりに違いがなさ過ぎて逆に不安になったので違いを探してみた。しかし違いはないということで正しいみたいだ。GNUプロジェクトも「3条項BSDライセンス(Modified BSD lisence)とMITライセンス(X11 lisence)はおおよそ同意義である」と言っている。→リンク先ページの"Modified BSD lisence"の項を参照

そんなわけで3条項BSDライセンスとMITライセンスに法的な違いは無いということで解説を締めくくりたいと思います。…つまらない結論だなぁ。

つまらないので一つだけ補足します。
MITライセンスはGPLと2本立てで用いることができます。3条項BSDライセンスについても同様にGPLと2本立てで用いることができます。→参考リンク
このように1つのソフトウェアを2つ以上のライセンスで配布することをデュアルライセンスといいます。jQueryはGPLとMITライセンスのデュアルライセンスですね。
それでは!
2010/01/19(Tue) 19:28:02

 オープンソースに思うこと / マルパチ 

ここのところmagicienに教えてもらったGPLだとかBSDライセンスだとかを勉強してて思った。この分野はどんどん新しいものが出てくるなあ。

最初のうちはプログラム使うのに必要な法律なんか著作権法だけで十分だったんだろう。けど今はもう著作権法だけでは最新のプログラムをフォローできなくなってきてるように思える。
GPLやBSDライセンスなんていう変則的なものが出てきて、それがソフトウェア著作権の分野で一般的になっている。
これからは法律屋もこういった流れをきちんと追っかけていかないといけないのかな。

そんなわけでおれも何か勉強してみようかと思い立ったわけです。そうすればオープンソースの今を知ることができるかもしれない。
このあいだmagicienが記事にしていたscripty2なんか面白そう。オープンソースなjavascriptのライブラリか…

scripty2をググっていたらこのブログに行き着く。ん?ここに書いてあるjQueryって何だ?scripty2と同じjavascriptのライブラリなのかな。
うーん何が違うのかよくわからん。とりあえずscripty2はMITライセンス、jQueryはGPLとMITライセンスのデュアルライセンスか。
せっかく時間もあることだしこれらで何か作ってみようかな。そうすりゃ違いもわかるでしょ。
2010/01/17(Sun) 16:04:35

 BSDライセンス解説vol.1―BSDライセンスってなに?― / マルパチ 

さて今回はBSD(=Berkeley Software Distribution)ライセンスについて書きたいと思います。
BSDライセンスはいろいろな亜種があるのですがオーソドックスな3条項BSDライセンス/3-clause BSD license(=修正BSDライセンス/modified BSD license)を題材に書いていきますね。(リンク先の文書には4つの条項がありますが第3条が削除されたので3条項になります。)

BSDライセンスは、今まで説明してきたGPL(=General Public License)と同じく、ライセンスされたソフトウェアがフリーソフトウェアであると述べています。しかしBSDライセンスの記述はGPLの記述に比べるとずいぶんあっさりしています。
どのくらいあっさりしているのかわかりやすくするためにBSDライセンスが要求する利用・再配布・改変の条件を書き出してみたいと思います。

<著作権告知省略>
改変のあるなしにかかわらず、以下の条件を満たす限り、ソースコード形式及びバイナリ形式での利用及び再配布が許諾される。
1.ソースコードの再配布の際には、上記の著作権告知、ここに列挙された条件、そして下記の免責条項を保持しなければならない。
2.バイナリ形式での再配布の際には、上記の著作権告知、ここに列挙された条件、そして下記の免責条項をコピーした文書その他の資料と一緒に再配布しなければならない。
4.大学の名前(カリフォルニア大学バークレー校)もコントリビューターの名前も、このソフトウェアから派生する製品の推奨・販促に使ってはならない。但し書面による事前の明示的な許諾がある場合を除く。
<免責条項省略>

以上です。あれこれ要求するGPLに比べるとずいぶんあっさりしているでしょう?
しかもGPLと違い、改変されたフリーソフトウェアを再配布する際に「改変されたソフトウェアの全体に丸ごとこのライセンスを適用させること(GPLv3第5条1パラグラフc項)」が要求されていません。→前回記事の条件⑤を参照
これはどういうことかというと、改変したソフトウェアを再配布するときにソースコードを公開する必要がないということです。(つまりBSDライセンスソフトウェアはフリーソフトウェアではあるけれどもコピーレフトではないのですね。)

そんなわけで今回はあっさりとした記事にすることができました。毎回こんな感じだと読みやすくて良いのでしょうけど…。
次回は「古いバージョンのGPL」について書きたいと思います。それでは!
2010/01/16(Sat) 16:40:07

 GPL解説vol.4―フリーソフトウェアとコピーレフトその2― / マルパチ 

前回「GPL(=General Public License)ライセンスソフトウェアを使うと何ができて何ができないのか」の続きです。
「改変されたフリーソフトウェア」の再配布の条件について説明したいと思います。

「改変されたフリーソフトウェア」は6つの条件を守れば、ソースコード形式でのみ再配布できます。再配布は必ずソースコード形式で行わなければなりません。オブジェクトコード形式での再配布の際はさらに条件が付け加えられるので注意してください。

6つの条件とは①適切な著作権告知を全てのコピーに目立つように発行すること、②GPLのコピーを全ての受取人に提供すること、③改変したという事実及び改変の日付をはっきりと告知すること、④GPLが適用される旨・GPLv3第7条に基づく全ての条項が適用される旨をはっきりと告知すること、⑤改変されたソフトウェアの全体に丸ごとGPLを適用させること、⑥あなたの改変によりソフトウェアインタラクティブユーザーインターフェイスを追加された場合は適切な法的告知を表示すること。→GPLv第5条1パラグラフ
①「適切な著作権告知(appropriate copyright notice)」は前回説明したとおり。フリーソフトウェアの元々の著作権告知を変更するなという意味です。
④の条件は前回説明した②の条件に似ていますが違うものです。どこが違うかというとGPLv3第7条に基づく「全ての」条件を告知しなければならない点が違います。非許可条項の告知だけで良しとされた「フリーソフトウェアの完全なコピー」とは大違いです。
⑤は6つの条件の中で一番大事な条件と言っても過言ではありません。この条件によりGPLはAからA'へ、A'からA''へと伝播していくのです。(ライセンス感染とか皮肉られる原因でもあったり…)
⑥の「適切な法的告知(Appropriate Legal Notices)」ってなんやねん、という問題があります。これについてはGPL自身が「適切な法的告知」の定義づけをしてくれています(GPLv3第0条8パラグラフ)。GPLによると「適切な法的告知」とは、まず適切な著作権告知(apprpriate copyright notice)の表示があること、そして利用者に対して3点につき伝えること(無保証である場合には無保証であること、受領者がGPLに基づきプログラムの再配布が出来ること、GPLのコピーを参照する方法)なのだそうです。適切な著作権告知って①の条件とほぼ同じですね。ファイルとディスプレイで2重に著作権告知をしろということです。

さて前回から2回にわたって長々と解説してきましたがいかがでしたでしょうか?
タイトルにも書いたコピーレフトについてはついにここまで触れずじまいでした(笑)

コピーレフトとは、本来なら非著作権者による著作物の利用を制限するために用いる著作権法を、逆に非著作権者による著作物の自由な利用・再配布・改変のために用いてしまおうという逆転の発想です。つまり最初の著作権者が、自分の著作権を盾にして、全ての再配布者に対してフリーソフトウェア化を要求してしまうのです。
この発想はプログラマーの方にとっては既に当たり前の考え方なのかもしれませんが、僕みたいに法律の考え方に馴染んだ人間にはやっぱり違和感があります。著作権法などの私法ってのは普通、自分の利益のために使うものであって、他人の利益や公共の利益のために使うものではありませんからね…。

次回は「古いバージョンのGPL」について説明しようかと思いましたがこれは後回しにして、ここらでちょっと「BSDライセンス」について書くことにします。
それでは!
2010/01/15(Fri) 23:18:29