パンチカードや磁気テープを使ってソフトウェアをロードしていた頃は、すべてのプログラムは「フリーソフトウェア」かつ「オープンソース」でした。しかし、プロプライエタリソフトウェアの出現によってすべてが変わりました。これに対し、プログラマーたちは反抗し、フリーソフトウェアとオープンソースソフトウェアの最初の正式な定義を開発しました。

今日では、クローズドソースコードは稀な例外となっています。しかしながら、オープンソースを開発モデルではなくビジネスモデルと誤解している一部の企業が、独自の手法と「オープンソース」コードを組み合わせようと試みるのを止めることはできません。最新の例としては、Sentryの「Functional Source License」（FSL）が挙げられます。

FSL は、Server-Side Public License (SSPL)、Common Clause、および Business Source License の伝統に従い、オープン ソースの重要性を強調しているように見えますが、そのアプローチを「努力をすることなく自由を享受する」と表現し、オープン ソースの中核原則を嘲笑しています。

へへ。

Sentryは、開発者向けのアプリケーションコード監視サービスです。元々はDjango（オープンソースの高水準Pythonネットワークフレームワーク）を使った小規模なコード開発から始まりました。現在も、主にオープンソースコードを使用して開発されています。オープンソースなしではSentryは成り立たないことは明らかです。

これは、「ソースコード利用可能」やその他の準オープンソースライセンスを採用している他のすべての企業にも当てはまります。これらのライセンスはすべてオープンソース企業から派生したもので、利益を最大化するために、無料で入手したコードを再ライセンス化し、事実上コードをロックしているのです。

オープンソース・イニシアティブ（OSI）の副会長、ティエリー・カレズ氏は私にこう言いました。「オープンソースのコードベースを基盤としてソフトウェアを構築している企業もあります。何百ものオープンソース・パッケージを依存関係として利用する際にライセンスを申請する必要もありません。彼らはオープンソースの原則を遵守することを公に約束することで評判を築いています。しかし、より大きな価値を追求するあまり、当初成功をもたらしたモデルを近視眼的に放棄してしまうのです。」まさにその通りです。

Sentry、MariaDB、Redis、HashiCorpといったかつてのオープンソース企業がこのような措置を講じることができるのは、著作権を侵害する貢献者ライセンス契約（CLA）を採用しているからです。これらの契約は、オープンソースプロジェクト内でのコードの使用に関して貢献者が同意する条件を定めた法的文書です。Apache Software FoundationのCLAやLinuxのDeveloper Certificate of Origin（開発者証明書）など、一部のCLAは単にプロジェクトの法的権利を保護するために使用されていますが、MongoDBの貢献者契約のように、コードとその著作権を盗用するために使用されるものもあります。このようなCLAがあれば、彼らはあなたのコードを好きなように使用し、ライセンスを変更することが非常に容易になります。

SourceHutの創設者兼CEOであるドリュー・デボルト氏は、Elasticsearchがオープンソースから「ソースコードが公開されている」状態に移行したことについて、次のように見解を述べています。「Elasticsearchは1,573人の貢献者によって所有されており、彼らは著作権を保持し、Elasticに成果物を配布する無条件のライセンスを付与しています。ElasticがElasticsearchをオープンソース化しないことを決定した際、彼らはこの脆弱性を悪用しました。これは、そもそも彼らが意図的に仕掛けたものでした。Elasticは1,573人の貢献者、そして彼らを信頼し、忠誠を誓い、サポートしてくれたすべての人々に背を向けたのです。」

今日、Sentryはまさにその好例と言えるでしょう。本質的には同じものですが、形は違います。公平を期すために言うと、Sentryは長年にわたりソースコードが利用可能なライセンスを使用してきました。会社が設立されFSLを採用する前は、2018年からBSLを使用していました。もし誰かがSentryにコードを寄付し続けているのであれば、彼らは自分が何をしているのかを確かに理解しているはずです。

では、なぜ新しいライセンスを作成したのでしょうか？ Sentryのオープンソース担当責任者であるChad Whitacre氏は次のように説明しています。「BSLには2つの大きな欠点があります。まず、事前に定められた非競争期間は4年間ですが、これはソフトウェア業界にとっては非常に長い期間です。そのため、最終的なオープンソースへの移行は単なる象徴的な行為であるという印象を与えかねません。実質的には100年です。Sentryでは、この期間を3年に短縮することを選択しましたが、3年でも長すぎる可能性があることも認識しています。」

ライセンスの有効期限が切れると、コードはApache 2.0ライセンスまたはMITライセンスのいずれかに基づいてライセンスされます。しかし、一見するとそれほど寛大なライセンスではありません。FSLによると、コードはあらゆる目的で使用できますが、「競合目的の使用を除きます。競合目的の使用とは、ソフトウェア自体、またはソフトウェアに基づいて当社が提供する他の製品やサービス（ただし、当社が当該ソフトウェアのリリース日以前に当該競合製品またはサービスを提供している場合）と競合する商用製品またはサービスを開発または提供するためにソフトウェアを使用することを指します。」

つまり、コードを閲覧することはできますが、ビジネスに利用することはできません。より深く理解するには、ApacheライセンスとMITライセンスのFSL版をご覧ください。個人的には、どちらもオープンソースライセンスとは考えていません。

ウィテカー氏はさらにこう説明した。「さらに深刻な欠陥は、BSLには変更日、ライセンス変更、追加使用許可といったパラメータが多すぎることです。最大の問題は追加使用許可です。これは膨大な空欄補充問題であり、BSLごとに本質的に異なるライセンスになってしまうのです。」

この点については反論できません。各社のBSLはそれぞれ異なります。つまり、顧客がBSLを使用している企業と契約する際に、法的にどのような権利が確保されているかを正確に把握することが難しいということです。SentryはFSLを通じて、自社の製品とサービスを顧客にとってより魅力的なものにしたいと考えています。

このアプローチはうまくいくかもしれない。しかし、私はCarrez氏の発言に同意する。「開発者から技術選択の自由を奪うようなライセンスの亜種をリリースすることは、今に始まったことではない。これは本質的に、ソフトウェアエコシステム全体から開発者が得る根本的な自由を破壊し、プロプライエタリソフトウェアの所有権とその使用権を主張しているに過ぎない。これはオープンソースではなく、オープンソースを装ったプロプライエタリポータルに過ぎない。」