Latest topics 近況報告

「コピーレフトとBSDスタイルではBSDスタイルの方が発展するのでは」という議論についての誤解あるいは言葉の裏にある欺瞞 - Feb 03, 2013

元のプロダクトがGPLでも、自分で開発した部分のソースは別のライセンスを指定できるよ、というエントリを書いた後で、言及した事例が自分の想像を超えた残念事例だったという事を認識して、非常に落胆しています。

ここまでのまとめ

先のエントリで言及したProximodo Liteの事例は、まとめると、こういうものでした。

1. 元々クローズドソースのProxomitronというソフトウェアがあって、これが大人気だった。
2. しかし、作者が死亡してしまい、作者によるメンテナンスが行われなくなってしまった。
3. ソースがないから誰も開発を引き継げなくて、完全に死んだプロダクトプロジェクトになってしまった。
4. しょうがないからProximodoというクローンが新たに開発された。
5. 今後同じ事が繰り返されないように（という理由だったのかどうかは分かりませんが、結果として同じ事が繰り返されなくなる効果がある選択として）、Proximodoにはコピーレフトなライセンスが設定された。
6. Proximodoの開発は頓挫し、機能的にも性能的にも中途半端な状態で放置されてしまった。
7. そこにhide氏が目を付けて、改造版となるProximodo Liteの開発を始めた。このhide氏は、元開発者が様々な理由からプロジェクトの継続を断念したソフトウェアについて、ソース提供を受けてその改良版・後継版を積極的に開発している人物であった。
8. Proximodo Liteのバイナリを公開しようとした段階になって、hide氏はProximodoがGPLでライセンスされていることに気がついた。
9. hide氏はGPLでProximodo Liteのソースを公開するつもりがなかった（ひょっとすると、いかなるライセンスであろうともソースを公開するつもり自体が無かった）ため、バイナリ公開を断念した。
10. それでもProximodo Liteを公開したくて、hide氏はProximodoの作者に対して、ProximodoのライセンスをGPLからBSDスタイルに変更する事を求めている。（イマココ）

実際の経緯については、一旦バイナリを公開した後、指摘を受けて公開を取り下げた上で、上記のような経緯であったと読み取れるようにページ上の記述を改変したという話もあるようですが、自分はその時の動きも改変前のページも見ていないので、どちらが事実だったのかは僕には分かりません。いずれにしても現時点ではライセンスに反している状態にはなっていないということで、とりあえず、以下の記述の前提としては、僕が見た時に書いてあった通りに解釈した上記の「経緯」が事実であったと仮定することにします。

意義ある活動である事は事実

僕自身釈然としない物がありますが、hide氏のしている事が善か悪か、という事は一概には断ぜられません。

ソフトウェアはユーザに使われて用を果たしてナンボの存在、用を果たせなければゴミクズ同然です。いくらかつて好評を博したソフトウェアであっても、今の環境で動かなかったり、重篤な脆弱性が放置されたままであったりするならば、ユーザにとっては無価値です。そういった「死んだ」プロジェクトを引き取って、新しい環境でも動くようにしたり、あるいは欠けていた機能を補ったりして、後継バージョンとして提供を続ける、という点においてhide氏の活動には大きな意義があります。

元作者が趣味の範囲で継続できなくなったプロジェクトは、他の人が趣味の範囲で引き取るのが、本来は最も望ましい自然な形でしょう。しかし誰にも引き取られておらず、それでもユーザがそのソフトウェアの利用を望むのであれば、趣味の範囲でなく仕事の範囲で引き取って貰うほかありません。つまり、プロジェクト運営専任のスタッフを雇ったり、ソフトウェア開発を生業としている人にお金を払って続きを開発して貰ったり、ということです。僕が所属しているクリアコードでも、顧客の要望を100％満たしてはくれない既存のソフトウェアについて、受託開発という形で改良して顧客に成果を提供するということは少なくないです。

その一方で、（hide氏にソースを公開する意図が無いのであれば、）Proxomitronの悲劇をまた繰り返そうとしているのか、あの過ちから何も学んでいないのか、あの悲劇を避けることよりも自分が独占的に対価や称賛を受け取る事を優先するのか、Proximodoの成果にただ乗りするだけただ乗りして何も還元しないのか、という憤りを僕は感じています。

成果を還元するということ

先程「僕も仕事で似たような事をやっている」と書きましたが、それでもクリアコードでは全社的な基本方針として、変更点のうち本来そのプロダクトに含まれているべき部分、他にも多くの人が困っているであろう部分については、アップストリームにpull requestやパッチとして還元するか、あるいはfork版として同一ライセンスの元でソースコードを公開する、という事をしています。ライセンス的にコピーレフトであろうと無かろうと、この方針は変わりません。（これが事実である事は、GitHubのオーガナイゼーションのページから各メンバーの活動状況を見てもらってもお分かり頂けるのではないかと思います。）

そして、成果を還元したい（成果をソースも含めてすべて公開したい）という思いと、お客さんに不利益をもたらしたくない（クリティカルな情報は公開できない）という思いの2つを、天秤にかけてどちらかを即決で選ぶのではなく、どちらも大切だから両立できるような道を探りたい、と考えています。自分自身が、フリーソフトウェアであったりオープンソースであったりの文化の中で育ち・育てられてきて、有形無形を問わず様々な形でおこぼれに預かってきたのだから、何かお返しをしないと格好が付かないし、誰もが収奪するばかりでは後が続かない。そのための努力を惜しむんでは自分に言い訳が立たない。そういう、誇りとか矜持とかの問題だと自分は思っています。

そこまで手間をかけられない、誇りじゃおまんま食えないよ、だからよくわからないGPLは避けてBSDスタイルを選ぶよ、という立場もあるとは思います。でもできれば、自分が1つ果実を持って行ったのであれば、畑に1鍬入れていって欲しい。そういう思いが僕にはあるので、オープンソースとかフリーソフトウェアとかコピーレフトとかについて誤解があるせいで還元できる場面なのに還元できていないという事例を見かけたら、先のエントリのような形で言及して誤解を解きたい、皆が安心して1鍬入れていける状況を整えたい、と思っています。そこで先のエントリでは、「自分で書いた部分はBSDスタイルのライセンスを設定してソースを公開し、元のソフトウェアと組み合わせた結果をGPLで公開する」というやり方を解説してみました。

上記のような事、「1つ実を取ったら1鍬入れる」を、綺麗事であるとか非現実的であるとか思う人はいると思います。宗教じみてて気持ち悪い、と思う人もいるかもしれません。そういった風潮に対して、寄付頼みの宗教団体でなくとも現実的な経済の営みの中でちゃんとできる事なんですよ、汚染物質を垂れ流さなくてもいい製品は作れるし利益も上げられるんですよ、非正規雇用のスタッフを使い潰さなくても利益は上げられるんですよ、コンプライアンスを軽視しなければ利益は出せないということはないんですよ、CSRは果たせるんですよ、という事を証明したくて、僕はクリアコードに在籍し続けているのかもしれません。（今思うと、Web標準は非現実的な絵空事ではないんだ、Web標準準拠でも格好いいWebページは作れるんだ、ということを証明したくて活動していた頃と、動機は変わっていないんですね。）

「BSDスタイルの方が発展する」という言葉と、その後に起こる事が一致していないという欺瞞

僕がこの事例で特に強い違和感を覚えたのは、hide氏の以下のコメントです。

