IBM、Red hatとフリーソフトウェア： ある老犬の見解

著作権 2023 by Jon “maddog” Hall
クリエイティブ・コモンズ BY-SA-ND ライセンス
写真: © Santiago Ferrita Litowtschenko

Red hatが最近発表したソフトウェアの販売条件の変更について、何人かの人が意見を述べている。 今回この記事で述べていることは、「長い間この業界にいて」、「多くの出来事の渦中にいて」、「様々な立場に立ってきた」、そんな人物の考えである。

かなり昔にさかのぼるため、このブログはとても長い記事になります。 私のことをを知っている人は遅かれ早かれ、私がとても多くのことを語ることになることに気づくでしょうが辛抱してください。 このブログの一番下までスキップしてすべての理由を知らずに「すべてを結びつける」のセクションを読むこともできます。

古代の歴史を理解する

私がプログラミングを始めたのは1969年だ。 パンチカードにプログラムを書き、大学の協力教育生としてFORTRANを使った。本を読んで練習しながらプログラミングを学んだ。 最初のコンピュータはIBM 1130で、それがIBMやいくつかのコンピュータ会社について触れた最初のきっかけだった。

大学に戻ると、DECの顧客が書いたソフトウェアのライブラリがあり、コピー代（紙テープの場合もあれば磁気テープの場合もある）で配布しているDECUS（Digital Equipment User’s Society）に参加した。

当時は「プロのプログラマー」なんてほとんどいなかった。 実際、私はプログラミングを教えていた教授に、「プロのプログラマー」として生計を立てることは決してできないだろうと言われた。 当時コードを書くとしたら、物理学者か化学者か電気技師か大学教授で、自分の仕事や研究のためにコードを必要としていた。

彼らは自分の必要を満たしたらDECUSにプログラムを提供し、配布していた。

実際、ソフトウェアを販売するのは難しかっただけでなく、ソフトウェアに著作権を設定することも、特許を申請することもできなかった。 コードを保護する方法は、「営業秘密」と「契約法」だった。 つまり、ユーザー一人一人と契約を結ぶか、バイナリ形式でソフトウェアを配布しなければならなかったのです。 当時、ソフトウェアをバイナリ形式で配布することはとても困難でした。というのも、1つのアーキテクチャのマシンはそれほど多くなく、オペレーティングシステムがあったとしても（多くはありませんでしたが）、任意のアーキテクチャ上で動作するオペレーティングシステムは数多く存在したからです。

どのアーキテクチャのコンピューターも数が少なく、オペレーティングシステムがあったとしても、各アーキテクチャごとに多くのオペレーティングシステムがあった（DEC PDP-11には11以上のオペレーティングシステムがあった）ため、多くの企業はソフトウェアをソースコードの形で配布したり、エンジニアを派遣してインストールさせ、テストスイートを実行させ、動作することを証明させたりもした。 その後、顧客がソフトウェアのソースコードを受け取った場合、供給元が倒産した場合に備えてエスクローに預けられることが多かった。

私は、1975年に効率的なCOBOLコンパイラの契約を交渉したことを覚えている。ライセンス料は、IBMのメインフレーム1台で動作し、一度に1つのコンパイルに使用できるコンパイラのコピー1部に対して10万米ドルだった。 彼らのエンジニアがコンパイラーをインストールし、動作させ、受け入れテストを実行するのに2、3日かかった。 そう、私の会社の弁護士はソースコード・テープを預かったままにしておいたのだ。

他の多くのユーザーやプログラマーは、自分のコードを「パブリック・ドメイン」で配布していた。

1980年代初頭、バイナリとソースコードに強力な著作権法が適用され、すべてが変わった。 これは、ゲームに使われるROMや、（後に）インテルベースのCP/MやMS DOSシステム用に配布されるソフトウェアのために必要だった。

ソフトウェアに著作権が発生すると、ソフトウェア開発者は、そのソフトウェアを使用する際の権利を他のユーザーに伝えるためのライセンスを必要とした。

エンドユーザーにとっては、これが悪名高いEULA（誰も読まない「エンドユーザーライセンス契約書」）であり、開発者にとってはソースコード契約書であった。

Unix™の起源と台頭

Unixは1969年にベル研究所によって開発された。 何年もの間、ベル研究所とウェスタン・エレクトリック社の内部でのみ配布されていたが、やがてカリフォルニア大学バークレー校、マサチューセッツ工科大学（MIT）、スタンフォード大学（Stanford）、カリフォルニア大学ロサンゼルス校（CMU）などの研究大学にも配布され、教授や学生が研究したり「遊んだり」できるようになった。 これらの大学は最終的に、極めて少額の資金で全学的なソースコードライセンスを与えられ、コードは大学間で自由に配布されるようになった。

その中でもユニークだったのがカリフォルニア大学バークレー校だ。 カリフォルニア州バークレーの高いレッドウッドの木々に囲まれ、サンフランシスコののんびりとしたコスモポリタンライフに近い、素晴らしい気候に恵まれたこの大学は、ケン・トンプソンがUNIXの磁気テープを取り出し、それを使って熱心な若い学生たちにオペレーティングシステムの設計を教えるために選んだ大学のひとつだった。 最終的に、学生とスタッフはケンと協力して、AT&TのUNIXシステムよりも優れていると言えるかもしれないバージョンのUNIXを作ることができた。 AT&Tがまだスワッピング・メモリ・モデルだったのに対し、BSD Unixは需要のあるページングされた仮想メモリを持っていた。 最終的にBSD UnixにはネイティブのTCP/IPが搭載されたが、AT&T UNIXにはuucpしかなかった。 BSD Unixには豊富なユーティリティ・セットがあったが、AT&TはSystem IVからSystem Vへの移行でユーティリティ・ベースを削ぎ落としていた。

これが、サン・マイクロシステムズ（SunOS）、DEC（Ultrix）、HP（HP/UX）を含む多くの初期のUnix企業が、バイナリのみの製品にBSDベースを採用した理由である。

もうひとつ、歴史的に興味深いのはジョン・ライオンズである。 ジョンはオーストラリアのニューサウスウェールズ大学の教授で、ベル研究所で起きていることに非常に興味を持っていた。

