Twitterに「#笑ってはいけないSIer」というのが流れていまして、そこから枝分かれてして「「そもそもOSSがサポート無いと使えない。GPLは禁止。OSSを使うのに研修を受ける必要がある。OSSのソースを読むのは禁止。#笑ってはいけないSIer」から派生したGPLについての談義 – Togetter」というのが出てきました。
そのなかのGPLなソースコードについて説明されていることが、すこーし違うんじゃないかなぁ、と思うところがあり、私なりに調べてみました。
#2011-11-19 AM8:30 「短いコード」と「結論」を追記
#2011-11-20 AM5:30 「運用」を追記。「結論」を修正
#2012-01-20 AM0:30 短いコードにいくつかの具体例を追記してみた
#2013-07-20 PM10:20「二次創作同人”小説”」に関する記述を追加
著作権の適用範囲
著作権の保護は、アイデアとアルゴリズムには及びません。
第一章 総則 – 第一節 – 第二条
一 著作物
思想又は感情を創作的に表現したものであつて、文芸、学術、美術又は音楽の範囲に属するものをいう。十の二 プログラム 電子計算機を機能させて一の結果を得ることができるようにこれに対する指令を組み合わせたものとして表現したものをいう。
「創作的に表現したもの」が著作物。「プログラム」も著作物。
第二章 著作者の権利 – 第一節 – 第十条
3 第一項第九号に掲げる著作物に対するこの法律による保護は、その著作物を作成するために用いるプログラム言語、規約及び解法に及ばない。この場合において、これらの用語の意義は、次の各号に定めるところによる。
一 プログラム言語 プログラムを表現する手段としての文字その他の記号及びその体系をいう。
二 規約 特定のプログラムにおける前号のプログラム言語の用法についての特別の約束をいう。
三 解法 プログラムにおける電子計算機に対する指令の組合せの方法をいう。
つまり、日本の著作権法では、プログラム言語とプロトコル(規約)・アルゴリズム(解法)には、著作権の保護は及びません。
第１０２条 著作権の対象：総則
(b) いかなる場合にも、著作者が作成した創作的な著作物に対する著作権による保護は、着想、手順、プロセス、方式、操作方法、概念、原理または発見(これらが著作物において記述され、説明され、描写され、または収録される形式の如何を問わない)には及ばない。
アメリカの著作権法では、アイデア(着想)、手順・プロセス・方式・原理(アルゴリズム)には、著作権の保護は及びません。
GPLと著作権
GPLのソースコードのうち、アイデアやアルゴリズムには著作権の保護が及びません。なぜなら、GPLは、著作権の及ぶものを対象にしているから。そして前述のとおり、アイデアやアルゴリズムは、著作権の保護が及ばないから。
【0条】
「『プログラム』を基にした著作物」とは『プログラム』やその他著作権法の下で派生物と見なされるもの全般を指す。【2条】
あなたは自分の『プログラム』の複製物かその一部を改変して『プログラム』を基にした著作物を形成し、そのような改変点や著作物を上記第1節の定める条件の下で複製または頒布することができる。
0条で定義されているように、”『プログラム』を基にした著作物”とは、著作権法の下で派生物と見なされるもの全般。それが、2条の対象になります。つまり、著作物でないものは、GPLの適用対象外。
【0. 定義】
ある作品の「改変」(modify)とは、その作品の全体ないし一部を、『コピーライト』の許可を必要とするようなやり方で複製ないし翻案することを意味する。ただし、完全に同一なコピーを作成する場合は除く。改変の結果出来た作品は、以前の作品の「改変されたバージョン」(modified version)、または、以前の作品を「基にした」(based on)作品と呼ばれる。【5. 改変されたバージョンのソースの伝達】
あなたは、『プログラム』を基にした作品、あるいはそうした作品を『プログラム』から作成するための改変点を、上記第4項の規定に従ってソースコード形式で伝達することができる。ただしその場合、あなたは以下に示す条件のすべてを満たさなければならない:
0条のコピーライトとは、著作権(Copyright)のこと。
そして、0条で定義されているように、”『プログラム』を基にした作品”とは、著作権(Copyright)の許可を必要とするようなやり方で改変・翻案した作品。それが、5条の対象になっている。つまり、著作物でないものは、GPLの適用対象外。
クリーンルーム設計
ソースコードから、アイデアやアルゴリズムだけ取り出すことができるのか。クリーンルーム設計という手法があります。
クリーンルーム設計（クリーンルームせっけい、英: Clean room design チャイニーズウォールテクニックとしても知られる）とは、ある製品をリバースエンジニアリングし、かつ著作権や企業秘密に関わる部分に抵触することなく、その製品デザインを模倣する手法である。
(中略)
通常、クリーンルーム設計は、模倣するために製品を調べ、仕様書を書くことでなされる。この仕様書は、著作権の侵害がないか法律家による検査を受ける。それから、つながりの全くない別のチームによって、この仕様書通りの製品が作られる。
(中略)
IBM PCのBIOSをクリーンルーム設計によって実装し、その互換機を生み出したコロンビア・データ・プロダクツ(en:Columbia Data Products)の例が有名である。
Ruby 1.9.2リリースとWEBrick脆弱性問題の顛末 – 西尾泰和のはてなダイアリー
モラルとライセンスの話がゴッチャになってないか。
GPLが適用されたソースコードがあって、それを他言語に移植してBSDライセンスで公開する行為は、”GPLでコードをずっとフリーにしておきたい”というオリジナル開発者の思いを無視することかも知れません。でも、「そういうのはBSDライセンスにしちゃダメだと思う」というのは、ライセンスではなくモラルの話。今回のケースは、多分GPLでは防げない。利用条件で禁止していないから仕方ない。
だから、やたらと安全側にふって、ソースコードについての自由な研究を萎縮するのも、なんだかなぁ。
じゃあ、どうすれば良いのでしょう。
万能ではないかも知れませんが、モラルの問題は、モラルで解決したらどうでしょう。
もしも誰かのGPL適用なソースコードを公開していたとして、あなたが別のプログラミング言語にクリーンルーム実装で移植して、それをBSDライセンスで公開したいなら、オリジナル版の開発者に連絡を取ってみたらどうでしょう。
たとえばさ、「あなたのプログラムは素晴らしい。私は、あなたのプログラムを使いたい。でも、私の使っているプログラム言語版が存在しない。BSDライセンスじゃないと困る状況がある。私は、あなたのプログラムを他言語に移植してBSDライセンスで公開したい。情報交換しませんか。」とかなんとか。
そうやって、いっしょにコミュニティを作っていけば良いんじゃないかな。
短いコードの場合
短いコードで創作性が発揮できない場合は、GPLは適用しない方がいい。
著作物がライセンス自身よりもそんなに長くない場合はどうしたらよいですか?
– もし単一のプログラムでその程度の短さならば、GNU GPLではない、より単純でどんなことでも許可しているようなライセンスを適用したほうが良いでしょう。
あと、「誰が書いても同じになるような慣用句的なコードは、ライセンスを適用しても意味がない」、とかストールマンが言っていた記憶があるんだけれど見つからず。誰が知ってたら教えてください。
これについて、いくつか例を挙げてみます。
まず、ご存知「hello world」。K&Rのプログラミング言語Cに出てきます。
#include
int main(void) {
printf(“Hello, World!\n”);
return 0;
}
これは、C言語で書いてもバリエーションがあるし、他のプログラミング言語の入門書での登場するけれど、1行のテキストを表示するというアイデアでは、創作性というほどオリジナリティを発揮できそうもない。Fizz Buzzなんかも同じじゃないかな。
日本語の「おはよう」で著作権を主張するのは難しいし、それを翻案した「Good morning」も慣用句でしょう。
でも、短いコードは著作権を持てないか? たとえば、ショートコーディングとかCodeGolfというような取り組みであれば、創作性が発揮されそうな気がする。お題(アイデア)は同じでも、コード(表現)には違いがある。
俳句や短歌は立派な著作物だといえるし、その他言語訳も著作物になるんじゃないかな。
運用について
それでもまだ、SIerとしては安全側に倒すしかない、という意見もありました。詳しくは、コメント参照。
「二次創作同人”小説”」が合法って本当？
#2013-07-20 追記
マンガ家でJコミを手がける赤松 健氏は、自身のミニブログの記事「「二次創作同人”小説”」が合法って本当？ | 赤松健の連絡帳」を掲載しています。
小説中の文章をそのままコピー＆貼り付けするのは盗作という著作権侵害ですが、小説の登場人物の名前・設定などを借りた二次創作はアイデアの流用にあたるので、著作権侵害にはなりにくく、”「二次創作小説」は（現実問題として）かなり安全な部類に入る、というのが私の結論”と述べています。
この記事では、著作物のどの要素が著作権の対象か、どういったポイントが同一と判断されるか、といった点についても詳しく解説しています。
さて本稿は、ソースコードの再実装を、著作権としてどのように捉えるかを議論しているわけですが、この赤松氏の記事と比べるとかなり乱暴です(笑)。ソースコードからアイデア・アルゴリズムを抽出するとしても、アイデア・アルゴリズムとは何か、という点では、もう一段深い議論が必要かも知れません。たとえば、コンピュータゲームのソースコードがあったとして、そのゲームのルールはアイデア・アルゴリズムなのか、とかでしょうか。
結論
ソースコードからアイデア・アルゴリズムを抽出して、他プログラミング言語(あるいは同じ言語)に実装し直すのは、ライセンス的にはOK。
ま、私の個人的な考えでしかないし、これが有効かも不明ですが。
誰かの参考になれば幸いです。また、皆さんのご意見をお待ちしております。
結論としては「アイデアとアルゴリズムを抽出して他言語または同じ言語で実装しなおすのはOK」ということですよね？
みんな誤解してると思うんですが、
多他言語への移植と翻訳（変換）の境界線が曖昧でわかりにくいというのは、GPLの問題ではなく、著作権法そのものの問題ですよね。というネタを書こうと思ってたところです。多くのオープンソースの開発者は上記のアプローチに同意してくれると思います。もちろん、これはGPLに限らず、ブログ等で公開されている、ライセンス文のかかれていないコード変についても言えることです。僕もブログの著者に連絡したことはあります。
ただ、ライセンスの話をするときに、性善説で話をするのはナンセンスですよね。みんなが良い人という前提であればそもそもライセンスなんて不要ですから。そして、多くの人が見落としがちな点は、「違反かどうかは、利用された側が判断する」という点です。「アイディアだけのコピーなのか」「コードの改変なのか」を判断するのは本人ではありません。
Rubyのパッチの話の際も「そのような小さな修正であれば著作権なんて発生しない」という人もいたそうですが、Rubyという広く使われるシステムの意義を考えて、あえてクリーンルーム的な手法を選択したそうです。
仮にライセンス違反が発覚した場合、多くの人が迷惑を被ります。ライセンスに問題にあるコードを置き換えたバージョンをリリースしたとしても、それを使っていたシステムでは置き換えと検証などで人手がかかります。人手がかかるということはお金がかかり、損失が発生する可能性があるということです。サービスの停止なども起き、そこからの損失も発生するでしょう。
特許と異なり、相手からお金を直接取ることはあまり発生はしないと思いますが、例えば、商用とGPL系のデュアルライセンスの場合、その開発元を買収して権利を得て、競合他社の商売をジャマするといったことも起きないとは言えません。サービス停止による損失と天秤にかけて、商用ライセンスを売りつける、といったこともあるかもしれません。
ちょっとしたツールをなんらかのオープンソースの元で公開しているような場合は問題ないかもしれません。その場合はGPLのコードから学んで学習する意義の方が大きいかもしれません。今作っているコードがどれだけ多くの人に使われるのか、どれだけのキャッシュ・フローを生むシステムなのか、使えなくなった場合の影響範囲はどうなのか。それが大きなシステムであればあるほど、小さなミスも命取りになるでしょう。これも一種の異常ケースの設計と言えるかもしれません。「こんなことは起きないはず」という正常ケースしか考えないシステムエンジニアはいないですよね？
きちんと理解している人なら問題のあるコードを生産することはないかもしれません。ただ、元の文脈はSIerの職場という話でした。日本のSIerは2次受、3次受と層が分かれることが多数です。オフショア経験したことがある方なら分かると思いますが、書いてもらったコードを隅から隅まで確認して違反がないか、参考にしたコードと類似性を確認することなど到底できません。問題発生した場合、SIerも、お金を払った側も、両方に損失が発生します。それなら「見ることも禁止」とするのはビジネス的判断としてはリーズナブルでしょう。
そういうことまで考えれば、モラルの問題には収まらないと思います。上記で書かれているのはどの程度のシステムまでを考慮されていますか？
Okunoさん、いつもコメントありがとうございます。
結論、追記しました。あと、コメントのタイポも直しておきました。
私は一人のOSS開発者としてGPLをリスペクトしていますが、ほとんどのケースではそもそも問題になることはないし、著作権所持者が一人しかいな場合はおっしゃるとおりその方と連絡を取れば済む話だと思っています。この点については今回は論点ではなくあまり強調されておらず、はてブコメントがGPLに対してネガティブなものばかりになってしまい残念に思います。
ただプロプライエタリ・ソフトウェアに関わっている場合、神経質にならざるを得ないケースが実際にあります。そこでこの話題に関心を持ったのですが、結論としてはやはりその場合は安全側に倒すしかないと思います。そこで何が安全なのかということになりますが、クリーンルーム設計が現実的に取れる唯一の方法のように思えます。@n_sodaさんの解釈では、オリジナルに十分に似ていなければ問題ないということですが、似ているかどうかの判断は現実的にはできないと考えます。
渋川さん、有益なコメントを頂き、本当にありがとうございます。
見落としがちな点は、「違反かどうかは、利用された側が判断する」という点です。「アイディアだけのコピーなのか」「コードの改変なのか」を判断するのは本人ではありません。
確かに、利用者だけで判断が付かない場合がありますね。だとしたら、”利用しない”といのではなく、”利用者だけで判断しない”となればいいのでは。利用者となるSIerが、顧客・オリジナル開発者・コミュニティに説明責任を果たすことが重要だと思うのです。
それなら「見ることも禁止」とするのはビジネス的判断としてはリーズナブルでしょう。
そういうことまで考えれば、モラルの問題には収まらないと思います。上記で書かれているのはどの程度のシステムまでを考慮されていますか？
オフショアを含めた2次受、3次受の問題は認識しています。
ただ、「見ることも禁止」とするルールは、その運用を徹底できるでしょうか。ただルールを作るだけでは、現場のプログラマーの性善説に頼っていることになりませんか。それを、オフショアを含めた2次受・3次受まで徹底するのは大変です。
「見ること禁止」を開発委託契約に盛り込めば、モラルではなく契約の話になりますが、それは委託先のマネジメントの問題に変わっているだけだし。
私が思いつくアイデアとしては、
1.プログラマに対する教育の徹底
2.ペアプログラミングを含めたコードレビュー
3.ソースコード管理
4.OSSのソースコード管理ツールの利用(BlackDuckとか)
5.必要に応じたクリーンルーム設計
といったところですが、まあリーズナブルとは言えないかも知れません。
それに、これでは・・・
・そもそもOSSがサポート無いと使えない。
・GPLは禁止。
・OSSを使うのに研修を受ける必要がある。
・OSSのソースを読むのは禁止。
というのと、あまり変わりません(笑）。
@__gfx__さん、コメントありがとうございます。
>ただプロプライエタリ・ソフトウェアに関わっている場合、神経質にならざるを得ないケースが実際にあります。そこでこの話題に関心を持ったのですが、結論としてはやはりその場合は安全側に倒すしかないと思います。
とりあえずは、ライセンスの問題と、利用時の開発体制の問題が切り分けられれば、いいんじゃないかと思いました。
横からですが、渋川さんの意見にコメントさせて頂きます。
性善説という哲学的なコンテキストを持ち出す理由はなんでしょうか。（可知さんの意見や一連のツィートが）性善説だからナンセンスだとおっしゃるのなら、反対に性悪説もナンセンスだという批判も認められなければいけません。
例えば、もし反対に性悪説に従ったならば、BSDライセンスなどで提供されたオープンソースソフトウェアも禁止しなければいけません。BSDライセンスではオリジナルの著作権表示が義務付けられていますが、みなさんどれだけそれに従ってらっしゃるのでしょうか？下請けの開発者が意図せずBSDLなソフトウェアのソースコードを流用していたら、そのソフトウェアには著作権表示が義務付けられることになります。「BSDLなソフトウェアの開発者はそのようなことを要求しない」というのは性善説です。やる気になれば「著作権表示がねーよオラオラ！」という裁判だって起こせます。（そこに経済的なメリットがないから裁判が起きないだけです。）性善説や性悪説という哲学的なコンテキストをライセンスの議論に持ち込むのはよくないと思います。性悪説の立場から見れば、オープンソースソフトウェアの存在自身を否定することになります。（例えば、BSDLなソフトウェアを引用した場合でも、そのソフトウェア自身が何らかのライセンス違反を犯している可能性もあります。PDとして公開されているソフトウェアですらライセンス違反の可能性があります。性悪説に基づくなら、如何なるオープンソースソフトウェアも信用してはならないことになります。）
> そして、多くの人が見落としがちな点は、「違反かどうかは、利用された側が判断する」という点です。「アイディアだけのコピーなのか」「コードの改変なのか」を判断するのは本人ではありません。
この点について指摘しますが、ライセンス違反かどうかを最終的に判断するのは裁判所です。オリジナルの作者が違反だと判断してから取れる行動は、裁判所に訴えるかどうかというところまでです。著作権法上の違反になるかどうかは裁判所が行いますので、判断には一定の客観性が求められます。また、GPLの条文自信の著作権はFSFがもっており、どのような場面でGPLが適用されるかという事例も多々持っていますので、FSFの見解も尊重されるべきでしょう。従って、「本人」がその客観性に従って判断するのは、あながち間違ったプラクティスではないと思いますがいかがでしょうか。反対に、客観性に自信が持てなければやめておくというのもプラクティスとしてはアリだと思います。
元々の@n_soda氏の”そのページにある通りGPLは著作権の仕組みを用いたライセンスです。アイディアやアルゴリズムは著作権で保護されませんから問題ありません”というツイーとは間違っていません。GPL上も著作権法上もOKです。それに対する渋川さんの”GPLのライセンス文には一部を改変して採用した場合もGPLになると明示されています。まぁ、著作権を侵害していると自覚して、社会的な不利益を被るリスクを承知で利用するならいいんじゃないでしょうか？”というのは、GPLの拡大解釈であって、ライセンスの解釈でも著作権法的にも正しくありません。もし仮に、GPLの条文を逸脱して過度にGPLの適用を強要したら、それは強要したほうがGPL違反となります。このツィートはむしろGPLを利用すると如何にも社会的な不利益を被るリスクが生じるような物言いのように見受けられます。
OSSライセンスについてひとつだけ確実に言えることは、ライセンスはきちんと遵守しようということです。GPLであれそれ以外のライセンスであれです。ライセンスはライセンスであって、その適用の可否はロジカルに判断するべきです。その背景にある哲学とは、分けて論じるべきでしょう。（哲学は個人の自由なので、好き勝手言ってもいいと思います。個人としてGPLがお嫌いであれば、その意思は尊重されるべきです。）
オフショアなどの現場で、GPLの参照を禁止するという規則を設けることは批判しません。おっしゃるようにそれがプラクティスとして有益な場合もあるでしょうから。しかしその行為はプラクティスの一つであって、「絶対にこうあるべき」とか「こうするのが正しい」という類のものではないという点は主張しておきたいです。GPLなソフトウェアを参照したほうがメリットがあるケースも存在するでしょう。プラクティスの適用可否は状況や立場によって異なりますし、プラクティスの有用性と法的な正しさ、ライセンス上の正しさは分けて議論するべきです。
Okuno さん
再三にわたり、有益なコメントをいただき、ありがとうございます。
渋川さんに向けて、コメントされていますが、私も横から。
これは、たぶん、「ライセンスとモラルと運用/マネージメントをきちんと分けて考える」
という話だと思います。
性善説という言葉は、私が使った「モラル」という言葉に反応してのことかも知れません。
>この点について指摘しますが、ライセンス違反かどうかを最終的に判断するのは裁判所です。オリジナルの作者が違反だと判断してから取れる行動は、裁判所に訴えるかどうかというところまでです。
ライセンスのレイヤーでは、そのとおりだと思います。一方で、SIer企業のマネージメントレベルでは、「オリジナル作者が著作権侵害だと判断してから、裁判所の結論が出るまでの間、をどのようにするのか」というリスク管理まで考える必要があると思います。受託開発で、そのリスクは取れないという判断も確かにあるでしょう。
私の書いた記事は、ライセンスとモラルのレベルでは、それなりにポイントをカバーしていると思いますが、企業や開発プロジェクトのマネージメントのレベルでは、不十分なところがまだまだありそうです。
引き続き、ご意見を頂ければ。
PS. そろそろオープンソースライセンス本(電子書籍版)の目処が付きそうなので、また、どこかで勉強会／情報交換会がやれたらいいなと思っています。そのときは、ぜひ参加ください。
このテーマを整理したいと考えています。
ピンバック: パズルの著作権、詰め将棋の著作権 | オープンソース・ライセンスの談話室
ピンバック: あなたの作成物は、誰の著作物になりますか。 | オープンソース・ライセンスの談話室