これらの Linux ディストリビューションはオープンソースであると主張していますが、オープンソースにほとんど近づいていません

Linux は人々が自分のコンピュータを制御できるという評判がありますが、多くの商用製品は Linux を使用しており、所有者にはまったく制御を与えていません。独自のソフトウェアが同梱されたり、ソース コードへのアクセスが制限されたり、ハードウェアが徹底的にロックダウンされたりして、修正されたオペレーティング システムのインストールが現実的ではなくなります。

オペレーティング システムがオープンソースのラベルに値するかどうかを判断するには、さまざまな方法があります。 Free Software Foundation (FSF) は、4 つのソフトウェアの自由と GNU Free システム配布ガイドラインを通じて厳格な基準を設定しています。 Trisquel、Guix System、Parabola などのディストリビューションは、独自のソフトウェアを排除することでこれらの要件を満たすことを目指しています。 Ubuntu、Debian、Fedora はより寛容なアプローチを採用しており、オープン ソース コンポーネントとともに独自のファームウェアとソフトウェアへのアクセスをサポートまたは提供しています。

オープン ソース イニシアチブ (OSI) は、自由な再配布、ソース コードへのアクセス、派生作品の変更と配布の許可などのライセンス要件に重点を置いたオープン ソース定義を使用しています。この標準に基づいて、Ubuntu、Debian、および Fedora には広範なオープンソース基盤があります。 Debian の社会契約およびフリー ソフトウェア ガイドラインでも、メイン アーカイブに含まれるソフトウェアに関する明確な原則が定められていますが、商用オペレーティング システムに関しては、オープン ソース ライセンスは一部分しか伝えません。ソース コードを入手して、オペレーティング システムを自分で構築し、設計されたハードウェアに独自のバージョンをインストールできますか?

Red Hat が販売する製品の再構築を困難に

RHEL のソースコード ポリシーが状況を一変させた

Red Hat Enterprise Linux (RHEL) には、GPL およびその他のオープンソース ライセンスに基づいて配布されるソフトウェアが含まれており、同社は長年にわたってオープンソース プロジェクトにも幅広く貢献してきました。しかし、2023 年に RHEL ソース パッケージへのパブリック アクセスを制限するという決定は、Linux コミュニティ全体で大きな反発を引き起こしました。

2023 年 6 月、Red Hat は、CentOS Stream が RHEL 関連のソース コードの唯一のパブリック リポジトリになると発表しました。以前は、一般にアクセス可能な CentOS インフラストラクチャを通じて RHEL ソース パッケージを入手できました。変更後は、通常、顧客は Red Hat の顧客チャネルを通じて関連ソースにアクセスする必要がありました。

Red Hat のサブスクリプション規約では、サブスクリプション コンテンツの再配布が制限されているため、同社のソース パッケージを使用して互換性のあるディストリビューションを公開する取り組みが複雑になっています。 Red Hat は、自社のサブスクリプション モデルは正当であり、CentOS Stream は共同開発に適した場所を提供していると主張していますが、(多くの批評家がそうしているように) Red Hat はアクセス可能なソース コードを中心に構築されたエコシステムの恩恵を受け、その結果、独立したプロジェクトが商用製品を再現するのがはるかに困難になったと主張することもできます。

Rocky Linux と AlmaLinux はアプローチの再考を余儀なくされたプロジェクトの 1 つであり、どちらもエンタープライズ Linux 互換性を提供し続けるためにビルド プロセスを適応させました。 Red Hat は単に RHEL を独自のソフトウェアにしたわけではありません。オープンソース コンポーネントをカバーするライセンスは引き続き適用されますが、Red Hat のポリシーにより、部外者が商業条件を無視して同じソース パッケージを入手し、互換性のあるシステムを再配布することが難しくなりました。

オープンソース ソフトウェアは、人々がコードを取得し、その上に構築し、該当するライセンスに基づいて自分の作品を共有できるかどうかに依存しています。オープンソース ソフトウェアに成功を依存する製品にとって、そのプロセスが困難になると、それを取り巻く協調的なエコシステムが損なわれます。同社はサブスクリプションモデルを擁護することはできるが、Linux コミュニティがこのアプローチが RHEL の成功に貢献したエコシステムに役立つかどうかを疑問視する十分な理由がある。

Tizen はオープンソースですが、Samsung TV はオープンソースではありません

プロジェクトと製品は異なるストーリーを語ります

Tizen は、Linux Foundation の下でホストされている本物のオープンソース オペレーティング システム プロジェクトです。パブリック リポジトリ、開発者ツール、ドキュメントがあり、テレビを含むいくつかのデバイス カテゴリをサポートしています。 Samsung は、自社の TV 用のアプリケーションを構築したい開発者向けのリソースも提供しています。

ただし、Tizen を搭載した Samsung TV を購入しても、オープンソース プロジェクトが示唆するような自由は得られません。商用製品には、Samsung 固有のソフトウェア、独自のサービス、ハードウェアの適応、および必ずしも完全な再現可能なビルドとして入手できるとは限らないファームウェアが含まれています。