ジョンは1978年にサバティカル（研究休暇）を取り、ベル研究所を訪れました。 ケン・トンプソン、デニス・リッチー、ダグ・マキロイらとともにUnixのバージョン6に関する本を書き、Unixカーネルのすべてのソースコードと、そのコードが選ばれた理由とその機能についての解説を書きました。 残念なことに、1979年にUnixのライセンスが変更され、ジョンは20年以上も本を出版することができなかった。

AT&Tにとって残念なことに、ジョンは自分の本の草稿をコピーし、コメントや質問、校閲のために生徒に渡していた。 ジョンの本が出版中止になると、学生たちはジョンの本のコピーをとり、またコピーをとり、またコピーをとり、そのたびに前の世代よりわずかに軽く、読みにくくなっていった。

何年もの間、Unixプログラマーたちは、自分が持っているジョンの本の世代によって、Unixコミュニティにおける自分の「年齢」を測っていた。 私は3世代目のコピー本を持っていることを誇りに思っている。

ジョンの努力は、Unixカーネルの要素がどのように機能するのか、そしてシステムを開発する上でのケンとデニスの思考パターンについて、何千人ものプログラマを教育しました。

(最終的にジョンの本は出版されました※1。 もし望むなら、Linux上で動くSIMHというシミュレータ上でバージョン6 Unix ※2のコピーを動かすことができる。 Unixの初期バージョンがどのようなものであったかを見ることができます。)

やがて一部の営利企業も、非常に高価で制限の多い契約法のもとで、AT&Tからソースコード・ライセンスを取得するようになった。 この高価なライセンスは、研究大学とはみなされない小規模な学校でも使われていた。 ハートフォード州立工科大学もそのような学校のひとつでしたから、私は知っています。1977年から1980年の間、私は学生たちのためにUnixを手に入れることができませんでした。 天文学的な額のライセンス料を払わなければならなかっただけでなく、ソースコードを載せるマシンのシリアル番号をベル研究所に伝えなければならなかった。 そのマシンが壊れたら、ベル研究所に電話して、ソースコードを移すマシンのシリアル番号を伝えなければならなかった。

最終的には、サン・マイクロシステムズのように、AT&Tベル研究所と再配布契約を交渉し、AT&Tベル研究所から直接ソースコードを入手するよりもはるかに制約が少なく、はるかに安価なライセンス料で、Unixライクなシステムのバイナリのみのコピーを販売する企業も出てきた。

AT&Tから派生したソースコードを顧客に配布するには、顧客がAT&Tのソースコードライセンスを持っている必要があり、それはまだ非常に高価で、入手が非常に困難だったからです。

指摘しておきたいのは、これらの企業はAT&Tのコードをただパクって再コンパイルして配布していたわけではないということだ。 彼らは多くのエンジニアを雇い、AT&Tのコードに多くの変更を加え、中にはカリフォルニア大学バークレー校のコードを自社製品の基礎として使用することを決め、さらに自社のエンジニアを使ってコードを変更していった。 多くの場合、これはカーネルの項目を変更するだけでなく、アーキテクチャに合わせてコンパイラを変更したり、その他の重要なエンジニアリング作業を意味した。

そして1980年代初頭、MITの学生であったリチャード・M・ストールマン（RMS）は、バイナリのみのUnixのディストリビューションを受け取った。 MITはAT&Tのソースコードのサイトワイドライセンスを持っていましたが、そのディストリビューションを彼らのハードウェアのために作った会社は、ソースを簡単には売りませんでした。

そこでRMSは、自由なオペレーティング・システムを配布する目的で、GNU（「GNUはUnixではない」）プロジェクトを開始しました。GNUは、バイナリを配布する人々が、そのバイナリを受け取った人々がソースを受け取り、バグを修正したり必要な修正を加えることができるようにすることを要求するものです。

RMSにはこれを手伝ってくれるスタッフはいなかったし、ハードウェアやテストスタッフに使う数百万ドルもなかった。 そこで、彼はGNUプロジェクトと(後の)フリーソフトウェアファウンデーションの周りに人々のコミュニティを作ったのです。 この記事の残りの部分では、このコミュニティをGNUコミュニティ(略して “GNU”)と呼ぶことにします。

RMSは興味深い計画を思いつきました。それは、多種多様なオペレーティング・システム上でそれを使う人々にとって有用なソフトウェアを作るというものでした。

最初のソフトウェアはemacsで、強力なテキストエディタであり、オペレーティングシステムを越えて動作するものでした。プログラマたちはemacsを使ううちに、作業するすべてのシステムで同じサブコマンドとキーストロークを使うことの価値に気づきました。

それからGNUはコンパイラ・スイートに取り組み、それからユーティリティに取り組んだ。 すべてのプロジェクトはプログラマにとって有用であり、プログラマは他のコードの断片を彼らにとって有用なものにしました。

GNUが取り組まなかったものは何でしょう? オフィス・パッケージです。 オフィス文書に多くの時間を費やすプログラマはほとんどいませんでした。

その一方で、もう一つのニーズがありました。 コンピュータの研究をしている大学では、配布する必要のあるコードを生成していました。

MITとカリフォルニア大学バークレー校は、売りたくないコードを生成していた。 理想を言えば、他の人々が研究に使えるように、それを提供したかったのだ。 しかし、そのソフトウェアは著作権で保護されているため、これらの大学には、著作権で保護されたコードで何ができるかを示すライセンスが必要だった。 さらに重要なことは、大学の立場からすると、ライセンスはソフトウェアのユーザーに対して、有用性の保証はなく、サポートを期待してはいけないし、ソフトウェアの使用による損害について大学が責任を負うこともない、ということも伝えていたことだ。

私たちは当時、「ライセンスは、そのソフトウェアを入れたシステムが火事になったり炎上したりしないことさえ保証していない」と冗談を言った。 これは皮肉で言ったのですが、実際に考慮すべきことでした。

これらのライセンス（およびそれ以上）は、最終的にオープンソースの「寛容な」ライセンスとして知られるようになった。 開発者は、バイナリのみのディストリビューションを自由に作成し、エンドユーザにバイナリを渡すことができました。

