「元のソフトウェアがGPLだから公開できない」という誤解について宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。2013会社のブログに掲載するつもりで書きましたが、タイミング的に発表が遅れてしまいそうということだったので、勢い重視でこちらで公開してみます。1月31日16時台追記。hide氏の意向についてのこのエントリでの推測が全くの見当違いである可能性が示唆されています。詳しくは追記2をご覧下さい。「GPLだから公開できない」?今日、「元のソフトウェアがGPLだから、改造版を公開できない」という、一見すると矛盾しているようにも思えるフレーズを見かけました。GPLといえば「改造版を公開したら、改造版のソースも公開すること(※厳密にはちょっと違いますが、話を簡単にするためにこう書くことにします)、という条件の下で利用を許諾する」という形のライセンスです。素直に考えれば「元のソフトウェアがGPLだから、(元のソフトウェアの作者にいちいち「改造版を作りましたが、公開してもいいですか?」などと確認を求めなくても)改造版を公開できる」ということになります。かかわらず、なぜ「元のソフトウェアがGPLだから、改造版を公開できない」という話になるのか。これを理解するためにはいくつかの背景事情を知る必要があります。Liteを開発したhide氏は以下のように書かれています。気分良く公開しようかな...、ってだめじゃん!?↓ライセンスがGPL...。特定の開発者にとっては鬼門と言うべき存在。某OS開発企業も知名度の高いゲーム会社も漏れなく謝罪とその対応に追われたことを知る者としては無視できません。その気が無くてもうっかり私の作品に混入したら目も当てられませんからね。万一に備えて手を入れた箇所はProximodo専用に新規に書き下ろした処理のみにして、他では一切使用しないようにProximodo用処理であることが一目で分かるような書き方をしていますが。発展しているオープンソースのプロジェクトは大抵BSDかそれに準ずるライセンスを採用している状況を鑑みて、もし後継を望むのであれば修正BSDにすべきでしたね。Liteのページより引用)これを受けての中村友次郎氏のツイートが、以下の物です。開発が止まっていたProxomitronクローンProximodoを引き継いで完成させたけど、元のライセンスがGPLなので公開できないという話。2013年1月30日hide氏の想定されている「GPLで公開した場合のシナリオ」とは、おそらく以下のようなものであると思われます。Liteを、GPLで公開した。Lite独自の、Proximodoには無い部分)を、自作の別のソフトウェア(仮にAと称します)に流用した。その結果、そのAまでもがGPLとなってしまい、これまで非公開にしていた部分も含めてAのすべてのソースコードを全世界に向けて公開しなければならなくなってしまった。(そのAが業務上で開発したソフトウェアで、機密保持契約の縛りの下で開発されていたとすると、ソースコードの公開は機密保持契約違反にあたるため、場合によっては賠償金を支払うなどのペナルティが課されてしまう。)ですが、このシナリオにはいくつかの誤解が含まれています。実際にはこのような事は起こりませんし、Proximodoの元作者にライセンスの変更を求める必要もありません。Liteを公開することができると考えられます。(1月31日16時台追記。そもそもhide氏自身が、自分で書いた部分のコードを一切公開したくないという意向である可能性もあるようです。hide氏が自身で書いたコードの一切を非公開の状態に保つためには、Proximodoの元作者にライセンスの変更を求める以外ありませんので、以下で提案している解決策は全くの見当違いということになります。いう経路でGPLが「感染」する事を危惧しているように見受けられます。独自の変更点の著作権はhide氏自身が保有しているため、実際にはこのような経路での「感染」は起こりません。独自の変更点として書かれたコードを仮にBと称するとして、Bの著作権はあくまでhide氏が保有しています。これをどのような条件で他人に利用を許諾するかはhide氏自身が自由に決められ、その都度好きなように利用許諾条件を定める......つまりライセンスを設定することができます。GPLにすることもできますし、修正BSDライセンスにすることも、Apacheライセンスにすることもできます。Liteに組み込んだと考えることができます。Liteからの派生物は同様にGPLとする必要がありますし、B'からの派生物もまたGPLとなります。その上でhide氏がBをさらに別のソフトウェアに組み込む時には、これはB'からの派生バージョンではなく、大元のBからの新たな派生バージョンB''となります。B'から派生したバージョンにはGPLが継承されていきますが、それとは別経路で生まれたB''にはGPLの影響は及びません。hide氏はB''を組み込んでクローズドソースのソフトウェアを自由に開発できますし、そのクローズドソースのソフトウェアの利用者からB''のソースコードの開示を求められても、それに応じる義務は一切ありません。Proximodo由来のコード(hide氏の著作物でないコード)を他のソフトウェアに組み込んで流用した場合も、組み込む前のバージョンにはGPLは「感染」しない上記の話は、流用した箇所(上記のB)の著作権をhide氏自身が保有している事が大前提となります。Proximodoに含まれていた部分やその改良物をhide氏が他のソフトウェアに流用した場合はどうなるのでしょうか。結論から先に言うと、これも上記の話と同じ理屈になります。Proximodoの一部を組み込む事にするソフトウェア(Proximodoの一部が組み込まれる前の状態)を仮にCと呼ぶとすると、Proximodoが組み込まれた後のソフトウェアC'は、ProximodoとCを組み合わせた派生物となり、Proximodoに設定されているGPLが引き継がれます。このC'からさらに派生物を作成した場合は、それらにもまたGPLが引き継がれていくことになります。Proximodoの一部が組み込まれる前のCにはGPLの影響は及びません。hide氏は引き続きCにGPL以外のライセンスを設定できますし、非GPLな派生物としてC''を開発することもできます。(C'の時点での実装は公開することになってしまいますが、その後にC''に加えた変更までは公開する必要はありません。)GPLに「感染」したからといって、すべてのソースコードを全世界に向けて公開する必要があるとは限らないまた、GPLについて言われる事の1つに、「GPLのソフトウェアを改造したら、ソースコードを広く一般に公開しなければならない」という話がありますが、これも誤解です。GPLのソフトウェアを改造したとしても、必ずしも全世界に向けてソースコードを公開しなければならないということはありません。GPLでは、そのソフトウェアのバイナリ(実行形式ファイル)を入手したユーザが、ソースコードの開示を要求した場合についてのみ、その要求に応えてソースコードを開示する義務があります。言い換えると、ユーザでない人にまでソースコードを開示する必要はありません。(もちろん、いちいち要求に応じてソースを提供するのは面倒だから誰でもソースをダウンロードできるようにしておく、という選択肢を取ることもできますが、それは義務ではありません。)例えばhide氏が個人で受託開発を手がけるベンダで、上記のB'やC'を顧客企業や官公庁などに導入したとして、その顧客企業や官公庁のユーザが「運用を他の業者に任せたい。以後のメンテナンスはその業者にやってもらいたいから、ソースコードを渡して欲しい。」と言った場合に、hide氏は顧客企業や官公庁のユーザにソースコードを開示しなくてはなりません。うちにもそのソースを下さいよ。」と言われたとしても、それに応える義務は全く無いのです。(とはいえ、顧客は提供されたコードをGPLの範囲で自由に再利用でき、また、GPLではそれを禁止することができない(追加の禁止条項を設けてはならないという規定がある)ので、絶対に第三者にコードが流出しては困るという場合には使えない事になります。場合においては、顧客の側から「(うちが金を出したんだから)他にばらまかないでくれよ」と言われるか、あるいは顧客の側もFLOSSに理解を示してくれて「公開していいよ」と言ってくれるかのどちらかだと思われますので、これが問題になるようなケースは受託開発の現場では少ないのかなと思いますが......と書いていたら、顧客が敵対企業にコードを売り渡すという場合があるという指摘を頂きました。そこまでいくともうライセンスがどうとかの話ではなくもっと別のレイヤの問題なのだと思います。)ただ、上記のCのソースコード全体をC'のユーザには見られたくない、という場合もあるでしょう。ソースコードの中に秘密のパスワードが含まれていたり、非公開の技術が含まれていたりという場合が考えられます。その場合でも、見られたくない部分がC'のユーザにとって必要でなく、またC'が正常動作するためにも必要ないのであれば、その箇所をC'のソースから取り除いた上でバイナリを提供すれば、何ら問題はありません。ユーザが手にしているのはC'のバイナリであるため、ソースコードの開示を要求できるのはあくまでC'に含まれている範囲のみに限定されます。Cが内蔵の秘密鍵を使ってサーバから自動的に最新のファイルを取ってくる機能を含むソフトウェアであったとして、秘密鍵を公開したくなく、また、提供先のユーザがその自動更新機能を使うつもりもないのであれば、C'では自動更新機能を丸ごと削除しておくことによって、提供先ユーザは何ら困らず、秘密鍵の公開もせずに済むことになります。それに対して、例えばCおよびC'を起動するのに必須の秘密の鍵があり、その鍵を取り除いた物をC'として提供した場合、提供されたC'は期待通りには動作しない役立たずなコードということになります。GPLv3ではこのような「使えない」提供の仕方を禁じているため、この形でC'を提供することはできません。しても秘密の鍵を表に出したくないのであれば、秘密の鍵をチェックする部分まで含めてC'から削除しておく必要があります。C'が特定のハードウェア向けの専用ソフトウェアだとして、鍵のチェック機構がハードウェア側に組み込まれているのであれば、C'にも秘密鍵を含めるか、C'というソフトウェア自体の提供を諦めるかの二者択一ということになります。言うまでもないのですが、Proximodo由来のコードを他のクローズドソースのソフトウェアの一般公開バージョンに流用した場合には、公開バージョンのユーザ(オンラインソフトであれば可能性としては全世界のインターネットユーザが該当するわけですが)に対してソースコードを開示する義務が生じます。このような状態が意図せず発生してしまっていた、というのは「GPL違反」の事例としてはよく見られるものです。なっては困るという場合には、どのコードがどのプロダクト由来なのか、それは誰が著作権を持っているコードなのか、という事は常にきちんと把握しておく必要がありますし、自分が権利を保有しているコードとそれ以外のコードとはなるべく設計的にも粗結合にするよう気をつけた方がよいでしょう。(ただ、外部由来のコードをガンガン書き換えたりコピペしたりして自作のコードなのか他人のコードなのかあやふやになってしまうことは多いですし、また、そういった「安全にするための工夫」を徹底するせいで設計が分かりにくくなるのも嫌なので、必要がなさそうな場合であっても、僕は公開するソフトウェアには流用箇所のライセンスと同じライセンスを全体に適用するようにしていますが。Liteを公開したとしても、hide氏は他のソフトウェアのソースコードをGPLで公開する必要はありません。Liteとhide氏の開発した他のソフトウェア(ここでは仮にDと称することにします)とを見比べて、両者に共通する箇所が少しでも含まれていた場合に、GPL違反であるとしてDのソースコードの開示を要求してくるということはあり得ます。LiteとDの間の共通箇所が上記の例でいうB由来であるのか、それともProximodo由来であるのか、という事の区別が外野からつかない場合に起こります。このような時も、共通箇所がProximodo由来でないのであれば、Dのソースコードの開示要求に応える必要はありませんし、共通箇所がProximodo由来でないことを証明できれば裁判にも勝てることでしょう。いえ、いちいち説明するのも大変ですし、裁判となると相当な時間と労力が必要になります。そのようなトラブルに巻き込まれるリスクを減らしたり、どちら由来のコードであるのかで揉めた時に説明する手間を省略するためには、上記の例でいうBにあたる箇所をあらかじめ修正BSDライセンスなどで公開しておく、という対策が有効だと考えられます。説明した通り、Bの著作権を保有しているhide氏自身は、その派生物にどのようなライセンスでも設定することができます。これはクローズドソースに限らず、逆に修正BSDやMITライセンスといったライセンスでB''を公開することもできるという事です。Lite独自の変更箇所のソースコードを公開する事自体については問題視していないと読み取れます。Lite独自の変更箇所のソースを修正BSDライセンスで公開する。LiteをGPLで公開する。Liteに組み込んだだけである。Dのソースコードまで開示する必要はない。して、GPL違反の疑いを晴らすことも容易になるでしょう。(実際、僕は個人的に開発しているアドオンの中で頻出の処理を抜き出して、個々の機能単位で使えるようにしたり、フレームワークとして使えるようにしたりしたものをそれぞれMITライセンスで公開していて、公開のアドオンと会社の仕事で作る納品物の両方で共用しています。)これを見ても分かる通り、独自の変更点を修正BSDライセンスで公開するにあたって、Proximodoのライセンスまで修正BSDに変更する必要はありません。Liteの実行バイナリもソースコードも公開することができるというわけです。Liteの関係を例にとって解説してみました。このように、GPLがどのような形で派生物に影響を与えるのかを正しく理解して、同時に、どのソフトウェアの著作権を誰が保持しているのかを正しく把握していれば、GPLと適切な距離を保ったままでも、コミュニティによる開発の成果を安全に利用したり、その逆に、独自の開発の成果をコミュニティに還元したりすることができます。実際に僕が所属しているクリアコードでも、業務上でお客様のご要望にお応えするにあたって、車輪の無駄な再発明を避けてコミュニティの成果を利用するという場面は多いです。様々なお客様のご要望に迅速にお応えできるのも、コミュニティのソフトウェア資産を安全に活用する知識があればこそです。このような誤解が生まれるのには、誤った認識に基づいて「GPLは怖い」と思い込んでしまう人や、そのような誤った認識を広めてしまう人(今回の件でも、hide氏のコメントを見て「へぇ、GPLって危ないんだ」「BSDなら問題ないんだ」と漠然と受け取ってしまう人はいるでしょう)、あるいは、GPLがどのように「感染」するのかを誤解したまま「GPL違反だ」と騒ぎ立ててしまう人、などの存在が少なからず影響していると自分は思っています。この一連の話を「めんどくさいな!」と思う人は少なくないと思います。他の人の著作物を利用する際は、GPLに限らずどんなライセンスであっても、どのようなことが許可・禁止されているのか、どのような影響があるのか、といったことはきちんと理解しておく必要があります。「修正BSDならめんどくさい縛りは全然無いのに」と言う人は多いですが、その修正BSDライセンスですらライセンス違反を犯してしまう人は実際にいます。GPLだけ避けていれば何も問題ない、という話ではないのです。条文が多いとややこしい、条文が少ないと分かりやすくて使い勝手のよいライセンス、と単純に考えてしまうのも早計です。条文が多いと言うことはそれだけキッチリ「この場合はこうですよ」ということがあらかじめ明言されているということで、解釈のぶれが少なくなって、「なるほど、この範囲内であれば安心して使っていいんだな」と判断できるでしょう。考えると、「複雑なライセンス」であることは必ずしも悪いことというわけでもない......と、自分は思っています。フリーソフトウェアライセンスへの誤解があるために、素晴らしい成果ができたにも関わらずそれが世に出ないままで終わってしまったり、しなくてもよい苦労をすることになってしまったりというのは、大変残念なことです。皆さんも折に触れて、オープンソースやフリーソフトウェアのライセンスへの理解を深めていただければ幸いです。余談:GPLのコードを見て学習した上で自分で書いたコードは、GPLになるのかどうかライセンスの「感染」は、コードのコピペだけが問題になるのではなく、何らかの形で影響を受けた時点で「感染」してしまうのだ、という見方もあります。1.9.2リリースに際してのWEBrickの脆弱性の修正についてゴタゴタがありました。これは要約すると、「コミュニティのMLに脆弱性を修正するパッチが投稿されたが、そのパッチにはライセンスが明示されていなかった。1.9.2をリリースできなくなってしまうし、パッチを見たことがある人が同じ問題を修正する別のパッチを作ったとしても、問題のパッチに引きずられて「派生物」と見なせるようなパッチになってしまう恐れがある。1.9.2をリリースすることができた。今回の例でも、hide氏がProximodoのコードを読んだ上で追加の実装を行ったのであれば、「追加の実装の箇所は100%完全に氏独自の実装とは言えず、Proximodoの影響を強く受けており、GPLの影響範囲となる」という風な考え方はできるかもしれません。それを言い出すと、そもそもProximodoのコードを一度見てしまった以上、その後に開発した氏のコードにはどこにProximodoの影響が出ているか分からないという事になってしまいます。それはつまり、Proximodoが修正BSDなどのソースコード開示義務のないライセンスの元で再公開されない限り、今後hide氏は永遠にGPL違反の火種を抱え続けてしまう事になった、意地の悪い言い方をすると、Proximodoのコードを見たと自分から言わなければバレなかったのに、言ってしまったがために、今後は「これGPL違反なんじゃないの?」と疑いの目を持たれ続けてしまうハメになってしまった、ということです。考えると、クローズドソースな世界と関わりを持ち続ける必要があったのであれば、hide氏はGPLなコードを一切目にしないまま生きるしかなかった、GPLなコードを見てしまった時点でもう手遅れだった、という話になります。これは、本当にリスクを0にするにはということで突き詰めた考え方で、僕自身、正直それは「やりすぎなんじゃないの」と思ってしまいます。そこまで気にしてたら生きていけないよ、とも。「GPLは嫌だから、危険だから」とざっくり言い切って、どうせお前ら強硬なんだろ、なんて無駄に煽ってしまうと、じゃあご期待通りに強硬になってやろうじゃないのとなってしまって、「ほう、それでお前さんはGPLから逃れられたと思ってるわけだな。言わせてもらうが......」と、こういう切り口で粘着質に責め立てられてしまう(って、まさにそういう底意地の悪いことをこの段落で書いているわけですけれども......)、そういう不幸の再生産のスパイラルに陥ってしまうんではないのか、と自分は思ってしまいました。藪蛇になるだけなんだから、こういう言及の仕方はあえてしない方がよかったんじゃないのかな、と、素朴に思った次第です。余談2:Proximodoをコピーレフトでなくしたい、という皮肉な要望についてここまでの話では触れませんでしたが、Proximodoが開発された経緯について考えてみると、hide氏の「ProximodoをBSDライセンスに」という要望はどうにも皮肉な物だなあと思えてしまいます。いうのも、Proximodoの登場の経緯を見てみると元々クローズドソースのProxomitronというソフトウェアがあって、これが大人気だった。作者によるメンテナンスが行われなくなってしまった。ソースがないから誰も開発を引き継げなくて完全に死んだプロダクトになってしまった。しょうがないからProximodoというクローンが新たに開発された。今後同じ事が繰り返されないように(という理由だったのかどうかは分かりませんが、結果として同じ事が繰り返されなくなる効果がある選択として)、Proximodoにはコピーレフトなライセンスが設定された。いうことで、Proximodoを使いたい人達は、Proxomitronの悲劇を繰り返して欲しくなんかないという思いが人一倍強くなっててもおかしくないんじゃないかなあ、と思うのです。BSD系のライセンスはコピーレフトではないので、もしProximodoが修正BSDでリリースされていて、それを誰か有志の人が改造して完成させてクローズドソースなライセンスでバイナリだけ公開して、それが人気を博した後で作者が急に姿を消したりなんかしたら、またProxomitronの時と同じ悲劇が起こってしまうわけです。GPL(コピーレフト)ならそうはならない、と。かかわらず、やっと表れた有志の人が「コピーレフトをやめてくれ」と要望を出している。これを皮肉と言わずして何と言うか。今回の件のように「GPLだから開発に協力しない」ということで有志の協力者達から見放されて、そうしてProximodo自体が改良されないまま放置されてしまうんだったら、それもそれでやっぱり皮肉な話だなあ......と、僕は思うのです。......と書いていたら、以下のような指摘がありました。Lite」は元が修正BSDらしいのですが、コードを公開している様子もなかったもので、こんな風に思ってしまいました。2013年1月31日その発想はなかった!!......というか、確かに言われてみると、素直に読めばそういう解釈の方が正しい気がしてきました。件のhide氏の「公開」という表現を、僕はソースも含めての公開だと勝手に思い込んでいたのですが、これがバイナリだけの公開を指していて、ソースを公開するつもりが一切無かったのであれば、確かにProximodo自体が修正BSDになってくれていないといけません。2013年1月31日ということで、なんかもうほんとにどうしようもなくどうしようもない残念案件だったようです。知って役立つOSSのライセンス:雑誌記事として掲載された物が公開されています。基礎知識としてどうぞ。達人出版会:「知って役立つOSSのライセンス」の著者の可知さんによる電子書籍です。オープンソースなライセンスやコピーレフトなライセンス、クリエイティブコモンズについて、他のライセンスとどう組み合わせられるのかを図にしてみた:過去に書いたエントリです。Togetter:RubyのMatz氏などいろんな方々の、ライセンスに対する考えがまとめられています。Togetter:このエントリの話からの流れで、非互換なライセンスの場合の話が出ています。オープンソース・ライセンスの談話室:可知さんによる、「こういう時このライセンスはどういう扱いになるのか?」といったトラブル事例集。説明が怪しい、という点についての補記ざっと読んだ感じ「元のソフトウェアがGPLだから公開できない」がおかしいことについては賛同できるけど、解説自体はすごく怪しいと思う。ライセンスは尊重して慎重に扱うべき。2013年1月30日という指摘を頂きました。具体的にどのあたりが怪しいのか、という事については以下のリンク先にまとめて下さっています。「「元のソフトウェアがGPLだから公開できない」という誤解について」へのコメントプロプライエタリなソフトのソースコード(オリジナル)の一部をオープンソースに流用した場合のオリジナルへの影響は、関係するライセンス全てを確認して、総合的に判断する必要がある。確かにこれはその通りで、ライセンスの種類によってもコードの流用の仕方によっても可否が変わってくるため、この例の話があらゆるケースに適用できるとは限らないという事は書いておくべきでした。いえ「ケースバイケースです」だけで閉じてしまっては訳が分からないので、本エントリは乱暴を承知である程度断定する書き方にしています。表現から、プロプライエタリなソフト開発において、オープンソースを都合よく使おうという姿勢しか感じられない。最初に断っておきたい点として、自分個人としても所属している会社の方針としても、自分達で開発した物は原則として自由なライセンスで公開したいと考えています。本エントリがともすれば「どうすればフリーソフトウェアやコピーレフトの成果にタダ乗りできるのか?」という事に躍起になっているとも受け取れるような内容になっていることは否めません。Liteが公開できない」というhide氏のコメントを出発点として、異なるポリシー同士をどのように擦り合わせれば矛盾しないで並立できるのか?という事を焦点に、特にプロプライエタリ側の視点から話をまとめまた結果そのようになったに過ぎず、ポリシーが衝突しないのであれば、やはり原則としてはアップストリームに自然な形で還元するのが望ましいと考えているという事は、釈明しておきたいと思います。コピーレフトが嫌いなら最初からGPLでライセンスされたコードに載っからずにスクラッチしなよ......」「っていうかProximodo自体が他のGPLなソフトウェアを引用してるんだったら、ライセンスの変更なんてそもそもその人1人の判断じゃできないだろうに......そこまでちゃんと考えた上で要求してるんだろうか?」といったあたりでした。件のページには「(そういったことの)是非について言及することはしませんし、議論したいとも思いません。」と明言されていました。本エントリでは敢えてその点には触れないことにして、ただ「誤解のせいで、問題なく公開できるはずの物を公開できないと勘違いしてしまっている」という事についてのみ言及するように心がけてみた次第です(余談の箇所を除く)。以下は、GPLv3でも問題ないのか?これは、いわゆるTivoizationについての話かと思われますので、より誤解がないように本文に説明を付け加えました。オープンソースに流用するプロプライエタリなソフトのソースコード(オリジナル)の一部は、公開することを前提にオープンソースを使用するかを検討する必要がある、と明確に説明した方がよいのではないか。ここはちょっと意味がよくわからなかったです。みたいなことをやりたい(文字列を分割してそれぞれの要素に対し処理を実行)Comments/Trackbacksバイナリ配布には厳しい制約があります「言い換えると、ユーザでない人にまでソースコードを開示する必要はありません。」は、バイナリ配布にはあてはまりません。