Latest topics 近況報告
たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。
以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能！
結婚指輪を常に付けるかどうかとかの話 - Feb 09, 2014
中国嫁日記の、結婚指輪を紛失した話を見て思い出したり思ったりしたこと。
僕自身は、母がずっと結婚指輪を付けている人だった（小さい頃に聞いたら「肉が付いて外れなくなったから」と言ってたんだけど……）から、結婚指輪とはそういうものかと思い込んでいた。
が、自分が実際に店に行ってカタログを眺めてみる段になって、それらは「当たり前」の認識ではないのだという事を知った。
- 派手なデザインの結婚指輪も色々あるらしい。
- あんまり派手だと生活する上で不便じゃないだろうか、と疑問を口にしたら、「常時付けるとも限りませんし」みたいな事を言われた。
率直に言ってカルチャーショックだった。結婚指輪を付け外しするかどうか、なんてそんなに話題に上る話でもなかったから、最初の時点でインストールされた認識以外の考え方があるなんて思いもよらなかった。
とはいえ、なぜそれでカルチャーショックになるのかというのが重要な点だ。目玉焼きには塩でしょ醤油でしょソースでしょみたいな話は、突き詰めれば好みの問題と片付けられるけど、結婚指輪を付けるかどうかというのは僕にとってはもっと重要な意味合いがあった。それは、「結婚指輪を付けていることが、良好な夫婦関係の証明である」という認識だ。
というのも、ドラマやなんかで既婚者が浮気・不倫をする時に、既婚者だとバレないように指輪を外してから行くとか、「自分と一緒にいる今は、結婚の事を忘れて欲しい……」とかなんとか言って相手が既婚者側の指から指輪を抜き取るだとか、そういう描かれ方をしているところを何度か見てきていたから、「結婚指輪って特別なものなんだな」と、知らず知らずのうちに刷り込まれていたのだと思う。どこでそういうのを見たのかを思い出せないくらいには、僕にはすっかりその規範が内面化されてしまっていた。
でも、この事がきっかけとなって、僕は「そうでない価値観があるのだ」と思えるようになった。そう考えるに足るいくつかの気付きがあった。
- 「そもそも結婚指輪を作ってない」とかの極端な例すらあるという事をその後知った。というか父がそうだった（いや、ずっと付けてるものと思い込んでたんで……思い込みって怖いですね）。
- 自分が見てない所で結婚指輪を外していたとしても、どうせ気付けない。
- 結婚指輪をしていたって、浮気する人はする。
- 自分が相手に強制して、相手に嫌々指輪を常時付けさせていたとして、それが良好な夫婦関係の証明であるとは到底言えない。それはむしろDVの証明であろう。
相手が本気になれば僕のことなんかいくらでも欺けるのであって、結婚指輪1つにこだわっても本質的な解決にはならない。それに、欺かれないように監視・束縛を強めることで相手が幸せになるわけでもない（束縛されたがりの人は除くとして）。結局、自分がどれだけ相手のことを信じられるのかにかかっている。相手は絶対に自分の事を欺かないはずだと確信するとか、自分は相手に欺かれたとしても絶対に後悔しないでいようと心に決めるとか、そういう事なんだと思う。
という事に気づいたことで、僕は結婚指輪に対する妄執から解放された。今では、自分がずっと結婚指輪を付けているという事自体についてすらも、客観的にフラットに認識できているのではないかと思う。習慣と「自分がこうしていたいから」と、あと「自慢したいから」、そんな程度の理由で付けている、というのが今の自分の認識です。
もらって嬉しいプルリクエストと、もらって残念な思いをするプルリクエスト - Nov 10, 2013
人格攻撃をしたくて書いてるわけじゃないですよ、という事はまず最初に表明しておきます。
GitHubで公開してるプロジェクトについて、幸いなことに時々プルリクエストをもらえる事があるんだけれども、その時に、何のストレスもなく「Merge」ボタンを押せる時と、そうでない時とがあるなあと思ってた。
その差は何なんだろう？と思ってたんだけど、今回treestyletabのargumentsを使っている箇所を書き換えるプルリクエストをもらって、それに関してやり取りをした事を通じて、「あ、こういう事かな」と思った点が1つあった。
それは、「相手の考えを尊重する態度が見られるかどうか」。
ロケールの翻訳であったり単純なtypoの訂正であったりというパッチではそういうのはまず見えてこないんだけど、今回のように設計のポリシーにまで踏み込んだパッチだと、互いの思惑がずれていることが見えてくる事がある。今回の場合、僕と彼とでは「こうあるべき」と思っているコードの姿がずれているんだなと思った。また、「ああ、僕がこれほど大事に思っていることが、彼にとっては些事に過ぎないと見えているのだなあ」という残念な思いも感じた。
考え方が違うことがすべて悪だとは思わない。JavaScriptの古い仕様であるargumentsから、ES6のRest argumentsへの置き換えを進めるというのは、古い物ばかり見てしまっていて且つ保守的な自分からはそういう発想がまず出てこない（大抵、どうしようもなくなってからようやく重い腰を上げる感じです）ので、自分の目が届いていないところについて「こういうのもあるよ」と教えてもらえるのは、正直、とてもありがたい。
ただ、僕が大事だと思っている事についてバッサリ切り捨てるような態度を取られるのには、いい気がしない。arguments・Rest argumentsで全部の引数を引き渡すように書くべきか、それともすべての引数をきちんと定義しておくべきか、という議論では特にそれを強く感じた。
僕は僕なりの考えを持って、過去に悩まされた色々な事例からの反省であったり、現実的にどこまでメンテナンスに時間をかけられるかという葛藤であったり、どういうコードであれば僕の思う「How」を正しく書き記せるのかであったり、といった事を考えた結果としてああいうコードを書いていたのだけれども、それらの一切合切を無視して「こうあるべき」と別のスタイルを押しつけられることに、僕はどうしても不快感を感じてしまった。コードを自分と同一視していて、自分自身を否定されたかのような感覚すらあったのかもしれない。最初の1回だったら、まあそういう前提が共有されているはずもないので、齟齬があるのはしょうがないと思うんだけど、2度にわたって否定されると、「あ、この人は僕のいろんな思いを尊重しようというつもりが全然ないんだな」と感じて、急速に心が冷たくなっていく、そんな感じがした。
何年もコードを書いてきたんだとか、自分がここまで育ててきたんだとか、そんなクソくっだらない個人的感情に基づいた見栄でもって、真理を歪めてはならない、というのは、その通りだと思う。でも、とても残念なことなんだけど、僕は大義のために自分の命や思い入れをためらいなく差し出せるタイプの人間ではなく、むしろ個人的な感情の方をこそ大事にしてしまうタイプの人間のようなのだ。僕はそういう頭の悪い人間ではないのだ・もっと賢くて理性的な人間なのだと思い込もうとしてたんだけど、実際にはそうではない・そうなれないのだなということを、31歳の今では痛感している。
思い返してみると、僕がかつて「技術系コミュニティ」という物に激しい拒否感を持っていたのは、それが理由だったのかもしれない。唯一絶対の真理として論理的な正さを偏重し、そうでない価値観は無意味と切り捨てる、そういう傲慢さや冷酷さのような物を僕は嫌っていたのだと思う。まあ、そういう自分の想いでもって彼らを・世界を変えたいと思っていたというのも、また同種の傲慢だったのだなという事も今では分かる。我か彼かではなく、どちらの価値観も並行して存在していてよいのだ、そういうカオスを受け入れることが大事なのだ、という事を認識できるようになったのは、それよりずいぶん後になってからのことだ。
ともかく、そういう残念な人間である僕にとって、一緒に作業をしたいと思える相手はやはり、僕の思いをなるべく尊重してくれる人という事になるのだなあ、と思うし、また自分が他の人と一緒に作業する時も、ある一面から見た時だけの正義をいたずらに振り回すことなく、最大限相手の思いを尊重して事にあたっていきたいなあ、と思う、そんなことを改めて考えた出来事だったのでした。
世の中には、ぬるま湯に浸かっていては駄目だ、自分の間違いをビシビシ指摘してくれる厳しい人と一緒にこそいるべきだ、という言説もある。僕はそれは、基本的にはいい事言ってると思うんだけど、でも、そこに相手を尊重する態度があるかどうかってのが、結構重要なんじゃないかと思ってる。
相手を尊重した上で、その思いを遂げるためにはもっとこうした方が良いよ、というアドバイスをしたり、その思いはこれこれこういう前提がおかしいよと新しい視点を示すというのは、僕にはまだ受け入れられるんじゃないかなって思う。でも、そうでなく、お前は間違っているからこうするべきだ、と、僕の思いを歯牙にもかけないでその人の思う正義であったりあるいは誰か第三者が掲げる正解であったりに沿って特定の行動を押しつけられるというのは、ストレスになる。その「厳しい指摘」がどっちであるかというのは、論理的な正しさだけを見ていると分からないと思う。
俗な言い方をすると、それが「愛があるかないか」って事なんじゃないだろうか。「厳しい指摘」をする時に、「指摘する側である自分の自己愛に溢れた指摘（独り善がりな指摘）」ではなく「指摘される相手への愛がある指摘」をする、というのは、なかなか難しいことだと思うけれども、せめてそう心がけたいとは思ってる。
また、逆に言うと、自分に向けられた「厳しい指摘」をすべて受け入れるでもすべて拒否するでもなく、その中で「愛のある指摘」を上手くより分けることができれば、他人の言説にいたずらに振り回されて疲弊することも、世界全部を敵に回しているかのような疎外感を感じることも、ないのかな……とも思う。
結論：愛は地球を救う！
プロジェクト名や製品名等、固有名詞の英語表記の1文字目を大文字にするべきか否か - Oct 17, 2013
英語ネイティブの人に、それが固有名詞であると分かってもらいたいなら、1文字目は大文字にしたほうがよい。ということは言えるようだ。
プロジェクト名や社名や製品名の英語表記について、「テキストデータの中では大文字始まり」「ロゴタイプでは小文字始まり」という使い分けがなされている事例をよく見る。例えばこんなの。
- Ubuntu
- Debian
- Red Hat
- Mozilla
- Node.js
- Twitter（過去に使われていたロゴマークやTweetボタンでは「twitter」に見える書体が使われていた）
振り返ってみると、「固有名詞だがテキストデータ上も小文字始まりである」というケースは、日本人が書いている以外の例を僕は見た事がない気がする（Gemのパッケージ名だとかコマンド名だとかは例外ね）。
例えばミクシィは、ロゴタイプが小文字始まりの「mixi」だが、Webサイト上のテキストデータも小文字始まりの「mixi」で統一されているようだ。mixi自身が提供する英語版コンテンツでも小文字始まり。でも外部の人が編集したと思われる英語版Wikipediaのページでは、大文字始まりで表記されている。
英語ネイティブの人達にとってはどういう感覚なのだろうか？という事を知りたくて英語版Wikipediaで固有名詞の英語におけるキャピタライゼーションについての記述を参照したら、「summer」や「winter」などのごく少数の例外を除いて、固有名詞は大文字始まりで表記するのが原則であるという風なことが書かれていた。
そういえば以前に読んだ記事で、TwitterだかGoogleだかが、サービス名や社名を小文字始まりで書いたり、「ググる」みたいな俗語として「googling」を使ったりということについて、文句を言っているとか、辞書にそういう見出しで掲載するんじゃないと非難しているとか、そういう話を見たことがあったと思う。
英語ネイティブな人が身近にいないから、外してるかもなって思うんだけど、彼らにとっては、「固有名詞は大文字始まりで書くのが原則である、小文字始まりの固有名詞は不自然である」という感覚は、「印象を柔らかくしたいので小文字で表記したい」という欲求よりも優先度・重要度が高い……というか、 後者を優先するという発想が出てこないほどに、前者の感覚が常識として浸透している という事なのかなあ、と、僕は思っている。
もっと言うと、（mixiがそうしているように）日本人が固有名詞を頑なに小文字表記で書きたがるというのは、彼らから見たら、日本語の事を分かっていないDQN親が中二病な発想でキラキラネームを子供に付けてキャッキャ言ってるようなものなんじゃないのかなあ、と、僕には思えてしまう。いや、英語ネイティブの人達がほんとにそう思ってるかどうかは知らないけど、僕はmixiのような事例を見る度に、「うあああニワカが厨二病発症して俺ルール貫いてるよおおお！！ 英語の本家であらせられるところのネイティブの人達に失笑されてるに違いないよおおお！！」と、無意味に恥ずかしく感じてしまう。
と、ここまで書いたところでこのサイトの名前も小文字始まり表記である事に今頃気が付いて、どう見ても完全にブーメランなのでした。
ITpro「記者の眼」の「シス管系女子」の紹介記事がきっかけで反省した話 - Sep 28, 2013
現在発売中の
内容を抜粋しての紹介と併せて、担当さんの視点からの裏話も掲載されています。読んでいて、立ち上げ期の事を色々思い出してしまいました。
で、その勢いで前回のまとめ本と今回のまとめ本を自分で一気読みしてみたのですが……いやー、これ、文字多過ぎ。夜に読んだら寝るわマジで……。前回のまとめ本の時にそれを痛感して、「#!シス管系女子」になってからはなるべく詰め込みすぎにならないようにと意識していたつもりだったんですが、まだまだでしたね。でもこれ以上セリフを減らすと解説が成り立たなくなりそうだし、悩むところです。
っていうか、上記の記事で抜粋されているような「いまいち分かりにくいものをビジュアル化して分かりやすく解説」というのも、そもそもは、「そういう文字ばっかりの説明をやってもしょうがないじゃないか！ 漫画という表現形態ならもっと絵で説明しなきゃ勿体ない！」と思っての事だったのでした。しかし、無印時代は具体的なコマンドや仕組みの説明が多かったのでまだやりやすかったんですが、シェルスクリプト編に入ってからは抽象的な概念を扱う事が増えてきたということもあって、最近はうまくビジュアル化できてないまま送り出してしまっているなあ……と改めて反省しております。
「#!シス管系女子」の宣伝ということで上記記事を書いて下さったのですが、自分を省みるいい機会になりました。初心に返って頑張らねば……！
オフィスの広さとか - Sep 05, 2013
妻の勤務先の会社が、なんやかやでオフィスが広くなったという話を聞きました。
場所を変えずに人を雇っていったら机が増えて椅子も増えてだんだん混雑してきて、最終的には、椅子を引いたら後ろの人に当たるくらいに物理的に窮屈なレベルになってたとかなってなかったとか。横でうるさくされていると気が散って作業に集中できないタイプだと言っていたので、それだけ混んでたらまあ嫌でしょうね……と、話を聞いて思ってたんですけど。それが一気に広くなって、だいぶストレスが軽減されたそうです。
他方、自分が仕事上でお付き合いのあるとある会社のオフィスは、マンションの一室で数人のスタッフがいて作業をしているという環境でした。後ろを通過するためには椅子を引いてもらわないといけない程度……ということは、話に聞いていた妻の職場環境と同じかそれ以上の人口密度なんじゃないかと思います。が、（実際どうなのか正直な所は聞いてみないと分かりませんが）そんなに皆さんストレスフルでイライラしているという印象は受けませんでした。
人には、踏み込まれると不快になる距離、パーソナルスペースというものがあるという話を聞いたことがあります。よく知らない相手だったり、嫌いな相手だったりすると、踏み込まれたら嫌な距離は大きくなり、家族だったらその距離は小さく、恋人同士や新婚カップルや親子だとゼロ距離でも不快に感じない、と。
妻の勤務している会社は数百人規模で、顔も名前も知らない社員がいて当たり前という環境だと聞きました。その一方で、僕がお邪魔したその会社は社員数1桁台で、気心知れた仲間同士でやっているという雰囲気があった気がします。もちろん個々人の性格や考え方による部分もあるとは思いますが、パーソナルスペースが重なり合うような窮屈さでも大丈夫というのは、気の合う仲間とだから成り立つ働き方なのかなあと思ったのでした。
僕はグッデイとクリアコードとMozilla Japanのオフィスしか仕事環境としては体験したことがなかった（打ち合わせやなんかで他の会社にお邪魔しても、見られるのはだいたい会議室まで）ので、世の中にはいろんなオフィスがあるのだなあと思うのですが、僕自身はというと、作業に集中してると周りのことが見えなくなってしまうタイプなので、もしかしたら（クーラーとかがきいてれば）トイレくらいの広さのスペースででも仕事できちゃうのかもしれません……
「コピーレフトとBSDスタイルではBSDスタイルの方が発展するのでは」という議論についての誤解あるいは言葉の裏にある欺瞞 - Feb 03, 2013
元のプロダクトがGPLでも、自分で開発した部分のソースは別のライセンスを指定できるよ、というエントリを書いた後で、言及した事例が自分の想像を超えた残念事例だったという事を認識して、非常に落胆しています。
ここまでのまとめ
先のエントリで言及したProximodo Liteの事例は、まとめると、こういうものでした。
- 元々クローズドソースのProxomitronというソフトウェアがあって、これが大人気だった。
- しかし、作者が死亡してしまい、作者によるメンテナンスが行われなくなってしまった。
- ソースがないから誰も開発を引き継げなくて、完全に死んだ
プロダクトプロジェクトになってしまった。 - しょうがないからProximodoというクローンが新たに開発された。
- 今後同じ事が繰り返されないように（という理由だったのかどうかは分かりませんが、結果として同じ事が繰り返されなくなる効果がある選択として）、Proximodoにはコピーレフトなライセンスが設定された。
- Proximodoの開発は頓挫し、機能的にも性能的にも中途半端な状態で放置されてしまった。
- そこにhide氏が目を付けて、改造版となるProximodo Liteの開発を始めた。このhide氏は、元開発者が様々な理由からプロジェクトの継続を断念したソフトウェアについて、ソース提供を受けてその改良版・後継版を積極的に開発している人物であった。
- Proximodo Liteのバイナリを公開しようとした段階になって、hide氏はProximodoがGPLでライセンスされていることに気がついた。
- hide氏はGPLでProximodo Liteのソースを公開するつもりがなかった（ひょっとすると、いかなるライセンスであろうともソースを公開するつもり自体が無かった）ため、バイナリ公開を断念した。
- それでも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で公開しているコードなのでそのせいでパッチが提供されないのだという推測も成り立ちますから、鶏と卵だと思っています）、どうせいつか自分でメンテナンスを再開することになるのだろうという諦観から、気分の問題としてコピーレフトの選択をする場合がある、という話です。
すべての人がすべての状況で同じ判断をしてくれ、とは思いません。僕ほどには泥をすすることを厭わない人もいるでしょうし、そんな先のことなんか考えたってしょうがないよという人もいると思います。「やり方」からお金を稼ぐのが全然嫌じゃないという人もいるでしょうし、ものすごくユニークな技術を持っていて、そこから莫大なお金を引き出せるから秘匿したいという人もいるでしょう（コカコーラとかペプシコーラとかが、レシピを特許化しないでいるのはそのためだと聞いた記憶があります）。僕だって、そういう状況になったら別の判断をするかもしれません。人それぞれ前提が異なりますから、みんなが自分の前提に合った選択をして欲しいし、惑わしてその意志を曲げさせるような事もあって欲しくない、と僕は思います。
サナギ - Nov 12, 2012
蝶とか蛾とかは幼虫→蛹→成虫と変態するんだけど、蛹の状態というのは一部の器官を除いてあの袋の中で体がドロドロに溶けてて、成虫の形にちょっとずつ作り替えられてるんだそうだ。その間身動きなんか取れるわけがなく、変態が完了するまではほんとに何もできないんだと。自分は高校の理科で生物を選択しなかったからよく知らんかったけど、生物選択だとその辺詳しくやるんだろうか。僕は大人になってからグロ写真見て「うぇえ……」となりました。
プログラム書いてて思うんだけど、僕に好き勝手に作業をやらせると、リポジトリが蛹のようになってしまいがちだ。全体的な見通しが立たないままに作業を始めて、やがていろんなモジュールをぶっ壊してしまう。この時はまるで何にも動かない。そういう状態のままコードをさらに書いていって、次に動くようになった時にはあら不思議！ 元のモジュール構成は影も形もありませんでした！ でも動いてて当初の目的は達成されてる……みたいな。
こーいうのはよくないよなー。ほんとよくない。複数人でやってるプロジェクトでこういうことはしてはいけないと思ってるんだけど。でもやってしまってる。テストドリブンとか何処吹く風や。コミット履歴の中にこういうことになってる部分があると、その周辺はもはや履歴が履歴として役に立たない。
masterでやらずにトピックブランチ切ってやりましょうよって話かもしれないんだけど、それとてmasterが動く状態を保てるということを除けば、特に、履歴がグチャグチャになるとかの点ではあんまり変わらない気がするし。
「ワンライナーで頑張っちゃうとかの変態的なプログラミングは、コードがアンリーダブルになってしまうからやめときましょう」というのは多分一般的な認識だと思うんだけど、「蛹な状態を作ってしまうと上記のような感じで宜しくないので、昆虫的な意味での完全変態的なプログラミングもやめときましょう」なんて事も言えるのかなー、ということを考えていて、誰がうまいこと言えって言ったよと自分で自分に突っ込みつつもドヤ顔でこういうエントリを書いてしまうところが、まだまだ大人になりきれてないと思った次第です。
大学で立ち上げ期に参加したサークルが大発展を遂げていた - Nov 05, 2012
先日、母校の大学祭に合わせてサークルのプチ同窓会が催された。僕も参加したかったんだけど、スケジュールが埋まってて参加できなかったので、大学祭の様子の詳細なレポートを後で見せてもらった。
大学では最初「SF研究会」という部に仮入部したんだけど、ちょっと方向性が違うなあ……と思っていて、そんな時に「新しくサークルを作ろうとしてる人らがいるらしいよ」という噂を聞きつけて、「ぼ、ぼくも仲間に入れてもらえませんかねﾃﾞｭﾌｯ」と参加させてもらった、それが「コミックアート」だった。メディア学科の1年生が中心となって活動を始めたばかりの小規模な非公認サークルだった。
僕の母校のサークル活動にはいくつかのレベルがあって、大学の運営や学生会とは全く関係なく勝手に集まってわいわいやる「非公認サークル」、学生会に認められた「公認サークル」「同好会」、予算や部室なんかもついた「部」という感じで昇格していくシステムだった。人を集めたり活動したりするにはやっぱり予算や部室があった方がいいので、「部」を目指して活動してたんだけど、昇格するためには「これこれこういう理由で意義のある活動なんですよ」「ちゃんと活動実態もありますよ」みたいなことをアピールする必要があった。だからというわけでもないんだけど、会則を決めたり、絵の描き方・漫画の描き方の自主勉強会（教室を借りるのは無料でできた）をやったり、漫画の参考書を梅田のジュンク堂まで探しに行ったり、僕の高校時代の漫研での活動を参考に大学祭で展示発表をしてみたり会誌を製本してみたり（そういうわけで「会誌編集長」という役職をやらせてもらっていたというのが、僕の携帯電話のメールアドレスに「へんしゅうちょう」って入ってる理由なのです。その頃からずっとアドレスを変えてない。）、そうさく畑に参加してみたり、勧誘のために色々チラシを作ってみたり、空いてる時間に集まってダラダラしゃべったり、安い焼肉屋で忘年会をしたり、とにかく前例がないところで自分たちが最初にルールや運用を決めていかないといけないって事で、色々やってた。僕の大学時代はそんな感じで、講義を受けてるかコミックアートの活動をしてるかMozillaの拡張機能を書いてるかで埋まってた（いわゆる合コンというものにも1度も参加しないままだった……）から、ものすごく思い入れがある。
僕が在籍していた当時は結局非公認サークルのままだったんだけど、その後の世代がちゃんと継続して活動してくれてて、今では数十人のメンバーを抱える大所帯となり、同好会になってさらには部にも昇格したのだそうだ。検索したら、大学の公的なサイトにも「41人」って書いてあって、うわーまじかーって思った。（ちなみに、サークル名で検索するとトップに当時の僕らが作って放置かましてしまった化石サイトが出てきたりして、それは別の意味で「うわーまじかー」って感じだ。）また、参加者の中にはプロの漫画家としてデビューした人も2人いるそうで（そのうち1人は、本屋の店頭でコミックスが今まさに平積みされてるのを見たばっかりの人だったので、余計に驚いた）、まあそういう人は元から漫画描きまくってる人だったりするからそこにコミックアートがどれだけ寄与したのかは何とも言えない（それどころか、ひょっとしたら、SF研究会を抜けた時の僕みたいに「ここにいても駄目だ……」って見切りを付けられる側だったりしたのだろうか……本当のところを知るのが怖い）んだけど、とにかく素人集団で始めたものがこうしてちゃんと10年続いたんだ！と思うと、非常に感慨深い。
これからもずっと続いていってほしいものです。
漫画、連載 - Jul 02, 2012
「描かないマンガ家」の3巻で、マンガ家デビューを目指す若手が3話連載のチャンスをもらって、好評なら長期連載ということだったんだけど不評で予定通り3話でおしまいになって、長期連載になるチャンスを逃して涙する、という話があって、見てていたたまれなくなった……
日経Linuxで連載中のシス管系女子も、実は当初はとりあえず3回くらいでっていうことで話をもらってて、3話目の最後に「つづく」って入れていいのか良くないのか（っていうか話的にちゃんときりのいい所で終わらせなきゃなんじゃないのかとか）悩んでたりしたんだけど、なんか特にそこを突っ込まれることもなく4話5話と続いて、今に至ってる。それでもうすぐ1周年ですよ。感慨深い。
でもそれはあくまで技術系の雑誌（専門誌？）の連載「記事」としての評価なのであって、「雑誌の連載漫画作品」というのとはまたちょっと違うのかな－、と思う所もある。画力も話作り（技術解説の部分ではない、エンタテインメントとしての部分）も取り立てて優れているわけではない……というか、むしろ下手な方だと思うし。そこら辺、純粋に画力や話作りで勝負する「漫画業界」に比べるとずいぶんユルく甘やかされてるんだと思う。「描かないマンガ家」「バクマン」等のマンガ家漫画を見てると、こんなんで連載やらせてもらってるのが忍びないです。
という事に引け目を感じるくらいなら、上達することに一生懸命になれよって話ですよね……
自宅のPCから異音がするようになったのが直った - May 09, 2012
なんか先週末くらいから急に、カラカラカラというかシャッシャッシャッシャッというか、回転する物が何か別の物と当たったり擦れたりしてるような音がしだした。
寿命を迎えたPC用の冷却ファンによくある音だよな……と思って蓋開けて見てみて、CPUでもなければ筐体のでもないしということで、グラフィックカードのファンから音がしてるっぽいという事は分かった。
でもなんで急にそんな音がするようになったのか皆目見当も付かなくて、ホントに寿命なのかなーだったら困るなーと思いながら騙し騙し使ってたんだけど、一昨日あたりからカリカリいう音が絶えず出るようになっていかにもこれはヤバイという感じだったので、とりあえず電源落としてた。
今日になって、もしかして油さしたらよくなるかな？と思って潤滑油のスプレー（ノズルの先に細いストローみたいなのをさす奴）をプシュッとやってみたんだけど、部屋が油臭くなっただけで音は全然変わらなかった（擦れてる音がちょっとだけ、潤滑油のおかげか小さくなりはしたけど）。
こうなったらとことんやってやろうじゃないか、ということでまた蓋開けてグラフィックカード外してファンのとこを指でくるくる回してみたら、どうも出っ張ってる部品とかファンの周りのヒートシンク？とかに当たってるみたいで、なんで急にそんな風に当たるようになったんだろ……コンデンサが膨張してぶつかるようになったとかそういう事でもないみたいなんだけどなあ、とかなんとか思いながらヤスリで当たってたとこをゴリゴリ削り始めたところで、回転するファン自体の方に、なんか指で押すとぐにっと隙間ができてそれが広がる感じになってるとこがあるという事に気がついた。
そういう作りのものなのかなーと思ってたんだけど、ふとファンの真ん中の所にカバーみたいに貼ってあったシールをはがしてみたら、そういう作りなんじゃなくて、ヒビが入ってファンの半分が浮いてる状態になってるだけだったという事にやっと気がついた。半分は軸にくっついてて半分は軸からはがれてるという状態だったから、回転数が上がると遠心力で広がって周囲にぶつかったり、重力やら空力やらで歪んで電子部品にぶつかったりしてたみたいだった。ここに辿り着くまで1週間くらいかかってしまった……
割れたところを、軸にまで染み込まないように注意しながら瞬間接着剤を流し込んで補修したら、電源入れても擦れる音はしなくなった。やっぱりこれが原因で間違いなかった。
もうかれこれ5年くらい使ってる気がするけど、環境移行するのがめんどいのでまだまだ頑張ってもらいます。1回電源が逝ったのをわざわざ有償修理で直してもらったくらいだし……（DELLの通販で買ったマシンだから、明らかに新品買った方がコストパフォーマンス的にはいいはずだけど、それよりも同じ環境使える事の方が僕にとっては大事なのです。）