GPLの「制限的な」ライセンスだけが、開発者に、バイナリを受け取ったエンドユーザが自分の変更を見ることができるようにすることを強制したのです。

もともとは、異なるライセンスにまつわる多くの混乱がありました。

ある人々は、GNUコンパイラを使って作成されたバイナリもGPLの及ぶところだと考えていました。たとえ、ライセンスを生成したソースがいかなるライセンスも完全に自由であったとしてもです(すなわち、ユーザ自身によって作成されたものです)。

GPLでライセンスされたコードを売ることはできないと考える人もいました。 RMSはそれに反論しましたが、GPLでライセンスされたコードは、一般的に、単にそのコードを多額のお金で売ることは、多くの理由から「困難」であることを認めました。

しかし、多くの人々がコードを売っていました。 Walnut Creek社(Bob Bruce)やPrime Time Freeware for Unix社(Richard Morin)のような会社は、CD-ROMや(後に)DVDにまとめられたコードの大要をお金で売っていました。 これらの大要に含まれるプログラムは個々の「オープンソース」ライセンスでカバーされていましたが、CDやDVD全体には独自の著作権とライセンスがあったかもしれません。 ISO全体をコピーして自分のCDやDVDを作成し、それを販売することが「合法」であったとしても、おそらくオリジナルの作成者は転売者に対して厳しい考えを持ったかもしれない。

この間、デジタル・イクイップメント・コーポレーション、HP、サン、IBMなどのシステム・ベンダーは、AT&T System Vまたはバークレー・ソフトウェア・ディストリビューションの一部（多くの場合、BSD Unix 4.xから）をベースにしたUnixライクなオペレーティング・システムを開発していました。 これらの企業はそれぞれ、膨大な数のUnixソフトウェアエンジニア、文書作成担当者、品質保証担当者、プロダクトマネージャーなどを雇っていました。 彼らは巨大なビルを持ち、多くの弁護士を雇い、ディストリビューションを大金で売りました。 その多くは、ハードウェアにソフトウェアをバンドルして提供する「システム会社」だった。 サンタクルズ・オペレーションズ（SCO）のように、ソフトウェア・ディストリビューションだけを作ったところもある。

もともとこれらの企業は、オペレーティングシステムのないハードウェアはかなり使い物にならないと考え、独自のオペレーティングシステムを製造し、ハードウェアと一緒に販売していたが、後にハードウェアの販売とオペレーティングシステムの販売を分離し、顧客の問題を解決するために、より柔軟なジョブミックスを顧客に提供するようになった。

しかし、これは通常、ハードウェアと個別のオペレーティング・システムの両方にコストがかかることを意味する。 また、社外や社内の競合他社との差別化が難しかった。 こうした争いの中で最も有名なのは、DECのVMSオペレーティング・システムとさまざまなUnix製品……さらにはPDP-11対VAXだったでしょう。

DECは、Digital Unixを製造するために、周辺エンジニアリングや製品管理とともに、Digital Unixグループに500人以上の人員（ほとんどがエンジニアとドキュメンテーション担当者）を抱えていました。

大雑把に言えば、各社は自社のシステムを売るために年間10億〜20億ドル近くを費やし、自社のUnixライクなシステムがベストであることを示すために、高度なコンピューターサイエンスの機能に投資していた。

マイクロソフトの台頭とユニックスの死

一方、ワシントン州レッドモンドのソフトウェア会社は、HP、IBM、DECのいずれから購入してもPC上で動作する同じオペレーティング・システムを製造・販売していた。 サーバーの台数はデスクトップ・システムの台数より明らかに少なかったが、サーバー用オペレーティング・システムのライセンス価格は3万ドル以上になることもあった。

Unix市場は岩と岩の間で立ち往生していた。 ユニークなUnixライク・システムを開発し続け、他のUnixライク・ベンダーと競争するだけでなく、Windows NTとも戦うには、あまりにもコストがかかりすぎていた。 長年Unixのサブシステムやコマンドに関する書籍を出版してきたオライリー・パブリッシャーズでさえ、Windows NTに関する書籍の出版に切り替えつつあった。

Linuxの台頭

そしてLinuxカーネル・プロジェクトが登場した。 カーネル・プロジェクトは、6つの主要な検討事項によって可能になった：

• 大量のソフトウェアがGNUから入手できた。MIT、BSD、独立ソフトウェアプロジェクト
• オペレーティング・システムの内部に関する大量の情報がインターネット上で入手可能だった。
• 高速インターネットは、産業界や学界だけでなく、一般家庭にも普及しつつあった。
• デマンド・ページ型の仮想メモリが可能な低価格で強力なプロセッサが市場に出回っていただけでなく、より強力なシステムに置き換えられつつあった。
• 多くの幸運とチャンス
• カリスマ性にあふれた、独特の頑固なプロジェクトリーダーだった。

1991年後半に始まった「カーネル・プロジェクト」は、1993年後半には「ソフトランディング・システムズ」、「ユグドラシル」、「Debian」、「スラックウェア」、「Red hat」など、多くのディストリビューション・クリエイターを生み出し、隆盛を極めた。

これらの中には、金儲けの夢と希望を抱いて「商用」ディストリビューションとして始められたものもあれば、「コミュニティ」のために「コミュニティ・プロジェクト」として始められたものもある。

同時に、バークレイ・ソフトウェア・ディストリビューションをベースとしたディストリビューションは、長い間続いていた「Unix Systems Labs Vs BSDi」スイートによって、さまざまなBSDディストリビューションを開始するのに使われる「BSDlite」の作成がまだ妨げられていました。

Linux(あるいはGNU/Linuxと呼ばれるもの)は、多くのディストリビューションと報道(雑誌や論文を含む)に押され、離陸し始めた。

Linuxはかわいいペンギンだった

以下は、Linux対BSDの人気についての私自身の考えであることを認めますが、私の観点からすると、それは多くの要因が組み合わさったものでした。

前にも言ったように、1993年末の時点では、BSDはまだ訴訟によって押さえつけられていたが、Linuxの会社は前進しており、このためBSDの会社（当時は1つか2つしかなかった）はプレスに対して新しいことを言うことができなかった。