発展しているオープンソースのプロジェクトは大抵BSDかそれに準ずるライセンスを採用している状況を鑑みて､もし後継を望むのであれば修正BSDにすべきでしたね｡

（Proximodo Liteのページより引用）

BSDスタイルの方が何故発展しやすいのか、そもそも何を発展と呼ぶのか。何を以て後継とするのか。そこをこのコメントではごまかしている気がしました。

オープンソースのプロジェクト自体の発展とは、そのプロジェクトがオープンソースであるままで継続的に開発が行われる事、派生プロジェクトも含めて後がどんどん続いていくことである、と僕は考えています。例えば仮にProximodoがBSDスタイルのライセンスであったとして、hide氏がProximodo Liteをクローズドソースでバイナリのみ提供するようになったとして、それを「オープンソースのプロジェクトが発展した」と言えるでしょうか。hide氏による開発が途絶えた後で誰か他の人がさらにその後継バージョンを作りたくても、もうできません。短期的には派生物が出てきても、その後が続かない、長期的に継続しないのです。僕は、このような未来を「発展した」とはとても言えません。

GPLやLGPLは、自分が開発した成果のソースコードを利用者にも開示するよう強制することで、必ずソースコードを社会に還元させるという方式のライセンスです。それに対してBSDスタイルのライセンスでは、自分が開発した成果のソースコードを社会に還元するかどうかを、その人自身の判断に委ねています。必ずしもすべての部分を社会に還元できるわけではなく、どうしても秘匿しなければいけない部分があるという場合がままある、そういう場合にGPLだと「全部公開するか、全く公開しないか」の二者択一になってしまうから、GPLのソフトウェアを元にした成果は社会に還元しづらい。BSDスタイルだと、秘匿したい部分を秘匿したままにできるので、成果を気軽に還元できる。そういう話は確かにあると思います。

AppleやGoogleは、ソースコードを再度オープンなライセンスで公開する道を選びました。Appleはゼロから製品を開発する事を避けて、LGPLのKHTMLを改良してWebKit（WebCoreとJavaScriptCore）を作り、LGPLでソースコードも含めて公開しました。そしたらその成果に載っかる形で、GoogleがV8を開発し、Chromeを開発し、それらのソースを修正BSDライセンスで公開しました。V8がオープンになっていたことから、node.jsが生まれました。皆、自分達の製品を作るための要素技術としてオープンソースのソフトウェアを採用し、成果をまたオープンソースのソフトウェアとして社会に還元しています。ソースコードをオープンに保ったままで、付加価値によって利益を上げ、継続するシステムを作り上げています。僕はこのような流れをこそ「発展」と呼びたいと思っています。

コピーレフトとBSDスタイルのどちらが「発展する」のかという議論は、どちらの方がよりソースコードを社会に還元して貰いやすくなるのかという観点での議論であって、どちらの方がクローズドな派生物を作りやすいかという観点での議論ではないはずです（そもそもGPLではクローズドな物を「作れない」わけで、そのためにわざわざLGPLという物が別に用意されているのであって、この点での議論の余地は元から無いでしょう）。そこをごっちゃにして、「BSDの方が発展する」と言って元作者にBSDスタイルのライセンスへの変更を持ちかけ、自分は成果のソースコードを還元するつもりは無いというのは、筋の通らない話だと僕は思っています。

ところで､ライセンスというのは双方(権利者と利用者)の合意で成り立ちます(合意に至らないならば､当然交渉になります)｡

（開発とライセンスのホットな関係より引用）

hide氏はこのように書いていますが、hide氏の合意形成あるいは交渉のやり方は、僕にはいまいちアンフェアであるように思えます。

I think that GPL is cause of the various problems.
I do not like trouble.

So please change "New BSD License" or "2-clause BSD license".
I will publish new version if it does so.
Please understand and accept my proposal!

（Proximodo Liteのページより引用）

hide氏はProximodoの作者に向けてこのようにライセンス変更を求めていますが、「その上でソースを秘匿しシェアウェア化したいと思っている」「バイナリのみ公開したい」といった意図があるのか無いのかを、少なくとも僕は、この文言から読み取ることはできませんでした。

ライセンスの変更は、おいそれとできるものではありません。自分のポリシーと照らし合わせて検討し直すだけでなく、場合によっては関係するすべての人に連絡を取り、貢献して貰ったコードのライセンスを変更して良いかどうか承諾を求める必要もあります。あるいは、GPLフリーにするために、GPLな他のソフトウェア由来の部分をすべてスクラッチで書き直さないといけないことすらもあります（実際、AppleはGCCを使わないで済むようにするためにCコンパイラの再実装に多大な貢献をしていますし、僕もXUL/Migemoを問題のない形で再公開するにあたって、ライセンスが不明瞭だった部分を手間をかけて入れ換えました）。信念の問題としても手間の問題としても、それなりに重い作業である可能性があります。それだけのことを求めるにあたって、「GPLには色々問題があるからBSDにしてくれ」だけでは、説明責任を十分に果たしているとは言えないと僕は思います。自分が何故BSDスタイルへのライセンス変更を求めているのか、この「publish」がどのような意味での言葉なのか、BSDライセンスになった後で自分がどのような形で成果を還元しようと思っているのか、あるいは思っていないのかを、hide氏は十分に説明できていないのではないでしょうか。

BSDスタイルとコピーレフトとを僕が使い分ける際の基準について

「こういう事をああだこうだ言っても人は動かない」「説得になってない」といった指摘はあると思います。僕自身、他人に何を言われようともこのhide氏が方針を変えるということは無いだろうと思っています（過去の活動の事を知るまではその可能性も考えていましたが、他のBSDスタイルのソフトウェアについて「改良版をバイナリだけ公開、シェアウェア化」という事をされていると知って、これは相容れないタイプだな……と思い知りました）。ただまぁ、「そもそも元作者とこの人の2者間の話なのだから他人が口出しする筋合いではない」ということについては、確かにそうですが傍目にフェアなやり取りとはちょっと思えなかったので、前項ではその点については口出しをしてみたんですけれども。

このエントリで言いたかったのは、「なんとなくBSDのほうがよさそう」「よくわからないけどなんだかGPLって面倒そう」ということで手放しにBSDスタイルが良いとされる風潮には、僕は違和感がある、ということです。

僕自身、ライブラリとして広く使い回したい物にはMITライセンスを設定して公開していますし、そうでない物についてもGPL/LGPL/MPLのトリプルライセンス（これはかつてのFirefoxに倣ってのもの）やMPL2.0を設定するなどして、ガチガチのコピーレフトよりはもう少し緩いものを選択しています。それに、ストールマンの「何でも公開しろ」という態度は、あれはあれで傲慢に感じていて好きではありません。コピーレフト寄りであっても、どこまでコピーレフトにするかという事には個人差があるものです。

• 自分の作った物が誰にどう使われようとも構わない、極端な話、誰かが看板だけ掛け替えた「改良版」を作って商売していようとも全く構わない、という事であれば、パブリックドメインにしたり、あるいはBSDスタイルのライセンスを選択して問題ないでしょう。
• 自分の作った物が看板を掛け替えただけの「改良版」として勝手に商売に使われるのは我慢ならない、やるならこっちにも分け前をよこせ、それが嫌なら無償で同じ条件でソースも含めて公開しろ、という事であれば、コピーレフトなライセンスを選択した方がいいでしょう。
• 自分の作った物がアイデアだけ引き継がれるのはいいけど、自分の血と汗と涙の結晶であるソースコードが他人にそのまま利用されるのは腹立たしい。アイデアを同じように具現化したかったら、自分で同じだけの血と汗と涙を投じて実装し直して欲しい。という事であれば、ソースコードを公開しないクローズドライセンスにした方がいいでしょう。
• 自分の作った物がソースコードも含めて引き継がれていって欲しい、他の人が自分と同じような苦労をしなくてもいいようにしたい、人類共有の財産にしたい、という時に、コピーレフトにするべきなのか、それともBSDスタイルにするべきなのか。そこが問題です。

