[DE | EN | FR | JA | ES]

またまたGeorgのBrave GNU Worldにようこそ。 今月号は、 フランスからのプロジェクトで始めましょう。

Lolix

Rodolphe QuiedevilleによるLolixプロジェクト [5] は、 Free Softwareを軸とした求職者が、 脈のある雇用者と会うことのできるウェブページに基づいています。

これは、 会社が求人を登録するのと対応し、 IT専門家が自分の経歴をリストするという、 実証ずみの概念にしたがっています。 両区分の照合候補は、 検索エンジンで閲覧できます。 さらによい照合結果が検索でとれるよう、 検索エンジンのパラメータは微調整できるので、 かなり興味深いものです。 Rodolpheにとっては技術的な実装の高品質が非常に重要であり、 また彼は、 これが自分のプロジェクトの主な利点のうちの1つだと認めています。

現在、 Loic DacharyとRaphael Rousseauが技術的部分の支援をしています。 もちろん、 コードはすべて、 GNU General Public Licenseの下で公開されています。

Lolixは当初、 フランスの雇用市場にかぎられていましたが、 2000年9月以降は、 合衆国でもこのサービスを提供しています。 これからの目標は、 他の市場のサポートと、 他の言語へのウェブページの翻訳で、 特にドイツ語とスペイン語の優先度は非常に高いです。 とはいえ、 英語への翻訳もまだ完全ではなく、 いくらか改善の余地があるでしょう。 この課題のため、 主催者は、 まだいろいろな国とのコネを求めています。 また、 機能やオンライン・ヘルプも改良しようとしています。

特にFree Softwareへの特化のため、 私はこのプロジェクトを非常に興味深く思います。 また、 ドイツと英国の雇用市場への対応もすぐであろうと望むばかりです。

GtkLP

GtkLP [6] プロジェクトは、 Common Unix Printing System (CUPS) 用のグラフィックなフロントエンドです。 名前からわかるとおり、 これはGTK+ツールキットに基づいていて、 GNOMEデスクトップへのとりわけスムーズな統合を確かなものにしています。 多くの人々はいろいろなコマンド行引数を覚えていませんから、 「標準的」利用者には、 こういうプロジェクトの利点は明白なはずです。

GNU General Public Licenseの下、 このプロジェクトは、 数学と計算機科学の学生であるTobias Muellerが書きました。 実際に唯一欠けているものは、 パスワードで保護されたプリンタと、 特別なオプションのサポートです。 CUPSの標準的なオプションはすべて、 すでに完全に実装されています。 さらに多くの言語へのサポートもあればなかなかいいのですが、 そういった拡張機能の追加は、 次の課題です。 どちらにしろ、 このプロジェクトで、 明らかに世の中は楽になります。

GNU FaXile

Wolfgang Sourdeauは、 GNUシステム用にFAXの完備した環境の実装を目標とした、 GNU FaXile [7] プロジェクトを立ち上げました。 たとえ名前がそうだとしても、 GNU FaXileは、 まだ公式のGNU Projectではありません。 ですが現在、 そのようにすべく議論されています。 これはすでにGNU General Public Licenseの下で公開されているので、 大きな問題が引き起こることはまったくないはずです。 Wolfgang Sourdeauの作業から、 独占ソフトウェアが利益を得ているのを見ることにたいして、 彼は非常に反発しているため、 ライブラリーにさえもGPLを使っています。

Free Softwareに基づく完全、 高性能かつ利用者にやさしいFAX環境、 というゴールは、 まだまだ遠い先のことです。 いま動作する部分は唯一、 FAXビューアだけです。 しかしこれは、 もうなかなか良さそうに見えます。

技術的実装についての目標の1つは、 パッケージを転送方法の実装から独立させることです。 GNU FaXileは、 mgettyやefaxと同様、 HylaFAXをサポートするでしょう。 これらすべてのため、 GNOME GUIのみならず、 テキスト・ベースのインターフェースが提供されます。 そして次の目標は、 HylaFAXとmgettyの若干の構成要素をよりよく、 そしてより便利にした再実装です。

