Latest topics 近況報告

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

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

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

msysgitとTortoiseGitの組み合わせでSSHでの接続に失敗する - Nov 10, 2010

SubversionからGitに移行したまとめには書いてなかったけど、TortoiseGitを使うと git@github.com:piroor/treestyletab.git とかのcloneやpullに失敗するという現象に遭遇した。「じゃあ諦めてmsysygitのbashコンソールからやるか……」で今まではなんとかなってたんだけど、これもいつの間にか動かなくなってた。「fatal: the remote end hang up unexpectedly.」とか言われる。

僕は会社でメインで使ってるUbuntuの上で作ったOpenSSHの鍵を使ってて、Windows環境ではそれをPuTTY形式の鍵に変換して使ってる。変換がうまくいってれば、OpenSSHの公開鍵をauthorized_keysに登録してあるサーバに対してもPuTTYで接続できる事を確認済み。pagent.exeが起動していてそいつにPuTTY形式の鍵が読み込まれていれば、パスフレーズの入力も省略できる。

なのにGitではうまくいかない。

TortoiseGitでSSHできない件についてはTortoiseGit 1.5.8付属のTortoisePlink.exeのバグらしい。次のリリース版では直ると書いてあるけど、今使えないんじゃ困る……なので、TortoiseGitの設定ダイアログのNetworkの所でSSH Clientに「C:\Program Files\TortoiseGit\bin\TortoisePlink.exe」の代わりに「C:\Program Files\TortoiseSVN\bin\TortoisePlink.exe」（TortoiseSVN付属のTortoisePlink.exe。こっちはこのバグがない。）を指定して回避することにした。

これでGUI（TortoiseGit）からはcloneしたりpullしたりpushしたりできるようになったんだけど、msysgitのbashからは相変わらずpullも何もできなくてやっぱり「fatal: the remote end hang up unexpectedly.」って言われる。

エラーメッセージで検索してたら、英語圏のフォーラムの記事が引っかかったんだけど、読み進めてるうちにGIT_SSHという環境変数が関係してるらしいという事が分かった。bashコンソール等でSSH経由での接続を試みる時は、Windowsの環境変数でGIT_SSHに入ってる物がSSHのクライアントとして使われるみたいだ。早速システムのプロパティで確認してみたら、大当たりだった。「C:\Program Files\TortoiseGit\bin\TortoisePlink.exe」とバグ持ちのSSHクライアントのパスが入ってたので、「C:\Program Files\TortoiseSVN\bin\TortoisePlink.exe」を指定し直しておいた。bashコンソールを起動し直してもう一度試したら、ちゃんとpullできるようになってた。

TortoiseSVNだとフォルダを複数選択してまとめてチェックアウトでワーキングコピーを最新の物に更新できてたんだけど、TortoiseGitだとそれがうまくいかないようだったので、こういうbashスクリプトで代用しようとして、Windows環境だとgitにパスが通ってない（Cygwinとmsysygit両方入ってる環境だから敢えてmsysgitにはパスを通してない）から

for dirname in *
do
  if [ -d $dirname/.git ]
  then
    cd $dirname
    echo "pull: $dirname"
    "/c/Program Files/Git/bin/git.exe" pull
    echo "submodule update: $dirname"
    "/c/Program Files/Git/bin/git.exe" submodule update --init ""
    "/c/Program Files/Git/bin/git.exe" submodule foreach 'git fetch;git c he cko ut  origin/master'
    cd ..
  fi
done

としてたんだけど、それがうまくいかなかったからムキーッとなってたんだけど、うまくいくようになってよかった。

SubversionからGitに移行した - Nov 01, 2010

アドオンの開発にはずっと須藤さんに用意してもらったSubversionのリポジトリを使ってたんだけど、

• インターネットに繋がらない状態でコミットできないのが辛い
• 他の人からの変更を受け取りづらい（そんな事があればの話なんだけど）

と思っていて、Git（あるいは他の分散型バージョン管理システム）ならそれが解消されると期待してて、でもずっと移行できていなかった。