僕がBSDスタイルのライセンスを選択する場面は大抵は、それ以上の改良が他の誰の手によって行われなくても別に構わない、あるいは、直すときには自分で直すつもりだ、という時です。BSDスタイルのライセンスにするということは、他の人が行った改良がフィードバックされない可能性が出てくるということです。それでも別にいいやと思える時に、僕はBSDスタイルのライセンスを採用する事が多いです。既存のプロダクトの多くで共通して存在していた部分を共有ライブラリとして切り出した、という場面で僕はよくこの選択をします。

その一方で、完成したプロダクトとはちょっと言えない、まだまだ改良が必要そうだと思える物や、アプリケーションレイヤの物については、僕はコピーレフトのライセンスを設定することが多いです。僕が関心を失った後でも、必要としている人がいつでも開発を引き継げますし、その人がまた興味を失ったとしても、さらに次の人が開発を引き継げます。

その時に僕がBSDスタイルを選択していないのは、やはり、オープンな形で開発が継続していて欲しい、仮に一旦途絶えたとしてもいつでも継続できる状態が保たれていて欲しい、「継続されて欲しいという意図」まで含めて引き継がれて欲しいからです。いつか自分が帰ってきたときに継続できなくなっていて欲しくないからです。囲い込みたい、継続する流れを途絶えさせたいと思っている人には使われなくても構わない、とすら思っています（でも完全に排除するつもりもないので、選択するのは若干緩いコピーレフトにしています）。

自分が作った物をBSDスタイルのライセンスにするということは、自分が感心を失って開発を放棄した後、誰かがそれを引き継いでくれたとして、その人が機能的に不足していた部分を補って完成させてくれたとして、自分がユーザーとして戻ってきて「ここはちょっと不満があるな……」と思ったとしても、もう二度とそこに手出し口出しできなくなる可能性がある、ということです。そうなってしまうともう、涙を呑んで、車輪の再発明や再実装に精を出し、泥をすすってデバッグに途方もない時間を費やすしかありません。元はといえば自分が作った物なのに、善意でそれを社会に還元したはずなのに、なんでそんな思いをしなきゃいけないのか。目の前に既に「あとちょっとここが直っていれば、期待通りなのに」という物があるにもかかわらず、不毛な開発に精を出さないといけないのか。これほど馬鹿馬鹿しい話もないでしょう。

僕はそういう事を我慢できそうにないので、自分が趣味の範囲で作った物のうち、アプリケーションレイヤの物やまだまだ改良が必要そうな物をBSDスタイルのライセンスで公開する勇気を持てないでいます。（でも仕事でやる物については、開発する工数自体に対してお金を払ってもらえるので、ライセンスはわりとどうでもいいと思っているかもしれません。同じ事をやり直すことにやる気は湧きませんが、その分お金が出るのであれば我慢できると思いますので。）

また、僕はアプリケーションレイヤの物について、ソースを秘匿することで利益を出せるという気がしていない、というのもあります。自分がそんな革新的な物を作れるとは思っていませんし秘密の技術をマネタイズする術も持っていません。誰にでもできる事の「やり方」を隠すことでお金を稼ぐというのは好きじゃない、というのも大きいかもしれません。それよりは、やり方は誰でも知ってるけどやるのが面倒くさいとか、やり続けるのに熟練が必要とか、うまくやるのにはセンスがいるとか、そういう所からお金を頂ければいいんじゃないのかな、と思っています。日経Linux誌での「シス管系女子」の連載も、やってる内容はそんなに高度な技術は扱っていませんし、絵もそう上手というわけではないですが、漫画で技術を説明するという事にユニークな価値を見出して頂けているからこそ、連載が続いているのだと思っています（自画自賛）。

ソフトウェアのユーザにとっての寿命は人の寿命よりも短いものですが、人1人の関心の寿命や、人1人が趣味でコミットできる期間の寿命よりは長いことが多いのではないでしょうか。また、開発の主体が企業である場合も、ユーザにとってのその製品の寿命は、企業の製品開発サイクルよりも長い場合が多々あります（Windows XPが一体何年使われ続けてきたか思い出してみて下さい）し、ともすれば企業の寿命よりも長いかもしれません。開発者としてなるべくソフトウェアが長いこと生き続けていて欲しいし、ユーザとしての自分にとってもなるべく長く便利に使える物であって欲しいので、僕は上記のような方針でライセンスを選択しているし、「独占的な権利を1000ドルで売ってくれ」なんていうメールが来てもガン無視しているのだと思います。

もちろん、これは非常に悲観的な見方で、楽観的な見方からBSDスタイルの方が発展しやすい・生き残りやすいと言う人は少なくないです。コピーレフトとBSDスタイルは、この点において北風と太陽のようなもので、多少のフリーライドを容認してでも寛容であった方が最終的にはいい結果につながるだろう、という話です。また、GPLが毛嫌いされている現状ではGPLを選択することの方が却って後継の登場を妨げるから、政治的にGPLは選択できない、という話もあります（先のエントリに書いた通り、誤解によって恐れられている部分があると思っているので、それが理由でBSDスタイルを選択するというのは本末転倒だと僕は思っていますが）。僕は、これについては「そうかもしれない」と思っていて、それ故に、「誰も彼もが無条件にコピーレフトにすればいい」とまでの過激な意見は持てずにいます。

なので、このエントリでもあくまで「自分はこうしている」という判断の事例を述べるに留めます。あくまで個人の心情として、上記のような不安をぬぐいきれず、また、ソースを公開していた所で大多数の人はパッチなど送ってくれないものであるという実感もあり（これについては、既にGPL/LGPL/MPLで公開しているコードなのでそのせいでパッチが提供されないのだという推測も成り立ちますから、鶏と卵だと思っています）、どうせいつか自分でメンテナンスを再開することになるのだろうという諦観から、気分の問題としてコピーレフトの選択をする場合がある、という話です。

すべての人がすべての状況で同じ判断をしてくれ、とは思いません。僕ほどには泥をすすることを厭わない人もいるでしょうし、そんな先のことなんか考えたってしょうがないよという人もいると思います。「やり方」からお金を稼ぐのが全然嫌じゃないという人もいるでしょうし、ものすごくユニークな技術を持っていて、そこから莫大なお金を引き出せるから秘匿したいという人もいるでしょう（コカコーラとかペプシコーラとかが、レシピを特許化しないでいるのはそのためだと聞いた記憶があります）。僕だって、そういう状況になったら別の判断をするかもしれません。人それぞれ前提が異なりますから、みんなが自分の前提に合った選択をして欲しいし、惑わしてその意志を曲げさせるような事もあって欲しくない、と僕は思います。

「元のソフトウェアが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のページより引用）

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

開発が止まっていたProxomitronクローンProximodoを引き継いで完成させたけど、元のライセンスがGPLなので公開できないという話。異論もあるだろうけど、趣味開発なら自分の開発ポリシー曲げてまで一般公開する義理はないしなあhp.vector.co.jp/authors/VA0538…