Linuxディストリビューションが前進したもう一つの理由は、モデルの違いだった。 GPLは、ソースコードをバイナリと一緒に出すことを強制するというモデルに動的な影響を与えた。 その後、多くの組み込みシステム関係者や、クローズドシステム用の安価なOSを求める企業は、MITライセンスやBSDライセンスのソフトウェアを選ぶかもしれません。

人々は誰の許可も得ることなくディストリビューション・プロジェクトを始めることができ、最終的には何百ものディストリビューションが生まれました。

Xウィンドウ・システムとプロジェクト・アテナ

MITのProject Athenaについても触れておこう。これはもともと、Unixワークステーション用の軽量なクライアント・サーバー環境を作るための研究プロジェクトだった。

このプロジェクトから、ネットワークベースの認証システムであるKerberosとX Window Systemが生まれた。

この頃サン・マイクロシステムズは、NFSをUnix業界の「標準」にすることに成功し、「News」と名付けられたDisplay Postscriptベースのウィンドウ・システムを提唱しようとしていた。

他社は代替案を模索しており、クライアント・サーバーベースのX Window Systemは有望だった。 しかし、Project AthenaのリリースのひとつであるX10.3は、最終的にX11.xにつながるさらなる開発が必要であり、その上にイントリニクスとウィジェット（ボタンボックス、ラジオボックス、スクロールバーなど）があった。

このようなニーズが、MITとプロジェクト・アテナからXコンソーシアムへとXウィンドウ・システムの開発を進める原動力となった。 Xコンソーシアムは、Xがサポートされることで得られるものがあると考える企業や人々からのメンバーシップによって資金を調達していた。 Xコンソーシアムは1993年に設立され、1996年に閉鎖された。

これらの同じ企業の一部は、サン・マイクロシステムズとAT&Tが設立したコンソーシアムであるUnix System Labsに対抗するため、オープン・ソフトウェア・ファウンデーション（OSF）を設立し、UnixシステムのソースコードとAPIの標準を設定することを決定した。 1988年に設立され、1996年にX/オープンと合併してオープン・グループを設立した。 今日、彼らは一連の正式な標準と認証を維持している。

他にも多くのコンソーシアムが結成された。 コモン・デスクトップ・エンバイロメントもそのひとつだ。 そして、コンソーシアムは常に、立ち上がり、十分な資金を得た後、資金を提供する企業が周囲を見回して、「なぜ私がこの費用を負担しなければならないのか、他の企業がすべて負担してくれるだろう」と言い、それらの企業はコンソーシアムの資金が枯渇するのを待つために脱退するように思われた。

少数から多数へ

この時点で、読者の皆さんは、ソフトウェアがもともとそれを必要とする人々によって書かれたものであったのに対し、「プロのプログラマー」は他人のためにコードを書き、彼らにとって価値のあるものにするために資金を必要としたことを見てきた。 プロのプログラマーの “問題 “は、彼らがコードを書くことで生計を立てようとしていることだ。 彼らは食べ物や住居を買い、税金を払わなければならない。 彼らが書いたコードを日常生活で使うかどうかもわからない。

また、オペレーティング・システムは、ほとんどの場合、コンピュータ会社が自社のシステムを使えるようにするために書くか、教育機関が研究プロジェクトとして書くかのどちらかだった。 Linuxが成熟し、標準規格によって、あるベンダーの平均的な「PC」がますます電気的に同じになるにつれて、Linuxの各ディストリビューションを「PC」上で動作させるために必要なエンジニアの数は最小限になっている。

PCは一般的に、他と差別化するのが難しく、「価格」がその緩和要因のひとつとなっている。 オペレーティング・システムにお金を払わなければならないというのは、どの企業もやりたがらないことだし、そのためにお金を払うことを期待しているユーザーもほとんどいない。 だから、ハードウェアベンダーはますますLinuxに目を向けるようになる……自分たちのプラットフォームに載せるためにお金を払う必要のないオペレーティング・システムだ。

最近、私は堤防に亀裂が入っているのを目にするようになった。 FOSSの利用者が増えるにつれて、開発者への要求も増えている。

FOSSの開発者から、コードのブロックに取り組んでいる開発者の数が少なすぎる、時にはいない、という話を聞くことがあります。 もちろん、これはクローズドソースのコードでも起こりうることだが、この人手不足は、品質保証、リリースエンジニアリング、ドキュメンテーション、翻訳など、「セクシー」とはみなされない分野で主に発生する。

資金調達

初期の頃は、利用者が比較的少ないプロジェクトに取り組んでいる人たちが数人いただけだった。 彼らは自分の仕事に熱中していたが、誰も報酬を得ていなかった。

私が初めて何らかのうわさを耳にしたのは、Linuxでお金を稼ぐ方法を見つけた人たちがいたときだった。 開発者たちが、自分たちが書いて無償で提供したコードで金儲けしてほしくないという憤りだった。

私はこの人たちの気持ちを理解したが、もし企業がLinuxでお金を稼ぐことを認めなければ、この運動はゆっくりと、冷たい糖蜜のように進むだろうと主張した。 企業に金儲けを認めれば、Linuxは急速に前進する。 これに同意しない初期の開発者は何人か失ったが、本当に重要な開発者（リーナスを含む）のほとんどは、この論理を理解していた。

この頃、さまざまな企業が「オープンソース」に注目していた。 ネットスケープはブラウザを開発している他の企業と争っていたし、もう一方ではアパッチのようなウェブサーバーがサーバーを提供するために必要だった。

同時にネットスケープは、より多くの開発者を取り込み、ワールドクラスのブラウザーとサーバーを製造するコストを下げようと、コードを「オープンソース」にすることを決めた。

コミュニティ

ソフトウェアの歴史を通じて、「コミュニティ」は存在した。 初期の頃のコミュニティは、ユーザーグループや、ある種のソフトウェアプロジェクトに関わる人々のグループが、共通の目標のために協力することを中心に活動していました。

システム会社（DECUS、IBMのSHARE、Sun MicrosystemsのSun-sitesなど）を中心に形成されることもあり、後に掲示板やニュースグループなどができた。

