気持ちは分かります。多くの人は英語なんか普段使いませんし。
ライセンスの非公式日本語訳の問題は、自分のソフトウェアのライセンスよりも 既存のソフトウェアのライセンスの解釈に用いる場合ではないかと思います。 誤訳があって他人の権利を間違って侵害してしまった場合に責任が取れないということですよね。
自分のライセンスに誰かが日本語訳したGPLやBSDライセンスをつけることの問題は、 それよりは少ないと思います。たとえば日本語・英語の両方を添付して、 翻訳間で矛盾があった場合には英語が優先とか書いとくと、 もしかして苦労が少ないかもしれませんね。
日本語ネーティブのオープンソースライセンスについては、 誰がコストを負担するかですね。 本当に安心して(？)裁判に耐えられるようなライセンス(というものが本当にありえるとして) を作るためにはきちんと弁護士に相談して契約文書として作る必要があると思いますが、 それには個人では負担したくないくらいのコストがかかるでしょう。 さらにオープンソースライセンスについて不安なく相談できる弁護士が日本に何人いるのか。
やはりその辺をきちんとするコストを負担できる中間層の育成が必要なのでしょうか。
Open Source Group Japanにて日本語訳を集める とうのは面白い考えですね。誰に頼めばいいんだろう。鵜飼さん？
フリーソフトウェアのライセンスは権利者の意志の表明の要素が強いと思います。 そもそも実際に裁判でどのくらい有効かさえよくわからないというのが正直なところではないでしょうか。
となると、
などいろいろなレベルが考えられるわけですが、どうしたもんでしょうね。 起きてもない裁判の不安をあまり強調するのは 一種のFUD効果を持つわけですし。
p.s.
今のBSDライセンスのことを「修正BSDライセンス」と呼ぶのは一般的なんですか。 私は逆に古いのを「宣伝条項付きBSDライセンス」と呼んでました。
日経ITproから。しかし本文を読むと
兵庫県洲本市は2003年7月中旬に、オープンソース・ソフトを使ったシステムの開発支援プロジェクトを開始する。プロジェクト名は「OSCA（Open Source Community in Awaji）プロジェクト」。
ということで、こっちが本当なら「オープンソースソフトを使ったシステムの開発支援」 っていうのは「オープンソース開発支援」という単語から想起するものとはだいぶ違うような気がする。
いや、あらかじめ断っておくと私はこのことを非難するつもりはない*1。 彼らはいわゆる「中間層」になるのだから、私としては拡大はむしろ歓迎する。
あとは、このOSCAなるプロジェクトが、単にオープンソースソフトウェアを利用するだけでなく、 なんらかの形で貢献できるところまで配慮して発展していくことを強く望むものだ。
*1 Stallmanなら「フリーソフトウェアのただ乗り」と批判しそうだけど
ZDnet Japanより。そのうちRubyとかもなにかしたいって話になるのかしら。 そういう話がくれば光栄だけど。
で、注目したのはそういうことではなく、非常に些細なこと。
新しい規格はいいアイデアだとするのは、Pythonスクリプティング言語の作者であるホイド・ファン・ロスュム氏。
え、誰？
あ、「Guido van Rossum」ってのはオランダ語では「ホイド・ファン・ロスュム」と発音するんですか？ 彼は今アメリカにいるし、みんな「グイード・バン・ロッサム」みたいに呼んでたのでそう思いこんでました。
かくのようにカタカナ表記は難しいということで。
家族を連れて少し離れた温泉プールに遊びに行く。
2時間ほどつかっていた(泳いだとは言わない)のだが、結構くたびれた。 やはり運動不足で体力が落ちている。 しかし、少しは運動した気になったし、子供たちは満足したようだし、 温泉につかって気持ちがよかったし、なんか充実した気がする。
先日募集した読者プレゼントですが、 さっそく当選発表したいと思います。
応募総数は9通でした。少ない。選別は以下の方法で行われました。
まず、9通のメールを事情を全く知らない妻に読ませて、 ウケを測定しました。そのウケが高いものから順に３名を当選としました。
なんじゃそりゃ。
とうことで、当選者です。
以上３名です。当選された方にはこちらからメールで連絡いたします。 おめでとうございます。
はずれた方は残念でした。今後も適当なブツがみつかればプレゼントを行いたいと思います。 お楽しみに。
プレゼントの提供も歓迎します。
以前アパートに住んでいた時にはなかったことだが、 玄関が引戸なせいか、わが家への訪問者はチャイムを鳴らすと同時に戸を開ける人が多い。
その度に慣れないせいもあってかなり動揺するわけだが、 今日は白装束に獅子舞の頭を持った人がやってきた。
「ごめんください」
「神楽(かぐら)です」
えーと、これはなんですか。頼めば獅子舞を踊ってくれるんでしょうか。 縁起物なのでお布施とか必要なんでしょうか。 私はどう振る舞うべきなんでしょうか。
ほとんどパニックになりながら、口から出た言葉は
「うちはクリスチャンですから」
すごすごと引き下がってしまわれました。
しまった。生の神楽を玄関で見るチャンスはそうなかったかも。 惜しいことをしたか。
〆切。ぎりぎりだった。もうちょっと早め早めと思っているのに、〆切まぎわにならないと取り掛かれない。 この性格は直さないと。
テーマは「DBM」。メールオーガナイザーのための調査を流用。 開発日記はそのまんまメールオーガナイザーの話。
オープンソースソフトウェアを開発しているとする。 公開するとなればライセンスを決める必要がある。 個人的にはGPLを選ぶだろう。 FSFやStallman個人に賛同しているというよりも、 Linusのように実利的な理由からだ。自分の開発した「フリーソフトウェア」がいつまでも「フリーソフトウェア」でありつづけてほしいという望みは、正当なものだと感じる。
しかし、そのソフトウェアがライブラリ的使われかたをするものだと話は別だ。 GPLだとそのライブラリをリンクしたソフトウェアも派生物と見なされるので、 全体にGPLが適用されることになる。 リンクするソフトウェアがGPLと互換性のないライセンスのものだと面倒なことになる。 ライセンスという非技術的な理由でライブラリが使えないのは、 開発者・利用者双方にとって不幸だ。どうせならできるだけ広い範囲の人々に使ってもらいたいというのが人情だし、 プレゼンスの向上などの理由でもその方が望ましい。
LGPLにはそのような制約はないので、たとえばソースを公開しない 独占的ソフトウェアであってもリンクすることはできる。 これは利用者の範囲を広げるためにはありがたい。 しかし、再リンクを許すための条項(6条)がかなり面倒である。
いっそ、LGPLではなく純粋なGPLに「ただし、リンクされたソフトウェアは派生物と見なさない」という例外条項を付けるのはどうか。これはGPLではないが、GPLよりも「より緩い条件」なのでGPLとの互換性は維持される。ライブラリソフトウェアそのものに将来に渡ってGPLが適用されることを保証したいだけなので、リンクするソフトウェアに対してLGPL 6項のような要求を行わない。なんとなく理想的な気が。
ただ、ライセンス問題はややこしいので、 上記のような例外条項が本当に意味を持つのか確信を持つことはできない。
結局、BSDライセンスを選んでしまう、私たちであった。
追記
野首さんから
以前に新部さん、ひろのぶさん、小島さんととも似た話をしたのですが、FSF的自由とプロプライエタリとのいいとこどりは困難だ、というのが結論になってしまいました。
というツッコミをいただいた。ツッコミ欄で返答したのだが、重要な点なので再掲しておく。
私は別に「FSF的自由とプロプライエタリとのいいとこどり」をしたいわけではないつもりです。立場としては、自分(たち)の書いたソースコードについてはいつまでも「FSF的自由」を適用したいが、それをリンクした他人のコードにはそれを要求したくない、というものです。ですから自分たちの「コードを守りたい」気持ちはあるのでBSDライセンスだと不満が残るのです。
それにしても「リンク例外条項付きGPL」は結構いいアイディアのような気がしてきたぞ。
先週削った部分に金属を入れてもらう。でも、やっぱりしみるんだけど。 うーん、ちゃんと磨いてたつもりだったのになあ。
やはり電動歯ブラシでは不足で、 超音波歯ブラシを導入すべきか、 などと考えてしまうのは、テクノロジー主導の技術屋の発想か。
ちゃんと磨けばいいんだろうけどねえ。
日経Linux8月号原稿完成。なんか、すごい手間がかかった。 まあ、ゼロから書くことを思えば、以前の原稿を参考にできた分だけ楽だったんだろうけどねえ。
しかし、Cによるソケットプログラミングを忘れていたのにはあきれたよね。 まあ、以前からソケットプログラムが必要なときにはext/socket.cを読んでいたんだけど。
ITProから。 OSDL Japan Linux Symposiumの記事。
いや、まあ、まず手を動かさないことにはならんので、 そこからじゃないかと。
で、次が伝える努力かなあ。Ruby業界では日本の動向はいつも注目されているので、 出て行ってあげると喜ばれると思う。つたない英語だろうがなんだろうが、 彼らにとっては日本語よりも65536倍わかるんだから。 わからなかったら聞いてくれるし。
要は「一歩踏み出す勇気」かなあ。
クロージャがあれば並行プロセスの実現は簡単、という話。
とはいえ、1.8でのクロージャは重いから、Rubyだと「超軽量」とはいかないのが残念なところだ。
で、上記の「超軽量プロセス」をRubyで実装してみたjijixiさんによる例。
うーん、演算子によって型が決まるタイプの言語で 型変換用メソッドを用意するというのは よくあるテクニックであるとは思う。
Rubyでもto_*シリーズとしてこれらに相当するメソッドがある(例、to_str, to_int, to_io, etc.)。 しかし、それを「Duck Typingは演算子にやらせる」と呼ぶのは なんか違うような気がするなあ。