FAXビューアをわきにおくと、 完全なパッケージは、 FAX送信用のダイアログ、 管理用のフロントエンド、 GNOMEのパネル・アプレットを提供することになるでしょう。 非GUI構成要素のほとんどすべては、 他のプログラムでも使えるよう、 1つのモジュール・ライブラリーとして提供されることになるでしょう。

Free Softwareに基づくFAX環境の構築を目標としたプロジェクトとして、 第2には、 George Farrisによる GNOME-GFax [8] があります。 双方のプロジェクトがかなり似かよったことを達成しようとしているので、 Wolfgang Sourdeau、 George Farris、 そして、 GNOME-GFax用の非常に活動的な参加者のうちの1人Till Bubbeqは、 両方のプロジェクトの合流についていっしょに議論しています。 今のところ、 これはとてもうまくいっていて、 おたがいの協力が期待できます。

コードの合流の後、 次の共同のゴールは、 GNOMEとの高度な統合 (特にgnome-printやGNOME住所録への接続性) でしょう。 その上、 実行ログのような機能は、 実装されることになるでしょう。 しかし、 そうなる前にWolfgangにとって、 GNU FaXileがGNU Projectの公式の部分になるのを確認することは、 その名を正当化するためにも、 非常に重要です。 彼の長期的計画はOCRエンジンの実装ですが、 明らかに数ヶ月間単位で終わるようなことではありません。

真の作業を今、 始められるようにする前に、 若干の構想の略図を描いたり、 議論したりしなければなりません。 これについて、 他の開発者からのアイデアやサポートは、 非常に歓迎されています。

主にエンド・ユーザーに魅力あるプロジェクトの後は、 ソフトウェア開発の分野に行きましょう。

KBasic

KBasicプロジェクト [9] は、 MS Visual Basicのような非常に使い易い開発環境のため作業中です。 グラフィカル・ユーザー・インターフェースは、 マウスで構築できます。 その後、 作者は、 BASICの関数を能動的な要素と結び付けていくつもりでいます。

元々の作者であり、 現在の管理者でもあるBernd Noetscherは、 彼がGNU/Linux下でまっとうなBASIC IDEが見つからないと悟りました。 C/C++用であれば、 Glade (GNOME) とか、 KDevelop (KDE) とかのプロジェクトを使うことができます。 しかし、 そのようなものでしかもBASICに基づいたものをさがし出そうとして、 彼は、 つまってしまいました。 BASICは、 経験豊かな開発者の間で最高の評判を得ることはないにしろ、 その簡単さのため、 かなり多くの人々が最初に学ぶ言語にはなっています。 KBasicでは、 それほどの経験のないプログラマでも長く作業せずに、 機能的なGUIプログラムが作成できるようになります。

KBasicは、 今まだα水準のソフトウェアです。 最初の安定したリリースは、 来年出ることになっています。 比較的大きな開発チームには、 その地点まで多くの仕事がまだ残っていて、 C++やVisual Basic経験のあるプログラマはまだまだ、 大歓迎されています。

KBasicプロジェクトの中の開発者であり文献の著者であるTommy Scheunemannは、 KBasicの提供するのは、 MS Visual Basicの機能と似たようなものであろうが、 Visual Basicのプログラムの実行はできないだろう、 と強調してほしいとのこと。 その理由は、 Visual Basicの独占的な性質によるものです。 もちろんKBasicは、 GNU General Public Licenseの下で開発されています。

Colibri

Colibri [10] は、 Christian Lieschが計算機科学の研究中に、 作成しました。 それは、 GNU GPL配下で公開されたASCII用アプリケーションの開発者の枠組です。

小さなディスプレーつき専用サーバーや、 組込み分野用のASCIIベース・アプリケーションの開発者にとって、 きっとこのプロジェクトはかなり興味深いでしょう。 これは、 XMLの記述でASCII GUIを作ることができるので、 一種の (訳注: 前述のGNOME版にたいする) ASCII版Gladeととれるでしょう。

