オープンソース：自由、責任、そして選択

この考え方の影響は、プログラミングの世界にとどまりません。誰が技術を握るのか、知識がどのように共有されるのか、改善が他の人の役に立てるのか、状況が変わったときにどんな選択肢が残るのか。こうしたことに直結します。

オープンソースは、すべてが無償であるという約束ではありません。ソフトウェアの維持に手間がかからないという約束でもありません。意図的に守られているのは、特定の自由です。それによって、誰かが作ったものを丸ごと信じるだけではなく、すでにある仕事の上に積み上げることができます。

なぜそれが重要なのかを理解するには、オープンソースとは何か、どのように発展してきたのか、どんな責任が伴うのか、そしてなぜ今も多くの人が自分の仕事を公開し続けるのかを知るのが近道です。

ソースコードとは、人間が読める形で書かれたソフトウェアのことです。開発者がプログラミング言語で書いた指示であり、機械が実行する形に置き換えられる前の姿です。ソースコードに手が届くかどうかが、「使うだけのソフトウェア」と「調べられるソフトウェア」を分けます。読める形がなければ、振る舞いを観察することしかできません。読める形があれば、なぜそう動くのか、ネットワークに何を送っているのか、不具合はどこにあるのか、変更はどこに入れるのかを、自分で、あるいは依頼した相手が確認できます。

オープンソースは、ソフトウェアの作り方を説明する言葉でも、たまたまコードが見える状態を指す言葉でもありません。ライセンスによってソフトウェアに付与される許諾の組み合わせであり、その許諾が満たすべき内容については、広く使われている定義があります。

Open Source Initiative はその定義を維持し、どのライセンスをオープンソースとみなすかの判断に使っています。定義が求めているのは、たとえば次のようなことです。ソフトウェアを自由に再配布できること。ソースコードが、実際に変更を加えるプログラマーが使う形で入手できること。変更版や派生版を作成し、配布できること。誰が使うか、何に使うかをライセンスが制限しないこと。そして、特定の技術やインターフェースの様式に依存する部分がないこと。この定義は Debian のガイドラインをもとにまとめられたもので、だからこそ「オープンソース」は、感じのよい言葉ではなく、意味の定まった言葉として機能します。

同じ言葉が二つの意味で使われるために、混乱が起きます。自由ソフトウェアの「自由」は、束縛がないという意味の自由です。価格がゼロという意味ではありません。たまたま両方が重なることはあります。Apache-2.0 は対価を求めないので、オープンソースのソフトウェアの多くは無償でも入手できます。しかし両者は別の話です。

オープンソースソフトウェアを動かすには、時間と技能と費用がかかります。ホスティングを用意し、更新を適用し、セキュリティの問題に対応し、利用者からの質問に答える人が必要です。ライセンスが求めないのは対価であり、求められるのは仕事です。この二つを分けておくと、ソフトウェアの選択を、目を開いた状態で行えます。

Apache-2.0 や MIT のような寛容なライセンスは、条件を軽くして許諾を与えます。ソフトウェアを使い、変更し、再配布できます。有償のサービスの中に組み込むこともできます。条件は、受け取った著作権表示と帰属表示を残すことです。

GNU GPL のようなコピーレフトのライセンスは、同じ自由を与えたうえで、配布について条件を加えます。複製を配布するとき、あるいは変更した版を配布するとき、そこから生まれた作品も同じ性格のライセンスでなければなりません。こうして、自由が次の受け取り手のところで失われないようにします。

これは緩いか厳しいかの違いではなく、作者が何を守りたいかの違いです。どちらもオープンソースのライセンスとして認められており、どちらも義務を配布に結び付けます。自分だけで使う分には、義務は生じません。

ライセンスが与えるのは許諾であり、能力ではありません。ある事業者から別の事業者へサイトを移せるとしても、リポジトリへのアクセスがあり、どの設定が使われているかを知り、公開の手順を理解していなければ、実際には移せません。

ファイルの複製は、ドメイン、ホスティングのアカウント、ビルドの設定が他人の名義であれば、ほとんど役に立ちません。だからこそ「移行できます」という説明は、信じるものではなく、確かめるものです。Foundation はこの二つを分けて扱います。許諾はライセンスによって恒久的に与えられ、実際の能力は、リポジトリ、設定、アセット、運用マニュアルの構成によって保たれます。