• コマンドライン操作が嫌いなので、Subversionを使うのにWindowsではTortoiseSVNを、LinuxではRabbitVCS（旧称：NautilusSVN）を使ってるけど、GitではWindowsにはTortoiseGitがあってもLinuxでは相当する物が無いみたい。
• バージョン管理システムを移行するとそれまでのコミットの履歴も全部なくなっちゃうんじゃないの？
• git-svnっていうのを使うといいと聞いたけど、試しても空のディレクトリしかできないんですけど……

というのがその理由だった。でも

• git-svnは時々動作がうまくいかない事があるみたいで、Windows上のmsysgitが特に高確率で失敗するだけで、VirtualPC上のUbuntu 10.04LTSのgit-svnだとそれほどでもなかった。
  • それで成功したケースだとコミット履歴が完全に引き継がれてた。なんだ、ちゃんと動けばちゃんとやってくれるんじゃん！！！
• 最近、システムモニターの開発でGitをずっと使ってたから、まあLinux上ではコマンドラインでも別にいいかな……という気がしてきた。

という事で、思い切って移行してみる事にしました。具体的な手順はSourceForge.JP のプロジェクトを Subversion から Git へ移行するに従いました。

SubversionとGit

大まかに言うとこういう事だと僕は理解してる。

• Subversionでは、中央に1つのリポジトリがあって、それを各人がチェックアウトしてワーキングコピーを作り、ワーキングコピーに対して行った変更をリポジトリにコミットする、という形で「バージョンの管理」と「成果の共有」を実現する。
• Gitでは、リポジトリのコピーを誰でも簡単に手元に作る事ができて（Gitではこれをcloneと言う）、Subversionでワーキングコピーからリポジトリに変更点をコミットするのと同じように、Gitではリポジトリとリポジトリの間で変更点をコミットできる（Gitではこれをpushとかpullとか言う）。
  • どれか1つのリポジトリを「中央のリポジトリ」として運用すれば、Subversionでのバージョン管理と同じような運用もできる。
  • 手元にできるのは「履歴の情報を持たないワーキングコピー」ではなく「元のリポジトリを複製したリポジトリそのもの」なので、インターネットに繋がってない状態でもローカルのリポジトリに対してコミットできる。
  • Subversionではtrunkと呼ばれていた物は、Gitではmasterと呼ばれる。
• git-svnは、以下のような事をする。
  • Subversionのリポジトリのコミット履歴を全部辿る。
  • ローカルに新しいGitリポジトリを作って、Subversionのコミット履歴に対応するコミットを順番にそのGitリポジトリにコミットする。
  • なので、git-svnでGitリポジトリ化したSubversionリポジトリは、元のリポジトリの変更履歴を完全に引き継いだ物になる。

やってみる

ツリー型タブのSubversionリポジトリをgithub上の同名のリポジトリに移行する手順を振り返ってみる。

1. Subversionのリポジトリをgit-svnでGitリポジトリに変換する。

   $ git svn clone --prefix svn/ -s https://www.cozmixng.org/repos/piro/treestyletab

   これでローカルにtreestyletabという名前のディレクトリができて、これがGitリポジトリになってる。コミットを1件1件取り込むので、コミット数が多いとメチャメチャ時間がかかるけど、黙って待つ。たまに失敗するので、そういう時はできたゴミディレクトリを消してもう一度やり直す。
2. githubに「treestyletab」という名前でリポジトリを作る。（分かりやすくするためにSubversionの物と同じ名前にするといい。リポジトリ名は後でgithub上で好きなように変更できるので。）これで、読み書き両用のURLとして「git@github.com:piroor/treestyletab.git」みたいなのが使えるようになる。
3. ローカルにできたtreestyletabのGitリポジトリの「元」として、githubのリポジトリを登録する。

   $ git remote add origin git@github.com:piroor/treestyletab.git

   これによって、「このリポジトリはgithubのリポジトリをcloneした物ですよ」「このリポジトリに行われた変更を元のリポジトリにpushする時は、githubにpushしますよ」ということになる。
4. pushする。

   $ git push origin master

   これで、Subversionのリポジトリから持ってきたコミット履歴が全部github上のリポジトリに反映される。
