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

またGeorgのBrave GNU Worldへようこそ。 今月は哲学的背景を中心に、 商業用のFree Softwareについての疑問に焦点を当てていこうと思います。

ですがその前に、 新しいプロジェクトを紹介しましょう。

TuxFamily.org

Julien Ducrosとボランティアのグループは、 "TuxFamily.org" [5] プロジェクトを始めました。 このもとになったのは、 アメリカのSourceForge [6] プロジェクトで、 これは開発や公開の中核的基盤 (ウェブ・サーバー、 FTPサーバー、 CVSサーバーなどなど) をプロジェクトに提供するものです。

ヨーロッパやアフリカ大陸のコミュニティーもそういうサービスが必要、 というのがJulien Docrusの信ずるところです。 フランスのTuxFamilyプロジェクトの提供するのは、 まさにこれです。

TuxFamily自身、 Free Softwareへの強い指向が明白です。 ホスティング用のソフトウェア (vhffs) は、 GNU General Public Licenseの下で公開されています。 また、 TuxFamilyはFree Softwareとみなせるプロジェクトだけを対象にしています。

新たにホームをさがしているプロジェクトがあれば、 参加を検討してみてはどうでしょう。

Chrooted SSH CVS-Server HOWTO

比較的小さな会社はよくFree Software用にいい仕事をしていることがありますが、 たいていその国の外ではまったく知られていません。 フランスのIdealxもそういった会社のひとつです。

IdealxのCommunityホーム・ページ [7] には、 Free Softwareについての文献やモジュールで、 興味深いものがいろいろあります。 いろいろ標準的な問題が解決されていて、 しかももちろん、 GNU General Public LicenseやGNU Free Documentation Licenseの下で、 すべて入手できるようになっています。

CGIスクリプト内でカレンダーを作ることのできるPythonのモジュールが、 パッケージの中にあります。 新しいバージョンのチェックイン時の動作を自動化する、 XMLでカスタム化のできるCVS通知スクリプトというものや、 ErlangからPythonへの束縛というものもあります。

かなり興味深いとある文献は、 Olivier BergerとOlivier Tharanの書いたHowto [8] で、 非常に安全、 かつ良好に分離されたCVSサーバーの設定について述べたものです。

"Concurrent Version System" (CVS) [9] の利点は、 プログラマならばふつう知っていることですが、 とりわけCVSは大勢の人々にあなどられています。 ですので、 ここで手短に紹介しておきましょう。

ソフトウェアがふつうソース・コードのかたちで書かれている、 ということは、 皆さんごぞんじのとおりです。 開発の過程で、 ソース・コードは、 単数または複数の作者により、 改良されていきます。 このとき、 複数の作者の間での調整という問題がおきます。 なぜなら、 各開発者は、 自分個人のマシンにたいして変更をくわえるからです。 つまり、 ソース・コードは、 往々にして同時に違う場所で変化するわけです。

この問題を解くため、 ほかの「バージョン管理システム」同様、 CVSには、 いわゆる「リポジトリー」という集中的蓄積点があります。 各開発者は、 リポジトリーと直接通信し、 ほかの作者による変更をとりこみ、 自分の変更をくわえます。 もちろん、 2人の作者が同じ部分を (同時に) 変更することもありえますが、 その際、 このような矛盾を回避、 解決する各種の方法が重要なのではありません。

重要なのは、 CVSが最新版だけを格納するものではなく、 全部の変更を保存する、 ということです。 これで後々、 開発過程を一歩一歩たどることができます。 また、 プロジェクトを分岐させるため、 昔のバージョンへ戻したり、 後で併合することも視野に入れ、 別々な開発過程を並行にはしらせたりすることができます。

これはみな開発者だけに関係する話ではありません。 ソース・コードはたいてい単なるASCIIファイルである事実を思い出せば、 どんな種類のデータ (テキストのみの形式で表現できる場合は特にですが) にたいしても使えることは明らかです。

ウェブ・サイト、 文書、 電子メールの保管などなどは、 完全に、 CVSの使える分野です。

