Latest topics 近況報告

ツリー型タブにおける、タブのドラッグ時のアニメーション効果についてのポリシー - Sep 13, 2013

English version of this entry is available.

ツリー型タブに頂いたプルリクエストについて、ポリシー上の理由から取り込めないなあと思ったのだけれども、これまで、参照しやすい形でまとまった文章としてポリシーを表明していなかった気がするで、何故この変更を取り込まないか（タブをドラッグ＆ドロップするときのアニメーション効果をOFFにできるようにしないのか）の判断理由を頑張って文章にしてみました。アーカイブとして、少し手直し＆追記してこちらにも転記しておきます。

Firefox本体の挙動としてタブのドラッグ＆ドロップ操作にアニメーション効果が適用されるようになって以後、ツリー型タブにも、その挙動に合わせるための変更を随時行ってきました。

しかしながら、この変更は万人にとって望ましい結果をもたらしたとは言えず、「タブをドラッグ＆ドロップで操作しにくい」「タブのドラッグ＆ドロップ操作時のアニメーション効果を無効にできるようにして欲しい」といった意見・要望が何度か寄せられています。今すぐにパッと挙げられるだけでも、Issue Tracker上には以下の2つのIssueがありました。

• "Drag as Child" is difficult to perform with tab animation · Issue #399 · piroor/treestyletab
• Turn off tab animations · Issue #499 · piroor/treestyletab

メールを通じて寄せられた意見も合わせると、無視できない数の人がこの件に関心を持っているようだ、という印象を僕は持っています。

冒頭に挙げたプルリクエストは、ドラッグ＆ドロップ時のアニメーションを無効化する設定をツリー型タブに加える、という物でした。変更箇所は最小限で、内容もおかしなことをしている部分はなく、コードとしてはそのまま取り込んで全く違和感のないパッチです。

ですが、自分の認識としては、このパッチで示されている方向での対応というのは言わば、「FirefoxのGeckoエンジンはバグだらけだしWebkitと互換性が低いから、Geckoを全部消して、WebkitにFirefox風のUIを付けた物を次のバージョンのFirefoxにしますよ」というような物なのではないか、と考えています。……という例えは極端なのでもう少し普通の言葉で言い直すと、「確かに皆が望む通りに対処することは簡単なのだけれども、プロジェクトの運営ポリシー的に、この点で皆が望む通りの対処の仕方をする事には非常に慎重である」ということになります。

大前提として、このプロジェクト（ツリー型タブというアドオンの開発プロジェクト）は、Mozilla Firefoxという自分には制御のできない別のプロジェクトに依存している・振り回される事を避けられないプロジェクトである、という事をまず押さえておく必要があります。

ツリー型タブ以外も含めた自作のFirefoxアドオン全体で、Firefoxの仕様変更に追従するために大きな変更が必要だったことが過去に何度かあり、その時の苦い経験から、現在のところ、自分はこれらのアドオン開発のプロジェクトにおいて以下のような方針を立てるようにしています。