ソフトウェアの共有は、インターネットより古い習慣です。1950年代から1960年代にかけて、ソフトウェアは研究の現場と大型計算機の周辺で育ちました。利用者どうしは利用者グループを通じてコードを交換していました。当時、ソフトウェアはしばしばハードウェアに付随するものと考えられ、独立した商品ではありませんでした。

状況は、ソフトウェアがハードウェアとは別に販売されるようになり、利用者がソースコードを受け取る機会が減るにつれて変わりました。1970年代の終わりから1980年代にかけて、プログラムが著作権で保護される著作物であることが法制度上も明確になり、ソフトウェアはライセンス契約のもとで配られるのが一般的になります。1976年にビル・ゲイツが、当時の愛好家向け BASIC の複製について公開書簡を出したことは、それまで当然だった共有が、許諾のない複製として扱われるようになったことを示す早い例です。

その後も共有は可能でしたが、先に許諾を得る必要がありました。現在のオープンソースは、その状況への答えです。昔に戻す運動ではなく、共有する自由を、合法で、あてにできる形にする方法です。

1983年、リチャード・ストールマンは GNU プロジェクトを発表しました。自由に使い、調べ、変更し、配布できる完全なオペレーティングシステムを作る試みです。1985年には Free Software Foundation を設立し、GNU 宣言を書きました。そこでは理由が技術ではなく、利用者の自由の問題として説明されています。

このプロジェクトは、エディタの Emacs、コンパイラの GCC、デバッガ、ライブラリ、コマンドラインツールなど、今も使われている部品を生みました。しかし最も影響が大きかったのはライセンスです。1989年に最初の版が、1991年に第2版が公開された GNU General Public License は、著作権を使って自由を保証します。誰でも使って変更できる。ただし配布する変更版は同じライセンスでなければならない。この考え方はコピーレフトと呼ばれ、自由を呼びかけから法的な条件へ変えました。

1990年代初めまで欠けていたのはカーネル、つまりハードウェアを制御する中核部分でした。その空白を、別の人の仕事が埋めることになります。

1991年、リヌス・トルバルズは趣味で書いたカーネルを発表し、他の人にコメントと改善を呼びかけました。すでにあった GNU のツールと組み合わさって、それは完全なシステムになります。GNU/Linux と呼ばれるものです。

重要なのは結果だけではなく、進め方でした。開発はインターネット上で公開されて進みました。変更はメーリングリストに送られ、公開の場で議論され、採否も公開で決まります。この進め方は、後に日常の道具にも組み込まれていきます。バージョン管理システムの Git は、2005年にカーネルの開発を管理するために書かれました。

この方法で本格的な基盤が作れることは、使われ方によって示されました。Linux 系のシステムは世界のサーバーの多くを動かし、携帯電話の基盤にもなり、個人のコンピュータでも使われています。変更と再配布の自由があるため、その仕事は、始めた人がいなくなっても、調べ、調整し、続けられます。

1998年1月、Netscape はブラウザ Navigator のコードを公開すると発表し、同年3月にそのコードが公開されました。これは Mozilla プロジェクトの始まりです。この出来事は、企業の関心を公開型の開発に向けました。

同じ1998年の2月、自由ソフトウェアに長く関わってきた人たちがカリフォルニア州パロアルトに集まりました。そこで新しい呼び名、オープンソース（open source）が選ばれます。同じ価値を、無償であるという誤解を招かずに伝えるためでした。あわせて Open Source Initiative が設立され、その定義は、前年からあった Debian のガイドラインをもとにまとめられました。

なぜ新しい言葉が必要だったのか。公開型の開発には、倫理の議論に関心のない企業でも判断できる利点があります。1998年に必要だったのは、そこを伝えることでした。

自由ソフトウェアとオープンソースは、しばしば同じものと見なされます。日常の実務では、実際にほぼ同じです。どちらも同じライセンスを使い、どちらも、使って変更して配布できるソフトウェアを生みます。違いは力点にあります。

自由ソフトウェアの伝統では、利用者の自由はそれ自体が目的であり、倫理の問題として扱われます。オープンソースの側は、公開型の開発のほうが良いソフトウェアができ、信頼しやすいという実利に力点を置き、職場でも受け入れられやすい言葉としてこの呼び名を使います。Apache-2.0 はどちらの立場からも認められており、GNU GPL も同様です。

この違いは、立場を持つ人にとっては現実のものです。両方の側から影響力のある文章が出ています。ただ、ソフトウェアを使う側にとって覚えておくべきなのは、論争ではなく実務上の帰結です。何ができて何ができないかは、呼び名ではなく、そのソフトウェアに付されたライセンスが決めます。