— 友次郎（Yujiro.N）さん (@finalbeta) 2013年1月30日

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となります。

その上で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違反」の事例としてはよく見られるものです。 そうならなっては困るという場合には、どのコードがどのプロダクト由来なのか、それは誰が著作権を持っているコードなのか、という事は常にきちんと把握しておく必要がありますし、自分が権利を保有しているコードとそれ以外のコードとはなるべく設計的にも粗結合にするよう気をつけた方がよいでしょう。 （ただ、外部由来のコードをガンガン書き換えたりコピペしたりして自作のコードなのか他人のコードなのかあやふやになってしまうことは多いですし、また、そういった「安全にするための工夫」を徹底するせいで設計が分かりにくくなるのも嫌なので、必要がなさそうな場合であっても、僕は公開するソフトウェアには流用箇所のライセンスと同じライセンスを全体に適用するようにしていますが。）

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自体が改良されないまま放置されてしまうんだったら、それもそれでやっぱり皮肉な話だなあ……と、僕は思うのです。

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

分りやすい具体例で学ぶGPL / ただ元発言の人は誤解ではなく「自前コードは一切公開したくない」から修正BSDにしてくれって言ってる気も / “Latest topics > 「元のソフトウェアがGPLだから公開できない」という誤…” htn.to/q4YSJ

— macawさん (@macaw_3) 2013年1月31日

@piro_or 件の方のソフトで「FastCopy Lite」は元が修正BSDらしいのですが、コードを公開している様子もなかったもので、こんな風に思ってしまいました。当方の見落としか下種の勘ぐりであればいいんですが

— macawさん (@macaw_3) 2013年1月31日

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

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

@piro_or 配布してるソフト一覧見れば分かるんですけど開発停止したソフトにliteって付けてソース非公開のシェアウェア化しまくってる

— malaさん (@bulkneets) 2013年1月31日

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

参考情報

• 知って役立つOSSのライセンス：雑誌記事として掲載された物が公開されています。基礎知識としてどうぞ。
• 知る、読む、使う！ オープンソースライセンス - 達人出版会：「知って役立つOSSのライセンス」の著者の可知さんによる電子書籍です。
• オープンソースなライセンスやコピーレフトなライセンス、クリエイティブコモンズについて、他のライセンスとどう組み合わせられるのかを図にしてみた：過去に書いたエントリです。
• ライセンス論議（※別の問題の考察用） - Togetter：RubyのMatz氏などいろんな方々の、ライセンスに対する考えがまとめられています。
• GPLコードとApache Licenseコードのライセンスの話 - Togetter：このエントリの話からの流れで、非互換なライセンスの場合の話が出ています。
• ケーススタディ | オープンソース・ライセンスの談話室：可知さんによる、「こういう時このライセンスはどういう扱いになるのか？」といったトラブル事例集。

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

ざっと読んだ感じ「元のソフトウェアがGPLだから公開できない」がおかしいことについては賛同できるけど、解説自体はすごく怪しいと思う。ライセンスは尊重して慎重に扱うべき。 / “Latest topics > 「元のソフトウェアがG…” htn.to/BzMefg

— Kietaさん (@typex20) 2013年1月30日

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

• 「「元のソフトウェアがGPLだから公開できない」という誤解について」へのコメント

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

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

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

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

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

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

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

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

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

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

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

フリーソフト作者の自衛のための手段としてのオープンソース化と、自衛のための「寄付は受け付けないよ」 - May 16, 2010

• Togetter - まとめ「ユーザの自由、作者の自由」

夜フクロウというMac OS X用のメジャーなTwitterクライアントがあるんだけど、夜フクロウのアップデートに伴って、作者のポリシーによって一部の機能が削除されたというか使い方が制限されるようになったそうだ。それに対して、その機能を使っていたユーザが「なんで機能を削除したんだ」「作者の横暴だ」「作者にはユーザの要望に応える義務がある」「作者の思想を押しつけるな」といった発言を作者に対して行ったそうだ。

以前、僕はこんな事を書いた。

あなたが使いたい物がどこにもないのなら、あなたが自分で作るしかない。使いたい物があっても作る気が無いのなら、誰にも文句は言えない。作る気がなくても使いたいのなら、賃金なり労力なりのコストを負担するのが当然。あなたのためにタダで働いてくれる都合のいい奴隷は、そうそういない。いまあなたがタダで利益を得られているとしたら、他の人がその人自身のためにやったことのおすそ分けを貰っているからにすぎない。おすそ分けが少ないぞと文句を言う権利はあなたにはあるけれども、それに応じる義務は誰にも無い。なんでおすそ分けをもっとよこさないんだ、と不満を述べる姿はただ滑稽なだけだ。

この辺の僕の認識は今もずっと変わっていない。

しかし作者がどう考えていようとも、「お客様は神さまだろゴルァ！！！」と横暴な物言いをするユーザは出てくるし、「ちょっとくらい耳を傾けてくれてもいいのに」と言って結局は全面的に要求が受け入れられるまでいつまでもしつこく食い下がるユーザも出てくる。それは避けられない。

でも、そういう声に毎日のように晒されてウンザリしてやる気を削がれたり、強迫観念に囚われて精神を病んでしまったりすることは、避けられると思う。自作のソフトウェアをオープンソースなライセンスのもとで公開するのは、そのための自衛の手段として有効なんじゃないかと僕は結構本気で思ってる。

フリーソフトウェア（※ここではストールマンが言う所の自由なソフトウェアの事）やオープンソースの考え方がどういう理由で出てきたかは、この際どうでもいい。重要なのは、「嫌ならフォーク（元のプロジェクトと袂を分かち、別プロジェクトとして分岐・継続すること）してよ」と言えるようになるという点だ。

こういう声を受けてストレスを感じる人というのは、多分、責任感が強いとかマジメだとか、そういう気質を持ってるんだと思う。だからこそ、要望が寄せられると「自分がやらなきゃいけない」と感じて抱え込んでしまうんじゃないだろうか。

クローズドソースだと、まさに文字通り「自分がやらなきゃ誰もできない」ので言い訳ができない。要望に応えないことを選ぶ場合、それに対する責めに真っ正面から立ち向かわないといけない。精神力が強くないとやってらんない。

でも、オープンソースにしておけば、言い訳ができる。自分がやらなくても、他の誰かがソースコードに手を加えて実現することが、理屈の上では可能なのだから。自分一人で抱え込まなくてもよくなる。

あるいは、「どうしてもやりたいんだったら自分でやってくれ」と言うこともできる。僕はよく、そういう言い方をしてると思う。自分自身が、他の人の作った拡張機能が動かなくなったのを見よう見まねで改造して動くように修正した、という所からアドオン開発のキャリアがスタートしているから、実感を持ってそう言ってる。やる気と時間さえあれば多分できるはず、本気でそれが必要なんだったら何が何でもやるはずだ、そう思ってる。こうなると、その機能がいつまで経っても実現されないのは、「僕のせい」ではなく「自分でやろうとしないその人のせい」になる。

相手がどう思おうとどうでもいい、とにかく自分の中でそういう理屈で言い訳ができるって事が大事なんだと思う。

同じ理由で僕は、Mozilla Add-onsの寄付募集機能も使わないようにしてる。

AMOでは、作者が設定しさえすればPayPal経由で寄付を受け取れるようになっている。ちょっと前にそういう機能が付いた。機能を使ってる人もちょっとずつ増えていってるみたいだ。でも僕は今の所、寄付機能を使って寄付を募るつもりはない。