• Firefox本体で実装している物と同じ目的の物は、できる限り、アドオン側で独自に実装し直さない。
  例えばTab Mix Plusはタブのセッション管理機能について、Firefox本体にそのような機能が入る前から開発されてきたという経緯から、Firefox本体のセッション管理機能とは全く別のセッション管理機能を持っています。が、今新たにTab Mix Plusを開発するとしたら、独自の仕組みを持つメリットは全くありません。 メンテナンスコストの削減と、「Firefox本体の機能と親和性が高くなるように開発されている」他のアドオンと併用したときの相互運用性を高く保つという、2つの観点から、独自の仕組みをメンテナンスし続けるよりは、Firefox本体で実装された仕組みにうまく載っかるように改修する道を選ぶべきであると、自分は考えています。
  • ただ、アドオン内の各部分が独自の仕組みに強く依存した設計になっており、Firefox本体で採用された新しい仕組みに基づく形に改修するのが非常に難しい（工数が大きい）場合には、独自の仕組みを保ち続ける選択を取る場合があります。
    例えば、TSTでは非同期な処理と非同期な処理の連携をうまく取るために、JSDeferredというライブラリを使用しています。一方で、最近のFirefoxではPromiseやTaskといった仕組みが導入されており、本来であれば、JSDeferredではなくこれらに基づく形で全体を作りなおすべきところです。が、ESR版Firefoxではまだこれらが使えないという事情もあって、移行はできていません。
    （逆に言うと、そのような手のかかる変更に現在のところ自分は着手できていないが、問題視はしているということで、この点を解消するプルリクエストであれば、他のアドオンとの互換性などいくつかの懸念が払拭できていれば、是非とも取り込んでいきたいと思っていると言えます。）
  • Firefox本体で提供されているライブラリのAPIの安定性がいまいち信頼できないという場合、そのより低位の、より変更が少ないと予想されるAPIに基づいて、自分でライブラリを作成して使用しているという場合もあります。
    例えば、Firefoxではユーザ設定を保存する機能としてpreferenceという仕組みがありますが、真偽値・整数値・文字列値という型の違いがあったり、設定の変更を監視するのが面倒だったりということで、より簡単に使えるようにするためのライブラリをFirefox自身がいくつか提供しています。FUELもそのひとつです。しかしながら、それらの「シンタックスシュガー」的な用途で作られたライブラリは、ライブラリ自体のAPIが彼らの都合でコロコロ変えられてしまうリスクが結構あり、それで泣かされるのは非常にアホらしいという認識が自分にはあります。なので、僕は自作のアドオン群では、preferenceを扱う最も低いレイヤのAPIであるnsIPrefBranchを直に操作するライブラリ（modules/lib/prefs.js）を自分で作って使っています。
    PromiseやTaskへの移行に踏み切れていない理由の1つとしては、このような懸念もあります。が、FUELのようなライブラリがFirefox内部でほとんど使われていないために捨てられてしまうリスクがある（彼らは、自分が使う物は大事にメンテナンスしますが、「アドオン作者が使うように」といった感じでお仕着せの便利ライブラリとして用意した物については、彼ら自身が使っていないので冷遇しがちという印象が僕にはあります。）のに比べると、PromiseやTaskはFirefoxの中の深い部分で既に多用され始めているので、今更捨てられてしまうリスクはそれほどには高くないかな……という目算もあります。
• Firefox本体で廃止が決まっている機能、廃止される見込みがある機能には、なるべく依存しない。
  例えば、記憶に新しいところではE4Xの廃止というトピックがありました。文字列のヒアドキュメント代わりにE4Xを使用している箇所が、E4Xの廃止で動かなくなるという事に対して、E4Xを諦めるか、E4Xを使い続けるのか、という2つの道があり得ました。プロジェクトによっては、E4Xを自前で実装し直すことでそれ以外の箇所の変更を最小限に留めるという道を選んだところもあったようですが、自分は、E4Xを捨てる道を選びました。このあたりの判断については過去に会社のブログで詳しく書いていますので、そちらも見てもらえると幸いです。
• プロジェクトのコンセプトから外れる事は、なるべくしない。
  コンセプトは「自分が使いたいものを、1機能につき1アドオンとして、最小の形で開発する」ということ。
  過去のエントリで詳しく書いていますが、自分が使わない機能や、コンセプトから外れる機能を盛り込むことは、短期的にはユーザの満足度を高める結果に繋がる可能性がありますが、長期的には、プロジェクトの寿命を縮めるリスクを増やす事だと自分は考えています。GitHub上に置いてある僕のアドオンは、基本的にはどれも「自分が使いたいから・使い続けたいから」開発をしているので、自分が使い続けにくくなる可能性が高まる変更は、なるべく取り込みたくないと考えています。
• 細かい挙動はFirefox本体の本来の挙動に可能な限り合わせる。違和感が無いように作り込む。
  例えばFirefox本体の機能として、F11キーでフルスクリーン表示に切り替えた時に、ツールバーが画面の外に隠れるというものがあります。ツリー型タブには「タブバーを自動的に隠す」機能がありますが、単機能だシンプル化だと言っておきながら一見するとツリーとは関係ないこのような機能を未だに含め続けているのには、このF11でのフルスクリーン表示時の挙動をFirefox本体の挙動に自然にマッチするようにしたいからというのが大きな動機としてあります。
  タブのドラッグ＆ドロップ操作のアニメーションに、ツリー型タブでそれなりの労力を割いて対応している最大の理由も、これです。（Firefoxにタブのドラッグ＆ドロップのアニメーションが実装されるまでは、UIが似ているAdobe Illustratorのオブジェクトとレイヤーの操作性を参考に作り込んでいました。これは今でも、タブ以外のオブジェクトをタブバー上にドラッグした時に見ることができます。）