5. Subversionのtagsの内容をGitのtagに変換する。Subversionでtags以下に作ったタグはブランチとして取り込まれているので、これをGitのタグにしてやる。

   $ git branch -r

   これでブランチの一覧を見れるので、

   $ git checkout svn/tags/0.10.2010102501

   という風にしてブランチを切り替えて

   $ git tag 0.10.2010102501

   でタグを打って

   $ git push --tags origin

   でタグの情報をgithubのリポジトリにpushする。タグの数だけこの操作を繰り返す。
6. Subversionのbranchesにブランチがある場合、Gitのbranchに変換する。Gitだとローカルにあるブランチをgit push origin ローカルリポジトリのブランチ名:リモートリポジトリのブランチ名でリモートリポジトリにpushできるんだけど、git−svnでcloneしたローカルリポジトリにあるブランチはそのままだとpushできない（不可視のブランチになってる？）ようなので、

   $ git checkout svn/my-branch

   でブランチを切り替えて

   $ git branch my-branch

   で普通のブランチとして切り直して

   $ git push origin my-branch:my-branch

   でgithubにpushする。

自分はアドオンの数自体20個以上あるし、それぞれアホみたいに何度もリリースしててタグの数がハンパないことになってるので、全部手動でやることを考えたら気が遠くなりました。なのでこういうスクリプトをRubyで書いてみました。

#!/usr/bin/ruby

SVN_REPOSITORY_PATH = "https://www.cozmixng.org/repos/piro/<%= src_project_name %>"
GIT_REPOSITORY_PATH = "git@github.com:piroor/<%= dest_project_name %>.git"

$LOAD_PATH.unshift(File.dirname(__FILE__))

require "fileutils"
require "erb"
require "shellwords"

def main
  ARGV.each do |arg|
    p "process #{arg}"
    args = arg.split(":")
    src_project_name = args[0]
    dest_project_name = args.size > 1 ? args[1] : args[0]
    svn_to_git(src_project_name, dest_project_name)
  end
end

def svn_to_git(src_project_name, dest_project_name)
  p "svn:#{src_project_name}, git:#{dest_project_name}"
  clone(src_project_name)
  push(src_project_name, dest_project_name)
  push_branches_and_tags(src_project_name)
rescue Exception
  p $!
end

def clone(src_project_name)
  result = run("git", "svn", "clone",
               "--prefix", "svn/",
               "-s", ERB.new(SVN_REPOSITORY_PATH).result(binding).chomp)
    p result.to_s
  raise Exception.new("clone of #{src_project_name}, #{result.to_s}") unless result.to_s.include?("Checked out HEAD:")
end

def push(src_project_name, dest_project_name)
  FileUtils.cd(src_project_name) do
    result = run("git", "remote", "add",
                 "origin", ERB.new(GIT_REPOSITORY_PATH).result(binding).chomp)
    p result.to_s
    result = run("git", "push", "origin", "master")
    p result.to_s
    raise Exception.new("push of #{src_project_name}, #{result.to_s}") unless result.to_s.include?("master -> master")
  end
end

def push_branches_and_tags(src_project_name)
  FileUtils.cd(src_project_name) do
    branches = run("git", "branch", "-r")
    branches = branches.to_s.split("\n")
    branches.each do |branch|
      next unless branch.include?("svn/")
      branch.strip!

      name = branch.split("svn/")[1]
      next if name == "trunk"

      if name.include?("tags/")
        tag = branch.split("tags/")[1]
        p run("git", "checkout", branch)
        p run("git", "tag", tag)
        p run("git", "push", "--tags", "origin")
      else
        p run("git", "checkout", branch)
        p run("git", "branch", name)
        p run("git", "push", "origin", "#{name}:#{name}")
      end
    end
  end
end

def run(*args)
  command_line = Shellwords.shelljoin(args)
  result = `#{command_line} 2>&1`
  result
end

main

ファイル名は svn-to-git.rb として、

$ ./svn-to-git.rb treestyletab