オープンソースのプロジェクトは、たいてい小さく個人的な出来事から始まります。誰かが問題に直面し、その場の解決策を書き、同じ問題を抱える人が他にもいると気づく。学習のため、自分の仕事を役に立てたいから、同じ分野の人に自分の仕事が評価されるから、といった理由もよく挙がります。

組織の場合、理由はもっと実務的です。多くの主体が使うライブラリは、それぞれの会社が作り直すより、共同で維持するほうが安くつきます。優秀な人材を引き寄せるため、自分たちが頼っている標準の方向に影響を与えるため、あるいは公的資金で作られたソフトウェアは誰でも使える形にすべきだから、という理由もあります。

より広い理由もあります。一部の基盤は、一つの会社だけに依存していると健全ではありません。コードとライセンスを公開しておけば、状況が変わっても、その仕事を他の人が続けられます。

最初にコードを書く時間は、仕事全体のごく一部です。時間の大半は、不具合の報告を読み、利用者からの質問に答え、依存関係を更新し、セキュリティの問題に対応し、ドキュメントを書き直し、リリースを用意し、更新によって既存の使い方が壊れないようにするために使われます。

多くの人にとって重要なプロジェクトが、ごく少数の人に支えられていることも珍しくありません。一人に依存している状態は、その人が手を止めれば仕事も止まるという、現実の危険です。

だからこそ、簡単に見える支援が効きます。明確な報告は修正までの時間を縮めます。他の利用者への回答は同じ質問の繰り返しを減らします。資金の支援は、他の仕事の合間ではなく、決まった時間をこの作業に充てることを可能にします。

オープンソースのライセンスは、品質の保証を伴いません。Apache-2.0 も他の寛容なライセンスと同じく、ソフトウェアは現状のまま提供され、いかなる保証も付かないと述べています。特定の不具合を直すことや、サービスを提供することを、メンテナーに義務づけるものでもありません。

その代わりに得られるのは、自分で動ける自由です。自分で直す、別の開発者に依頼する、必要に合わない部分を差し替える。Foundation も同じ考え方で作られており、そのためこのページでは、存在しないサービスを約束しません。

自由には責任が伴います。どの版を使うか、いつ更新するか、バックアップをどう確かめるかは、あなたが決めます。確かな選択肢のほうが、守れない約束より役に立ちます。

もっとも役に立つのは、正確な報告です。何を期待したか、実際に何が起きたか、どうすれば再現できるか、どの版を使っているか。改善の提案も、思いついた解決策だけでなく、解決したい問題を説明するほうが役に立ちます。

ドキュメントの修正や翻訳は、次の読者に直接届きます。公開の場で他の人の質問に答えることは、同じ疑問を持つ人を助けます。

技術的な作業については、変更を受け入れるかどうかはプロジェクトのメンテナーが決めます。それは、手元の複製を変更する自由を狭めるものではありません。自分の版を変更して使うことは、いつでもできます。

Apache-2.0 は寛容で、企業の間で広く知られており、あなた自身の成果を公開することを求めません。世界中で有効な著作権の許諾を、無償で、非独占的に、取り消しできない形で与えます。受け取った版について与えられた許諾は、後から撤回できません。

さらに、貢献者からの特許の許諾が明記されています。短い寛容型のライセンスは特許について何も述べていないことが多く、Apache-2.0 はそこを明示します。利用者の独立性を重視するプロジェクトにとって、この明確さは利点です。

条件は少なく、実務的です。ソフトウェア、または変更した版を配布するときは、ライセンスの写しを添え、変更したファイルにその旨を示し、受け取った著作権・特許・商標・帰属の表示を残します。

ライセンスが与えるのは許諾です。日々の独立性は、もっと地に足のついたものに支えられます。自分でアクセスできるリポジトリ、型と検証のある設定、ファイルとして保存されたコンテンツ、差し替えられるアセット、誰でも読める運用マニュアル、そして Provelopment に尋ねなくても他の人が実行できる公開手順です。

Foundation は、この二つが一緒に成り立つように作られています。許諾は Apache-2.0 が与え、実際の能力は、プロジェクトが仕事をどのように保存し、どのように文書化しているかが支えます。何を誰が持つのかの詳細は、所有と移行のページで別に説明しています。

どのライセンスも、運用の費用そのものを消しはしません。サイトには更新、監視、動作確認が必要で、それはあなた自身か、あなたが選んだ開発者か、対価を払う事業者が行います。それはオープンソースの欠点ではなく、実際の仕事の姿です。