これはCで書かれてはいますが、 オブジェクト指向の構造がとられています。 Colibriは、 XMLの解釈にExpatのパーザーを使っていますが、 今のところこれでは、 文書型定義 (Dtd -- Document Type Definition) が扱えません。 不正なXMLファイルの場合、 プログラムが異常終了することがあるので、 これがChristianの知るかぎり最大の弱点です。

したがって、 彼の更なる計画には、 マウス操作 (click-by-click) のWYSIWYGインターフェース作成のための開発者用キットと同様に、 Dtdのサポートと、 色つきのGUIが入っています。 もちろん、 手助けは常に歓迎です。 とはいえその前に、 ガイドラインを書いておかなければならないようですが。

このプロジェクトは、 小さな1/4 VGAディスプレーの測定ステーション用の制御ソフトウェアがその出発点です。 この実現のため、 Christianは、 プロセス実行用のメニューを作りました。 このメニューは、 記述ファイルによっていました。 このメニューは、 ゆっくりと一式のウイジット (widget) に変わっていき、 記述ファイルは、 今やXMLで書かれているわけです。

java2htmlとcpp2html

java2html [11] とcpp2html [12] という2つのプロジェクトは、 前号で紹介したgengetoptの管理者、 Lorenzo Bettiniの書いたものです。 プログラムは、 JavaやC/C++のソース・コードから、 構文を強調したHTMLファイルを作成します。

このツールは、 特にプレゼンテーションや、 ウェブ・ページでのソース・コードの説明、 視覚化用に、 非常に有益かもしれません。 同様のプロジェクトと比べたときの主な長所は、 MS Windowsの下でもうごく、 ということです。 したがってこれは、 異機種環境で使えます。

出力のカスタム化は非常に高度で、 CSSが利用できます。 残念ながら、 他のソース・コードのHTMLファイルへのハイパー・リンクは、 サポートしません。 Lorenzoによれば、 これは最大の弱点で、 課題リストの先頭にあります。 残作業はたぶん、 残ったバグを見つけて、 直すことでしょう。 ここで彼は本当に手助けをほしがっています。

ライセンスについて、 両方のプロジェクトは、 GNU Projectの公式部分であり、 GNU General Public Licenseの下で公開されています。

PPCBoot

Embedded PowerPC Linux Boot Project (PPCBoot) [13] は、 fads823ボード用に拡張したMagnus Dammによる8xxROMプロジェクトに基づいています。 目標は、 4xx/5xx/8xx Motorolaプロセッサに焦点を合わせた組込み装置用の、 容易で、 拡張可能な標準的ブート・ソルーションを作成することです。 他のプロセッサ型のサポートは、 陽に除外されているわけではありませんが、 そのプロジェクトへの支援次第になるでしょう。

主な問題は、 組込み分野の製品においては、 いかなる標準にたいしてもこだわりをもつということがない、 ということです。 そして、 高度にカスタム化の可能なインターフェースが必要になります。 他の利用者が車輪を再発明することのないようにするため、 最多数の例の提供も必要です。 これらの作業は、 比較的高い優先順位があります。

上述の開発者のほか、 絶えず成長している活動的プログラマのグループ --特にWolfgang Denk、 Duncan Palmer、 Dan A. Dickeyについては欠かせません-- があります。 現在、 Wolfgang Denkは、 カーネルのブート方法を柔軟にするため、 BOOTPとTFTPのサポートに取り組んでいます。 毎回毎回Flash ROMにカーネルを書き込む必要がないので、 特に小さなフラッシュ・カードつきの装置には、 非常に便利かもしれません。 この上に、 モデム装置、 ISDN、 イーサネット、 IDE用のPCMCIAのサポートについて、 検討されています。 ところで、 このプロジェクトのことを知らせてくれたRaphael Bossekによると、 PPCBootがモジュラー概念に完全にしたがっているということ、 不必要とされたり、 欠けてはいないと判断された機能は、 みな除外することができるということを、 ぜひ知ってほしいとのことです。