何故かというと、「金払ってるんだから言う事を聞けよ」って言われるストレスに晒されたくないからだ。「いい物にはお金を払いたい、だから寄付したいんだ」と言われたらそれはそれで嬉しい。でも、金と一緒に「そしてお金を払ったんだからこっちの言う事を聞いて欲しい」という要求がくっついてくるんだったら（「寄付」のためのシステムを「対価を払うため」に使われるんだったら）、金は受け取りたくない。受け取らない代わりに自由でいさせて欲しい。

というか、相手がそう言っていなくても多分自分の中で「金を受け取っておいて無視するのか？」という声が聞こえてくるだろうと思う。金を受け取っていなければ、「別に、応えなきゃいけない義理はないんだし」という言い訳をしやすい。相手に対してというよりも、自分自身に対して、そう言い聞かせやすくなる。

アドウェア（広告を表示する機能をくっつけて公開することで、費用を広告収入でまかなうという配布形態）にしないのもこの理由が大きい。まあ、広告を入れる余地がどこにもないという設計上の理由もあるんだけど。

確かにソースを公開しないでいれば、競合相手が登場しにくくなって、名声を独り占めできるかもしれない。確かに寄付を募れば、お金が手に入るかもしれない。でも、何かを得るためには何かを失わないといけない。自由な時間、自分自身からも追い立てられることのない気楽な状態、そういう物が代わりに失われる。それに耐えられない脆弱な神経しか持ち合わせていないので、僕は、地位名声の独り占めも寄付金も諦めることにした。僕は、気楽な方がいい。ストレスに追い立てられながらこなすのは、生きるために避けられない仕事だけでいい。生きるために必要でない余暇のことにおいてまで、ストレスに追い立てられなくてはならない道理はない。

このエントリを見て阿久根市長みたいだなと言う人もいるようだ。

阿久根市長がどういう事を言ってるのか逐一ウォッチしてる訳じゃないからちゃんと把握してないんだけど、「自分でやれ」「嫌ならフォークしろ」とかそういう言い方が該当するんだろうか。それとも、作者が暴君のように振る舞う限りは作者自身は気楽だけど、その分のストレスは善良なユーザにしわ寄せが行ってるということだろうか。

僕は、善意のソフトウェア作者に精神を病んで欲しくない。フリーソフト作者（※言うまでもないけど、ここでは自由ソフトウェアではなく無料ソフトウェアの方ね）の中に一定数いるであろう「便利な物を作ってみたから、みんなもどうぞー」という素朴な善意でソフトウェアを公開している気のいいあんちゃんが、たかり体質の人間にまとわりつかれて疲弊して潰れる姿は、見たくない。だからこのエントリは、そういう人に自衛のための手段を紹介するという点にフォーカスして書いたつもり。

たかり体質の人は、「それが当然だ」という理由を尤もらしい言葉で強い語調で語る。だから気が弱い気のいいあんちゃんはうっかり「もしかしたら本当にそうなのかな」って思ってしまうかもしれない。

もう一度引用する。

あなたが使いたい物がどこにもないのなら、あなたが自分で作るしかない。使いたい物があっても作る気が無いのなら、誰にも文句は言えない。作る気がなくても使いたいのなら、賃金なり労力なりのコストを負担するのが当然。あなたのためにタダで働いてくれる都合のいい奴隷は、そうそういない。いまあなたがタダで利益を得られているとしたら、他の人がその人自身のためにやったことのおすそ分けを貰っているからにすぎない。おすそ分けが少ないぞと文句を言う権利はあなたにはあるけれども、それに応じる義務は誰にも無い。なんでおすそ分けをもっとよこさないんだ、と不満を述べる姿はただ滑稽なだけだ。

ユーザからの要望に応えることが作者自身にとっても当たり前になってくると、そもそもなんで要望に応えなきゃいけないの？という事が分からなくなってくる。自分で自分をがんじがらめにして、「要望に応えなきゃ」というプレッシャーだけが一人歩きしてしまう。

だから、思い返してみて欲しい。何故自分がそれを始めたのか、そして、何故それを続けているのかを。あなたは、エンドユーザの奴隷になるためにソフトウェアの公開を始めたのか？　違うだろう。

HYPER-ANCHORの「選択範囲のRangeからXPath式を求める」処理を追いかけたらLine Markerに再会 - Nov 09, 2009

Firefox Developers Conference 2009、企業でアドオンを開発してる所でただの宣伝ではない技術的な話が聞けそうなセッションということで、A3 「ビッツにおける拡張機能開発 (Wired-Marker 他)」見たいなあと思ってたんだけど、15:40からのトークセッションの打ち合わせがあったので見れなかったんですよね。Webに上がってる感想を見ると、AMOで公開した後のやりとりについて色々話してたそうで、うわー分かる分かる！見たかったなあ！と、悔しい思いをしてたんです。

今日になってチラシを改めて見ながら、僕の代わりにセッションを聞いてもらってた小野寺さんに「どんな発表だったん？　技術的に面白そうな所ありました？」と聞いたら、「ページ内の選択箇所の位置情報をXPathでURLに付与するとかなんとか」って言われて、「へぇーずいぶん前に僕も同じようなことをやったなあ、同じ事考える人がいるんだなあ。ひょっとして僕のコードコピペして使ったんかな？w　使われてたらちょっと嬉しいなあ。」と思って、でも公式サイト見てみても特に僕の名前とかLine Markerへの言及は無いし、「予想外したかなあ。でももし仮に僕のコードが入ってたらライセンス違反（笑）だよなあ。」と思いながらAMOの配布ページからXPIをダウンロードして中を見てみて、該当する箇所を見てみたんですよね。

わあ。懐かしいコードに出会ってしまった。

クリエイティブコモンズの表示-非営利-改変禁止ライセンス（ちなみにこのライセンスは、無料で見れる映像作品などに設定する場合に使われる「作者を明らかにしてタダで再配布しなさいよ、自分の物だと言い張ったりお金取ったりしたらあかんで、あと改造したり切り貼り素材に使ったりするのもあかんで」という性質のライセンスです）なので、具体的にコードの一部を引用して比較することは避けておきますが、content/hyperanchor/hyperanchor.jsの中で定義されてるgetXPathForNodeというメソッドと、Line MarkerのcontextMenuOverlay.jsの同名のメソッドを見比べると、変数の書き方とかループのラベルとか// fallback, for markers in another marker or other cases...というコメントとかを見る限り、Line Marker由来のコードと見て間違いないみたいなんですよね。どうも。

amachangとAzaと後藤さんと通訳の人と打ち合わせしてる隣で堂々とCopyright(c) BITS Co., Ltd. and Prof. Okubo. All Rights Reserved.なこのコードの解説が行われていたかと思うと、なんか笑えます。

まあそんなに独創性のあるアイデアでもないし、僕もコピペした後元のコードの作者の名前を書き忘れることがあるし、こういうのを作れる技術力のある人ならこの関数をスクラッチで書き直す（＆改良する）のは大して苦じゃないでしょうから、このエントリに気付いて今後のバージョンでライセンス違反を解消してくれればいいねえと期待しつつ生暖かい目で見守りたいと思います。

