Home > Latest topics

Latest topics > 「元のソフトウェアがGPLだから公開できない」という誤解について

宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能! シス管系女子って何!? - 「シス管系女子」特設サイト

「元のソフトウェアがGPLだから公開できない」という誤解について - Jan 30, 2013

会社のブログに掲載するつもりで書きましたが、タイミング的に発表が遅れてしまいそうということだったので、勢い重視でこちらで公開してみます。

1月31日16時台追記。hide氏の意向についてのこのエントリでの推測が全くの見当違いである可能性が示唆されています。詳しくは追記2をご覧下さい。

「GPLだから公開できない」?

今日、「元のソフトウェアがGPLだから、改造版を公開できない」という、一見すると矛盾しているようにも思えるフレーズを見かけました。

GPLといえば「改造版を公開したら、改造版のソースも公開すること(※厳密にはちょっと違いますが、話を簡単にするためにこう書くことにします)、という条件の下で利用を許諾する」という形のライセンスです。 ですので、素直に考えれば「元のソフトウェアがGPLだから、(元のソフトウェアの作者にいちいち「改造版を作りましたが、公開してもいいですか?」などと確認を求めなくても)改造版を公開できる」ということになります。

にもかかわらず、なぜ「元のソフトウェアがGPLだから、改造版を公開できない」という話になるのか。これを理解するためにはいくつかの背景事情を知る必要があります。

想定されているであろう最悪のシナリオ

問題の「公開できない」とされているソフトウェアは、hideのひだまりな日々で紹介されている「Proximodo Lite」です。こちらはGPLで公開されているProximodoというソフトウェアを改良して開発されたものなのだそうですが、Proximodo Liteを開発したhide氏は以下のように書かれています。

さて気分良く公開しようかな…、ってだめじゃん!?↓
ライセンスがGPL…。特定の開発者にとっては鬼門と言うべき存在。某OS開発企業も知名度の高いゲーム会社も漏れなく謝罪とその対応に追われたことを知る者としては無視できません。
その気が無くてもうっかり私の作品に混入したら目も当てられませんからね。当然万一に備えて手を入れた箇所はProximodo専用に新規に書き下ろした処理のみにして、他では一切使用しないようにProximodo用処理であることが一目で分かるような書き方をしていますが。

発展しているオープンソースのプロジェクトは大抵BSDかそれに準ずるライセンスを採用している状況を鑑みて、もし後継を望むのであれば修正BSDにすべきでしたね。
ということで、今からでも遅くはないので修正BSDライセンス(New BSD License or 2-clause BSD license)に変更してください、作者(Mr Antony Boucher)様!

Proximodo Liteのページより引用)

これを受けての中村友次郎氏のツイートが、以下の物です。

hide氏の想定されている「GPLで公開した場合のシナリオ」とは、おそらく以下のようなものであると思われます。

  1. Proximodoを改造(改良)して開発したProximodo Liteを、GPLで公開した。
  2. Proximodo Liteの開発で必要になって作った部分(Proximodo Lite独自の、Proximodoには無い部分)を、自作の別のソフトウェア(仮にAと称します)に流用した。
  3. その結果、そのAまでもがGPLとなってしまい、これまで非公開にしていた部分も含めてAのすべてのソースコードを全世界に向けて公開しなければならなくなってしまった。
    (そのAが業務上で開発したソフトウェアで、機密保持契約の縛りの下で開発されていたとすると、ソースコードの公開は機密保持契約違反にあたるため、場合によっては賠償金を支払うなどのペナルティが課されてしまう。)

ですが、このシナリオにはいくつかの誤解が含まれています。実際にはこのような事は起こりませんし、Proximodoの元作者にライセンスの変更を求める必要もありません。やり方を少し工夫するだけで、何の問題もなくProximodo Liteを公開することができると考えられます。

(1月31日16時台追記。そもそもhide氏自身が、自分で書いた部分のコードを一切公開したくないという意向である可能性もあるようです。hide氏が自身で書いたコードの一切を非公開の状態に保つためには、Proximodoの元作者にライセンスの変更を求める以外ありませんので、以下で提案している解決策は全くの見当違いということになります。)

Proximodo Lite独自の変更点をhide氏が別のソフトウェアに流用しても、GPLは「感染」しない

上記のhide氏は、Proximodo Lite独自の変更点に含まれるコードを別のソフトウェアに流用した際に、Proximodo→Proximodo Lite→独自の変更点→別のソフトウェア という経路でGPLが「感染」する事を危惧しているように見受けられます。 ですが、独自の変更点の著作権はhide氏自身が保有しているため、実際にはこのような経路での「感染」は起こりません。

