[DE | EN | FR | IT | JA | ES | KO | PT]

Brave GNU Worldの新しい号へようこそ。前号の最後でお約束したように、 今月は私の生活を楽にしてくれるプロジェクトを紹介したいと思います。

SpamAssassin

Justin MasonによるSpamAssassin [5] は、到着する電子メールにあるSpamを 「抹殺 ("assassinating")」します。最悪でも、Spamにマークをつけて、 Procmailや他のメール・リーダーが、 利用者に一番うっとうしくない方法で処理できるようにします。

SpamAssassinの精神は、Perlそれ自体と同様にGNU General Public License、 Artistic Licenseという同じ2本立ての許諾で配布される、 Perlのプログラムであることです。SpamAssassinはそのため、 "Comprehensive Perl Archive Network" (CPAN) [6] 経由で配布でき、法的問題ぬきで、そこから再利用できるのです。

ところで、許諾の問題は、プロジェクトの開始当初から、決定的部分でした。 SpamAssassinを書く前、Justinは、 Perlで書いた別のメール・フィルターを使っていたのですが、 その静的なルールと、あいまいな許諾条件のせいで、問題があったのです。

このプロジェクトから、Justinは、点数で作用させる、 というアイデアを適用しました。 これは、ニュースとメールのリーダーであるGNUS [7] で採用されている "Adaptive Scoring" (適応的配点法) にかなりよく似た概念です。

解析するメールにたいして多くのさまざまな検査を適用することで、 SpamAssassinは作用します。その中には、HTMLのみのメール、Spamきまり文句の有無、 法律や条例に基づく「Spamでない」という主張の有無、 並はずれた数の感嘆符や疑問符、"Millions Dollars" (数百万ドル) について書いているか、などなどの検査があります。

どの検査に何点あたえるかは、 まあまあ簡単なASCIIの構成ファイルで利用者が指定でき、 その電子メールで引っかかった全検査について、点が加算されます。 合計点が、これも利用者定義可能な、ある閾 (しきい) 値をくぐると、 「おそらくそのメールはSpam」とSpamAssassinが判定をします。

この決定に基づき、SpamAssassinは、 検査結果を通知するフラグをヘッダーに挿入します。もし利用者がそう望めば、 Spam電子メールのContent-Typeが「text/plain」になるようにして、 結果を後でチェックしやすくできます。 また、メールがSpamと査定された理由を利用者が見やすくなるよう、SpamAssassinは、 詳細な検査報告をメール (の本文) の先頭に挿入することもできます。

SpamAssassinを利用することによる潜在的な最大の危険は、 あきらかに「誤報」("false-positive")、 すなわち、ふつうの通常のメールをうっかりSpamと分類することです。 ですので、誤報の修正のため、 検出されたSpamの入るフォルダーを定期的に見ることをお勧めします。

SpamAssassinの感度を下げることもできますが、 検出されないSpamの量は増えてしまいます。適正な釣合いを見つけることは、 SpamAssassin管理者にとっての巧妙なところです。

SpamAssassinの検査を迂回する方法をSpam差出人に見破られるのを防ぐため、 このプロジェクトではできるだけ多くのさまざまな検査を組み込み、 また拡張しやすいようにしています。

もちろん、オンライン・ブラックリストのサポートもあります。 Spamの既知の発生点や中継点を集めた標準DNSブラックリストは、 既知Spamを同定するためのSpamデータベースであるVipul's Razor [8] として、 同様にサポートされています。

大量メールの簡単なフィルターリングや、 できるだけ多くのメール発信源との接続のため、Craig Hughesは、 SpamAssassinパッケージについてくる"spamd"デーモンを書きました。

SpamAssassin最大の弱点は、いくぶん技術的経験のある利用者向けであること、 グラフィカル・ユーザー・インターフェースが (まだ) ないことです。

その点の解決は、メール発信源への接続の作成や、より多くの検査の記述と同様、 さらなる開発の焦点です。現在有効な接続には、Procmail、Qmail、 Postfix、Milterライブラリー経由のSendmail、Mail::Auditプラグインがあります。