とやると、ここまでの手順のうちgithubのサイト上でリポジトリを作る所以外を全部自動でやってくれるという物です（ということは、スクリプトの実行前にあらかじめgithubのサイト上でリポジトリを作っておかないといけない）。これでなんとか全部のリポジトリをgithubに持ってくることができました。XUL/Migemoの辞書をSQLiteにしてみようとかそういうブランチを切ってた物が取り込めてなかったり、svn:externalsで参照してた物が入ってなかったり、Subversionに突っ込んでから1回もコミットしてないプロジェクトをまだgithubに持ってきてなかったり（必要あるの？　無いよね？）という課題は残っていますが。→ブランチの取り込み方が分かったので追記しました。→svn:externalsの移行は諦めてsubmoduleにすることにしました。TortoiseGitでメニューから「Submodule Add」を選んでリポジトリにgit@github.com:piroor/makexpi.gitを、パスにbuildscriptを指定する、という手順でだいたい同じような結果になるみたい。更新の時はTortoiseGitだと「Git Sync」から「Submodule Sync」しないといけないようだ。コマンドラインなら一発で更新できるようなんだけど……

今後はgit-svn駆け込み寺あたりを熟読して頑張っていきたいと思っております。あと、今後具体的にコードを提供してくれるような人がもしいれば、githubの方にpull requestっていうんですか？するようにしてもらえたら幸いです。

……というまとめエントリを書こうとしてもうちょっと調べ直してたら、git-svnでタグが自動で取り込まれないとかの問題を解消するラッパーのsvn2gitという物があるということを今更知りました。ギャフン！！！！！

……さらに後から気がついたけど、HTTPでアクセスできる公開のSubversionリポジトリをgithubに移行するだけならtagやbranchの変換も含めてgithubのWebインターフェース上の機能だけでサクッとできてしまうことが分かりました。ギャフンギャフン！！！！！！！！！　手順は以下の通りです。

1. githubで新しいリポジトリを作る。
2. 空のリポジトリができたら、最初に表示されてる説明の下の方にある「Subversionのリポジトリを取り込みたい?　ここをクリック」というリンク（日本語のUIにしてる場合。英語でも多分似たような文言があると思う。）を辿る。
3. インポート元のSubversionリポジトリのURLを入力する。
5. githubのユーザ名（ 「piroor <piro.outsider.reflex@gmail.com>」のような、githubのユーザ名と登録済みのメールアドレスの組み合わせ）を作者として入力する。
6. しばらく待つ。

最初githubのUIを英語で使ってたのと、下までスクロールしてなかったから気がついてなかった。なんということでしょう。丸1日以上を無駄にしてしまいました。

さくらのレンタルサーバ スタンダードプランでrep2 - Jun 08, 2010

いくつか前例はあるようだ。

• rep2のインストール - 雑記
• さくらインターネットのレン鯖に2ch Viewer rep2を導入 - HUBLOG

僕の契約はスタンダードプランなんだけど、複数ユーザでFreeBSD 7のサーバを共用してる状態で、管理者権限は無い。クライアントはUbuntu 10.04。という前提で。

sshの準備

何はともあれ、まずはリモート操作のための準備を整える。

ssh ユーザ名@ドメイン名

これでsshでログインできるんだけど、いちいちパスワードを訊かれてしまう。なのでsshの公開鍵を置いておくことにした。

1. 1回、上記の要領でSSHでログインする。
2. mkdir .ssh
3. chmod 700 .ssh
4. vi .ssh/authorized_keys
5. ローカルにある公開鍵（~/.ssh/id_rsa.pubなど）の内容を貼り付けて、ファイルを保存する。
6. chmod 600 .ssh/authorized_keys
7. exit

再度上記の要領でsshでログインを試みると、今度はパスワードを訊かれなくなる。scpも。

rep2設置

1. p2拡張機能パックの「依存ライブラリ込み」のファイル一式をダウンロードする。今回は rep2ex-100227-0215.7z を使った。
2. ファイルを展開する。
3. cd rep2ex-100227-0215-with-deps
4. tar zcvf rep2.tar.gz rep2 で再圧縮する。
5. scp ~/rep2.tar.gz ユーザ名@ドメイン名:~/ でサーバに送る。
6. ssh ユーザ名@ドメイン名:~/ でサーバに入る。
7. mkdir ~/p2data でWebから見えない位置にデータディレクトリを用意する。
8. tar zxvf rep2.tar.gz で展開する。
9. mv rep2 www/ でWebから見える位置に移動。
10. パーミッションを設定する。
    1. chmod 705 www/rep2
    2. cd www/rep2
    3. find . -name "*.php" -type f -print | xargs chmod 705