以上を踏まえてこのプルリクエストで触れている問題を考えると、自分は以下の理由から、この変更を行わない方が良いという考えを持っています。

• Firefox本体に、タブのドラッグ＆ドロップ時のアニメーションをOFFにする機能が無い。
  • アニメーションするかしないかでFirefox内でのコードパスが大きく異なり、どちらもそれなりに大きな規模である。
  • が、アニメーションのための開発が活発に行われていたのに対して、アニメーション無しのドラッグ＆ドロップについては冷遇されている（気が、自分はする）。
  • ということは、今後、アニメーション無しのドラッグ＆ドロップは実装が削除される可能性もある（と、自分は見ている）。 削除される可能性がそれなりにある実装に強く依存してしまうのは、リスクが高い。
• ON/OFFの設定がないという事は、Firefox的には、タブのドラッグ＆ドロップは基本的にアニメーションするものであるというスタンスだと考えられる。であれば、Firefoxに依存するプロジェクトは、Firefoxの方針に従っておくのが得策であろう。
  • アニメーション効果を適用することは、見た目のキレイさだけでなく、使い勝手の向上にも関係するので、自分はそのようなスタンスを取ることには肯定的である。
  • アニメーション効果をユーザが無理矢理無効化すると、正しく動かなくなる、という部分がFirefoxの中にすらある。
    具体的には、タブを閉じる処理は内部でのデストラクタを走らせるトリガーとして「アニメーションが完了した」というイベントを使っており、アニメーションが無効化されているとデストラクタが走らないのでタブがきちんと閉じられないという問題があった（今その問題がどうなっているかは把握していない）。
    Firefox本体の側がアニメーションOFFでの利用をここまで冷遇している以上、そのような使い方をこのアドオンで手厚くサポートする必然性を、自分は感じない。
• 「アニメーションがあるとタブをドラッグ＆ドロップで操作しにくい」、という要望に真正面から「アニメーション効果をOFFにできるようにしました」と応えるよりも、そういう要望が出にくくなるような形での解決を図るべきだと考えている。
  • そもそもドラッグ＆ドロップで操作する必然性が薄ければ、問題なくなるのではないか。手動でツリーを編集しなければ意図した通りにならない、という状況があるのなら、ユーザに手動でのツリー編集という手間を強いる方向よりは、ツリー編集しなくてもストレスを感じないように、ユーザの意図を汲んで自動的にいい感じにツリーを構築するようにした方が、より望ましいのではないか。
  • アニメーション有りの状態でドラッグ＆ドロップすると狙った位置にドロップしにくい、という問題があるのであれば、それは、アニメーションをOFFにすることで対処するのではなく、アニメーション有りでも狙った位置にドロップできるようにするのが、正しい解決ではないのか。
• 僕自身は、アニメーションをOFFにして使うつもりがない。自分が使わない機能に対するメンテナンスコストを抱え込みたくない。
• 視覚的に連続した変化を認識しにくい、アニメーションされた方が却って認識しづらくなる、といった性質あるいは障害を持っている人がいる、という事を考慮すると、アニメーションをOFFにできるようにすることは、アクセシビリティ上意義のある事だと思う。
  が、Firefox本体がアニメーションをOFFにできるようになっていない以上、「タブをツリー表示できるようにする」というコンセプトのこのアドオンが、独自にアクセシビリティ上の配慮を盛り込むのはおかしいのではないか。
  • この点を真面目に考えるのであれば、「FirefoxのBugzillaで問題提起して、Firefox本体の側でアニメーション効果のON/OFFをできるようにする」あるいは、「Firefoxのアニメーション効果を無効にするという1つのコンセプトに則ったアドオンを開発する」という道を選ぶべきだと、自分は思う。（アドオンではないが、userChrome.js用のzzzz-removeTabMoveAnimation.uc.jsというスクリプトは、そのための物と言えそう。）

以上の事は、あくまで現時点での自分の考えがそうであるというだけで、絶対普遍の真理であるとは考えていません。ここに挙げた数々の懸念点を払拭できる材料があったり、あるいは、そのような懸念があってもなおこのようにするべきであるという強い動機があって、僕が同意できるのであれば、変更を取り込むことにはやぶさかでないです。