で、皮肉るだけじゃあまりに非生産的なので、僕のコードに限らずMPL1.1/GPL2/LGPL2.1のTri-licenseなコード（Firefoxそのものもそうです）をこういう風に流用したい方へのアドバイスを書いておきます。トリプルライセンスなコードはトリプルライセンスまたはいずれか1つのライセンスを引き継げば問題無いので、

• 全体をMPL1.1/GPL2/LGPL2.1のトリプルライセンスとする。
• 引用したコードが含まれたファイル（今回の事例であればhyperanchor.js）だけMPL1.1にする（MPL1.1はファイル単位までしか感染しないので、こういうことができる）。
• 引用したいコードだけ別ファイルに分けてそのファイルをMPL1.1にする。

のような感じにしておくと、僕のようなうるさい奴が「ライセンス違反じゃー！！　天狗のしわざじゃー！！！」とどや顔で騒ぎ立てることが無くて良いと思いました。逆に言うと、そのようにしておけば誰に文句を言われることもなくFirefox内部のコードでもなんでもパクれるもとい再利用できるので、みんなどんどんFirefoxの中からコードをコピペすると良いと思います。

イベントの感想エントリより前にこんなの書いてる僕って何なんでしょうね。

追記。コメント欄にも書き込まれていますが、先方からメールでもご連絡をいただきました。ライセンス上の問題が解消されるまで一時的に、当該アドオンの公開を停止されるとのことです。当該アドオン自体の有用性を否定するつもりはありませんので、早く再公開されればいいなあと、アドオン開発者の一人として思っています。

なんでこういう嫌らしいエントリを書いて晒し上げにするわけ？　メールで連絡してなしのつぶてだったら初めて晒すのでも十分なんじゃないのか？　的な批判を裸電球さんからいただきましたので改めてよくよく考えてみましたが、今回の自分の「目的」というのはどうも、「ライセンス違反を解消してもらうこと」ではなく「尊敬されなかった事への不快感の表明・発露」だったのでしょうね。

「オープンソース」という言葉が生まれたのはGNUの思想と無関係にGPLなどのライセンスの恩恵を受けるためだった、という歴史がありますが、そういう意味では僕自身も、「自分の名前をどこかに残すため」「自分の痕跡を残すため」「称賛を得るため」「遺伝子を残せないなら、代わりにコードと名前を残す」という風な大目的のためにオープンソースにフリーライドしているという部分が大きいのだと思います。だからこそ、「フリーソフトウェアの思想のため」でもなければ「コードが適切に再利用されるため」でもなく、あくまで「リスペクトされなかった、自分が蔑ろにされた、成果から得られたはずの称賛を横取りされた（と、事実はともかく自分は感じて）、それによって傷付いた自分がここにいるのだということを世界に対し表明し、同情を買い、自分の心を慰めるため」という目的を意識した行動を真っ先に取ったのでしょう。即ち、twitterやここのような「自分のフィールド」で、間接的な嫌らしい書き方で、相手を非難する、という行動を。

だからおそらく、メールで知らせて人知れず修正されたとしても、あるいは淡々と事実のみを記しても、僕の「目的」は果たされることはなかった。また、その瞬間の僕の頭には「ああ可哀想な僕たん。こんなに可哀想なんだから同情されるよね間違いないよね。」というシナリオができあがっていたから、そのシナリオに沿った行動以外を取る気にはなれなかった。

しかし一通り吐き出してやっと、おそらく大方の第三者が冷静に考えて思うであろう「馬鹿だなあ、そんな書き方をしたら余計に嫌われるだけだろ」という結論に自分自身も辿り着いたため、何ともばつの悪い、しかし今更これを引っ込める事もできない、後味の悪さと、自分という人間の小者っぷりを最大限にアピールしてしまった事への後悔を感じたわけです。今となっては、自分に対しても本件に関わった誰に対しても、残念な思いしか感じられません。

テキストリンクとpopInとjQuery - Mar 31, 2009

テキストリンクとpopInの競合、について調べてる。

popInが入っているとテキストリンクが動かない、ことの理由はどうも以下の2点によるみたい。

• popInがdblclickイベントをstopPropagation()しているため、テキストリンクにイベントが渡されなくなっている。
• popInがポップアップアイコンの挿入位置を決定するために（？）、選択位置のテキストノードを動的に分割しており、仮にstopPropagation()されない状態にしてテキストリンク側でイベントを拾って処理を行おうとしても、イベント発生時とテキストリンクが処理を行う時とでDOMツリーの構造が微妙に変わっていて、正常に動かない。

何か有効な対策が無いか考えてる。

ところでpopInは内部的にjQueryを使ってるようなんだけど、その旨の表記を僕には見つけられなかった。jQueryはMITライセンスとGPLのデュアルライセンスで、MITを選択した場合でもThe above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.（著作権表示とMITライセンスの許諾表示をソフトウェアの全コピーかもしくは重要な箇所で示す必要がある）ということなので、下手したらMITライセンスの違反ということになるような気が……　（一応フィードバックフォームから送ってはみた）

叩きや煽りを気にしない、その代わり感謝にも心動かされない、というライフハック - Mar 09, 2009

話題としてはちょっと古いんだけど……

無料ソフト「PSP filer」開発者、ユーザーからの「文句」を腹に据えかねて開発・公開中止 - スラッシュドット・ジャパン

開発厨なんて言われながらどうして開発を続けられるの？　って話。

そういえば最近では、テキストリンクの事でわりとボロクソに書かれてた。あと「触れちゃいけないアドオン作者」とかって名前が挙げられてたりしたし。「触れてはいけない」ってどういう意味なんだろう。こいつの作る物は危険だから使っちゃいかん、という意味なのか、それとも、こいつはキチガイだから関わっちゃいかん、という意味なのか。

W3C信者として叩かれまくり→タブブラウザ拡張の作者として叩かれまくり→老害として叩かれまくり（？）　という経緯を経て今に至っている自分の感覚では、今となってはもう、叩きや煽りにいちいち反応してたら精神が保たないよねって感じではある。「あーやっちゃったーハハハ、また叩かれちまうなあー」みたいな。以前は結構素直にそういうのに反応してる所があって、それなりに傷付いたりしょげたりしてたと思う。

しょげなくなった代わりに、褒められても前ほど喜べなくなってしまったんじゃないかって気もする。貶されて傷付く心と、褒められて喜ぶ心とはひょっとしたら同じ所にあって、傷付かないように蓋をしたら一緒に喜ぶ心にも蓋をすることになってしまったんではないか、みたいな。褒められて素直に喜ぶためには心の無防備なところをさらけ出して待ち受けておかなくてはならず、そうしてると傷つける言葉ばかりがたくさん降ってきて耐えられなくなる……みたいな。

そうなるともう、完全に惰性なんだよねえ。あるいは、口実。積極的に新しい情報を追いかけたりしないといけない面倒くささに対する、「必要だから調べるんだよ、全く無駄というわけでもないんだよ、そしてこれはいつか本業（クリアコードの仕事）に役立つんだよ、あくまで仕込みなんだよ」という、自分に対しての言い訳。

オープンソースカンファレンス2009 Tokyo/Springにクリアコードも出展するよ - Feb 03, 2009

会社のブログに告知が出てますが、OSC2009Tokyo/Springにクリアコードもブースを設けて参加予定です。2月20日・21日の両方とも。

「ライブ開発」と題した、スタッフが展示物というヘンテコ企画がありますが、これは池添さんがThunderbirdのC++部分を中心にバグを直したり直さなかったりする感じになるんじゃないかと思われます。

あと「話題沸騰」に吹いた。

