«前の日(06-12) 最新 次の日(06-14)» 追記

Matzにっき


2003年06月13日 13日の金曜日

_ [OSS]ライセンスの適用

6月11日の記述に対するnaruseさんの意見は興味深いと思います*1

乱暴に要約すると

ということだと思います。

前にも書きましたが、やっぱり独自ライセンスはお勧めしませんです。

結局は自分のエゴとユーザの利便性のどちらをとるかということなのだと思います。 もちろん開発者は自分が開発したソフトウェアに対していかような決定も行うことができます。 そして、開発者にはユーザに守ってもらいたいいろいろなことがあるのだと思います。

たとえば、

  • 自分で使う分については著作権表示を削ってもかまわない、 けれど、改変したものについては著作権表示を残さないとダメ、
  • ソフトウェアを改変していて原型が無くなったら著作権表示を削ってよい*2

気持ちは分かります。

10年前の私も自分の「願い」を表現したライセンスを作ったことがあります。しかし、私は問題ないと思えたこのライセンスは実はGPLコンパチではないのです。以前Stallmanから直接指摘されました。

GPLコンパチでないということは、上記のライセンス(GPLでない部分)だけを適用したソフトウェアは

  • FSF的にはフリーソフトウェアでない
  • GPLソフトウェアと合法的にリンクできない

ことを意味します。自分ではよかれと思ったことなのにこんな面倒なことになるとは。 しかもどこをどう直せば自分の「願い」を実現しつつGPLコンパチにできるのか、 そもそもそんなことが可能なのかさえさっぱりわからないのです。 こうなると私の願いはそんなに重要なものだったのだろうかという気になります。 実はどうでもいいことだったんじゃないかと。

簡単に言うと「他のライセンスと組み合わせても問題のないライセンスを作ることはとても難しい」ということです。 そして、オープンソースソフトウェア(フリーソフトウェアでもよいけど)はその性質上さまざまなソフトウェアと組み合わせられることがとても多いのです。

「オープンソース」の示唆するものの中には

開発者のエゴを抑えると開発者自身を含めてみんながハッピーになれる

ということもあるんじゃないかって気がします。

独自ライセンスで実現したい「開発者のエゴ」は妥協できないものなのでしょうか。 よくよく考えてみると独自ライセンスのデメリットほどは重大ではないのではないでしょうか。

個々のソフトウェアがそれぞれ違うライセンス条項で配布され、 なにができてなにができないのか個別に(場合によっては専門家に相談して)検討する必要がある 面倒な事態を拡大するよりは 広く知られているライセンスを利用した方が賢明ではないかと最近では考えています。

「できればやってほしい」ようなものはライセンスに取り込まず、 READMEなので「お願い」するって手があります。ライセンスは万能の武器ではないのです。 なにもかもライセンスで実現する必要はありません。

ライセンスの適用に関してはソースコード自身か添付文章で「このライセンスに従う」と宣言するだけで構わないと思います。ライセンスを発行する主体と著作権者はライセンス文書そのものか添付文書に記述することになると思います。 ソフトウェアの作成日はライセンスには必須ではありません。

それから、OSIにあるBSDライセンスには元々宣伝条項が含まれていません。修正は不要です。 テンプレートに従い名前と年を埋めるだけで完成です。

*1  なんだか「お便りコーナー」みたいになってきましたね

*2  本当に「原型が無くなったら」ライセンスもなにもなく元の著作権表示は要らないと思うけど

_ [Ruby]知られざるRuby

先日うちが取っている新聞(地方紙です)で、松江の古書店がネット販売を開始し、 地方の書店で死蔵されたり捨てられたりする運命の古書をまた「生かして」やれるのが嬉しい、 というような記事を読みました。

古書店がインターネットというのは全国的には全然珍しいことではないのですが、 こんな田舎でもそうなんだねえと少々感心して読んでいました。

しかし、後で分かったことには、その古書店の主人はうちの会社の後輩のお祖父さんで、 管理システムの一部は彼が構築したLinuxサーバ上のRubyで動作しているそうです。

世間は狭いというかなんというか。

_ 救急車

うちの近所には毎日のように救急車が来ます。

今日、歩いて温泉に行ったら今日も救急車が来て、温泉旅館に入っていきました。 うーむ。

温泉旅館といえば、お風呂とお酒が付き物だからなあ。 酔っぱらってお風呂に入るのは危険です。気をつけましょう。


2004年06月13日

_

妻が新しいワンピースを着ていた。ロングスカートのすそにダイヤ形の切り込みが入っていて、 そこからふくらはぎの下あたりが見える。

かなり長めのスカートなので、別に見えてもどうということはない。 もっと短いスカートはいくらでもある。