でも、そうでない限りは、この種の変更については「フォーク版を作ってそっちで自由に開発していって下さい。そして、その機能を必要とする人自身の手でメンテナンスしていって下さい。」というのがこのプロジェクトの方針ということになります。僕がこれらのアドオン群にオープンソースライセンスを適用しているのには、そのような自由を保障しておきたかったからという理由もあります。

冷たいようですが、どこで線を引くのか・何を基準に線を引くのかを熟慮した結果、このような線引きに落ち着いたということで、同様の不満を抱いている方々にはどうかご理解を頂ければ幸いです。

日経Linux 2013年10月号は「#!シス管系女子」まとめ冊子付きです - Sep 05, 2013

情報が公になったっぽいので宣伝。

もうすぐ発売の日経Linux 2013年10月号ですが、別冊付録として「#!シス管系女子」の1話から11話までのまとめ冊子が付いてきます。その代わり、連載の方はお休みです。カラー化とか手直しとか（主に）コミケとかの作業で手一杯でそこまで手が回らなかったので、休ませて頂きました……次の話を楽しみにされていた方、すみません。

• 第1話（通算14話）の一部だけカラー化してあって、シス管系女子の作り方をまとめたのはこの作業があったからでした（説明用に使ってる話はカラーにはなってません）。
• 第2話（通算15話）の連載時にやらかしてしまった技術的な間違いについては、大筋を変えない形で訂正してあります。これでやっと、胸のつかえが1つ取れた感じです……
• 表紙の絵はコミケの作業の後で描いたので、コミケの時のノリが残ってしまってちょっと絵柄が違うような気がしなくもないです。次の回から本編がいきなり描き込みが激しくなるといった事は残念ながらありません。表紙詐欺や！

別冊付録じゃなくて単行本にならへんの？というツッコミもたまに頂きますが、ページ数が足りなくて……でもまあ、内容的には風化しにくそうな鉄板のトピックを取り上げるように心がけているつもりなので、出る頃にはすっかり時代後れだよコンチクショウってことにはならない……といいなあ。

ところで、前回のまとめ冊子を自分で見ていた時に、なんかすごいギュウギュウ詰め感で、通し読みするとやたら疲れたんですよね。同じような絵が無意味に連続してしまってたり、解説を盛り込むことを優先して内容の集積度が上がってしまったりと、「解説する」という事の方にばかり意識がいってしまって、基本的な漫画力の低さが露呈してしまった……ということだったのだと思います。

なので、その後に描いた分では意識的にメリハリを付けるように気をつけてみたつもりでした。できあがった物をまだ自分は紙媒体で読んでいないのですが、さて、成果が出ているかどうか。

オフィスの広さとか - Sep 05, 2013

妻の勤務先の会社が、なんやかやでオフィスが広くなったという話を聞きました。

場所を変えずに人を雇っていったら机が増えて椅子も増えてだんだん混雑してきて、最終的には、椅子を引いたら後ろの人に当たるくらいに物理的に窮屈なレベルになってたとかなってなかったとか。横でうるさくされていると気が散って作業に集中できないタイプだと言っていたので、それだけ混んでたらまあ嫌でしょうね……と、話を聞いて思ってたんですけど。それが一気に広くなって、だいぶストレスが軽減されたそうです。

他方、自分が仕事上でお付き合いのあるとある会社のオフィスは、マンションの一室で数人のスタッフがいて作業をしているという環境でした。後ろを通過するためには椅子を引いてもらわないといけない程度……ということは、話に聞いていた妻の職場環境と同じかそれ以上の人口密度なんじゃないかと思います。が、（実際どうなのか正直な所は聞いてみないと分かりませんが）そんなに皆さんストレスフルでイライラしているという印象は受けませんでした。

人には、踏み込まれると不快になる距離、パーソナルスペースというものがあるという話を聞いたことがあります。よく知らない相手だったり、嫌いな相手だったりすると、踏み込まれたら嫌な距離は大きくなり、家族だったらその距離は小さく、恋人同士や新婚カップルや親子だとゼロ距離でも不快に感じない、と。