脊髄反射的プロプライエタリ嫌い - Dec 26, 2008

Magi's View：憤りを感じさせられるプロプライエタリなFirefoxエクステンション - ITmedia エンタープライズ

先日ついたコメントを見た時も思ったけど、脊髄反射的プロプライエタリ嫌いには辟易する。

弊社（インターン募集中！）もGNU信者な人が多い（？）のでGNUの思想とかそういうのはよく分かるし別にそれを否定するつもりはないんだけど、この文脈でプロプライエタリかどうかは関係なくね？　っていう。全ての物事をプロプライエタリかどうかっていう観点でしか見てねえのかよ、っていう。何を置いてもまず真っ先に口から出てくるのがその言葉ってどうなのよ？　っていう。処女でなかったら問答無用NGの処女厨かよ、っていう。

Firefoxの開発者にはUIの設計という事に対するポリシーが欠けている - Sep 20, 2008

タイトルは半分くらい釣り。

ごく最近入った変更によって、最後のタブを閉じると常にウィンドウ全体が閉じられる、という挙動になったらしい（Firefox 3.1では多分それがデフォルトになる）。この変更はパッチを書いたDão Gottwald氏ではなく開発責任者の一人のMike Connor氏が決めたものらしい。

この件についてMike Conner氏のマネジメント能力の不足を責めてる人もいるようだけれども、僕としては、この人はUIの設計という物にポリシーを持ってないのかなー、という失望にも似た感想を覚えた。多分SearchLoad Optionsに抱いたものと同じ感覚。

最後のタブを閉じた時にウィンドウも閉じるべきかどうかってのは、隠し設定一つで動作を変えれるような些末な問題に落とし込むべき事じゃなくて、ユーザが触れるフロントエンドとしてのFirefoxの設計思想の根幹に関わる事だと僕は思う。ユーザに「Firefoxとはどういうものか」と説明する時の、メンタルモデルの作り方をガラッと変えてしまうものだと思う。

現状のFirefoxは、「Firefoxというアプリケーションがあって、そのアプリケーションは本体はごくシンプルな機能に限られていて、その中に、タブを伴って複数ページの切り替えができるサブフレームが含まれている」というトップダウンの設計になっている。「タブ」より上位に「メニューバーやツールバーやサイドバー」が存在しており、「タブ」より下位には何も従属していない。こういう構造だからGoogle Chromeのようなマルチプロセスにはできない（するにはとても手間がかかるだろう）。ユーザには、「タブとウィンドウは異なるレイヤに存在するもの」という認識が求められる。

Google Chromeは、「タブという小型でシンプルなWebブラウザがあって、それらを便利に操作できるようにするために一つのウィンドウに押し込めている」というボトムアップの設計になっている（ように見える、そういう演出をしている）。だからマルチプロセスで当たり前だし、「タブ」の上には何も（クローズボックスくらいは付いてるけど、それ以外のタイトルバーすら）なくて、ツールバーもロケーションバーも全部「タブ」より下位の存在として位置づけられている、そういう見た目をしている。ユーザには「タブ」と「ウィンドウ」の違いを意識させないようにしている、ように見える。

ちなみにOperaはMDIのアプリケーションで、この両者の中間にあると思う。「タブ」より上位の物もたくさんあるけど、ロケーションバー等は「タブ」に従属しており下位の存在である、という作りになっている。

タブより上にツールバーがあるか、タブより下にツールバーがあるか、っていうのは、単にバーの置き場所を上下に移動させればいいっていう話じゃないんですよ。フラットな「並び順の問題」じゃなく、縦の「主従関係」なんです、これは。

多分だけど、今回入った変更のような動作が許されるのは、「タブより下にツールバーがあるデザイン」のアプリケーションだけだ。タブより上位に何もないんだから、タブが閉じられたら後には何も残らないのが当たり前だ。

Firefoxの場合はそうではない。タブより外側に沢山の物があって、それらは「自分の下位にタブが存在している」ことを前提に動作している。下位の物（タブ）を一つ消したのなら、それより上位にある物は全部そのままでいるのが当たり前だ。にもかかわらず今回の変更で、下位にあるはずのタブによってそれより上位の物全てが破棄されるようになってしまった。そこにみんなは戸惑っているし怒っているんですよ。そういう、自分の中にある無意識のメンタルモデルまで分かった上で発言してる人は、そう多くないと思うけどさあ。

Mike Conner氏は、そこまでちゃんと分かった上で発言してたのかな？　自分が下した決定が、ユーザの心の中にあるメンタルモデルやそれまで動作していたアプリケーションの設計全ての前提を覆す物だって気がついていたのかな？　多分気付いてないよ。「ちょこっと動作を変えるだけ」そう考えてたんだろう。それが僕には、ポリシーがない無節操な行動に見える。

余談。冒頭で「半分は釣り」と書いたのは、これとは違うレイヤでFirefoxの設計にはポリシーがあるという事も知っているから。彼らは何でもかんでも中に取り込むのではなく、本体はシンプルに保ってそれ以外の要求はアドオンで解決する、というポリシーで開発を行っている（ように見える）。そのポリシーを今後も貫いていて欲しい。ただ、それは「Firefoxというプログラム」の設計ポリシーの話であって、「FirefoxというUI」の設計ポリシーじゃない。それとこれとは問題が別。ここまでタラタラと書いたこと、具体的な「FirefoxというUI」の設計に関して何もポリシーがないと、ユーザや開発者を振り回すことになる。そこのところをどうして彼らは分からないんだろう、という嘆きにも似た感情を、開発者主体で動いているオープンソースのプロジェクトというものについて感じることが僕にはたまにある。

追記。「（過去の）FirefoxとGoogle Chromeの動作（UIの設計思想）のどっちが素晴らしいか」ということについては、僕は考えないことにしてる。どっちにも一長一短がある以上、こういうのは刷り込みと慣れの問題でしかないと思うから。Mac OS伝統の「画面上端にメニューバー」とWindowsやGNOMEやKDEの「ウィンドウごとにメニューバー」のどっちが優れてるのか、というのと似たような話です。あくまで、UIとして（上記のような設計思想・メンタルモデルの面で）一貫性が保たれてないのはそれ以前の問題だ、というのがこのエントリの要旨ってことで。

さらに追記。前の動作に戻す隠し設定が欲しいというバグで中野さんが「初めて最後のタブを閉じようとした時に確認するのがいいんじゃないか」という提案をされている。選択肢をユーザにわざわざ見せるのは良くない、ユーザの理解を妨げる事は徹底して隠すべき、という人もいるだろうし、UIと動作と設計の整合性がとれてるなら僕もそれに同意だけど、現状のUIも動作も設計も全部がバラバラでちぐはぐな状況では、選択を求める方がまだナンボかマシだと僕は思う。ので、賛同コメントを付けてみた。まあ、コード書ける奴が正義のこの世界では、グダグダ評論家じみたことを書き連ねたり嫌味なコメントを残したりするより、とっととパッチ書いてIRCで担当者捕まえてねじ込む方が、実効性は高いと思うんですけどね……

またまた追記。くでんさんのコメントを読んだ後で思ったけど、上で書いた「疑い」とはむしろ逆で、Mike Conner氏は「Google Chromeのようなアプリケーションを元々作りたかったし、その信念に基づいて提案しただけ」なのかもしれないなあ。だから今回の変更も氏にとっては「本来そうあるべき姿に戻そうとしているのだから当然のこと」という感じなのかも。だとしても、できれば、行動を起こす前に「そういう理想はさておき、現状はどうなってるのか？」という所に先に目を向けて欲しかったとは思う。