11. vi conf/conf_admin.inc.php で初期設定を変更する。
    • $_conf['data_dir']などで指定しているデータディレクトリの位置を、先程作ったデータディレクトリへのパスに書き換える。 ~/p2data/ にデータディレクトリがあってrep2のindex.phpが ~/www/rep2/index.php にあるという位置関係なら、値は "../../p2data/" になる。
    • どこからでもアクセスを受け付けるようにするなら、 $_conf['secure']['auth_host'] の値を 0 にする。
12. http://ドメイン名/rep2/index.php にアクセスしてみる。

上記の参考エントリではこれだけでいけるという風に書いてあるんだけど、僕の場合はPHPのエラーで動かなかった。magic_quotes_gpcをOffにしろとかなんとか。

さくらのレンタルサーバのサーバコントロールパネルを見てみると「PHP設定の編集」というのがあったので、ここを見てみたところ、デフォルトの設定に対して必要な設定項目だけ上書き指定できるようだったので、magic_quotes_gpc = Off と記入して保存した。その後再度rep2のページにアクセスしてみた所、今度はちゃんとユーザ登録用のフォームが表示された。

ローカルのrep2のログを引き継ぐ

実はローカルで今までrep2を動かしてたので、そのログや「お気にスレ」などのデータを引き継ぎたかった。ローカルのデータは ~/public_html/rep2/data/ に置いてた、という前提で。

1. exit （sshでサーバに入ったままなのであれば）
2. cd ~/public_html/rep2
3. tar zcvf data.tar.gz data で圧縮する。
4. scp ~/data.tar.gz ユーザ名@ドメイン名:~/ でサーバに送る。
5. ssh ユーザ名@ドメイン名:~/ でサーバに入る。
6. tar zxvf data.tar.gz で展開する。
7. rm -r p2data
8. mv data p2data
9. rm p2data/p2_auth_user.php で古い認証ユーザの設定を削除する。
10. http://ドメイン名/rep2/index.php にアクセスしてみる。

今まで見てたスレの過去ログが見えるようになっていれば成功。

余談

今回の事で、さくらのレンタルサーバにsshで入る方法を習得した。もう少し色々試したら、定期的にサーバにある内容をまとめて圧縮してバックアップということもできるようになれるかな。なれるといいな。

TwitterIrcGatewayからRTできるように - Jan 04, 2010

半年くらい前に真琴さんの記事を見てTwitterIrcGatewayを導入したけど全然使いこなせてなかったけど他の人が他の人に教えてもらってるのを横で盗み見て設定したらちょっと使いこなせるようになった気がしたよ。

• TypableMapを有効化すると「re *** ほげほげ」で直前以外のポストにReplyできるようになる。
• ReTweetコマンドを追加するの手順に従ってスクリプトを設置＆編集すると「rt *** ほげほげ」でRTできるようになる。

酷く今更です。

NSISで"string".split(" ").forEach(...) みたいなことをやりたい（文字列を分割してそれぞれの要素に対し処理を実行） - Aug 31, 2009

INIファイルから文字列を読み込んで、それを空白（カンマ、コロン、パイプ、など何でもいいけどとにかく区切り文字）で区切ってループ回す、ということをNSISでやろうと思ったらどうやるのがスマートなんだろうか。

とりあえず見よう見まねと試行錯誤でこんな感じに書いたら一応期待通りに動いた。

!include "LogicLib.nsh"
!include "WordFunc.nsh"
!insertmacro WordFind

（中略）

Var STRING
Var PART
Var INDEX

（中略）

StrCpy $STRING "aaa bbb ccc ddd"
StrCpy $INDEX "0"

${While} 1 == 1
  IntOp $INDEX $INDEX + 1
  ${WordFind} $STRING " " "+$INDEX" $PART
  ${If} $INDEX > 1
    ${IfThen} $PART == $STRING ${|} ${Break} ${|}
  ${EndIf}
  Call MyFunction
${EndWhile}

