オープンソースの歴史とGPL、SSPLまでの流れ

オープンソースソフトウェアとは何か、どこから生まれたのか

オープンソースソフトウェアの歴史は、主にライセンスの歴史です。他人が書いたコードで何をしてよいかを決めるのは、ライセンスだけだからです。ライセンスが文書化されるよりはるか前から、コードは自由に共有されていました。コードが製品になると共有されなくなり、裁判でも共有を維持できるようにライセンスが作られました。

これが短い説明です。詳しい経緯が重要なのは、現在サーバーで実行しているソフトウェアにも、そうした決定の影響が残っているためです。決定の一部は 1983 年に行われました。別の決定は昨年行われました。その結果、セルフホスティングガイドで扱うアプリケーションの一部は、現在では異なる名前の 2 つのバージョンとして提供されています。

ソフトウェアは販売される前から共有されていました

1950年代と1960年代には、ソフトウェアはマシンに付属していました。IBM はシステムと一緒にソースコードを提供し、1955年に設立された SHARE などのユーザーグループは、テープでプログラムを共有していました。これを終わらせたのは2つの出来事です。IBM は1969年、ソフトウェアをハードウェアとは別に価格設定すると発表しました。これにより、ソフトウェア単体の市場が生まれました。その後、法律も実態に追いつきました。1980年の Computer Software Copyright Act は、米国でプログラムが著作権の対象となる著作物であることを認めました。1980年以降、自分で書いていないコードは原則として非公開となり、共有するには作者の書面による許可が必要になりました。

Homebrew Computer Club と Hobbyists への公開書簡

Homebrew Computer Club は、1975 年 3 月、California 州 Menlo Park のガレージで最初の会合を開きました。会員はハードウェアと紙テープを持ち寄り、会合ではコピーも行われました。Bill Gates と Paul Allen が作成した Altair BASIC は、コピーしたテープに収録され、会場内で回覧されました。1976 年 2 月、Gates はクラブのニュースレターで「An Open Letter to Hobbyists」により回答しました。

趣味でコンピューターを使う人の大半は認識しているはずですが、皆さんのほとんどはソフトウェアを盗用しています。

Gates は、Altair の所有者のうち BASIC の料金を支払った人は 10 人に 1 人未満であり、その開発に使われたコンピューター時間の価値は 40,000 dollars を超えると書きました。現在まで続く議論の要点は、すでにこの書簡に示されています。ソフトウェアのコピーには費用がかからず、コピーする人全員の利益になります。しかし、それを作成するために、誰かが 1 年間を費やしました。以下で説明する各ライセンスは、この 2 つの事実に同時に答えようとするものです。

1983 年の GNU と、法的な発明としての GPL

Richard Stallman は 1983 年 9 月、Web より前に人々が利用していたニュースグループネットワーク Usenet で GNU を発表しました。GNU は「GNU's Not Unix」を意味します。その計画は、誰でもコピーして変更できる、完全な Unix 互換システムを作ることでした。