sendmail-milterプラグイン [9] は、既存の解の探索に失敗した後、私の書いたものであり、 そのため私の受け取るメールにSpamAssassinでフィルターをかけることができる、 ということに触れさせていただくことをお許し願いたいと思います。 私側の時間不足で、プロジェクトをまっとうに管理できませんでしたが、 Free Softwareのしきたりにそって、Michael Brownが、管理者を引き継いでくれ、 また彼の会社は、彼を雇い商用環境に提供してくれました。

全利用者の最善のため、会社の商業的関心と、 古典的な「自分のかゆいところをかく」アプローチを調和させることが、 Free Softwareにはできる、ということを示すよい例に、これはなっているわけです。

インターネットを埋めさせるおそれのあるSpamの増大する洪水に直面すると、 毎日約60通ものSpam電子メールを削除してくれるSpamAssassinのようなプロジェクトにたいし、 私は大きく共鳴の意を表わしていることを認めざるをえません。

Voxximate

Brave GNU Worldの通常の読者なら、 科学の領域におけるFree Softwareについてのたいていの議論とは、 かなりおなじみのはずです。

あらゆる種類の科学への作業について、究極的にFree Softwareは、 長期的に意味ある唯一の選択肢です。なぜなら、Free Softwareだけが、 将来のプロジェクトへの利便を残す保証を提供し、 それを科学の上の結果にとりこまれるようにするからです。 つまり、人の労作の部分的な公開や、必要に応じた肩代わりのことです。

Andreas NeumannによるVoxximate [10] は、 GNU General Public Licenseの下でのそんな科学的Free Softwareプロジェクトです。

Voxximateは、 "Vortex flow simulation made at home" (家庭でできる渦巻き流模擬実験) のことで、これは、流体の流れ、渦の模擬実験をするプログラムです。 このプログラムは、事前定義された開始位置に基づき、 時間経過に伴う進展を追いかけつつ、 他の全渦のおよぼす渦それぞれの影響を計算する処理を実際におこなうことで、 動作します。

このプロジェクトが一番役立つのは、たぶん、渦同士がどう相互作用し、 構造を形づくるのかに興味をもって、流体力学の研究をしている学生でしょう。

Voxximateは、Javaで書かれており、Javaでおなじみの問題を投げかけますが、 だらといって、誰かにさらなる開発のサポートをさせずにおくべきではありません。 次の段階で、Andreasは、開始位置を定義し、 ウェブ公開用のアニメーションやグラフィックスを保存できる、 グラフィカル・エディターを含む見込みでいます。

Monica

Monica [11] は、Tilo Riemerによるモニターの測定プログラムです。 これは、C++で書かれており、XFree86 [13] のxgammaプログラムと、Fast Light Toolkit (FLTK) [12] を使っています。

γ補正を誤ったモニターでは、近寄った色の区別が不可能になりえたり、 満足いく配色体系の印象がもてなかったりします。 特にコンピュータをグラフィカルな作業に使う場合、これはうっとうしいことです。

当初、Tilo Riemerは、同族のプロジェクトである KGamma [14] を使おうとしましたが、若干のKDEライブラリーがなかったためコンパイルに失敗し、 またKGammaは、動作させるのにKDEのかなりの部分が必要なくらい深く、 KDEにはまりこんでいたのでした。

そこで2002年1月、小さく速いという特長をもつMonicaを彼は書き始めました。 それで、動的にフィードバックできる「その場 ("on-the-fly")」モードを入れることができました。 900MHzのコンピュータでは、10〜20%のCPU時間が必要になります。

さらなるMonicaの強みは、FLTK以上の依存関係がないこと、 利用者の".xinitrc"に変更を保存するポリシーです。 これで、ウインドー・マネージャやデスクトップと無関係になります。 (ドラフト注: 原文のセミコロン (の位置) は意図どおりなのかな?)

最近のリリースである1.0版は、 TiloがMonicaに時間を費やす予定のないことを示していますが、 これを国際化することについての努力は歓迎するそうです。

元来、Tiloは、Monicaを「パブリック・ドメーン」でリリースする予定でした。 というのも、小さくて、些細なものなので、許諾について考えることは割に合わない、 と思えたからです。