やがて「コミュニティ」は拡大し、文書作成者や翻訳者、あるいはさまざまな理由でフリーソフトウェアや「オープンソース」を推進する人々まで含まれるようになりました。

しかし、後年には、無償のソフトウェアを使い、自由ソフトウェアを理解しない人々が増えていきました。 海賊版ソフトウェアを使い、コミュニティや開発者にまったく還元しない人々と同じです。

戦慄が走る…。

ソフトウェアに関するその他の問題のひとつに、ライセンスに反してソフトウェアを違法にコピーし使用する「ソフトウェアの違法コピー」という概念がある。

長年にわたり、”FOSSコミュニティ “の一部の人々は、著作権がなければ自分たちのソフトウェアを全くコントロールできないことを認識することなく、知的財産の考え方や著作権の存在さえも軽視してきました。 パブリック・ドメインにあるソフトウェアは、人々がそのソフトウェアを持ち出し、変更を加え、バイナリ・コピーを作成し、顧客が支払うであろう金額で販売することから保護されることはない。 しかし、FOSSの人々の中には、ソフトウェアの違法コピーを容認し、見て見ぬふりをする人もいる。

私はそういう人間ではない。

ソフトウェアの違法コピーと戦うことの価値を認識した日のことを覚えている。 ブラジルで開催されたカンファレンスで、私は聴衆にフリーソフトウェアを使うべきだと言った。 彼らはこう答えた：

“ああ、マドッグさん、うちのソフトは全部無料ですよ！”

当時、ブラジルのデスクトップ・ソフトウェアの90％近くが海賊版であったため、ソフトウェアを無償で入手することが容易になり、フリー・ソフトウェアの有用性の一部（コストの安さ）が失われてしまった。

ビジネス・ソフトウェア・アライアンス ソフトウェア・アライアンス(BSA)という組織がオラクル、マイクロソフト、アドビなどの企業によって設立され、(典型的な)企業や政府機関がライセンスされていない、あるいはライセンスされていないソフトウェアを使用していることを発見し、告発するようになりました。

もしLinuxカーネルを使用しているすべての人々が、Linuxカーネルが動作している各ハードウェアプラットフォームに対して1ドルだけ支払えば、ほとんどのFOSS開発に簡単に資金を提供することができるだろう。

IBMに参入

IBMのダニエル・フライという人が、IBMとの連絡係になってくれた。 ダンはオープンソースのモデルとその理由を理解していた。

他の多くのコンピュータ会社（マイクロソフトを含む）と同様に、IBMにもFOSSを信じて、自分の時間を使ってプロジェクトに取り組んでいる人たちがいました。

ダニエルの焦点のひとつは、Linuxを前進させるためにIBM社内にFOSSユニットを作ることだった。

私は時々テキサス州オースティンに招待され、IBMとミーティングをした（DECの社員としては、とても奇妙な感じがした）。

あるとき私はそこにいて、ダンはLinux International(TM)の社長である私に、「Linuxグループ」の人たちが集まる会合で話をしてほしいと頼んだ。 私は講演をし、会議が続く間、「グリーンルーム」で待機することになった。 しばらくして私はトイレに行きたくなり、トイレを探していると、IBMの人たちの前でスクリーンに映し出された手紙を見た。 当時IBMの社長だったルー・ガースナーからの手紙だった。 その手紙には、事実上、過去においてIBMは、オープンソースにするビジネス上の理由が存在しない限り、クローズドソースの会社であった、と書かれていた。 将来的には、クローズド・ソースであることにビジネス上の理由がない限り、IBMはオープン・ソース企業になるだろう、と手紙は続いた。

DECで働いていた私は、DECのエンジニアが書いたコードの一部を「フリー・ソフトウェア」にすることがいかに難しいかを知っていたからだ。 そのプロセスを経た後、私はDECのエンジニアに「二度とごめんだ」と言われた。 ガースナーのこの発言によって、プロセスは逆転した。 オープンソースにできない理由を証明するのは、今やビジネス担当者次第だったのだ。

ガースナーがそんなことを言ったわけがない」と言う人が大勢いることは分かっている。 彼らは、IBMが「オープン」でなかった例を挙げるだろう。 私は、社長やCEOがそのような決断をすることと、IBMのような大企業がそれを実行することは別のことだと申し上げたい。 IBMのような企業がビジネスを変えるには時間がかかるし、ビジネスプランも必要だ。

IBMが「Linux」に10億ドルを投資するという有名な発表をしたのもこの頃だった。「 オープンソース」とも言っていたかもしれないが、そのタイミングは失念してしまった。 この発表は世界中に衝撃を与えた。これほど大きく、堅苦しいコンピューター会社がこのような発言をするとは……。

この1、2ヵ月後、ダンは私と再会し、私の目をじっと見て、LinuxコミュニティはIBMが「Linuxを乗っ取ろうとしている」と考えるかもしれないのか、Linuxコミュニティに入ってくる「踊る象」を受け入れられるのか、それともIBMがLinuxをつぶしてしまうのではないかと恐れているのか、と尋ねた。

私はダンに、Linuxコミュニティの “重要な人々 “はIBMをパートナーとして見てくれると確信していると言った。

その直後、私はIBMがLinux開発者を雇用し、彼らが以前のようにパートタイムではなく、Linuxのさまざまな部分でフルタイムで働けるようになったことを知った。 アパッチ・ウェブ・サーバーなど、「Linux」のさまざまな部分で働いていて、IBMから給料をもらっている人たちを知っていた。

それから約1年後、IBMは別の声明を発表した。 彼らは10億ドルの投資を回収し、さらに10億ドルを投資しようとしていた。

IBMがラップトップとデスクトップ部門をレノボに売却するという話を聞いたとき、私はニューヨークで開催されたLinuxのイベントに参加していた。 私は、その部門がまだ利益を上げていたとはいえ、IBMを支えるほどの利益を上げていなかったことを知っていました。 そこでIBMはその部門を売却し、プライス・ウォーターハウス・クーパーを買収し（統合部門の規模を倍増させた）、より収益性の高いビジネス・ソリューションの創造に力を注いだ。