22日追記。結局、「最後のタブを閉じた時にウィンドウを閉じない」隠し設定を付けるという、件のバグの表題通りの解決策についてはチェックインされて、それで解決ということになったようだ。でもって、他の文句は新しいバグ立てて述べなさいという仲裁も入った。Bugzilla的にはごく自然な流れ。にもかかわらず流れ読まずについ最後っ屁コメントを残してまた議論を蒸し返してしまった僕は、マヌケな悪役もいいとこですね。

Mac版Firefox 3正式版に、日本人ユーザにとって結構致命的な問題が残ってしまいそうな件について - Jun 10, 2008

• norah'# : みんなガンガン Vote しようぜ!!
• Re: みんなガンガン Vote しようぜ!! - WebStudio
• kozawa のたまに気になること | Firefox3.0リリースとMac上でFlash問題について
• Re: Firefox3.0リリースとMac上でFlash問題について - WebStudio

norahさんやkozawaさんはあくまで、「Firefox 3正式版」と銘打ってリリースされる記念すべき＆世間の注目度も非常に高い＆日本でのシェア拡大を考える際に重要な意味合いを持つと考えられるバージョンにおいて、一般のライトユーザ（特にMacではSafariで問題が起こるサイトがあるからFirefoxを使っているという人すらいる状況（つまり「Firefoxの方がマシ」という評価がある）であることに注意）が「あ、こりゃ使い物にならんわ」と判断を下してそれ以後も評価の対象にすらしなくなる、そんな事態になりかねないような致命的なバグを抱えたままリリースすることの、マーケティング上の問題の重大さを考えて、こう発言しているということは分かる。そもそもnorahさん自身はMac使ってないはずだし（kozawaさんはどうか知らない）。

「Netscape 6正式版」が公開されたことが皮肉にもNetscapeブランドの死を決定付けた、という過去をこの界隈の人なら憶えていないはずはないだろう。その同じ轍を踏むことを恐れているのだと思う。であるならば、僕もそこは全く同じ気持ちだ。

個人的には、ライバルのOperaもSafariも対応してる状況で:nth-child()等の疑似クラスやtext-shadowが間に合わなくて（まぁ過去の状況とかを見るに、今物凄いスピードで進展していて、年末リリース予定といわれているFirefox 3.1にはまあ多分入るだろう、という風な所にまでこぎ着けていることが驚きなんだけど）、CSSのサポートでカタログスペック上は一歩も二歩も取り残されてしまっている（でも実装の堅実さではGeckoは優れてると思う。Safariはこのページをまともにレンダリングできないんですぜ？）という事も残念だなあと思う。というのは余談なのでさておき。

今回問題になっている件は、RC1でやっと問題が修正されたものの、その修正によって逆に新たな深刻な問題が発生してしまったために修正取り消しとなって、RC1までは問題なかった（修正済になってた）のにRC2の段階でその修正が取り消されてしまって、タイミング的に正式リリースまでの再修正が絶望的になってしまったという、非常に間の悪い事故という感じのケースなので、これについては誰を責めてもしょうがないなあと僕は思う。

それでも敢えて犯人捜しをするのであれば、件の修正がバックアウトされてしまう原因になった問題がもっと早くに発覚していれば再修正も間に合ったかもしれなくて、リリース直前になるまでその問題が見つからなかった（報告日は5月20日）事が問題なわけで、件の修正自体ももっと早くに行われていればここまでタイミングの悪いことにはならなかったかもしれないわけで、Mac環境でのテストが不十分だったことやコードを書く人が少なかったことが問題なわけで、それはつまりMacユーザからのフィードバックやコードを書ける人の協力が今の今まで無かったからということであって、口をあんぐり開けて待ってさえいれば品質のいいソフトウェアがお上から降って来るものと思ってボサーッとしてたMacの（特にIMEを使用する言語圏の）Firefoxユーザ自身のせいということであって、そこらへんは中野さんの言う通りであって、自業自得なんだと思う。

norahさんやkozawaさんではなく、norahさんのエントリに日本人に対する嫌がらせが酷いですねというコメントを残してるような人、こういうのがよくないなあと思う。「お客様気分」っていうのかなあ。この辺のことはkozawaさんのエントリにあるzzz氏のコメントに書いてあることにただただ頷くばかりだ。

という風に煽り気味に書いてみたけれども、まあ、Macに限らずFirefoxユーザにそういう姿勢の人が多くなるというのは、しょーがないのかなとも思う。単純にエンドユーザが増えればその分、開発に協力するような人の割合は減ってくるし。今までだったら「ボランティアで運営してる？　労力が不足してる？　しょうがねえなあ、ほっとけねえから俺も手伝ってやるよ」という感じで手伝う人が現れてくれてた所、メジャー感が出てくると「ああ、Mozillaって金持ちなんでしょ？　じゃ人手も沢山雇えるだろうし、オフィシャルの人に任せときゃ大丈夫だよね」という感じで手伝う人が減ってくる、そういう所もあるんだろう。

Mozillaの中の人（中野さんとかの技術畑の人じゃなくて、組織の運営やお金の工面を考えるような分野の人）には、そういう所の諸々の問題も解決する方向で色々頑張ってもらいたいものだなあ、と、無責任に希望だけ書き捨てておく僕も前述の類の人と同じ穴の狢か。

追記。今回話題に上っている問題で具体的に誰がどーいう不便を被るのよ？　という例としては、ニコニコ動画でコメントを付けるとかUSTREAMのチャットで発言する時とかに、直接日本語を入力できなくて、必ず他のアプリケーションかネイティブな入力欄に日本語を入力してからそれをコピペしないといけない、という感じです。ニコ動はまあFirefoxの今のメインのユーザ層はあんまり使ってないかもだけど、USTREAMを活用してる層とFirefoxのアーリーアダプター層って結構かぶってる気がするので、組長あたりはご愁傷様ということになりますなあ。ということでこれらのサービスをよく使うマカーな人はRC1を使うか3.0.1を待つかこのバグがFixされたことが確認されているナイトリービルドを使うか、といった感じになるかと思います。

追記。言及された先にコメントとして書いた内容をこっちにも転載しておく。自分としては、この件はあくまで様々な関係者に少しずつ責任があると考えていて、Macユーザ「だけ」が悪いとは思っていないけれども、Macユーザの責任がゼロだとも思っていない。ただ、その事を以ってMacユーザ全員を敵に回して「お前らもっとコミットしやがれ」と居丈高にギャーギャー叫びたいわけでもない。「あなたが使いたい物がどこにもないのなら、あなたが自分で作るしかない。使いたい物があっても作る気が無いのなら、誰にも文句は言えない。作る気がなくても使いたいのなら、賃金なり労力なりのコストを負担するのが当然。あなたのためにタダで働いてくれる都合のいい奴隷は、そうそういない。いまあなたがタダで利益を得られているとしたら、他の人がその人自身のためにやったことのおすそ分けを貰っているからにすぎない。おすそ分けが少ないぞと文句を言う権利はあなたにはあるけれども、それに応じる義務は誰にも無い。なんでおすそ分けをもっとよこさないんだ、と不満を述べる姿はただ滑稽なだけだ。」ということを、今無邪気に要求の声を上げていて自覚していない人には自覚してもらいたい、ということをここでは言いたかった。