独自の変更点として書かれたコードを仮にBと称するとして、Bの著作権はあくまでhide氏が保有しています。 これをどのような条件で他人に利用を許諾するかはhide氏自身が自由に決められ、その都度好きなように利用許諾条件を定める……つまりライセンスを設定することができます。 GPLにすることもできますし、修正BSDライセンスにすることも、Apacheライセンスにすることもできます。

このBをProximodo Liteに組み込む場合、hide氏はBに対してGPLを設定した派生バージョンであるB'を新たに作り、それをProximodo Liteに組み込んだと考えることができます。 この場合、Proximodo Liteからの派生物は同様にGPLとする必要がありますし、B'からの派生物もまたGPLとなります。

(BからB'を派生させ、B'をProximodo Liteに組み込んでGPLで公開した後、さらにGPLの派生物が登場する様子の図)

その上でhide氏がBをさらに別のソフトウェアに組み込む時には、これはB'からの派生バージョンではなく、大元のBからの新たな派生バージョン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''に加えた変更までは公開する必要はありません。)


(CからC'を派生させ、Proximodoの一部と組み合わせたものを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およびC'を起動するのに必須の秘密の鍵があり、その鍵を取り除いた物をC'として提供した場合、提供されたC'は期待通りには動作しない役立たずなコードということになります。GPLv3ではこのような「使えない」提供の仕方を禁じているため、この形でC'を提供することはできません。 どうしても秘密の鍵を表に出したくないのであれば、秘密の鍵をチェックする部分まで含めてC'から削除しておく必要があります。 また、C'が特定のハードウェア向けの専用ソフトウェアだとして、鍵のチェック機構がハードウェア側に組み込まれているのであれば、C'にも秘密鍵を含めるか、C'というソフトウェア自体の提供を諦めるかの二者択一ということになります。

なお、改めて言うまでもないのですが、Proximodo由来のコードを他のクローズドソースのソフトウェアの一般公開バージョンに流用した場合には、公開バージョンのユーザ(オンラインソフトであれば可能性としては全世界のインターネットユーザが該当するわけですが)に対してソースコードを開示する義務が生じます。このような状態が意図せず発生してしまっていた、というのは「GPL違反」の事例としてはよく見られるものです。 そうならなっては困るという場合には、どのコードがどのプロダクト由来なのか、それは誰が著作権を持っているコードなのか、という事は常にきちんと把握しておく必要がありますし、自分が権利を保有しているコードとそれ以外のコードとはなるべく設計的にも粗結合にするよう気をつけた方がよいでしょう。 (ただ、外部由来のコードをガンガン書き換えたりコピペしたりして自作のコードなのか他人のコードなのかあやふやになってしまうことは多いですし、また、そういった「安全にするための工夫」を徹底するせいで設計が分かりにくくなるのも嫌なので、必要がなさそうな場合であっても、僕は公開するソフトウェアには流用箇所のライセンスと同じライセンスを全体に適用するようにしていますが。)

Proximodoのライセンスを変更する必要はない

上記の話を見ての通り、Proximodo Liteを公開したとしても、hide氏は他のソフトウェアのソースコードをGPLで公開する必要はありません。

ただ、このような事情を知らない人が、Proximodo Liteとhide氏の開発した他のソフトウェア(ここでは仮にDと称することにします)とを見比べて、両者に共通する箇所が少しでも含まれていた場合に、GPL違反であるとしてDのソースコードの開示を要求してくるということはあり得ます。 これは、Proximodo LiteとDの間の共通箇所が上記の例でいうB由来であるのか、それともProximodo由来であるのか、という事の区別が外野からつかない場合に起こります。

このような時も、共通箇所がProximodo由来でないのであれば、Dのソースコードの開示要求に応える必要はありませんし、共通箇所がProximodo由来でないことを証明できれば裁判にも勝てることでしょう。とはいえ、いちいち説明するのも大変ですし、裁判となると相当な時間と労力が必要になります。

そのようなトラブルに巻き込まれるリスクを減らしたり、どちら由来のコードであるのかで揉めた時に説明する手間を省略するためには、上記の例でいうBにあたる箇所をあらかじめ修正BSDライセンスなどで公開しておく、という対策が有効だと考えられます。

すでに説明した通り、Bの著作権を保有しているhide氏自身は、その派生物にどのようなライセンスでも設定することができます。 これはクローズドソースに限らず、逆に修正BSDやMITライセンスといったライセンスでB''を公開することもできるという事です。

文面から、hide氏は修正BSDライセンスでProximodo Lite、ひいてはProximodo Lite独自の変更箇所のソースコードを公開する事自体については問題視していないと読み取れます。 ですので、

  1. まず、Proximodo Lite独自の変更箇所のソースを修正BSDライセンスで公開する。
  2. 次に、Proximodoに1.を組み込んだProximodo LiteをGPLで公開する。

という形で2つのソフトウェア(ソースコード)を公開しておけば、 「その共通箇所は、修正BSDで公開済みのコードをProximodo Liteに組み込んだだけである。Dのソースコードまで開示する必要はない。」 として、GPL違反の疑いを晴らすことも容易になるでしょう。 (実際、僕は個人的に開発しているアドオンの中で頻出の処理を抜き出して、個々の機能単位で使えるようにしたりフレームワークとして使えるようにしたりしたものをそれぞれMITライセンスで公開していて、公開のアドオンと会社の仕事で作る納品物の両方で共用しています。)

これを見ても分かる通り、独自の変更点を修正BSDライセンスで公開するにあたって、Proximodoのライセンスまで修正BSDに変更する必要はありません。 Proximodoのライセンス変更を待たずとも、独自の変更点を切り出して修正BSDライセンスで公開するという1手間を加えるだけで、hide氏はリスクを負うことなくProximodo Liteの実行バイナリもソースコードも公開することができるというわけです。

まとめ

以上、GPLにまつわる誤解について、ProximodoとProximodo Liteの関係を例にとって解説してみました。

このように、GPLがどのような形で派生物に影響を与えるのかを正しく理解して、同時に、どのソフトウェアの著作権を誰が保持しているのかを正しく把握していれば、GPLと適切な距離を保ったままでも、コミュニティによる開発の成果を安全に利用したり、その逆に、独自の開発の成果をコミュニティに還元したりすることができます。

実際に僕が所属しているクリアコードでも、業務上でお客様のご要望にお応えするにあたって、車輪の無駄な再発明を避けてコミュニティの成果を利用するという場面は多いです。 様々なお客様のご要望に迅速にお応えできるのも、コミュニティのソフトウェア資産を安全に活用する知識があればこそです。

このような誤解が生まれるのには、誤った認識に基づいて「GPLは怖い」と思い込んでしまう人や、そのような誤った認識を広めてしまう人(今回の件でも、hide氏のコメントを見て「へぇ、GPLって危ないんだ」「BSDなら問題ないんだ」と漠然と受け取ってしまう人はいるでしょう)、あるいは、GPLがどのように「感染」するのかを誤解したまま「GPL違反だ」と騒ぎ立ててしまう人、などの存在が少なからず影響していると自分は思っています。

この一連の話を「めんどくさいな!」と思う人は少なくないと思います。ただ、他の人の著作物を利用する際は、GPLに限らずどんなライセンスであっても、どのようなことが許可・禁止されているのか、どのような影響があるのか、といったことはきちんと理解しておく必要があります。「修正BSDならめんどくさい縛りは全然無いのに」と言う人は多いですが、その修正BSDライセンスですらライセンス違反を犯してしまう人は実際にいます。GPLだけ避けていれば何も問題ない、という話ではないのです。

また、条文が多いとややこしい、条文が少ないと分かりやすくて使い勝手のよいライセンス、と単純に考えてしまうのも早計です。条文が多いと言うことはそれだけキッチリ「この場合はこうですよ」ということがあらかじめ明言されているということで、解釈のぶれが少なくなって、「なるほど、この範囲内であれば安心して使っていいんだな」と判断できるでしょう。そう考えると、「複雑なライセンス」であることは必ずしも悪いことというわけでもない……と、自分は思っています。

フリーソフトウェアライセンスへの誤解があるために、素晴らしい成果ができたにも関わらずそれが世に出ないままで終わってしまったり、しなくてもよい苦労をすることになってしまったりというのは、大変残念なことです。皆さんも折に触れて、オープンソースやフリーソフトウェアのライセンスへの理解を深めていただければ幸いです。

余談:GPLのコードを見て学習した上で自分で書いたコードは、GPLになるのかどうか

ライセンスの「感染」は、コードのコピペだけが問題になるのではなく、何らかの形で影響を受けた時点で「感染」してしまうのだ、という見方もあります。

例えば自分が記憶している例では、Ruby 1.9.2リリースに際してのWEBrickの脆弱性の修正についてゴタゴタがありました。これは要約すると、「コミュニティのMLに脆弱性を修正するパッチが投稿されたが、そのパッチにはライセンスが明示されていなかった。そのパッチをそのまま取り込んでしまうとRuby 1.9.2をリリースできなくなってしまうし、パッチを見たことがある人が同じ問題を修正する別のパッチを作ったとしても、問題のパッチに引きずられて「派生物」と見なせるようなパッチになってしまう恐れがある。そこで、MLに参加していなかった外部の人に協力を依頼して、無害なパッチを作ってもらってそれを取り込むことで、無事Ruby 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の登場の経緯を見てみると

  1. 元々クローズドソースのProxomitronというソフトウェアがあって、これが大人気だった。
  2. しかし、作者によるメンテナンスが行われなくなってしまった。
  3. ソースがないから誰も開発を引き継げなくて完全に死んだプロダクトになってしまった。
  4. しょうがないからProximodoというクローンが新たに開発された。
  5. 今後同じ事が繰り返されないように(という理由だったのかどうかは分かりませんが、結果として同じ事が繰り返されなくなる効果がある選択として)、Proximodoにはコピーレフトなライセンスが設定された。

ということで、Proximodoを使いたい人達は、Proxomitronの悲劇を繰り返して欲しくなんかないという思いが人一倍強くなっててもおかしくないんじゃないかなあ、と思うのです。

BSD系のライセンスはコピーレフトではないので、もしProximodoが修正BSDでリリースされていて、それを誰か有志の人が改造して完成させてクローズドソースなライセンスでバイナリだけ公開して、それが人気を博した後で作者が急に姿を消したりなんかしたら、またProxomitronの時と同じ悲劇が起こってしまうわけです。でもGPL(コピーレフト)ならそうはならない、と。

にもかかわらず、やっと表れた有志の人が「コピーレフトをやめてくれ」と要望を出している。これを皮肉と言わずして何と言うか。

まあ、今回の件のように「GPLだから開発に協力しない」ということで有志の協力者達から見放されて、そうしてProximodo自体が改良されないまま放置されてしまうんだったら、それもそれでやっぱり皮肉な話だなあ……と、僕は思うのです。

……と書いていたら、以下のような指摘がありました。

その発想はなかった!!……というか、確かに言われてみると、素直に読めばそういう解釈の方が正しい気がしてきました。件のhide氏の「公開」という表現を、僕はソースも含めての公開だと勝手に思い込んでいたのですが、これがバイナリだけの公開を指していて、ソースを公開するつもりが一切無かったのであれば、確かにProximodo自体が修正BSDになってくれていないといけません。

そう考えると、この人は本当にまたProxomitronの悲劇を繰り返そうとしていることになるわけで、実にやるせない話です……

ということで、なんかもうほんとにどうしようもなくどうしようもない残念案件だったようです。当初は、もしかしたらどこかでこの人の目に留まってくれたらいいなあとかちょっと思いながら、割と頑張ってこのエントリを書いていただけに、非常に落胆しております……

参考情報

説明が怪しい、という点についての補記

という指摘を頂きました。具体的にどのあたりが怪しいのか、という事については以下のリンク先にまとめて下さっています。

  • プロプライエタリなソフトのソースコード(オリジナル)の一部をオープンソースに流用した場合のオリジナルへの影響は、関係するライセンス全てを確認して、総合的に判断する必要がある。

確かにこれはその通りで、ライセンスの種類によってもコードの流用の仕方によっても可否が変わってくるため、この例の話があらゆるケースに適用できるとは限らないという事は書いておくべきでした。とはいえ「ケースバイケースです」だけで閉じてしまっては訳が分からないので、本エントリは乱暴を承知である程度断定する書き方にしています。

  • 「元作者にライセンスの変更を求める」ようなことにならないよう、当該ソフトを使用する前にライセンスを慎重に確認する必要がある。
  • 「感染」「義務」等の表現から、プロプライエタリなソフト開発において、オープンソースを都合よく使おうという姿勢しか感じられない。

まず最初に断っておきたい点として、自分個人としても所属している会社の方針としても、自分達で開発した物は原則として自由なライセンスで公開したいと考えています。

本エントリがともすれば「どうすればフリーソフトウェアやコピーレフトの成果にタダ乗りできるのか?」という事に躍起になっているとも受け取れるような内容になっていることは否めません。ただ、「Proximodo Liteが公開できない」というhide氏のコメントを出発点として、異なるポリシー同士をどのように擦り合わせれば矛盾しないで並立できるのか?という事を焦点に、特にプロプライエタリ側の視点から話をまとめまた結果そのようになったに過ぎず、ポリシーが衝突しないのであれば、やはり原則としてはアップストリームに自然な形で還元するのが望ましいと考えているという事は、釈明しておきたいと思います。

件の元発言を最初に見た時にも、真っ先に思ったことは「他人の成果物に載っかるんだったら、コード触る前にちゃんとライセンス確認しとこうよ……」「それで自分のポリシーを曲げたくないからって、後から本家にライセンスの変更を迫るなんて、下の下じゃないか……」「だいたい、本家がコピーレフトの思想の元にGPLで公開してるんだったらそれに素直に従うのが筋だろう? コピーレフトが嫌いなら最初からGPLでライセンスされたコードに載っからずにスクラッチしなよ……」「っていうかProximodo自体が他のGPLなソフトウェアを引用してるんだったら、ライセンスの変更なんてそもそもその人1人の判断じゃできないだろうに……そこまでちゃんと考えた上で要求してるんだろうか?」といったあたりでした。

しかしながら、件のページには「(そういったことの)是非について言及することはしませんし、議論したいとも思いません。」と明言されていました。ですので、本エントリでは敢えてその点には触れないことにして、ただ「誤解のせいで、問題なく公開できるはずの物を公開できないと勘違いしてしまっている」という事についてのみ言及するように心がけてみた次第です(余談の箇所を除く)。

  • 以下は、GPLv3でも問題ないのか?

これは、いわゆるTivoizationについての話かと思われますので、より誤解がないように本文に説明を付け加えました。

  • オープンソースに流用するプロプライエタリなソフトのソースコード(オリジナル)の一部は、公開することを前提にオープンソースを使用するかを検討する必要がある、と明確に説明した方がよいのではないか。

ここはちょっと意味がよくわからなかったです。

分類:ソフトウェア, , 時刻:20:06 | Comments/Trackbacks (3) | Edit

Comments/Trackbacks

バイナリ配布には厳しい制約があります

「言い換えると、ユーザでない人にまでソースコードを開示する必要はありません。 」
は、バイナリ配布にはあてはまりません。

下記をご覧ください。

http://www.gnu.org/licenses/gpl-faq.en.html#WhatDoesWrittenOfferValid

Commented by gniibe at 2013/01/31 (Thu) 22:18:43

no title

http://ossipedia.ipa.go.jp/doc/187/
こちらの8.2.1では

> オブジェクトコードを保有していない者がソースコードを請求した場合にそれに応ずる義務があるかについては、GPLv2では不明確であったが(“Accompany it with a written offer to give any third party”)、GPLv3 では請求に応じる必要がないことが明確になった(“accompanied by a written offer to give anyone who posseses the object code”)。これは、「なんらかの形態でプログラムを保有する人は、それを改変し実行する権利も持つべきである」(逆に言えば、オブジェクトコードも持たない人にまでソースコードを提供すべき理由はない)というコピーレフトの理念をより明確化したものといえる。

とあるので、その解釈に従って判断したのですが、この解釈が間違っている、あるいは、条文の方がまた変わったということなのでしょうか?
実際、http://www.gnu.org/licenses/gpl.html を見てみると、引用されている英文と同一の文章は現在の条文には書かれていないですし……

Commented by Piro at 2013/01/31 (Thu) 23:37:41

Proximodo が不自由なソフトウェアになる日

Proximodo に手を加えてコンパイルした人が、Proximodo のライセンスを GPL から修正 BSD ライセンスに変更するよう原作者に依頼する事例が発生し、各所に波紋を呼んでいるようです。 Proximodo 本家 hideのひだまりな日々 Proximodo Lite Latest topics > 「元のソフトウェアがGPLだから公開できない」という誤解について - outsider reflex Latest topics > 「コピーレフトとBSDスタイルではBSDス...

Trackback from 練炭ブログ at 2013/02/04 (Mon) 08:40:02

TrackBack ping me at


の末尾に2020年11月30日時点の日本の首相のファミリーネーム(ローマ字で回答)を繋げて下さい。例えば「noda」なら、「2013-01-30_gpl.trackbacknoda」です。これは機械的なトラックバックスパムを防止するための措置です。

Post a comment

writeback message: Ready to post a comment.

2020年11月30日時点の日本の首相のファミリーネーム(ひらがなで回答)

Powered by blosxom 2.0 + starter kit
Home

カテゴリ一覧

過去の記事

1999.2~2005.8

最近のコメント

最近のつぶやき