もうひとつ、微妙な問題があった。 その発表の前、文字通り1日前に、もしIBMのセールスマンがIBMのハードウェア以外のものを使ってソリューションを作っていたら、地獄が待っていたかもしれない。 しかし、そのリナックスのイベントでは、IBMがコンテストの賞品としてアップルのノートパソコンを2台プレゼントすると発表された。 その賞品プレゼントの意味するところは、私には理解できなかった。 その発表の2日前、もしIBMのマーケティング担当者がIBM以外の製品を賞品として提供していたら、おそらく彼らはクビになっていただろう。

将来、IBMによるビジネス・ソリューションは、IBMのものだけでなく、あらゆるハードウェアとあらゆるソフトウェアを使うかもしれない。 これは驚きだった。 なぜなら、オープンソースによって、IBMのソリューション・プロバイダーはより良いソリューションをより低コストで作ることができるからだ。 単純なことだ。

レノボは諸経費が少なく、ビジネスに集中しているため、こうしたローエンド・システムから簡単に相応の利益を上げることができた。

IBMはもはや「コンピューター会社」ではなかった。 ビジネス・ソリューションの会社だったのだ。

後にIBMは、同じ理由で小型サーバー部門をレノボに売却した。

では、IBMが企業向けソリューションにオープンソース・ソリューションを提供したいと考えたとき、どのディストリビューションを購入するつもりだったのだろうか？ Red hatだ。

そしてSCO

先ほど、マイクロソフトとよく似たUnixのディストリビューションとして「SCO」を挙げた。 SCOは、主にAT&Tのコード（バークレーではなく）をベースにしたディストリビューションを作成し、マイクロソフトがXenixの配布を望まなくなったときには、マイクロソフトからXenixの配布を引き継いだこともあった。

SCOは、美しいモントレー湾を見下ろすサンタクルーズ山脈に位置するサンタクルーズオペレーションズでした。

ラリーとダグの父子チームによって設立された彼らは、素晴らしい開発者たちを抱え、おそらく他のどのベンダーよりも多くのUnixライセンスを配布していました。 彼らは、キャラクタセル端末や後のXタームなどを使って、多くのホテルやレストランなどを動かすサーバーシステムを専門としていました。

特にダグは素晴らしい人だ。 彼がUniforumの役員だったとき、27歳という若さでLinusに “Lifetime Achievement “賞を与えるよう強く勧めたのもDougでした。

私は、共通デスクトップ環境(CDE)を含むいくつかのプロジェクトでダグと一緒に仕事をし、彼の従業員と一緒に働くことを楽しみました。

その後、ダグとラリーはSCOをCaldera Linuxの生みの親であるCaldera Groupに売却した。 ユタ州を拠点とするCanderaのメンバーは、Novellからのスピンオフだった。 私が見たところ、カルデラ社は “FreeDOM “Linuxにはあまり興味がなく、AT&Tのロイヤリティから解放された “安価なUnix “を持つことに興味があったようだ。 彼らは、Linuxディストリビューションにバインドして価値を与えることができるクローズドソースソフトウェアとの取引を絶えず追求していた。

この買収は、”Bad SCO”（カルデラ社が社名を “SCO “に変更したとき）として知られるようになり、”SCO “は、LinuxにはAT&Tのソースコードが含まれており、彼らのライセンス条項に違反しているとして、すぐにLinuxベンダーを訴えるというビジネス戦術をとった。

これはLinuxマーケットプレイスで大騒動を引き起こし、人々はLinuxが流通しなくなるかどうかわからないという状況に陥った。

もちろん、Linuxコミュニティの私たちのほとんどは、これらの挑戦が虚偽であることを知っていた。 SCOの主張のひとつは、AT&Tコードの著作権は自分たちが所有しているというものだった。 私はAT&Tとノベルの契約書を読み（DECは両社のライセンシーだったので、契約書を私たちと共有していた）、これが誤りであることを知っていた。

しかし、まもなく起こるであろう訴訟に誰が資金を提供するのか、誰も知らなかった。

IBMは（ノベル、Red hat、その他数社もそうであったように）訴訟に乗り出し、その後数年間、SCOが法廷に訴えを起こし、”善人 “がそれを打ち負かすという法廷闘争が続いた。 これについてはウィキペディアに詳しい。

最終的に裁判所は、せいぜいSCOがIBM自身と破棄された契約について争っているだけで、Linuxは問題ないと判断した。

しかし、IBMがなければ、Linuxコミュニティは困っていたかもしれない。 そして、”ビッグ・ブルー “がこの戦いに参加したことで、Linuxの多くのベンダーやユーザーは、物事がすべてうまくいくという確信を得た。

Red hatとRHEL

さて、Red hatとその歩みの話に入ろう。

私が初めてRed hatを知ったのは、ボブ・ヤングが、彼の会社のACCで最も多くのCDを生み出しているのは、ノースカロライナ州ローリーにあるこの小さな会社だと気づいた頃だった。

ボブはそこを訪れ、技術的には素晴らしいがビジネスやマーケティングには強くない3人の開発者を見つけた。

ボブはその会社を買収し、会社の方針策定を手伝った。 彼は、より多くのRed hatのコピーを配るために、より大きなサーバーと、より多くのインターネット接続を提唱した。 Linuxはキャットサップであり、私はRed Hat™を “Heinz™”と同じにする」と指摘したのもボブだった。

Red hatはサービスを販売するビジネスモデルを開発し、それで利益を上げるようになった。 最終的にRed hatは、当時最も収益性の高いIPOのひとつを行った。

Red Hatは一連の社長を経て、最終的にIBMのニーズとRed Hatの株主の要望が一致するまで、各社長はその時点で必要とされるスキルを有していた。

Red HatがRHELの開発プラットフォームとして以外、デスクトップに関心がなかったことは周知の事実だ。 彼らはデスクトップ開発をFedoraに譲った。 Red hatが気にかけていたのは企業であり、Red hatが売り込もうとしていたサポートに高額な値札を喜んで支払う企業であり、顧客が必要とする場合にソースコードを入手できるという保証がある企業であった。