サムスンは長年、自社のテレビソフトを巡って批判にさらされてきた。開発者は、サポートされているツールと API を使用してアプリケーションを作成できますが、完全なオペレーティング システムを再構築してテレビにインストールできるようになるのとは程遠いです。所有者は、パブリック Tizen ソース リポジトリに、特定のモデルのファームウェアを置き換えるのに必要なすべてが含まれていると想定することはできません。

もどかしいのは、オープンソースの取り組みが本物であるということです。 Tizen は、単に別の名前を付けた Linux カーネルではありません。その背後には実質的なプロジェクトがありますが、Tizen テレビを購入したからといって、そのプロジェクトを利用したり、ソフトウェア スタック全体を再構築したり、Samsung のバージョンを置き換えたりする自由は与えられません。

企業がオープンソースに基づいて構築していることを評価したいのであれば、何が非公開のままで、何が顧客によって実際に変更できるのかについてもっと率直に示すべきだと私は思います。 Samsung の開発者リソースは便利ですが、テレビをオープンソース デバイスにしていません。

Fire OSはAndroidのオープン性を借りて、同じ自由度を提供しない

Amazon は AOSP に基づいてエクスペリエンスを制御します

Amazon の Fire OS は、Fire TV デバイスと Fire タブレットを強化します。これは Android オープンソース プロジェクト (AOSP) から派生し、Linux カーネル上で実行されます。 Amazon は、ソース ディストリビューション要件の対象となるカーネルやその他のソフトウェアを含む、該当するオープンソース ライセンスの対象となるコンポーネントのソース コードを公開しています。

AOSP の多くは Apache License 2.0 を使用しており、通常、企業は独自の変更をリリースすることなくコードを変更および再配布することができます。 Amazon はその柔軟性を利用して独自のエコシステムを構築しました。 Fire OS ランチャーとインターフェイス、Amazon アプリストア、Alexa 統合、およびさまざまなシステム サービスは独自のものです。多くの Fire デバイスにはロックされたブートローダーもあるため、一般の所有者がインストールされているオペレーティング システムを独自のビルドに置き換えるのは困難または不可能になっています。

AOSP の寛容なライセンスの下では、通常、Amazon にはこれらの変更を公開する義務はありません。この取り決めがライセンス違反になるわけではありませんが、同社が自社製品の多くをクローズドに保ちながら、オープン プラットフォームの恩恵を受けることができることを意味します。

ブートローダーの制限により、実験したい人にとって状況はさらに悪化します。カーネル ソースを公開しても、Fire TV Stick に代替オペレーティング システムをインストールできるわけではありません。基盤となるコードの一部が利用可能な場合でも、デバイス固有の制限、独自のサービス、ハードウェア サポートが邪魔になる場合があります。

Amazon は Fire OS を完全にオープンソースとは呼んでいません。 Fire OSをオープンソースソフトウェア上に構築されたものとして説明することは効果的であり、Amazonが最終製品の完全な管理を維持しながら、AOSPの信頼性にマーケティングを任せることができます。これは慎重に便宜を図った言葉の使い方であり、表現は技術的には正確かもしれませんが、実際にオープンソースの自由を提供することなく、顧客に Fire OS をオープンソースの自由と関連付けることを奨励しています。 GNU プロジェクトには、「避けるべき言葉 (または注意して使用する)」というページもあります。おそらく、オープンソース ソフトウェアに基づいて構築された製品を販売するより多くの企業がこの本を読むべきでしょう。彼らは、オープン性に関する文言もコード自体と同じくらい慎重に管理できることに気づくかもしれません。

クレジット: GNU

オープンソースの主張を明らかにする 3 つの質問

企業は、何かをオープンソースと呼ぶのは聞こえが良いことを知っています。これは、透明性、ユーザー制御、人々が検査して改善できるソフトウェアを示唆しています。しかし、彼らの提案に賛同する前に、その会社が実際に何を提供しているのか知りたいかもしれません。

ソースコードにアクセスできるのは誰ですか?もしその答えが、お金を払っている顧客や、制限的な条件を喜んで受け入れる人々に限定されているのであれば、同社はすでに自社のソフトウェアとより広範なコミュニティの間に障壁を設けていることになる。そのコードを使って実際に何ができるのでしょうか?独自のサービス、クローズド インターフェイス、ベンダー制御のコンポーネントの下にオープン ソース カーネルが埋め込まれていても、オペレーティング システム全体がオープン ソースになるわけではありません。これにより、製品はオープンソースに依存するようになり、支払ったハードウェア上で独自のビルドを実行できるようになります。ブートローダーがロックされている場合、ファームウェアが利用できない場合、またはベンダーがソフトウェアを置き換える実用的な方法を提供していない場合、ソース コードを公開するだけでは限界があります。

オープンソース コンポーネントを使用する商用ソフトウェアには本質的に何も問題はなく、プロプライエタリなコードが自動的にライセンス違反になるわけではありません。しかし、問題は、オープンソースの評判を利用して、製品に関連する自由を顧客の手に負わせないまま製品を販売することです。