${WordFind}の第1引数が元の文字列、第2引数が区切り文字で、第3引数に「その文字で区切った後の配列の何番目の要素か（添え字は1から始まる）」を指定すると、第4引数の変数に要素の内容に相当する文字列が格納される。0番目あるいは配列の長さ（に相当するもの）よりも大きな数字を第3引数に渡すと、返り値は元の文字列そのままとなるので、これを脱出条件としてループさせてみた。

9月2日追記。配列（のようなもの）の長さが1つの時のことを考慮してなかったので修正した。

SAIで別のマシンで使ってたパレットを引き継ぐ - Jun 20, 2009

新PCにしてから一度もSAIを起動してなかったというかインストールすらしてなかったので、インストールした上で旧PCから救出した設定ファイルっぽいファイルを上書きして起動してみたところ、カラーパレットの中身がカラッポになってしまった。

他の部分はせいぜいペン先の太さ程度しかカスタマイズしてなかったのでまあ諦めてもいいんだけど、カラーパレットは……「これだ！」と思ったふぉくす子＆さんだば子の色を控えてあったので、なくなるのはとても痛い。なのでどうにかしてインポートできないか試行錯誤してみた。

• SSTというツールを使えばSAIのカラーパレットをファイルとしてエクスポートしたり逆にインポートしたりすることができるらしいんだけど、現行最新版のSAI 1.1には対応してないらしい。
  • そもそも、これを使おうと思ったら旧バージョンのSAIが正常に機能しており且つカラーパレットの中身が見えている環境が必要。それは僕の場合はつまり、HDDがイカレ気味な上に使えるビデオカードがないせいで死亡状態で放置しているWindows 2000マシンをどうにかして動く状態にしなきゃいけないってことだ。それは無理。
• カラーパレットの内容等はsai.ssdというファイルに保存されているそうなので、解析してみるか？と思ったけど、中身はバイナリでとても手に負えそうになかったので諦めた。

だいぶ諦めモードになったところで、「Windowsのユーザ名が同じだったら、別のマシンで使ってたsai.ssdを引き継げる」という情報に辿り着いた。実は以前のWindows 2000では主に「SHIMODA Hiroshi」というスペース混じりの長いアカウント名で使ってて、そういうアカウント名を考慮してないツールで時々苦労してたので、Vistaの新マシンではメインのアカウント名は「piro」にしていた。なので、SHIMODA Hiroshiという名前のアカウントを作ってそっちで旧環境から吸い出したSAIのインストールフォルダのsai.exeを起動してみたところ、ツール類の配置は初期化されてたけどパレットの中身は引き継がれた状態で起動できた。

この状態のスクリーンショットを撮って「ペイント」で保存し、ユーザを切り替えて今のメイン環境の方でSAIを起動し直して、スポイトでちまちま色を拾い直すことで、パレットをどうにか引き継げた。 画像の左側がスクリーンショットで、右側が今の環境のSAIのパレット。スクラッチパッドの中身は引き継ぎようがなかったので、ここの色もパレットに拾っておくことにした。

UIに関して言えば、SAIのオレオレ設計は絵を描く時にはストレスなく使えていいんだけど、こういう設定まわりとかはオレオレ設計になってると非常に困る。Illust Studioに乗り換えてしまおうかとちょっと本気で思ったよ。

Illustrator CS4でアートボードの大きさでPNG出力する手順 - Jun 11, 2009

世間的にすごい今更だと思うけど、今日やろうとして詰まったのでメモしておく。

Illustrator CS2を使ってた時は、以下のような感じだった。

• 何も考えずにPNG出力しようとすると、アートボード（用紙サイズ）より外側にあるオブジェクトまで含めたドキュメント全体をPNG出力してしまう。
• 何も選択してない状態で「オブジェクト」→「クリエイト」→「トリムマーク」とすると、アートボードのサイズのトリムマークが表示される。この状態でPNG出力すると、アートボードの範囲の内容だけがPNG出力される（それ以外の部分はトリミングされる）。

しかしIllustrator CS4では、「オブジェクト」メニューに「クリエイト」が無い。

• 代替の機能は「効果」の方の「トリムマーク」らしいんだけど、何も選択してない状態でこれを実行しても何も起こらない。
• 何かオブジェクトを作ってそれにこの機能でトリムマークを付けてみても、PNG出力の時の結果は変わらない（アートボードの外側まで出力されてしまう）。