このような企業は、コンピュータの必要性には真剣だが、必要なレベルのサポートを提供するための従業員への投資はしたくない。 だから彼らはRed hatにお金を払うのだ。 しかし、そのような企業のほとんどは、アップルやマイクロソフトをデスクトップに置いており、そこにFedoraがあることなど気にも留めていない。 彼らはRHELがしっかりしていて、電話が使えるようになっていて、そのためにお金を払うことを望んでいる。

代替案は、クローズドソースのソリューションを購入し、必要なときにソースコードを入手するために戦うか、IBMが必要とするハードウェア/ソフトウェアシステムソリューションではないソリューションを（サーバーベースで）取引することだ。

“フルスタック “システム会社とその他の会社

数年前、オラクルはサン・マイクロシステムズの知的財産を買収する決断を下した。 もちろん、オラクルは自社製品をさまざまなオペレーティング・システム上で動作させていたが、オラクルは、ハードウェア、オペレーティング・システム、アプリケーション・ベース（この場合、最高峰のオラクル・データベース・エンジン）を完全にコントロールできれば、「止められないオラクル」を作り出せると考えたのだ。

なぜフルスタックのシステム会社が好まれるのか？ フルスタックに変更や修正を加えることで、アプリケーションに利益をもたらすことができる。 同様に、フルスタックの非効率性や弱点をテストすることもできる。

私は “フルスタック “企業で働いていたことがある。 私たちは自社のハードウェアをサポートしていた。 私たちが書いたデバイス・ドライバは、オペレーティング・システムがシステム管理者に見えるようにするための診断機能を備えており、デバイスが故障しそうなことを知らせたり、デバイスを交換したりできるようになっていた。 私たちは、データベース製品やネットワーク製品に役立つ機能をシステムに組み込んだ。 よりシームレスにすることができました。

IBMはフルスタック企業だ。 アップルもフルスタック企業だ。 アップルの製品は高価になりがちですが、多くの真面目な人たちはアップルの製品に高いお金を払っています。

なぜ企業はお金を払ってまでRHELを使うのか？

特定の企業（私たちが「企業」と呼ぶ企業）は、大学や趣味の人たちとは違う。 そのような企業（および政府）は、「ミッション・クリティカル」や「常時稼動」といった言葉を使う。 通常、コンピュータの台数は数十台や数百台ではなく、数千台である。

彼らは「平均故障時間」（MTTF）や「平均修理時間」（MTTR）について語り、「サービス利用契約」（TSA）を結ぼうとする。TSAでは、保証される稼働時間（99.999％の稼働時間）を何時間とし、それが達成されない場合は罰則を科すとしている。 そして経験則として、コンピューター会社は、小数点以下が「9」になるごとに、そこに到達するために100倍の労力と費用が必要になることを知っている。

そして通常、この「利用規約」では、顧客とサービス・プロバイダーとの間にいくつの「コンタクト・ポイント」があるかについても語られる。 顧客から提供された「コンタクトポイント」は、平均的なユーザーよりもシステムや問題についての知識が豊富であるため、「コンタクトポイント」が少なければ少ないほど、契約費用は少なくて済む。

また、このような契約では、顧客は私たち業界で「ファーストライン・サポート」と呼ぶところに電話することはない。 顧客はすでにすべてのパッチを適用し、システムを再起動し、マウスが接続されていることを確認している。 そのため、顧客は特別な番号に電話し、セカンドラインかサードラインのサポートを受けることになる。

つまり、真面目な人たちだ。 本当に真面目な人たちだ。 そして、本当に真剣な人々は、それを得るために本当に真剣なお金を使う準備ができている。

私は、そのようなサービスを買いたい企業と、そのようなサービスを提供する必要がある企業の両方で働いてきた。

多くの人は、契約しているシステムの数が多ければ多いほど、抱える問題も多くなることを理解しているだろう。 同様に、契約しているシステムの数が多ければ多いほど、エンタープライズ・サポートを必要とするすべての顧客とシステムに均等に分散すれば、システムあたりのサービス提供コストは低くなる。

IBMは一般的に、本当に真剣なサポートを提供する企業のひとつでした。

すべてを結びつける

IBMは、ビジネス・ソリューション事業で使用する多くのオペレーティング・システムやソリューションをまだ持っていたが、IBMは、オラクルのようにフルスタック・ソリューションとして使用できるLinuxソリューションを必要としていた。 IBMは、ハードウェア、オペレーティング・システム、ソリューションを統合し、顧客により適合させることができる。

同様に、RHELソリューションを提供するRed hat・ソフトウェアには、エンタープライズ向けソリューションを提供するための評判とエンジニアリングがあった。

Red hatは、他の有名なディストリビューションとは異なり、エンタープライズ・サーバーにフォーカスしており、コミュニティ・バージョンの「Fedora」は、後にRHELに組み込まれる新しいアイデアのためのトライアル・ベースとして機能していた。 しかし、RHELはRed hatのビジネスの中心だった。

また、いくつかのソフトウェアがRed hatからのみ提供されていたことも指摘しておきたい。 RHEL “と呼ばれるディストリビューションのいくつかの部分に取り組んでいた “コミュニティの人々 “は少数だった。 そのため、多くの部分が著作権で保護され、あるバージョンのGPLのもとでリリースされましたが、RHELを構成する多くの貢献はRed hatからのみもたらされました。

Red hatはまた、Linuxコミュニティでも評判がよく、すべてのソースコードをより大きなコミュニティに公開し、サポートに課金していた。

しかし、時間の経過とともに、一部の顧客は少数のRHELシステムを購入し、その後、他のディストリビューションからRed Hatの「バグ互換」バージョンを使用するというパターンを開発しました。 もちろん、これは顧客の経費節減にはなりますが、同じ作業量に対して Red Hat が受け取る収益も減らすことになります。 このためRed hatは、販売するライセンスごとに多くの料金を請求したり、Red hatの従業員を解雇したり、他の方法では資金を提供できたかもしれないプロジェクトを行わなかったりせざるを得なくなった。

そこで最近、Red hat/IBMは、RHELを実行するすべてのシステムのライセンスを購入する顧客に顧客を限定し、その顧客にはソースコードとそのディストリビューションのビルド方法に必要な情報のみを配布するというビジネス上の決断を下した。 そのため、バイナリを受け取った人たちはソースを受け取ることになり、自分たちが望むようにバグを修正したり、オペレーティングシステムを拡張したりすることができる……これがGPLの本質であったし、今もそうである。