CVSサーバーの頭痛のタネは、 アクセス権の問題です。 これについては、 いろいろなセキュリティーの高さをもつ解決策が、 いくつもあります。 CVSサーバー上のアカウントはそのシステム上のアカウントがたいてい必要で、 認証方法によっては、 パスワードが平文 (ひらぶん) で流れるので、 ほかの人にも簡単に読めてしまいます。

それはSSHを使ったりして回避するとしても、 CVS利用者全員にシステムへの全面的アクセスをわたすのは普通、 望ましくありません。

前述のHowto [8] は、 特定のリポジトリーへの必要なアクセス権だけを利用者にあたえつつ、 複数のCVSサーバーを1台のサーバー上に構築、 設定する方法をうまく解説しています。 中級の利用者には、 前述したCVSの利点を活用すべく、 安全なCVSサーバーのインストールが、 自分のマシンでできるようになることでしょう。

AutoGen

新しいGNU-Projectの紹介は、 いつも喜ばしいことです。 今月ご紹介したいのは、 Bruce KorbによるAutoGen [10] で、 これは、 膨大な反復テキストやプログラムを作ったり、 管理したりするのが、 非常に快適になるよう、 設計されています。

このての古典的な例は、 コマンド行での繰返し評価です。 テキストは最悪の場合、 ある値を別な関数が見付けられるような場所に入れる必要上、 各オプションについてカット・アンド・ペーストで繰り返すはめになります。 これは非常に標準的な問題ですので、 これ専用の"AutoOpts"というテンプレートが、 AutoGenにはあります。

AutoGenは、 伝統的なUnixのマクロ処理系であるm4 [11] と、 ある面で似ています。 ですが、 新しいパラメーターを関数に追加する簡単な方法など、 m4より優れた点がたくさんあります。 またAutoGenは、 入れ子の値集合をサポートしています。 それゆえ、 Bruce Korbの次に活動的なAutoGenの開発者、 Gary V. Vaughanは、 autoconfでm4の代わりにAutoGenを使ってもらえれば、 と考えています。

Bruceによれば、 AutoGenの特別な強みの1つは、 テンプレートと定義の分割です。 というのも、 これによりテンプレートがより柔軟になるからです。 またデータは全部、 位置でなく名前で参照されますから、 ファイルの再構成や再整列が可能になります。 それをふまえると、 ファイルを古くしたままにして、 古い定義を時代遅れにすることができるので、 互換性が向上します。 またもちろんですが、 定義を入れ子にすることもできます。

置換位置を示す変数と見出し語を使うと、 どの部分を消したり、 繰り返したりするかを定義できます。 またAutoGenには、 Cプリプロセッサよりも良好な出力制御方法があります。

AutoGenの短所についてきかれたとき、 Bruce Korbは、 これが無名なこと、 象形文字のように見えるテンプレートが安直に書けてしまうことを話してくれました。 定義の静的評価がAutoGenの現在最大の限界ですが、 将来の版では動的にすることを計画しています。

それを除けば、 AutoGenはほとんど完成しており、 移植性の向上を中心としたフィードバックが必要になっています。 今のところ、 CygWinのインストールされたWindows NT同様、 GNU/Linux、 BSD、 SVR4-5、 HPUX、 SCo OpenServer、 Solarisで、 動作が確認されています。

AutoGen自体は、 GNU General Public Licenseの下で許諾されていますが、 付録の一部はLGPL、 FreeBSDの許諾や、 パブリック・ドメーンの下にあります。

Free Softwareと商業主義

「産業界とGPL」 ("Industry and GPL") についてたずねる、 Tommy Scheunemannをはじめとしたメールが、 私に届きました。 Free Softwareで金をもうけるのは合法かどうかという、 物議をかもす論議が、 FSF Europeの議論用メーリング・リストで起きていたのです。 この分野で未決の問題がまだあることに、 私は気付かされました。

産業界との相互作用や商業についての問題の理解の前に、 Free Softwareの定義を見てみなければなりません。 まず第1段階はいつも、 Free Softwareの"free"が「無料」 ("gratis") なのではなく、 むしろ「自由」 ("freedom") である、 ということのへ理解です。