妻の勤務している会社は数百人規模で、顔も名前も知らない社員がいて当たり前という環境だと聞きました。その一方で、僕がお邪魔したその会社は社員数1桁台で、気心知れた仲間同士でやっているという雰囲気があった気がします。もちろん個々人の性格や考え方による部分もあるとは思いますが、パーソナルスペースが重なり合うような窮屈さでも大丈夫というのは、気の合う仲間とだから成り立つ働き方なのかなあと思ったのでした。

僕はグッデイとクリアコードとMozilla Japanのオフィスしか仕事環境としては体験したことがなかった（打ち合わせやなんかで他の会社にお邪魔しても、見られるのはだいたい会議室まで）ので、世の中にはいろんなオフィスがあるのだなあと思うのですが、僕自身はというと、作業に集中してると周りのことが見えなくなってしまうタイプなので、もしかしたら（クーラーとかがきいてれば）トイレくらいの広さのスペースででも仕事できちゃうのかもしれません……

ニオイ - Aug 24, 2013

最近、奥さんのおばあさんの米寿のお祝いで、奥さんの実家にお邪魔しまして。泊まりがけだったのとその時はめちゃめちゃ暑かったのとで、着て行った服を洗濯していただきました（翌日がお祝いの本番で、その時用には別の服を持って行っていたのです）。

その事を特に思い出すこともないまま帰ってきてしばらく経ったある日のこと、出勤するのに着た服からなんか妙に甘い香りがするんですよね。なんだこれって思って。

それで理由をずっと考えてたんですが、トイレでウンコしてるときに気がつきまして。ああこれこないだ奥さんの実家に着ていったやつだ……と。普段自分ちで使ってる洗剤と違う洗剤で洗ったから、違う香りがついてたんですね。

テレビ見てると「一日中香りが続く!」と宣伝してる洗剤があったりしますが、実際丸1日同じ甘い香りが続くと（別に常時プンプン漂ってるわけではないんですが、風向きとかでふわっと漂ってくる）、なんか……べつにここまで香らなくてもいいかな……って気がしました。彼女とか奥さんとかに近寄ったときにふわっと漂ってくるのは多分ドキがムネムネしてキュンと来るアレなのですが、31歳おっさんの自分から漂ってきてもうれしくないです……

それはそれとして。

米寿のお祝いによせてメッセージカードを孫一同から送ろうという話になったそうで、ついでだからと自分もそこに混ぜて頂きました。しかし、以前に1回しか会ったことがなくて一体何を書けばいいものやら……と本番前日夜にうんうん唸っていて、「おめでとうございます」みたいな無難なメッセージから先にペンが進まずにおり、さりとて例文集を調べたら負けかなみたいな思いもあってまた一層うんうん唸っていたのですが、ふと思いついた事があって、それを書き始めてみたら自分で結構いい事言ってんじゃねって気分になってきたので、その路線で最後まで書き切ってみたんです。で、何を書いたのかという話なんですけども。

ほとんど話した事も無い直系姻族のおばあさんだけれども、当たり前だけどその人がいなかったら僕が結婚したこの奥さんは生まれていなかったし、もちろん僕が奥さんに出会うことも無かったんですよね。結婚自体してなかったかもしれない、漫画連載なんて事もできてなかったかもしれない（今できているのは奥さんのサポートがあってこそだと結構思ってる）。家の近くを散歩して何気ない風景を見て「面白いねえ」なんてなごやかに話すこともなかっただろうし、ダイビングだってやってみもしなかっただろうし、イルカと泳ぐことも、珊瑚礁の中を泳ぐこともなかっただろう。おばあさんがいなかったら、自分の今の幸せのかなりの部分が丸ごと全部無かったんだ。

そう思うと、奥さんのルーツにあたる人が88歳で今も生きていて「ありがとう」「おめでとう」を言えるというのはすごい事なんだなあと思えてきて、そういう事をメッセージカードに書いたのでした。

それで実際お会いした時に直接「ありがとう」と言えば良かったんだけど、お祝いの席では結構緊張してしまってそこまで気が回らなくて言えなかったので、次にお会いしたときに覚えていたら言っとこうと思います。