しかし、ヨーロッパ大陸において、パブリック・ドメーンという観念は、 完全に大丈夫とは言えないのです。ドイツにおいて、この用語の標準的法解釈は、 原作者・著作権の主張のないこと、つまり、通常、原作者が不明であるか、あるいは、 死後70年以上経過したか、どちらかをさします。この場合、明らかに、 どちらにも該当しません。

そのため、Tiloは、当面の問題を解決し、MonicaをFree Softwareとすべく、 BSD風の許諾の下でMonicaを公開することを決心しました。

この話はそれほど並はずれたものではなく、 開発者というものは許諾について考えるのがそれほど好きではない、 ということを示しています。 とはいえ、そうでない場合には、容易に不確実性におちいりうるのです。 ですので、私は、Free Softwareの法的な保守可能性について、 わかりやすく紹介をしてみたいと思います。

Free Softwareの法的な保守可能性 (legal maintainability)

あらゆるソフトウェアのうち、かなりの部分で継続的、技術的な保守が必要で、 さもないとその有用性がなくなっていく、ということは、 多くの人がご存じだと思います。往々にして、 継続的に保守されるソフトウェアだけが、長期にわたって採用されうるのです。

この技術手順は本来、ソース・コードへのアクセスと権利、すなわち、 保守をおこなう自由に依存しています。 一般的に、社会の各員の権利や義務の定義は、政治、法体系でおこなわれることです。

法体系が良好に機能しているかどうかが重要なのではありません。 注意すべきなのは、技術的な保守可能性の前提条件が、本質的に法的だ、 ということです。

特に商業環境においては、永続的でたゆむことのない保守可能性は、 Free Softwareについての有望な特長のひとつです。 この特長は、Free Softwareの法的な保守可能性に強く依存しています。

Free Softwareの自由、権利、義務は、許諾をとおして与えられ、 そしてときには守られています。この許諾は、作者の著作権を通じて、 ソフトウェアに「固定 (anchor)」されます。 Free Softwareは、機能すべき著作権法に厳密に依存してはいませんが、 (ドラフト注: "to work"ってどっちにかかるのかな?) 著作権法のある以上、私たちはそれを処理しなければなりません。

こうした前後関係において、法的な保守可能性とは、何なのでしょうか?

たとえこれは、多くの人がそれをどのように本能的に察知するのか、 ということでないとしても、法体系とは静的なものではなく、 絶えず変わってゆくものです。

著作権法にふれる変更は、ドイツで最近おきた一件でのように、 Free Softwareを潜在的に弱めたり、無法なものにしたりします。 この特殊な件において、ifrOSS [15] とFSF Europe [16] は、 提案された著作権法改訂版への変更を提起し、 Free Software用の例外を導入する機会にめぐまれました。 この変更は、ifrOSSから提案された原案どおりのかたちで、法案に採用され、 2002年1月25日に可決した法律の一部となり、間もなく施行されます。

FSF Europeのに任務のひとつは、そのような発達をさがし続け、 Free Softwareに前向きな方向で影響をあたえることです。 ifrOSSのような明らかに全面的本質的である法曹組織の協力ぬきでは、 このようなことをするのが困難だったでしょう。 FSF Europeはそのため、ヨーロッパ中に組織をつくったり、 強化をしたりしているわけです。

許諾の適合において、他の法的制限が必須であるように変更することも、 あるいは可能だったでしょう。 (ドラフト: ちょっと意訳。というか直訳だとさっぱり意味不明:-) 法的変更や、「アプリケーション・サービス・プロバイダ (ASP)」 といった新しい技術概念は、ある分野の自由の保護を回避したり、 あるいは、非効果的になるようひるがえして実効上、 許諾の精神をふみにじることさえ、可能かもしれません。

多くの開発者らが、 自分のソフトウェアをGNU General Public Licenseの下で公開することで、 自分のソフトウェアの自由を守ったり保護したりしようとしています。 そうすることで、Free Softwareを安全にすることへのいちばん重要なステップが、 すでになされたことになります。 「或いはそれ以降の各バージョン("or any later version")」 という節 (clause) を採り入れることで、FSFは、 (L)GPL配下での許諾の保守、弁護、保護への広域的権限を部分的に与えられます。

