![[image of the Head of a GNU]](/graphics/gnu-head-sm.jpg)
(jpeg 7k)
(jpeg 21k)
no gifs due to patent problems
Translated by おくじ
みなさんこんにちは、 Brave GNU Worldの第4号を公開できて嬉しく思ってます。 今月のコラムは第1号の後に受け取ったある反響を取り上げるところから始めましょう。
営利目的のGNUソフトウェア？
LGPLの改名に関する私の記事の後、 LGPLよりもGPLの方が良い、 という私の好みに対して不平を書いている電子メールをいくつか貰いました。 例としてMarcel Ruffの電子メールを引用させてください (注: ここでは日本語に翻訳していますが、原文はドイツ語版にあります): 「営利目的とフリーなソフトウェアを混在させるのに最も重要なものなので、 あらゆるフリーソフトウェアはLGPLに基いて公開されるべきだと思います。」 この論拠は一見理にかなっているようですが、誤った仮定に基いています - 詳しく説明させてください。
厳密にはLGPLとGPLはどう違うのでしょうか。 GNU General Public Licenseは各ユーザに対し、その人が望む限りいくらでも、 ソフトウェアを使用したり、改変したり、複製する権利を与えています。 この権利を守るためには、 GPLによってライセンスされたコードは決して独占的なプログラムの中で使われてはいけません。 これはLGPLでは当てはまりません。 そのコードのライセンスが決して変えられないとしても、 それは明示的に (独占的な場合でさえ) あらゆるプログラムでの利用を許容しているのです。 独占的であるということは、 ある個人や会社が、 誰がソフトウェアのある特定の部分を保有したり利用しても構わないのかを決められる、 唯一の権威となることを要求しているのです。 しかし、人々や会社がそこからお金を儲けるようなソフトウェアである、 という営利目的のソフトウェアについて、我々は今話しています。 このことは営利目的のソフトウェアは独占的であることが必要かどうか、 という主要な問題を提起します。 GNUプロジェクトは長期的にはこれは当てはまらないし、 GNU/Linuxの成功がそのことを証明していると言っています。
ソフトウェアをフリーソフトウェアとして公開する理由はたくさんあり、 これを経営者に説明するという試みが何年もの間、 多くの人々によって行われ続けてきました。 こうした試みの中で、最も顕著な例は「オープンソース」の運動です。
しかし、この節はフリーソフトウェアの利点に関するものではなく、 GPLやLGPLが好ましいのかどうかという質問に関するものです。 あるソフトウェアに対しては明らかに、 LGPLに基いて公開される方がより意味があります。 これは場合毎に決めれられるべきですが。 一般的に、GNUプロジェクトはGPLがより好ましいはずだと考えています。 この理由の一つは、 営利目的のフリーソフトウェアに競争におけるもう一つの刃を与えることです。 フリーソフトウェアの利点と結び付いたこのもう一つの刃は、 ちょうど小さな会社が成功するのに必要なものかもしれません。
これが今月の理屈です。 正しい組織を選ぶことが決定的になり得るので、 次の話題はきっと営利目的のソフトウェアを作っている人々に興味を呼び起こすでしょう。 たとえたった一人の開発者だけのプロジェクトであっても、 良い組織は多くの作業時間を節約できるでしょうし、 複数の開発者からなる分散したプロジェクトでは、 それはほとんど生命を救うほどになり得ます。 この理由から私は紹介します、
Aegis
Peter MillerによるAegis [4] はほとんど全てのUNIXプラットホーム上で動作するプロジェクトで、 GNU Autoconfを基盤としているので、インストールは素早く簡単です。 (訳注: CVSのような) 関連したプロジェクトと同様に、 Aegis は一つの中心的なアーカイブ、 いわゆるリポジトリを持ちます。 リポジトリはプロジェクトの開始以降の全てのバージョンを含んでいるので、 古いバージョンに戻ったり、 同時に二つの異なるブランチでプロジェクトを開発することが簡単に出来ます。
リポジトリは絶対に直接は変更されません。 開発者は作業用にローカルなソース・ツリーを作成します。 ソース・コードへの変更は、作業過程中に生じるあらゆる変更が集められる、 「変更集合」に置かれます。 Aegisは現在のバージョンの動作を保証し、 可能な限りバグのない状態に保つように設計されているので、 各変更集合は少なくとも一つのテストを含むようになっています。 これらのテストは変更集合がリポジトリに入れられるときに、 リポジトリの一部となります。 こうして新しいコードが「歴史に残る」テストを走らせることで、 古いルーチンを壊してしまわないことを確実にできます。 また、リポジトリ中のソース・ファイルの依存関係を追跡することで、 Aegisは新しい変更集合でも意味があるようなテスト・プログラムを提案できます。 含まれるテストと構築が上手く行く場合にだけ、変更集合が認められます。 最終的にリポジトリの一部となるためには、見直して、承認する必要があります。
これは少しややこしく思えるかもしれませんが、確実な利点を持っています。 他のシステムでは、 開発者があるファイルに何か変更しようと考えていると知らせるとすぐに、 そのシステムがそのファイルをロックする、 ということがときどき大きな問題となります。 これはよく使われるファイルではボトルネックとなりますが、 変更集合によって避けられています。 Aegisはまた、 あまり遅らせずに開発過程における作業の品質をある程度保証してくれます。 変更の承認は、例えば、各開発者や、開発者の中心グループ、外部団体、あるいは、 プロジェクトの指導者が行ってよく、 そのプロジェクトの必要性に適合するものが一番なのです。 どの場合にも変更を認可する誰かがいることになります。 このシステムはまた、 開発過程がそのままテスト済みで動作するバージョンを生み出せるようにします。 現在のバージョンをいつでも顧客に提供できるという理由で、 これは会社にとって非常に価値があります。
私が個人的に大変気に入っているのは、 ローカルなバージョンがリポジトリから切り離されないで良いという事実です。 Aegisはプッシュ＆プル更新をサポートしているので、 リポジトリの変更が作業ディレクトリへ自動的に送られるようにできます。
あまり深く踏み込まずに、 Aegisは複数の分散したリポジトリをサポートし、 電子メールやHTTPで変更集合を転送でき、 安全性の側面に注意して書かれている、とだけ言っておきます。
では、 「普通の」ユーザでも興味があるはずの二つのプロジェクトについて話します。 GNU Enscriptの管理者、 Markku Rossiは彼のプロジェクトの現状と計画をちょっと書いてほしい、 と私に依頼しました。
GNU Enscript
GNU EnscriptはアスキーをポストスクリプトやANSI (端末制御文字列)、 HTML、Overstrike (マニュアルページのnroff制御文字列)、 RTFに変換するためのプログラムです。
そのコードは現在書き直されているところですが、 GNU Enscriptはバージョン1.5.1以降、言語を認識して強調することができます。 これは多少Emacsの「font lock mode」に似ています。 ファイルの型が認識されて、 テキストのある部分 (例えばCプログラムのコメント) がユーザ定義の方法で強調されます。 その使い方の一つの例として、 ソースコードをウェブ上で公開するのに一度enscriptを走らせてやるだけで良い、 というのが挙げられるでしょう。 もしインストールしたものの中に(必要な)スタイルがないなら、 Markku RossiによるGNU Enscriptのホームページ [5] がおそらく行くべき場所です。 Enscriptは現在42の異なる言語とファイルの型をサポートしています。
新しい強調するためのエンジンは以前のものよりずっと高速で簡単に設定できます。 なぜなら、強調する規則やスタイル、出力言語が、 お互いに干渉しないで変更できるように定義されているからです。 もし見てみたいと関心を寄せているなら、 β版 [6] がすでにこの新しいエンジンを使用しています。
この関係で、もう一つの興味深いプロジェクトを紹介します。
Ted
Ted [7] はMark de Doesによる簡単なリッチテキスト処理プログラムです。 ユーザは電子メールもしくは手紙をWYSIWYG形式でただもくもくとタイプできます。 RTFがそれ自体のファイル書式として用いられているので、 問題なくMicrosoft WordやWordpadと文書を交わすことができます。 TedはNetscapeで利用可能なRTFビューアとして使うこともできます。 プロジェクトの目的は「Windowsの領域」に対して、 最大限の可搬性をもったアプリケーションを簡単に使えるようにすることです。
作者は今ではGTK+の方が好きなのですが、TedはMotifを基盤としています。 けれど画面とプリンターの関係を適切に得たり、 Latin1以外のアルファベットを提供することが現時点で最も重要なことです。 これらの仕事を援助してくれるとありがたいです。
私の考えをもう一つ述べてこの号を締めくくらせてください。 最近ウェブページを準備しているとき、 ウェブページで使える 「私たちはGNUを動作させています」 といったアイコンを見つけることができませんでした。 そのことをよく考えてみると、 そのようなアイコンは一度も見たことがない、ということに気が付きました。 どうか遠慮しないで、コラムに関する質問、 批判や意見はもちろんデザインの意見も電子メールで送って下さい [1]。
| 情報 |
|
[1] 意見、批判や質問は Brave GNU World <column@gnu.org> まで
|
Return to GNU's home page.
Please send FSF & GNU inquiries & questions to gnu@gnu.org. There are also other ways to contact the FSF.
Please send comments on the Brave GNU World column to column@gnu.org, send comments on these web pages to webmasters@www.gnu.org, send other questions to gnu@gnu.org.
Copyright (C) 1999 Georg C. F. Greve, German version published in the Linux-Magazin
Permission is granted to make and distribute verbatim copies of this transcript as long as the copyright and this permission notice appear.
Updated: Last modified: Mon Jul 5 01:25:27 JST 1999