あとそういう感じでなんだか最近自分の親とか祖父とかにも今更なんだけど感謝だったり尊敬だったりという思いを感じるようになってきていて、最近になってやっと人間らしくなってきたのかなあ今までは文字通り薄情者だったのだなあということを思ったりもしています。自分が幸せだなあと心の底から思えるようになってないと周囲、特に親への感謝なんてできないものなのかなあ、とか。かつては「なんで幸せになれないんだ」という感じの妬み嫉みだったりムカツキだったりが強くあって、それから現実を受容して無心の境地を経て、やっと感謝の気持ちに辿り着いたのかなあとか。というふうな書き方をしているとなんだか宗教体験っぽくてアレですね。

それと、親の介護がとか自分や奥さんが大怪我して介護が必要になってとか、そういう重大な問題に見舞われた時にも自分がそんな殊勝な気持ちを保っていられるのかどうかというのは未知の領域なので、どうにか殊勝な気持ちを保っていられるといいなあと思っていますという所で話を結んでおこうと思います。

シス管系女子のつくりかた - Aug 19, 2013

日経Linuxさんで連載させていただいております「シス管系女子」（「#!シス管系女子」）ですが、ごく希に、グレースケールで制作している漫画をカラー化する必要に迫られる事があります。が、あまりに希すぎて自分で作業の仕方を忘れてしまって、勘を取り戻すのに手間取ってしまったので、手順を文書化？して残しておく事にしました。

シス管系女子のつくりかた（カラー編） by Piro on pixiv

スクリーンショットも色つきの物に差し替えないといけないのですが、1回グレースケールにしてしまうともう元には戻せないので、初めてカラー化したときはわざわざスクリーンショットを撮り直す羽目になってしまいました。なのでそれ以後は、必ず元のフルカラーのスクリーンショットも残すようにしています。

で、これらの工程はグレースケールの元の漫画がある事が前提なので、ついでにグレースケールの漫画の作業工程の方も文書化してみました。（やってみたらこっちの方が分量が多くなった）

シス管系女子のつくりかた（白黒編） by Piro on pixiv

制作にはComicStudio Pro 4を使用しています。ごく初期の頃は紙に描いた下描きをスキャンしてペン入れからデジタル作業だったのですが、今は全工程をPC上で済ませるようになっています。

毎コマ魂込めて描く人もいる……というか絵描きを自認する人はそうあらねばならないのだろうなあと思うのですが、手が遅い僕は普段の仕事と並行してやろうと思うとそれでは余裕で破綻するのですよね。なので、複数のコマ、複数の話に渡って安定して同じような画作りができて、且つなるべく頭使わないで作業できるような方法を……と思って、現在はこんな感じのところに落ち着いています。

RubyのCGIスクリプトでService Hookを受けて実行した外部コマンドの標準出力を文字列として受け取る - Apr 02, 2013

1つ前のエントリで、Rubyでバッククォートで実行した外部コマンドの標準出力を何故か受け取れないと書いてたんだけど、追記した通り、これは「RubyスクリプトがCGIで実行されているせいで標準入出力がCGI用に使われており、バッククォートで起動した子プロセスはその標準入出力を引き継ぐから、子プロセスから標準出力に出した内容が文字列として呼び出し元のスクリプトに返される代わりに、CGI経由でクライアント（GitHubのService Hookのエージェント）に返されてしまっている」ということだった（すとうさんに教えていただいた）。

で、対策として spawn() と Process.waitpid() を使うと良いというアドバイスを頂いて、以下のように直してみた。

#!/usr/bin/ruby1.9.1
require "cgi"
require "shellwords"
require "json"
require "logger"
require "stringio"

SYNC_SCRIPT = "/home/piro/shared/or/tools/upload_nightly_xpi.sh"
RELEASE_SCRIPT = "/home/piro/shared/or/tools/release_addon.sh"
SSH_KEY = "/path/to/secret_key"
BASE_DIR = "/home/piro/shared/xul"
USER = "piro"

logger = Logger.new("/home/piro/shared/post-receiver.log")
#logger = Logger.new("/dev/null")
logger.level = Logger::INFO

# 子プロセスの実行結果（標準出力）を常に文字列で受け取るユーティリティ
def run(command_line)
  pipe_in, pipe_out = IO.pipe
  Process.waitpid(spawn(command_line, [:out, :err] => pipe_out))
  pipe_out.close
  pipe_in.read
end