さらに、 プロジェクトにスポンサーがついていることに非常に頼っていることを、 彼は強調しました。 彼があげたのは、 たとえば、 Wolfgang Denkと交渉して、 自社ボードのブート・ソルーションに入れる必要のある作業量見積りを彼に尋ねたSiemens Austriaです。 若干書き直さなければならないであろうのものがあったので、 Wolfgangは、 GNU General Public Licenseの下でなら約1ヶ月、 そうでなければ約2ヶ月かかるでしょう、 と返答しました。 Siemensは、 今PPCBootの一部になったGPLのソルーションを非常に早く受け入れました。 もちろん、 PPCBootの残りもGPLになっています。

ソフトウェア特許

最後に、 「ライセンスと特許」 という題ですでに1999年7月に書いた、 ソフトウェアの特許の話題について話したい、 と思います。 私は当時、 なぜ特許を有益な方法でソフトウェアに適用できないか、 というような疑問をとりあげ、 これに反対するよう、 お願いしました。

1年強の後、 この危険はいまだ激しく、 ソフトウェア特許については未決段階で、 その結果、 ソフトウェア特許の賛成は1票でした。 わずか1年前なら、 ソフトウェア特許への賛成は、 明らかにもう少しあったでしょうから、 これは、 ある程度の希望を保証するように思えるかもしれません。 しかし、 その作業はまだ決して終わっていません。 今このことが聞こえてきている、 ということが重要です。 なぜなら、 ソフトウェア特許が実際に悪いアイデアだろうということが、 開発に責任ある人々にたいして見えてきているからです。

この話題について、 League for Programming Freedom (「プログラミング自由同盟」) による優れた文献、 "An Industry at Risk" [14] (「危機にある産業」) があります。 私はこの文献を読んで、 これが、 かなり事実に基づいたアプローチを使って、 ソフトウェア特許擁護者の議論を再編成 (disassemble) していることだけを指摘 (recomment) しておこうと思います。 ソフトウェア特許によって、 米国はこの数年間、 技術革新の減速に苦しめられてこざるをえませんでした。 書かれたのはすでに6年前ですが、 この文献はほとんどぎょっとさせるほどに最先端をいっています。

私が個人的に、 皆さんひとりひとりにお願いしたいのは、 EuroLinux Petition against software patents in Europe [15] (「ソフトウェア特許にたいする EuroLinux 請願」) に署名し、 そして、 他の人にも同じようにするよう、 すすめることです。 この話題についての知識を広めることも、 重要です。 ですので、 あらゆる機会を使って他の人とこの話をしようとしてみてください。

他の人とのこの議論について考えるに…。 ソフトウェア特許擁護者は、 Free Softwareには例外を提示することによって、 最近、 非常によく、 討論を回避しようとしてきました。 しかし、 連中は、 コミュニティーを作るはたらきをもつ自由ではなく、 価格について考えてしまう点で、 基本的な誤りをいつも犯しています。

Free Softwareの基本原理は、 商用とそうでないソフトウェアの間に、 あえて差を全然つけません。 重要なプロジェクトの有意な部分、 少なくともさらにその一部分は、 商用です。 そしてプロジェクトのうちのいずれも、 商用なだけではありません。 この織り合わされた構造は、 積極的な相互作用を生成します。 この相互作用は、 Free Softwareの現在の成功のための基本のうちの1つです。 このフィードバック・ループが壊れるなら、 その打撃はばく大でしょう。

この理由のため、 Free Softwareのためのすべての例外が、 商用とそうでないFree Softwareを明白に含まなければならないことは、 重要です。 これ以上の譲歩は不可能ですし、 してはなりません。

おしまい

さてさて、 今月はこのへんで。 質問、 提案、 アイデア、 または、 コメントがあれば、 どうかためらうことなく、 私 [1] にを知らせてください。 このアドレスへは、 特記すべきプロジェクトの提案も歓迎です。