にもかかわらず、穴からのぞく足をみるとなんだかドキッとしてしまうのだ。 オトコってのはこれだから、もう。

_ 結婚式

午前中は教会で聖餐会に出席。午後は会社の後輩の披露宴に。 彼らは午前中のうちに(出雲大社よりも由緒正しいといううわさの)熊野神社で神前式をあげたらしい。

私はあんまり普通の結婚式に出たことないんで(前回は前田くんのか)、 なんだかものめずらしい。

  • 最近の若い人のフォーマルドレスってアメリカのドラマに出てくるのみたい。
  • 新婦はお色直しでほとんど席に居ない。ま、本人が納得してたらそれでいいのか。
  • 披露宴でカラオケって定番なのかな。
  • (また)食べ過ぎた。自制心ない。
  • 高専2年からの付き合いとは。ほのぼのした話だ。

で、来週は1週間休みで、新婚旅行だそうだ。 しかし、「東京で、ディズニーランドとショッピング」ってのは、 完全に奥さんの意向に沿ってるなあ。尻に敷かれてそう。

それはそれで幸せなのかも*1

*1  私は幸せです(笑)


2005年06月13日

_ [OSS] 「オープンソースの法的なトラブルを未然に防ぐ」−米SFLCのMoglen所長

FSFの法律顧問にして、コロンビア大学教授であり、 SFLCの所長でもあるEben Moglenが来日した、という話題。

一番興味深く、私にとって重要なのはここ。

SFLCの直近の重要なタスクとしては,FSFと共同で進めるGPL(GNU General Public License)v.3.0の策定がある。GPLは,Linuxなどが採用しているオープンソースのメジャーなライセンス。現行バージョンのv.2がリリースされたのは1991年で,14年もの間,改定されていない。「当時とは社会的にも技術的にも状況が大きく変わり,見直すべき時期に来た」と Moglen所長は語る。ただ,「今までのGPLの成功をベースにし,混乱をまねくような変更はしない」(Moglen所長)。使用される地域の拡大を背景として「国際性を反映しているか」,携帯電話からスーパーコンピュータまで広い分野で使われるようになったことを背景として「すべての分野をカバーしているか」といった点を確認することになるという。数カ月後をメドに,透明性を確保した策定プロセスをFSFと共同で発表。2006年いっぱいかけて広くディスカッションを行い,2007年始めにGPL v.3.0をリリースする計画である。

GPL 3.0の登場は2007年とな。楽しみに待つことにしよう。

_ [特許] 米下院で新法案--破綻した米国の特許システムの特効薬となるか

先願主義、異義申し立てなど、「まっとうな」特許システムにしようという法案のようだ。 っていうか、アメリカってまだ先発明主義だったのね。 もうとっくに「世界標準」の先願主義になっていると思っていた。

ただ、異義申し立てはともかく、先願主義は(私の感じている)特許問題とは直接関係ないように思える。 むしろ「先に届け出ちゃった方の勝ち」という先願主義の方が、 一度トラブルになった時に「真の発明者」が救済されない危険がある。 もっとも、先発明主義で本当に救済できるかといわれれば、それもまた疑問なのだが。

いずれにしても、アメリカに比べたらまだマシな日本のシステムでも問題がないわけでない以上、 「特効薬」としての効果は期待できないんでないかねえ。 なにもしないよりは良いことだと思うので、反対はしないけど。

_ [特許] ソフト特許、乱用許さず・経産省、来春めどに指針

まだ、これから研究会を作って「特許を保有する企業に対し、誰もが必要と認める基盤技術は安い料金で広く開放するよう求める」というような方針なので、いったいどういう風に転ぶのか予想するのは困難だけど、 少なくともソフトウェア特許に問題があると経済産業省が認めた(ように読める)のは朗報ではないかと。


2006年06月13日

_ 東大講演

朝一番の飛行機で東京へ。帰りは最終便が満席で予約できず、4時の便。

羽田から東大へ移動。浜松町、御徒町、本郷三丁目。

東大の構内で迷う。安田講堂を回り込んだところで、 後ろが弧を描いていることに気がつかず、行きすぎてしまったのだ。 「建物は四角」という思い込みがいかに強いかを痛感する。

引き返して、米澤先生の教室へ。

しばらくは米澤先生と昔話に興じる。 しかし、自分が勉強した教科書の著者の人と親しく話す機会があるというのは 感動ものかもしれない。LispやらSmalltalkやらActorやら、 めずらしい話を含めていろいろと。Alan Kayは最近丸くなったよね、 Turing賞や京都賞など、世間的に評価されたのと関係あるかも、とか。 Alanの印象は、米澤先生がかつてHewittのところの学生だったこととも関係あるかも。