Free Unix! Starting this Thanksgiving I am going to write a complete Unix-compatible software system called GNU (for Gnu's Not Unix), and give it away free to everyone who can use it.

Free Software Foundation (FSF) は 1985 年に続いて設立されました。FSF の Free Software Definition では、0 から番号付けされた 4 つの自由を定めています。任意の目的でプログラムを実行する自由、プログラムを調査・変更する自由、コピーを再配布する自由、変更したバージョンを配布する自由です。Freedom 1 にはソースコードが必要です。バイナリを実用的な方法で調査することは誰にもできないためです。ここでいう「Free」は価格ではなく自由を意味します。FSF 自身の表現では、free as in free speech であり、free beer ではありません。

発明されたのはマニフェストではありません。ライセンスです。GNU General Public License (GPL) は、著作権を共有の禁止ではなく、共有の義務付けに利用します。4 つの自由を受け取る条件は 1 つだけです。ソフトウェアを渡した相手にも、ソースコードとともに同じ自由を与えることです。Stallman はこれを copyleft と呼びました。これは 1985 年に GNU Emacs とともに最初にリリースされ、1989 年に GPL version 1 となり、1991 年 6 月に version 2 となりました。

GPL が機能するのは、著作権法に反するのではなく、著作権法を基盤としているためです。ライセンスがなければ、他者のコードを配布する権利はまったくありません。GPL はその権利を与え、その権利に条件を付けます。したがって、ベンダーが変更した GPL コードをルーターに組み込み、ソースコードの提供を拒否した場合、それは約束を破っているのではありません。著作権を侵害しており、著作権者は裁判所に訴えることができます。Harald Welte の 2000 年代の gpl-violations.org による訴訟から、2021 年に提起された Software Freedom Conservancy の Vizio に対する訴訟まで、強制執行が可能なのはそのためです。後者では、テレビを購入した人もソースコードを要求できると主張しています。

Linux がシステムを完成させました

1991 年までに、GNU プロジェクトにはコンパイラー、C ライブラリ、シェル、そして大半のツールがそろっていました。しかし、動作するカーネルはありませんでした。GNU 独自のカーネルである Hurd の開発が、計画よりはるかに長引いたためです。1991 年 8 月、ヘルシンキの学生が comp.os.minix ニュースグループに次の投稿をしました。

386(486) AT 互換機向けに、（無料の）オペレーティングシステムを作っています（単なる趣味で、大規模でプロフェッショナルな gnu のようなものにはなりません）。

Linux 0.01 は 1991 年 9 月に公開されました。当初は Linus Torvalds が自分で作成したライセンスが適用され、販売は禁止されていました。1992 年初頭に GPLv2 に置き換え、その後、この変更は最良の決断の 1 つだったと述べています。このライセンスによって、企業は安心して貢献できるようになりました。企業は、競合他社が改良部分を非公開にできないと分かったうえで、カーネル開発にエンジニアを参加させられたためです。

Berkeley には、すでにフリーな Unix が存在していました。Linux が BSD（Berkeley Software Distribution）ではなく、標準的なフリー Unix になった理由の一部は、訴訟にあります。Unix System Laboratories は 1992 年に Berkeley Software Design を提訴し、訴訟は 1994 年初頭まで続きました。この 2 年間、BSD システムには法的リスクがありましたが、Linux にはありませんでした。そして、その時期にユーザーが増えました。FSF は、統合されたシステムを GNU/Linux と呼ぶよう求めています。Linux はカーネルであり、周辺ツールの大半は GNU のものだからです。ほとんどの人は Linux と呼びます。どちらの名称も、同じソフトウェアの集合を指します。

1998: オープンソースへの改称と、癒えなかった分裂

1998 年 1 月、Netscape はブラウザーのソースコードを公開すると発表しました。これほど大規模な企業が同様の対応を取るのは初めてでしたが、実務上の問題が明らかになりました。"free software" という表現は英語では「費用のかからないソフトウェア」と読めるため、経営陣はまさにその意味で受け取りました。より適切な用語を探すため、1998 年 2 月に Palo Alto で会合が開かれ、Christine Peterson が "open source" を提案しました。数週間以内に Eric Raymond と Bruce Perens が Open Source Initiative (OSI) を設立しました。OSI は、Perens が 1997 年に作成した Debian Free Software Guidelines を基に、Open Source Definition を採用しました。

Open Source Definition には 10 個の基準があります。現代の議論の大半を決めるのは、そのうち 2 つです。ソースコードが利用可能であること、そしてライセンスがプログラムを利用できる人や利用目的を制限しないことです。「これを商用サービスとして提供してはならない」と定めるライセンスは、他に何を許可していても基準を満たしません。この文を覚えておいてください。これが、今日の source-available ライセンスが越える境界線です。

1998 年に始まった分裂は、どのライセンスを受け入れられるかではなく、その理由をめぐるものでした。FSF の主張は倫理的なものです。プログラムを変更できないユーザーは、自分のコンピューターを自分で管理できません。Raymond の論文 "The Cathedral and the Bazaar" で企業向けに説明された OSI の主張は実務的なものです。オープンな開発はより良いソフトウェアを生み、企業はその成果を活用できます。Stallman の反論である "Why Open Source Misses the Point of Free Software" は現在も gnu.org で公開されており、Stallman は新しい用語を一度も受け入れていません。OSI の設立に協力した Perens は、運動が free software から離れていったとして、1999 年に OSI の理事を辞任しました。

実務上の差がどれほど小さいかについては、正確に理解しておく必要があります。FSF の free licences の一覧と、OSI の approved licences の一覧は、GPL、MIT、Apache 2.0、BSD など、ほぼすべての点で一致しています。両方の意味を同時に表す必要がある執筆者は、FOSS (free and open source software) または FLOSS (free/libre and open source software) を使用します。

企業はどのようにコードをリリースするようになったか

1999 年の Red Hat の株式上場により、コピーの販売よりもサポートとパッケージングに利益があることが示されました。IBM は 2001 年、Linux に 10 億ドルを投じることを約束しました。Microsoft の最高経営責任者は 2001 年、Linux を「がん」と呼びました。しかし同じ Microsoft は 2016 年に Linux Foundation のプラチナメンバーとなり、2018 年には株式による 75 億ドルで GitHub を買収しました。IBM は 2019 年、Red Hat を 340 億ドルで買収しました。これらはいずれも、ライセンスに対する考え方の変化ではありません。利益が生まれる場所が変わったということです。オペレーティングシステムのコストを共有できる場合、自社で保守するのは高くつきます。そのため、各ベンダーはその上のレイヤーで競争することを望みます。

企業による所有は、別の方向にも作用します。Oracle が 2010 年に Sun を買収したとき、MySQL と OpenOffice.org も引き継ぎました。しかし、どちらのコミュニティも離脱しました。MariaDB は MySQL から派生し、LibreOffice は 2010 年 9 月に OpenOffice.org からフォークされました。フォークは、ユーザーコミュニティが実際に持つ唯一の意思表示です。そして、その意思表示を可能にするのがライセンスです。

自ホストするアプリの一部にフォークが生まれた理由

2018 年以降、すでにリリースしていたソフトウェアの利用条件を変更した企業が複数ありました。いずれの場合も状況は同じでした。1 社の企業が開発者のほぼ全員を雇用している一方、はるかに大規模なクラウドプロバイダーが同じソフトウェアをマネージドサービスとして提供しており、その小規模な企業は、競争できない原因はライセンスにあると判断しました。

• MongoDB は 2018 年 10 月に Server Side Public License (SSPL) を採用しました。SSPL では、ソフトウェアをサービスとして他者に提供する場合、そのサービスの提供に使用するすべてのもののソースコードを公開する必要があります。OSI はこれをオープンソースとして認めず、MongoDB は 2019 年に審査申請を取り下げました。
• Redis は 2018 年と 2019 年に一部のモジュールへ利用制限を追加し、その後 2024 年 3 月のバージョン 7.4 で、メインサーバーを 2 つの source-available 条件による提供へ移行しました。最後の BSD ライセンス版から数日後にフォークが登場し、Amazon、Google、Oracle などの支援を受け、Linux Foundation の下で Valkey となりました。2025 年 5 月、Redis は Redis 8 の第 3 の選択肢として、OSI が承認する Affero General Public License version 3 (AGPLv3) を追加しました。
• Elastic は 2021 年 1 月に Elasticsearch と Kibana を Apache 2.0 から移行し、SSPL と Elastic License のデュアルライセンス条件に変更しました。Amazon は OpenSearch をフォークしました。Elastic は 2024 年 8 月に第 3 の選択肢として AGPLv3 を追加し、OpenSearch は 2024 年 9 月に OpenSearch Software Foundation として Linux Foundation へ移管されました。
• HashiCorp は 2023 年 8 月に Terraform とその他のツールを Business Source License (BUSL) へ移行しました。BUSL は、効力を持つ間はオープンソースライセンスではありません。競合する本番利用を禁止するためです。各リリースは固定された日付にオープンライセンスへ移行します。Terraform の場合は 4 年後です。数週間以内に OpenTofu がフォークされ、現在はこれも Linux Foundation の下にあります。

この問題には双方に正当な主張があり、どちらも悪意を持って行動しているわけではありません。50 人分の給与を負担する企業の成果を、はるかに大規模な企業が再販している場合、善意だけでは解決できない問題が生じます。一方、Apache 2.0 の条件を前提に構築したユーザーが、ある日新しい条件の下に置かれることにも問題があります。しかも、ユーザーに事前の確認はありませんでした。2 つの事例で次に起きたことにも注目してください。フォークが定着した後、Elastic と Redis はどちらも強いコピーレフトを再び追加しました。AGPLv3 では、サービスプロバイダーが実行する変更を公開する必要があるため、コピーレフトは当初の不満に対応しました。2026 年 8 月時点でも、両方のプロジェクトと両方のフォークは活動を続けています。これは、各ライセンスが実現するよう設計されていた結果です。

ライセンスを変更できるのは誰か

プロジェクト全体の著作権を1つの主体が管理している場合に限り、そのプロジェクトのライセンスを変更できます。企業がその管理権を得る方法は2つあります。著作権譲渡では、各貢献の所有権を企業に移します。Contributor License Agreement（CLA）では、貢献者が所有権を保持したまま、企業にその成果物のライセンスを変更できる十分に広い権利を付与します。通常は、最初の pull request で bot が投稿するリンクをクリックして、いずれかに署名します。

Linux には CLA がありません。貢献は Developer Certificate of Origin と GPLv2 の下で提出され、著作権は数千の個人や企業に分散しています。誰も Linux のライセンスを変更できません。関係する全員の署名を集めることは不可能だからです。同じ保護は、独立した著作権者が多数いるあらゆるプロジェクトにも適用されます。これは単なる約束より強い保護です。何を誰が所有しているかという事実に基づくためです。

したがって、依存する予定のソフトウェアについて確認すべきなのは、現在オープンソースかどうかだけではありません。誰がライセンスを変更できるのか、そしてその変更を単独で実行できるのかを確認する必要があります。

基盤組織が実際に提供するもの

基盤組織は資産を管理し、意思決定の方法に関するルールを定めます。Apache Software Foundation、Linux Foundation、その内部にあるCloud Native Computing Foundation、Software Freedom Conservancyは、それぞれこの役割を担っています。基盤組織だからといって、自動的に中立になるわけではありません。メンバーは参加費を支払い、大規模な基盤プロジェクトでフルタイム勤務する人の多くは、メンバー企業から給与を受けています。基盤組織が提供する範囲はより限定的ですが、それでも大きな価値があります。商標とリリースプロセスが1社のベンダーに属さないため、単独の企業がプロジェクトを非公開化できないからです。

見落とされがちなのが商標です。コードにはライセンスが適用されます。名称は商標であり、商標はコードライセンスの対象ではありません。コードはいつでもフォークできます。しかし通常、その名称を使い続けることはできません。そのため、この話に登場するフォークはValkey、OpenSearch、OpenTofu、Forgejoと呼ばれています。

保守担当者の問題

現代のインフラは、無報酬の保守担当者が 1 人か 2 人しかいないプロジェクトに支えられています。そして、障害が起きたときに初めて、その事実が明らかになります。2014 年の OpenSSL における Heartbleed の脆弱性は、Web の暗号化通信の大部分を担うライブラリに影響しました。そのライブラリは、ほとんど資金のない少人数の担当者によって保守されていました。2021 年 12 月の Log4Shell では、世界中のインシデント対応が Apache Log4j プロジェクトの少人数のボランティアチームに集中しました。

2024 年 3 月に発見された XZ Utils のバックドアは、攻撃対象がコードではなく保守担当者だったため、最も鮮明な例です。あるアカウントは約 2 年間、Linux ディストリビューション全体で使用されている圧縮ライブラリに、本当に有用な貢献を続けていました。別のアカウント群は、疲弊していた唯一の保守担当者に支援を受け入れるよう圧力をかけました。その後、新しい共同保守担当者が、リリースアーカイブにバックドアを仕込みました。これは、SSH（secure shell）デーモンが liblzma とリンクしているシステムを標的にしたものでした。ある開発者が、ログインに想定より約 0.5 秒長くかかる理由を調査している際に、これを発見しました。これは幸運によるものであり、関係者全員がそのことを公に認めています。

資金も届き始めています。2019 年以降の GitHub Sponsors、Open Collective、2022 年以降の Germany's Sovereign Tech Fund、そして OpenSSF の Alpha-Omega project があります。ただし、資金は均等には届かず、すでに有名なプロジェクトに集まりやすい傾向があります。規制も導入され始めています。European Union's Cyber Resilience Act は 2024 年 12 月に発効し、その義務の大部分は 2027 年 12 月から適用されます。初期の草案では、無報酬のボランティアに製造者責任を負わせる内容になっていました。そのため、財団やディストリビューションによる長期的な働きかけを経て、最終文書では「open source software steward」という負担の軽い区分が設けられました。

VPS 上のソフトウェアにおけるオープンソースの歴史が示すこと

セルフホスティングガイドで扱うすべてのアプリケーションは、こうした判断の影響を受けています。Nextcloud が存在するのも、フォークがあったためです。2016 年、ownCloud の創設者とチームの大半が離脱し、AGPLv3 の下でプロジェクトを再始動しました。それ以来、2 つの製品は並行して開発されています。この歴史が、検討する価値のある Nextcloud の代替と、両方の製品と競合するセルフホスト型 Dropbox の代替の背景にあります。

Git ホスティングにも同じパターンがあります。Gitea 自体は、2016 年に Gogs のフォークとして始まりました。2022 年後半には、プロジェクトの商標とドメインが企業へ移管されました。同年 12 月には Codeberg が Forgejo をフォークし、Forgejo は 2024 年の version 9 で MIT から GPLv3 に移行しました。両方ともセルフホスト型 Git サーバーの選択肢で扱っています。ライセンスの違いは、両者が分岐し続ける大きな理由です。一方、ほとんどのフリーソフトウェアは、Microsoft が所有するクローズドなプラットフォームである GitHub 上で開発されています。この点は以前から議論されており、双方に妥当な主張があります。詳しくはGitHub の実態を参照してください。

サーバーをプロジェクトに割り当てる前に、10 分で確認できる項目が 4 つあります。

• マーケティングページではなく、リポジトリの LICENSE ファイルを確認します。LICENSE ファイルの内容と一致しなくなった後も、ページでは「オープンソース」と書かれ続けることがあります。
• CLA または著作権の譲渡契約があるか確認します。存在する場合、単一の所有者が将来のリリースの条件を変更できます。
• 著作権を誰が保有しているか確認します。1 社なのか、多数のコントリビューターなのか、財団なのかを調べます。
• アクティブなメンテナーの人数を数えます。1 人しかいないプロジェクトは、あなたにとってだけでなく、その人にとってもリスクになります。

これは、単一ベンダーのソフトウェアを避けるべきだという意味ではありません。優れたソフトウェアは多く、そのソフトウェアが有償であることが、実際には保守を続けられる理由になっている場合もあります。重要なのは、自分が何にさらされるかを把握することです。何をセルフホストする価値があるかを判断するときは、メモリ要件と並べてライセンスも比較項目に入れてください。

この歴史の一部は、手元のマシン上でも確認できます。Debian または Ubuntu のシステムでは、すべてのパッケージがそれぞれの条件を含んでいます。

ls /usr/share/doc | wc -l
head -n 20 /usr/share/doc/bash/copyright

最初の数字は、著作権ファイルを持つインストール済みパッケージの数です。小規模な VPS では、通常数百になります。2 つ目のコマンドは bash の著作権ファイルの先頭を表示し、GNU General Public License version 3 を示します。ファイルがない場合、そのパッケージは Debian ポリシーに従ってビルドされていないことを意味します。これはまれなため、信頼する前にもう一度確認する価値があります。

FAQ

無料ソフトウェアとオープンソースの違いは何ですか？

両者はほぼ同じライセンス群を対象としていますが、それらのライセンスが重要である理由についての考え方が異なります。「Free software」は古い用語で、1985 年に Free Software Foundation が提唱しました。その主張は倫理的なものです。プログラムを変更できないユーザーは、コンピューターを制御できないという考え方です。「Open source」は、同じライセンスを企業に説明しやすくするため、1998 年 2 月に作られた用語です。その主張は実用的なものです。GPL、MIT、BSD、Apache 2.0 の各ライセンスは、いずれも両方の公式リストに掲載されています。両方を同時に指す場合は、FOSS または FLOSS と表記します。

Source-available ソフトウェアはオープンソースと同じですか？

いいえ。Source-available は、コードを読めることを意味します。Open Source Definition におけるオープンソースは、ライセンスによって、誰がソフトウェアを使用できるか、また何の目的で使用できるかを制限してはならないことも意味します。SSPL と Business Source License は、競合する商用利用を制限します。そのため、どちらもソースコードを公開していますが、この定義ではオープンソースではありません。自分だけで self-host する場合、その制限が問題になることはないかもしれません。上に製品を構築する場合は、まずライセンス本文を注意深く確認してください。

企業は、すでに付与したオープンソースライセンスを取り消せますか？

すでにリリースしたコードについては、取り消せません。そのバージョンには、リリース時に付与されたライセンスが適用され続けます。だからこそ、Valkey や OpenTofu などの fork は、最後に寛容なライセンスが適用された commit から開始できました。企業ができるのは、将来のバージョンに新しい条件を適用することです。ただし、それが可能なのは、譲渡または contributor licence agreement によってプロジェクト全体の著作権を管理している場合に限られます。Linux など、多数の独立した著作権者がいるプロジェクトは、誰もライセンスを変更できません。

self-host するソフトウェアでは、どのライセンスを確認すべきですか？

自分で実行し、再販売しないソフトウェアであれば、GPL、AGPL、MIT、Apache 2.0 など、OSI が承認したライセンスで必要な権利はすべて得られます。より重要なのは、著作権を誰が保有しているかを確認することです。それによって、後から利用者に不利な形で条件を変更できるかどうかが決まります。財団または多数の独立したコントリビューターが保有するプロジェクトは、利用者に不利な形でライセンスを変更できません。単一ベンダーが保有し、contributor licence agreement があるプロジェクトでは変更できます。どちらも優れたソフトウェアになり得ます。ただし、自分の判断だけでルールを変更できるのは一方だけです。