|
．一般的に、契約書ってのは(おおむね)絶対ではあるけど完全ではないんだよね。 ．だから、会社同士なんかで契約を結ぶ時というのは、 それぞれの条項がどういう意図なのかというのを 事前に口頭で確認するのが普通だし、 その確認された内容は明文化されてなくても (というかあえて明文化しないのだが)守り、 後で不明確な点とか解釈の齟齬が出た場合には話し合いで解決する、 というのが、契約というものの暗黙のルールみたいなところがあるんだね。 それが、契約における信頼というもの。 ．で、オープンソースソフトウェアのライセンスにこれをあてはめて考えてみると、
．GPL におけるダイナミックリンクライブラリの扱いってのは、 この辺に関係してくるんじゃないでしょうかねぇ。 やっぱり GPL も普通の契約書並には不完全なんだよね。 佐野さんみたいに、メール出して事後の意思疎通を図る手もあるにはあるけど、 たとえば、Linux とか glibc みたいな良く普及したもので、 もし利用者全員がそれをやろうとしたら破綻するわけで。 まあ、ML を使うという手もあるけどね。 ．ただ、ちょっと配慮するだけで、すんごく単純な話になるんじゃないか、 という気もするんですわ。つまり、各ソフトウェア作者は、 細かい条件について明文化しておけばいい。それだけ。 少なくとも今の GPLv2 は、単に「GPL です」で済むほど完全でないし、 完全にするためにはちゃんと趣意書かなんかを書かんといけないと思う。 そういう意味で、もし「GPL は単一であるから楽」という主張をするのなら、 それは実質的には間違ってる、と私は個人的には思う。 同じ GPL 付けてても、混ぜられないもんは混ぜられない可能性がある。 ．で、最近の傾向として、ライセンスに対して FAQ を付けるようになった、 ってのはいい傾向だと思う。GPL は FAQ 出すのが遅すぎるけどね :-P。 確かに、FAQ ってのには拘束力はないんだけど、 それは口頭確認と似たようなもんで。 どこまで相手を信頼するか、という問題。 ．文句言われかねないので書いておくと、 特別に GPL だけがこういう特性を持ってるってわけじゃなくて、 BSD ライセンスも MIT ライセンスも、この特性を持ってるんですな。 単に、条件が緩いから問題になりにくいだけ。 ．まーでも、多くのフリーソフト作家にしてみたら、 ライセンスなんて実は本質的なことじゃないんだよね。 そういう人にとっては、明文化するってのはメンドイことなんじゃないかのう。 私のスタンスは以前から書いてる通りなので、 「(修正) BSD ライセンスなら、詳細を明文化しなくても、 利用者も作者も無難に生きていけるでしょう」 と言っておこう。 |
|
．広辞苑： しょうぎ‐だおし【将棋倒し】シヤウ‥ダフシ 将棋の駒を少しずつ間隔を置いて一行に並べ立て、 一端の駒を押せば次々にすべての駒が倒れること。 転じて、一端が崩れるに従って全体が崩れ倒れること。 太平記七「―をする如く、寄手四五百人、圧(おし)に討たれて死ににけり」。 「乗客が―になる」 ．ウ゛ァカかね?＞将棋連盟。 |
|
．それは 、 こう言ってしまうと身も蓋もないけども、あくまでも「お話」だからかと。 人間、本当にああいう状況になったらそうそう冷静ではないから、 リアリティという点では確かにうそ臭いのだけれども、 かといってそこで本当にリアリティを追求してしまうと、 読者と登場人物との一体感をもって読ませる話としては破綻してしまうでしょう。 ．なんでかっていうと、人間関係壊すのは一瞬だけど、 修復するのは年単位で時間がかかるから。 もし、現実であれに近い状況になれば、みんな確実に 感情で動いて人間関係がズタズタになるし、その修復過程を、 たかだか数時間で読み切るテキストで描写しても、 もはやタイムスケールという点で読む側の一体感は失われてしまうかな、 という気はします。 ．ほら、一般的に言って、シミュレーションゲームでさえも、 本当にリアルなゲームが本当に面白かった例って、ないでしょ :D |
|
．原爆の日。 ．やあ 3 のところには、HHH 機関の陰謀により、 「那須高原ビーフパイ」というものが届けられたらしい (HHH = 遙たんハァハァ)。合掌。 ．しゅがっぴ特派員によると、焼きたてでうまいらしい。 一人一個から二個が無難。20 分程度前に電話しておくとよい。 ． ．対抗して MMM 機関も登場した模様(MMM = 水月たん萌え萌え)。 |
|
．すっかり忘れておったが、だいぶ前からゲームはできるようになってるぞ： ．何気に行数は 10000 超えてるな。もっとも、修正 BSD ライセンス分があるから、 実質的にはもっと少ない：
kotori% wc **/*.{cc,h} ~/kotori.tshiozak/project/xtoraha/xtoraha
(中略)
10139 38365 288833 total
．うっとうしいから削った。 ．今の xtoraha のやりかただとローエンドは難しいでしょう 。 というのは、オリジナルのとらハのデータを全くコンバートせずに使うことを 目標にしてますので。 Window System とのかかわりという点では、 SDL の目指しているそれと同じような感じ。 ．でも、各 Window System の対応×各ゲームへの対応、 っていう 2 次元の組み合わせなので、近い将来破綻するでしょう。 まあ、現時点は、まだあまり根を詰めてないので、 その破綻するところにすら至ってませんが。 ．本当に、大きなものから小さなものまでいろんなデバイスで いろんなゲームを動かそうと思ったら、 そういうやりかたじゃなくて、 一度中間フォーマットに落として、そのレベルでエフェクトなんかの抽象化する、 という方法になると思ってます。 中間フォーマットのところで実装レベルみたいなのを設けて、 ちんまいターゲット向けに適当に reduce したバージョンの中間コードとか、 大きいターゲット向けのフルセットバージョンの中間コードとかを、 中間フォーマットコンバータで吐けるようにするんでしょうな。 ．まあ、ソースは追い追い。まだちょっと汚いし、いろいろあるので。 |
|
．xtoraha のソースを流用して、 例のスクリーンセーバーの X 版を作る。 ．今はセーバーにはなってない。セーバーにするには、 libamuse に、もうちょいいろいろと追加しないといかんな…。 ．ソース 。 諸事情により、いまのところ NetBSD でないと動きません。 諸事情により、とらハエンジンは入ってません。 コンパイル方法: cd xsss; make config; make dependall; cd sss; make dependallデータが別途必要だけどノーコメント。 今のところ、アレしか動きません (読み込む .scn ファイルを決め打ちにしてるから)。 ．諸事情、というのは、上のコマンドラインを見ても分かるとおり、 Berkeley portable make に依存してるんですな。それも NetBSD の .mk が必要。 あと、今のところめんどくさくて自前で wav 再生を実装してないので、 外部プレイヤーを叩くようにしてるのですが、 今はとりあえず NetBSD の audioplay にハードコードされてる。 こっちは、とりあえず sox の play に置き換えるとかすればおっけー。 xtoraha を公開してないのは、この辺を何とかしてからにしようと思ってるから。 ．しかし、ビルドプロセスはどうするのがいいのかのう。 わたしゃ gmake も autoconf も、 (アイディアはともかく)実装の筋が悪いので嫌いなんだが。 かといって、いつまでも pmake って訳にもねぇ。ううむ。 pmake 自体はどこへ持ってってもだいたい動くから、 .mk だけ適当に用意するのかのう。 |
(c)jANIS/ivory