Home > Latest topics

Latest topics 近況報告

たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。

萌えるふぉくす子さんだば子本制作プロジェクトの動向はもえじら組ブログで。

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

宣伝2。Firefox Hacks Rebooted発売中。本書の1/3を使って、再起動不要なアドオンの作り方のテクニックや非同期処理の効率のいい書き方などを解説しています。既刊のFirefox 3 Hacks拡張機能開発チュートリアルと併せてどうぞ。

Firefox Hacks Rebooted ―Mozillaテクノロジ徹底活用テクニック
浅井 智也 池田 譲治 小山田 昌史 五味渕 大賀 下田 洋志 寺田 真 松澤 太郎
オライリージャパン

Page 12/240: « 8 9 10 11 12 13 14 15 16 »

ITpro「記者の眼」の「シス管系女子」の紹介記事がきっかけで反省した話 - Sep 28, 2013

現在発売中の日経Linux 2013年10月号にまとめ本が付録で付いてきているマンガ「#!シス管系女子」ですが、担当さんが紹介記事を書いて下さいました。

記者の眼 - マンガで日本のITを救う:ITpro

内容を抜粋しての紹介と併せて、担当さんの視点からの裏話も掲載されています。読んでいて、立ち上げ期の事を色々思い出してしまいました。

で、その勢いで前回のまとめ本と今回のまとめ本を自分で一気読みしてみたのですが……いやー、これ、文字多過ぎ。夜に読んだら寝るわマジで……。前回のまとめ本の時にそれを痛感して、「#!シス管系女子」になってからはなるべく詰め込みすぎにならないようにと意識していたつもりだったんですが、まだまだでしたね。でもこれ以上セリフを減らすと解説が成り立たなくなりそうだし、悩むところです。

っていうか、上記の記事で抜粋されているような「いまいち分かりにくいものをビジュアル化して分かりやすく解説」というのも、そもそもは、「そういう文字ばっかりの説明をやってもしょうがないじゃないか! 漫画という表現形態ならもっと絵で説明しなきゃ勿体ない!」と思っての事だったのでした。しかし、無印時代は具体的なコマンドや仕組みの説明が多かったのでまだやりやすかったんですが、シェルスクリプト編に入ってからは抽象的な概念を扱う事が増えてきたということもあって、最近はうまくビジュアル化できてないまま送り出してしまっているなあ……と改めて反省しております。

「#!シス管系女子」の宣伝ということで上記記事を書いて下さったのですが、自分を省みるいい機会になりました。初心に返って頑張らねば……!

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

English version of this entry is available.

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

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

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

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

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

ですが、自分の認識としては、このパッチで示されている方向での対応というのは言わば、「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ではPromiseTaskといった仕組みが導入されており、本来であれば、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で公開しているコードなのでそのせいでパッチが提供されないのだという推測も成り立ちますから、鶏と卵だと思っています)、どうせいつか自分でメンテナンスを再開することになるのだろうという諦観から、気分の問題としてコピーレフトの選択をする場合がある、という話です。

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

Page 12/240: « 8 9 10 11 12 13 14 15 16 »

Powered by blosxom 2.0 + starter kit
Home

カテゴリ一覧

過去の記事

1999.2~2005.8

最近のつぶやき

オススメ

Mozilla Firefox ブラウザ無料ダウンロード