ときには、しかし、あからさまに許諾を変更することが、 重要になることもありえます。 法的権利の集中的な保守を確立していないプロジェクトでは、 特にGPL (を適用するため) の「或いはそれ以降の各バージョン」 という節をのぞいたような場合、深刻な問題が起りえます。 (ドラフト注: GPLを読めばわかるが、``or any later version''の節は、 GPLの外側、GPLを適用したいプログラムので記述例の中にある。)

この場合、全開発者――まあ、全員見つけられたと仮定して、ですが―― が、変更に合意する必要があります。 プロジェクトに従事する開発者の興味や意見の範囲が広いとき、 合意がちょくちょく成り立つとはいいがたいものがあります。

またたいていの場合、 いわゆる「排他的搾取権 ("exclusive exploitation rights")」 つまり、"Copyright" (著作権) の保持者だけが、 法廷において、許諾を強制する法的資格をあたえられます。 したがって、プロジェクトが法廷でその権益を代表しようとするとき、 深刻な困難に向かうことになります。

多くの作者らがプロジェクトに従事している場合、個人の権益を保護するためには、 実質的に一丸となって、いっしょに行動する必要があります。 これにはかなりの調整、時間、努力が必要です。 また、潜在的にはジリ貧かもしれない法廷闘争を、最期まで喜んで見届けることは、 作者全員に可能とはいえません。

より多くのプロジェクトで、このような関係に配慮し、十分な用心をしてもらうのは、 よいことです。 被信託者の任命で、作者らはソフトウェアの改良に戻ることができます。

利用者というものはたいていこのことにかなり注意を払いがちなものですから、 将来、明白に分類された法的環境の整ったプロジェクトが、一般にひろまり、 優位に立ちそうです。

Free Software ――ここでは特にGNU Projectの核部分ですが、それに限定するものではありません―― の法的保守可能性を確実なものとするため、 Free Softwareの権利を (必要とあらば法廷においても) 守り、 許諾を環境の変化に適応する権限をえるため、 Free Software Foundationは早くから、いわゆる "Copyright Assignments" (著作権委譲) に取り組んできました。

ヨーロッパ大陸の原作者法 (Authorship law) は、 英米の著作権 (Copyright) と基本を異にするので、 FSF Europeが作者らの被信託者として振舞えるようにするために、 ifrOSSのAxel Metzger、Carsten Schulz、Till Jaegerとともに、FSF Europeでは、 "Fiduciary Licence Agreement" (被信託者許諾合意) にも取り組んできました。

作者は、 無制限の「単一搾取権 ("single exploitation rights")」を保持します。 他の (潜在的には独占的でもありえる) 許諾の下で、 ソフトウェアを重許諾 (dual-license) するとき、作者は、 その許諾と単一搾取権をいっしょに使うこともできます。

と同時に、FSF Europeは、Free Softwareの権益にある被譲渡権利の行使だけを保証し、 Freeな許諾の下にあるソフトウェア ――そうでなければ、全権利は作者にあるわけです―― の公開だけをおこないます。

この合意は今、最終部内「見直し段階 ("review phase")」にあり、 そう遠くない将来、公にされることでしょう。

Free Software Foundationは長年にわたり知られているという信頼とともに、 そうした挑戦に直面し続けているので、私はFSF Europeを代表し、 FSFこそこの任務にふさわしい、と考えます。

FSFの人たちは、最大の知識と、 GNU General Public LicenseやLesser GPLという経験をもつだけでなく、 世界的に活動ができ、 Free Softwareの権益を守ることのできるという正当な評判もあります。 しかも必要とあらば、法的手段にもうったえて、です。

今日はこのへんで

今日はこのへんで十分でしょう。 最後の部分では、Free Software Foundationの作業、任務、 背景についての理解をいくらかでもうまく深められたと自負しています。

いつもどおり、お考え、コメント、質問、新しいプロジェクトについての電子メール [1] をどしどしお送りいただくよう、お願いしておきます。