実は、IllustratorはCS4から複数のアートボードをサポートするようになって、印刷や出力の基本単位はアートボードごとということになっているらしい。なので以下のようにすれば、CS2の時の結果と同様、アートボードの大きさでトリミングされたPNG画像を得ることができる。

• 「書き出し」を選択して、表示されるファイルおよび出力フォーマット選択のダイアログが表示されたら、まずファイル形式としてPNGを選択する。
• 次に、ダイアログの左下にある「各アートボードごと」にチェックを入れる。（ダイアログを開いた直後に選択されている形式では、このチェックボックスがグレイアウトしている）
• ファイル名を入力して「保存」をクリックすると、アートボードの大きさにトリミングされたプレビューが表示される。そのまま確定すれば、プレビューの通りにトリミングされたPNG画像を得られる。

ということでこの件については解決された。しかし「アートボードとぴったり同じ大きさの矩形オブジェクト」を作るのが面倒になったのはやっぱり頂けない（CS2だと、トリムマークを作ってそのまま解除すれば、アートボードと同じ大きさの矩形オブジェクトを得ることができた）。

Google Chrome 2.0の拡張機能 - May 14, 2009

前に@google.comなアドレスからメールが来たと書いたけど、その続き。またメールが来た。「前に約束したとおり、Chromeの拡張機能のフレームワークの開発方法について情報をアップデートしたよ！」とな。

• Chrome Extension HOWTO ‎(Chromium Developer Documentation)‎
• Sample Extensions ‎(Chromium Developer Documentation)‎

ということで内容が増えてた。

僕が気になったのはToolstripsという項目。どうやら、GreasemonkeyのようなことだけでなくUIの方にも手を加えられるようにしようという話の1つの結論がこういうことのようだ。サンプルとして置いてある物のスクリーンショットにあるウィンドウ下部のボタンがそれっぽい。

HTMLでボタンを定義しておくと、ステータスバーの領域にそれが表示されるようになるようだ。既存のUI部品の大改造はできないけど、新しいボタンを追加するという事に関してはこれでできるし、ひょっとしたら使い方次第でもっといろんな事ができるのかも知れない（触らないうちから妄想で書いてます）。

Gimp嫌われすぎワロタ - Dec 21, 2008

そういえばAza Raskinさんとも「GimpのUIはひどい！」で合意してしまいました。

Twitter / TAKESAKO: ちなみに「GIMPがあるからPhotoshopいらないじゃん」とか言ってる自称オープンソースプログラマー（の最適化能力とUIデザインセンス）は信用しないようにしている。

確かに本気で言ってる人がいるとしたらそうだなあと思う。

ただ、人に「こういうことがしたいんだけど」とか言われた時には、ついGimpの方を勧めてしまうなあ。そういう人達に対してPhotoshopは明らかにオーバースペックなのに、Photoshopのように「なんでもできる」事を望んでいて、それでいて出費はしたくない、そんなケース。そういう人って多分、細かい使い勝手とか作業効率とか気にならないと思う。だから問題にならない。あくまで「機能」しか大事じゃないから。それでGimpの解説本を1冊買って渡す。あとはシラネ。みたいな。

個人的にGimpが使い物になるのは、全ての作業をGimp上で完結させる場合か、SAI等で編集中の画像の一部のレイヤだけを切り出して加工して結果をSAIにもう一度取り込む、という場合かなあ。自分としては補助的な使い方をする分には我慢できるけど、メインで使うのはストレスフルすぎて辛い。慣れの問題？　いえいえ、フィーリングの問題です。

InkscapeとIllustratorでも同じ事が言えるかも。部分的にはInkscapeの方が高機能なんだけど、仕事で使うのはちょっと……というかなんというか。以前SAIの解説本にコラム書く時に、普段イラレでやってるようなことをInkscapeだけで再現してみたけど、半透明やドロップシャドウを使いまくってると、重くて重くてとても辛かった。という性能的な問題もあったけど、それ以上に、ツール類を出してるとボタン類がやたらでかくて、気持ちよく作業できなかった。これもまたフィーリングの問題。