しかしこれは何の自由を指しているのでしょう? もっとも正確なFree Softwareの定義は、 Free Software Foundationの4つの自由 [12] です。 "Debian Free Software Guidelines" [13] はこれから派生したものであり、 "Open Source Definition" [14] の基礎になったものです。 技術的にはこれらすべての定義は、 同じ許諾を説明するために書かれたものです。 4つの自由は最も簡潔な定義ですので、 これについてだけ話をしようと思います。

第1は、 どんな目的にたいしてもプログラムを使うことのできる自由です。 どんな方法であれ使用を制限することは、 すなわちフリー・ソフトウェアとしての資格がないことを意味します。

第2は、 プログラムがどうやって動作するのかを学ぶために、 それを調べることのできる自由です。 ソース・コードへのアクセスを許すことは、 この前提となります。

第3は、 複製を作って配る自由で、 第4の自由は、 第2、 第3の自由を合わせたものです。 つまり、 他人の利益のために改良したものを配れる自由がある、 ということです。 第2の自由のように、 これはソース・コードへのアクセスが必須です。

あることをする自由をもつことは、 それをしない自由をも含む、 ということ (これは特に第2、 第3、 第4の自由に当てはまります) を知ることが、 重要です。 プログラムの複製や変更をする義務はありませんし、 配る義務もありません。 実際、 変更の公開を強制するという要件が、 "Apple Public Source License"をFree Software許諾たらしめないのです。

とあるソフトウェアがFree Softwareかどうか、 という問題は、 その許諾によって決まります。 Free Softwareの諸許諾 [15] のうち、 GNU General Public Licenseは、 最もひろく使われています。 GPLの変種であるGNU Lesser General Public Licenseを除くと、 事実上最も重要なのは、 FreeBSDの許諾です。

それでは商業主義はどうでしょう? Free Softwareは、 かなり意図的に商業用の利用と、 非商業用の利用の区別を避けています。 商業用目的にたいする制限は、 まず第1の自由に反してしまいます。 つまりFree Softwareは、 必ず商業用でもあるのです。 配るという要件がない、 という事実と合わせると、 Free Softwareを売ることさえできるということが即、 明らかになります。

Free Softwareは商業用でありえますが、 必ずしもそうである必要はない、 ということも明らかでしょう。

現在、 産業界で支配的なソフトウェアの商業モデルは、 これら自由の制限で作為的に価格をつり上げられるような、 独占的なものです。 計上純益を短期的に上げるため、 自由のはく奪に会社がうかされてしまうこともありえます。

これには2種類のものがあります。 FreeBSD許諾をはじめとする諸許諾は、 公衆の興味よりも自分の興味を優先させる人はいない、 という仮定に基づいています。 これらは意図的に独占的な再許諾を認めています。

GNUの許諾には、 これを避ける「独占化防護」があります。 もしあなたが他人の労作を基に成功しようとするならば、 独占的な許諾の下で成果をリリースすることはできません。

この場合、 独占的スキームに戻れる唯一の仕組みは、 元のプログラムから技術的に分離したモジュールを書くことで、 これには余計な作業が発生するため、 常に可能とはかぎりません。

どちらにせよ、 独占化された最終製品はふつう、 自分の自由をあきらめるよう確信させることを目標とした「付加価値」ソフトウェア、 として売られることになります。 商業用でも非商業用でも、 これは起こりえます。

GPLの提供する防護にもかかわらず、 独占的モデルへの復帰を防ぐのは、 最終的には、 利用者の意識だけです。

要約: 非商業用のFree Softwareがあるのと同様、 疑いなく、 商業用のFree Softwareというものがあります。 これは選択の問題です。 この問題でとり乱すより、 我々としてはむしろ、 運動全体の基礎である自由を見失うことのないようにしたいものです。

本日ここまで

さて、 今日はこのへんで。 商業用のFree Softwareの問題についてはもう明らかになり、 なんとか理解のできる説明がついたのではないかな、 と期待しています。

いつものように、 コメント、 疑問、 お考え、 うまい思い付きや、 プロジェクトの紹介は、 いつものアドレス [1] へ。