あと、前回のGuy Steeleの講演資料もいただく。 うーん、Fortressかあ。使いやすいのかなあ。 自分自身が想定されるユーザ(科学技術計算関係者)ではないので、 なかなか判断できないな。

で、昼食後、たいそう立派な小柴ホールで講演させていただく。

先週の岡山の話に近いが、こっちはちょっと魔法風味。

スライドはこちら

今度は優しすぎたようだ。聴衆のレベルを甘く見ていたか。

私:「Haskell難しいですから」

「ええっ?」

とか。

全般に、いろいろな人の発言の端々に最高学府の自負が感じられた。 それは良いことだと思う。「普通の人」にリーチするかどうかはともかく。

その自負にあやかるべく、大学生協で東大グッズを買って帰った。 ノートとシャーペン。なんてミーハー、と自分でも思ったが、 家族には思いのほか好評であった。類は友を呼ぶ、というか、似た者家族というか。

あと、スライド中(42ページ目)の「LispからSmalltalk、SmalltalkからRubyまで」の年数に sumimさんからツッコミがあった。

すから LISP 誕生から Smalltalk 誕生までは 14 年から 15 年とするのが順当でしょうね。ぜんぜん関係ないですが、Ruby の誕生日は 1993 年 2 月 24 日だそうですから、LISP からは約 35 年、Smalltalk からは切りのいいところで約 20 年とするのが妥当なようです。なんにせよ、Smalltalk-80 が 1981 年に Byte 誌に発表された時点にはもう、すでに“死んだ言語”だったわけですから(超新星みたいやね…w)、これを起点にする手はありません。

だそうで。言語の誕生をどこに置くかは難しいところではあるが(普通Smalltalkと形容詞なしで読んだ場合Smalltalk-80を指すと思うし)、ま、少なくともあのページの内容は不正確、だということで、ひとつヨロシク。

いや、他のページも与太ばかりだけど。

_ 羽田まで

講演終了後、いろんな人と話す機会があった。 ほんとうはもっともっと話したかったのだが、飛行機の時間に余裕がなかったので 駆け足で話すことになってしまった。申し訳ない。

最後に米澤先生から某大手インターネット企業CTOの人を紹介してもらい、 お話をする。PHPとJava半々くらいでやっていて、 近い将来ラボを開設して先進的なことをやりたいが、そこにRubyも考えている、とか。 また、大手ならではのスケーラビリティーに関する貴重な話も聞かせてもらった。

今回は羽田までタクシーで送ってもらって(豪気な)、その中での話だったのだが、 次の約束をとって、もうちょっと情報交換することにした。

なんか最近風が吹いているよね。

_ [知財] 「補償金もDRMも必要ない」--音楽家 平沢進氏の提言

まったくだ。

こういう話を積み上げて、 客を泥棒扱いする人の声に対抗せねばならん。


2007年06月13日

_ [Ruby] Ruby開発ストーリー

先日の日経BP技術賞受賞にともなう、 開発ストーリーが公開された。

ま、あまり目新しい情報はないけど、 とりあえず今の正直な気持ちも含めて改めてまとめておいた。

_ [Ruby] 思っているよりもずっとずっと人生は短い。: 6年後のStanding ovation

6年前、アメリカでfirst Ruby Conferenceで私が受けたStanding Ovationを 今年は日本でDave Thomasに返すことができてとても良かった、という話。

こういう話を聞くにつれ、Daveのキーノートは本当に感動的だったんだなあ、と思う。 ただ単に「面白い話」では、人の心は動かない。 彼が真摯に愛について語ったからに違いない。

_ So that's what 128 gigabytes of RAM looks like ... - The Something Awful Forums

128ギガバイトのメモリを積んだマシン。 えーと、なんか想像を絶する感じ。

_ [言語] Scott Rosenberg’s Wordyard >> Blog Archive >> Code Reads #10: Guy Steele, “Growing a Language”

Guy Steelの語る「成長する言語」について。

しかし、成長する言語って設計するのがすっごく難しいと思う。 既存の文法や機能が簡単に将来の可能性を狭めてしまうから。

原理的には(Common) Lispのような「なんでもあり」の言語が 一番「成長する言語」でありつづける可能性があるわけだが、 それはそれ、括弧が(別の意味で)障害になったりするわけで。

  • 「普通の人」にも受け入れられる
  • かつ、将来の成長の可能性を疎外しない

ような言語を設計するためには、

  • 保守的な文法 (受け入れられるため)
  • 高い抽象化機能 (高階関数とかオブジェクト指向とか)
  • ライブラリで機能が提供できる枠組み

は必須だと思う。マクロは...悩ましいところだ。


«前の日(06-12) 最新 次の日(06-14)» 追記