cgi = CGI::new
puts "Content-Type: text/plain\n\n"
begin
  payload, = cgi.params["payload"]
  payload = JSON.parse(payload)
  project = payload["repository"]["name"]

  project_dir = File.join(BASE_DIR, Shellwords.escape(project))
  makefile = File.join(project_dir, "Makefile")
  if File.exist?(project_dir) and File.exist?(makefile)
    logger.info "build #{project}"
    sudo = "sudo -u #{USER} -H"
    command_line = "#{sudo} #{SYNC_SCRIPT} -i #{SSH_KEY} -b #{BASE_DIR} -d #{project_dir}"
    logger.info command_line
    logger.info run(command_line)

    command_line = "cd #{project_dir}; git describe"
    logger.info command_line
    current_commit = run(command_line).strip
    logger.info current_commit
    # 現在のコミットがタグを打ったまさにそのコミットである場合、
    # git describeの結果はタグ名だけになる。
    # なので、それをトリガーにしてリリース処理を走らせる。
    if !current_commit.empty? && !current_commit.match(/\A.+-[0-9]+-g[0-9a-f]+\z/)
      logger.info "=> release commit"
      command_line = "#{sudo} #{RELEASE_SCRIPT} -i #{SSH_KEY} -b #{BASE_DIR} -n #{project}"
      logger.info run(command_line)
    else
      logger.info "=> regular commit"
    end
  end

  logger.info "ok"
  p "ok"
rescue Exception => error
  logger.error error
  logger.info "ng"
  p "ng"
end

run() というのを定義していて、ここでパイプを作って spawn() の子プロセスの標準入出力に設定して、実行が終わるまで待ってパイプから実行結果を文字列として読み出す、ということをしている。（パイプを使う方法もすとうさんに教えていただいた。）

あと、このスクリプトは ~/public_html 以下に置いてるんだけど、apacheユーザで実行されてしまってファイルのアクセス権が……という事にも地味に悩まされていて、それでsudoを使ってたんだけど、suexecというApacheモジュールを使うと良いと教えてもらって sudo a2enmod suexec; sudo service apache2 restart としてみた。でもこの状態で git pull とかさせるとどういうわけか「error: cannot open .git/FETCH_HEAD: Permission denied」と言われてしまって（whoの結果ではapacheユーザじゃなくpublic_htmlがあるユーザになってるのに、何故だ……）、それで結局相変わらずsudoしている。

日経Linux 2013年4月号と5月号の「#!シス管系女子」 - Mar 31, 2013

現在発売中の日経Linux 2013年4月号なんですが、古いPCを復活させる企画の一環で痛PCを作られていて、素材にシス管系女子を使って頂いてます。

が、しかし。記事ではカッティングシートでデコる話が書かれているものの、実際に筐体にカッティングシートを貼った状態の写真が掲載されていません。なんでや……

実は編集さんから写真を頂いていて、ここに載せてもいいそうなので、せっかくなので貼り付けておきます。 MacBookの林檎マークとかみたいに、開いた時に他人から見て正位置になるように貼った方が「らしい」んじゃないのかなーと思わなくもないですね！

あと、その次の号の日経Linux 2013年5月号なんですが、#!シス管系女子のレギュラー連載に加えて付録として、無印シス管系女子の全話（1～13話）のPDFが付録ROMに収録されるとのことです。以前のまとめ冊子は1～12話収録だったのですが、今回は1話増えてさらにお得と言えなくもないので、無印時代が未読で以前のまとめ冊子も見逃されたという方は是非ともご覧頂ければ幸いです。

アドオンの自動ビルドとかリリース手順の自動化とか - Mar 30, 2013

以前、update.rdf関係を半自動生成するために頑張ったことがあって、各アドオンの紹介ページのHTMLからupdate.rdf（未署名）を作るあたりまでは自動化できてたんだけど、そこ止まりになっててまだまだ手動でやらなきゃいけないことが多くて、億劫で余計にリリースが滞る……という状況になっている。

それで、これじゃいかん！と思ってもっと自動化を進めることにして、とりあえずリポジトリのmaster/HEADを元に自動でテスト用ビルドを作るようにはした。

で、その知見を元にもう少し頑張って、開発版ではなくリリース版の方ももっと自動化するというチャレンジをしている。

続きを表示する ...

「コピーレフトと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についての話かと思われますので、より誤解がないように本文に説明を付け加えました。

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

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