私が読んだ記事のほとんど（すべてではないにせよ）は、”IBM/Red HatはGPLに従っているようだが……しかし……しかし……コミュニティが！”というような内容のことを言っていた。

どのコミュニティ？ IBMやRed Hatが提供するようなレベルのエンジニアリングやサポートを必要としない人々のためのディストリビューションはたくさんある。 Red HatとIBMは、GPLコードの変更を「上流」に送り続け、他のすべてのディストリビューションに流しています。 彼らはより大きなコミュニティとアイデアを共有し続けている。

DEC Linux/alphaポートの初期の頃、私はRed Hatを使いました。なぜなら、彼らはDECと協力してビットを出したディストリビューションだったからです。 その後、他のディストリビューションも、Red Hatが行った作業からAlphaに続いた。 率直に言って、私は「RHEL」を使ったことがないし、長い間Fedoraも使っていない。 個人的な好みだ。

しかし、私は今、多くの人々がどこからともなく現れ、胸を叩いて、RHELを無料で使いたい人々の投資をどう守るつもりなのかと言っているのを目にする。

さまざまなディストリビューションの開発者が、自分たちは「フリーローダー」ではないと宣言するTシャツを作っているのを見たことがある。 CentOSやRocky Linux、Alma、あるいは他のディストリビューションの「クローン」の開発者を、誰が「フリーローダー」と呼んだかは知らない。 私はこれまで十分な数のディストリビューションを世に送り出してきた。 仕事が必要なのだ。

しかし、私が「フリーローダー」だと考えるのは、このようなクローンを使い、いかなる形であれコミュニティに還元しない多くの人々であり、それはおそらく、IBM/Red Hatとビジネス契約を結び、その契約を守ろうとしない人々であろう。 このようなフリーローダーには、彼らのディストリビューションを使ってもらえれば「嬉しい」Linuxディストリビューションが他にもたくさんある。

/*
個人的なことを書いておく：

前述したように、私はオープンソースができる前から、フリーソフトウェア財団ができる前から、GNUプロジェクトができる前から、「オープンソース」コミュニティに参加してきた。

私は73歳で、50年以上を「コミュニティ」で過ごしてきた。 ソース・コードを推進し、ソースを提供したことで、背中には鞭の跡が残っている。たとえ解雇されたり、裁判沙汰になったりしても、顧客が必要としていたからだ。 私がDigital Unix Groupで働いていたとき、Linuxをサポートする私を笑った人々のほとんどは、今ではLinux企業で働いている。 それでいいのだ。 私は面の皮が厚いが、鞭の跡はまだ残っている。

コードを書いたり、ドキュメントを書いたり、妥当なバグレポートを作成したりする能力とは関係のないところで、人々がこのコミュニティの構築に貢献できる方法はたくさんある。

学校、会社、政府に自由ソフトウェアを宣伝し、コミュニティを理解するだけでも、長い道のりになるでしょう。 学校でLinuxクラブ(lpi.org/clubs)を立ち上げたり、Linuxへのアップグレード(upgradetolinux.com)を手伝うことは、Linuxユーザ(個人、企業、大学、政府を問いません)がコミュニティに貢献できる方法です。

しかし、フリーローダーの多くはそれさえもしない。
*/

これまでのところ、私は4つの異なるディストリビューションが「RHELではない」ディストリビューションの生産を継続すると言っているのを見た。 もし本当にそうしたいのなら、なぜ協力して1つの良いものを作らないのでしょうか？ なぜ自分たちのディストリビューションをRHELの競合にしないのか？ それをやっても儲からないとわかったとき、彼らはいつまで胸を張り続けるのだろうか？

SuSEは、RHELの競争相手の開発に1000万ドルを投資すると言った。 素晴らしい！ COMPETE。 同じビジネス・チャネル、ワールドワイドのサポート・チームなどを持つ、Red Hatの企業向け競合製品を作るのだ。 そのためには、決して安くはないことがわかるだろう。 1,000万ドルあれば始められるかもしれない。

これに対する私の答えは？ RHELの顧客は、自分がどうしたいかを決めなければならない。 IBMとRed Hatは、顧客がRHELの価値と、Red Hat/IBMとそのチャネル・パートナーが提供するサポートの価値を理解してくれることを望んでいるはずだ。

RHELのコピーを1つ買って、それがどのように作られたものであれ、他のすべてのシステムで “無料の “ディストリビューションを実行したいだけの残りの顧客は、IBMはもう彼らとはビジネスをしたくないようだ。

また、IBMとRed Hatは顧客に対して1組のビジネス条件を提示しており、顧客はそれを受け入れるか拒否するかは自由であることも指摘しておこう。 そしてIBMとRed Hatは、別の顧客のために別のビジネス条件を自由に設定することができる。

私は、彼らがライセンスに違反しない限り、ビジネス条件を設定する人々や企業を憎んでいるわけではないことを人々に知ってもらいたい。 ビジネスはビジネスだ。

しかし、Red HatとIBMがこのビジネスの変化において「悪」として描かれているのと同様に、エンドユーザーにソースを保証しない、あるいは「クローズド・ソース」ライセンスのみを提供する、オープンソースの「パーミッシブ・ライセンス」をサポートするすべての企業について、まったく言及されていないことを指摘しておきます……クローンを作ることを許さないし、許したこともない……これらの人々や企業に、石を投げる権利はありません（そして、あなたは自分が誰であるか知っています）。

Red HatとIBMは、契約に基づいてバイナリを受け取るすべての人にソースを公開しています。 それがGPLです。

研究者、学生、趣味の人、ほとんどお金のない人たちのために、彼らが選択できるディストリビューションは文字通り何百もあり、RHELが扱っていない他の興味深いアーキテクチャで動作するものもたくさんあります。

¹https://en.wikipedia.org/wiki/A_Commentary_on_the_UNIX_Operating_System
²https://gunkies.org/wiki/Installing_UNIX_v6_(PDP-11)_on_SIMH