オープンソースの次に来るもの

2019/04/08 09:00

前回の投稿では、オープンソースの歴史について議論し、以下のような主張で締め括りました:

今日の開発者たちは、この歴史について学んだこともなく、気にすることも、またそれとは無関係であると積極的に考えることもありません。・・・「オープンソース」が新たに名付けられたのと同じ理由で、今日の開発者たちから起こる運動にも、新しい名前が必要になるでしょう。

オープンソースのイデオロギーの歴史について話しましたが、それは真に開発者の関係するところではありません。私は、開発者たちがソースコードを非公開にする世界に逆戻りしているとは思いません。そうではなく、これはフリーソフトウェアの非常に古い議論に関連したものです。フリーソフトウェア財団の言葉を引用すると:

「フリーソフトウェア」とは、ユーザーの自由とコミュニティを尊重するソフトウェアを意味します。広く言えば、ユーザーがソフトウェアを使用、コピー、配布、研究、変更、そして改良する自由を有している、ということです。従って、「フリーソフトウェア」とは自由についてであり、価格についてではありません。このコンセプトを理解するためには、「free」を「free beer(無料のビール)」のfreeではなく、「free speech(言論の自由)」のfreeと捉えてください。ソフトウェアが無料であることを意味するのではないと示すため、フランス語・スペイン語におけるfreedomの「free」にあたる単語を借りて、「libre software」と呼んだりもします。

これと同様に、私は開発者たちが「言論の自由」の「自由」というコンセプトに反対しているとは思いません。彼らは、フリーソフトウェアとオープンソースの現在の定義が、実際にそのように「自由」なソフトウェアを生み出すとは信じていないのでしょう。

「自由」とは何を意味するのか?

「言論の自由」の「自由」とはそれ自体、フリーソフトウェア・オープンソースの異なるグループ間の分裂を意味します。この分裂の根底にあるのは戦略の違いです。具体的な戦術はシンプルなもので、2種類のライセンスのうち、どちらを選ぶか?ということです。その2つとは:

  • パーミッシブ・ライセンス
  • 好みに応じて、ウイルス性ライセンスまたはコピーレフト・ライセンス

オープンソースの支持者はパーミッシブ・ライセンスを好み、フリーソフトウェアの支持者はウイルス性 / コピーレフト・ライセンスを好みます。その違いは何でしょうか?まあ、それは別の投稿の議題となるでしょう。なぜってほら、もう万事休しています。根本的な問題はすでに発生しているのです。あなたは気付かなかったかもしれませんね。私もこれに気付くまでに、長い時間が掛かりましたから。

トリックを公開する前に、少し個人的な話をさせてください。

信心の喪失

私はかつて正真正銘の、フリーソフトウェアの熱心な支持者でした。リチャード・ストールマンの講演会をよく見ていたし、自分のパソコンには可能な限り、フリーソフトウェアしかインストールしませんでした。残りを取り除くために、coreboot対応のラップトップを購入しようと検討する程でした。

しかしそれから徐々に、私の気持ちは薄れて行きました。それは、私がカトリックを捨てると決めた時に酷似していると感じました。私はこれらの信仰が実際にはあまり役立たないこと、より率直に言うと、多くの場合有害でさえあることに気付き始めました。私はここで、フリーソフトウェアが有害だであると主張したい訳ではありません。私が言っているのは、無料のドライバが無いためにラップトップでWi-fi接続を使用しないというのが、基本的に何の役にも立たず、ただ害を及ぼすだけだということです。たとえあなたが、ボイコットが上手くいくと考えるタイプの人であったとしても、十分な規模のボイコットを形成するために必要なフリーソフトウェアの抵抗勢力は存在しません。それでもボイコットを実行し、同時にメッセージを送信したいのです。

私は、自分が使っていたソフトウェアの多くがパーミッシブ・ライセンスの下にあり、またそれが、与えられたソースの力を借りてソフトウェアを改善する夢を現実のものにする唯一の方法、GPL'dであったとしても尚好ましいものであるということに気付きました。そこで私は始めました。

その時点では、パーミッシブ・ライセンスは普及の一途を辿っていました。そのため私は、自分自身が奇妙な立場にあることに気付きました:フリーソフトウェアの熱心な支持者であったにも関わらず、私はほぼ独占的にオープンソースソフトウェアを構築していたのです。身の周りの至る所で、私はあらゆる方向からのコピーレフトに対する攻撃を見ました。そして、コピーレフトは失われていきました。

ある時点から、私は気に留めなくなりました。

フリーソフトウェア・オープンソースとは、ライセンスに関するもの

少し脱線しますが、ここに問題があります:フリーソフトウェアとオープンソースとは何であるかという話が、そのまま途切れることなくライセンスの話に突然切り替わったことに注目してください。これは、2つが事実上同義語であるためです。もう一度フリーソフトウェア財団の言葉を引用します:

公開されているソフトウェアは、フリーソフトウェアであるべきです。そうするためには、フリーソフトウェアライセンスの下でリリースする必要があります。

オープンソース・イニシアチブはこう言います:

オープンソースは単にソースコードへのアクセスを意味するのではありません。オープンソースソフトウェアの配布条件として、以下の基準を満たす必要があります:

フリーソフトウェアとオープンソースは、どちらも定義上、ソフトウェアライセンスに対する設計上の特定の制約です。フリーソフトウェア財団により始められ、オープンソース・イニシアチブがそれを継承しました。

フリーソフトウェア財団のページからの更なる引用が、更なる理解に役立つでしょう:

プログラムをコピーレフトするには、まずそのプログラムが著作権で保護されているという記述をします。次に、配布条件を追加します。これは、配布条件の変更が無い場合に限り、プログラムのコードまたはそこから派生するプログラムについて使用、変更、および再配布する権利を、すべての人に付与する法的手段です。このようにして、コードと自由は法的に不可分になります。

フリーソフトウェア財団はコピーレフト、つまり著作権を、ソフトウェアの自由を強制するための合法的なツールと見なしています。このことが、フリーソフトウェアの支持者をしばしば奇妙な立場に置きます。

例えば、彼らは著作権を保護するソフトウェアツール、Digital Rights Managementに反対して熱心にキャンペーンを行いますが、GPLの目的とあれば、著作権の拡大をサポートすることもあります(ご覧の通り、論争により少し後退しましたが)。

ライセンスは十分ではない

それではなぜ、フリーソフトウェアとオープンソースのコンセプトが本質的にライセンスに結びついていることが問題なのでしょう?それは、2つの運動の目的・目標は配布、つまり消費に関するものですが、今日人々が最も気にしているのはソフトウェアの制作についてだからです。ソフトウェアライセンスは流通を規制しますが、制作を規制することはできません。(技術的には可能ですが、実際には不可能です。以下に説明します。)これもまた、オープンソースに続くすべてのものにとって最大の課題であり、前の世代の法的戦略は頼りになりません。ここで解決策を提示することは、私にはできません。

まずは、開発者が何を望んでいるのかを説明しましょう。その後で、ライセンスがこれを達成できない理由について述べます。

開発者は制作を重要視している

前回の投稿では、殆どの開発者はオープンソースに混乱させられていると主張しました。私の主張に関する、2つの具体例を挙げましょう。

  • ある会社が、パーミッシブ・ライセンスを使用したオープンソースソフトウェアを入手し、それを自社製品に使用するとします。製品に使用する過程で、彼らはそのソフトウェアを改良します。この時彼らは、元のプロジェクトに対して何かしらの見返りを要求されるでしょうか?
  • ある会社が、コピーレフト・ライセンスを使用したオープンソースソフトウェアを入手し、それを自社製品に使用するとします。製品に使用する過程で、彼らはそのソフトウェアを改良します。彼らはライセンスを遵守するため、250ページに及ぶ「ソフトウェア使用許諾契約書」に次のような一文を追加します。「ソフトウェアの特定のコンポーネント、およびソフトウェアに含まれるサードパーティー品のオープンソースプログラムは、●●(会社名)によってオープンソースのWebサイト(http://www.opensource.mycompany.com/)上で既に提供されているか、または提供される可能性があります。」そのWebサイトには、(大幅に変更された)ソースが書かれたzipファイルが含まれています。ここでも、彼らはそれ以上の何かを要求されるでしょうか?

今日の多くの開発者にこの2つの質問をすれば、それぞれ次のような答えが返ってくるでしょう:

  • そうさ、だからオープンソースというのは厄介なんだ。企業は取るばっかりで、何も与えてくれはしないから。
  • ・・・何か、いかにも胡散臭いね。

多くの経験を積んできた人ならば、2つ目の例に挙げた状況が分かるかもしれません。これは、AppleがWebKitで行ったことです。GPLの下でライセンスされた、KHTMLというプロジェクトがありました。Appleはそれを分岐させ、GPLに準拠するために、まさに上記のことを行ったのです。そうすることは、完全に彼らの権利の範囲内でした。しかし現在でさえ、それは「オープンソースの精神ではなかった」と多くの人が認識しています。これらの戦略は、しばしば「ソースダンプ」や「コードボム」と呼ばれます。

しかし、ここでは精神ではなく、後者に続くかもしれない態度が、重要なポイントです。多くの開発者は、オープンソースがソフトウェア製品の遵守する特定のライセンスであることを理解しておらず、態度やイデオロギーだと考えています。そしてそのイデオロギーは、ソフトウェアの消費だけに関係するものではなく、その制作にも関係するものです。オープンソースプロジェクトには、公開されたバグ管理システムが必要です。議論のためにメーリングリストがあるべきです。あなたはソフトウェアの開発を観察し、理想を言うとそれに参加可能であるべきです。公開されたコードに焦点を合わせることは本末転倒です。これは実際、「ソースが利用可能な」ライセンスが嘲笑される理由の一つです。それはソースが開かれているということではありません。開かれていることは、オープンソースであることの必要条件であっても、十分条件ではありません。通常、これは流通の問題と分類されていますが、私は多くの人が制作の問題として理解していると思います。

このプロセス重視が、GNUプロジェクトが同様に支持を失っている理由であると私は思います。GNUプロジェクトがフリーソフトウェア開発に使用するツールは難解で見苦しく、そしてそれらに特有のものです。これは、多くの古い学校のオープンソースプロジェクトと同じです。もしもBugzillaのインスタンスを二度と目にすることが無いなら、私は幸せに死ねるでしょう。これが、ソフトウェアを構築するための素晴らしい開発者体験を提供したGitHubが、成功を収めた理由です。個人的に同意頂けないかもしれませんが、数字がそれを物語っています。GitHubは私有ソフトウェアなので、フリーソフトウェア財団はGitHubに移行せず、それが彼らの価値観に反すると考えています。多くの開発者は、それをタダで使うことができ、またそれを使って作られたソフトウェアはオープンソースであると思っています。彼らはこれを、自分たちの価値観と一致していると考えます。

開発者がオープンソースにおける問題について話すとき、それが制作上の問題であることがしばしばです。企業は、お金や開発者の時間を「返済」しません。もし開発者がオープンソースソフトウェアの独自の拡張機能を開発しても、それらの拡張機能がコミュニティと共有されていないと言って憤慨するプログラマーがいるとは思えません。彼らは訳もなく、制作工程がさらなる圧力によって妨げられないかと気にかけています。もしある企業がオープンソースプロジェクトに独自の機能を追加しようとするなら、オープンソース開発の部分でさらに5人の従業員を雇わなければなりません。フリーソフトウェア財団はこれを悲劇と呼んでいます。一般大衆は満足していません。新世代のオープンソース開発者はこうした企業を、彼らが使用し重要視するものの開発に貢献してくれている、責任ある企業と見なしています。

ソフトウェアライセンスは、ソースコードの配布時に制限を加えることしかできません。誰かにバグ管理システムや行動規範を強制したり、アップデートを受け入れさせたりすることはできません。コピーレフトは、プロジェクトに最小限の「貢献」を返すことができますが、誠実なものに対して強制することはできません。このことにより、多くの開発者が重要視している価値観で何かを構築するためのツールとしては、不適切なものになります。

課題

ソフトウェアの公開制作に関する運動を、どうすれば組織できるでしょうか?それには多くの課題があります。

まず第一に、あなたは法制度がそのようなことを強制することでさえも望みますか?これには賛否両論あります。法の力が無ければ、企業は準拠しそうにありません。それが、私たちがこの混乱に陥っている理由の一つです!

では次に、あなたは法的システムがどういう訳か、ソフトウェア制作に対してこの種の管理を強制することを望みます。しかし、どうやって?フリーソフトウェアとオープンソースが採用している戦略を詳しく見てみると、知的財産法の一種であり、財産法をモデルにしたライセンスを使用しています。先程、ライセンスを使って制作を規制することはできないと述べましたが、技術的な話をすると、これは正しくありません。例えば、私がマクドナルドのようなブランドを所有しているとします。私はそのブランドを取り巻く知的財産を所有しています。私は他の人々に対して、彼らがハンバーガー(何でも良いのですが)を作ることを条件に、ある知的財産について仕様に基づいたライセンスを与えることができます。

これは、オープンソースが設定されている方法では上手く行きません。ここでは、物事を指図するのはソフトウェア開発者、ライセンス条項を決めるのはプロジェクトと、真逆になっています。

私は、この種のことをするための別のパターンについて考えさせられました。次に挙げるものを見たことがありませんか?

製品に付けられるこちらのマークは、「認証」と呼ばれるプロセスの一部です。画像自体は「認証マーク」と呼ばれます。この画像を製品上で使用するには、「認証機関」、この場合USDAに申請する必要があります。この機関はある種の試験を設定しており、製品がそれに合格すれば、製品は認証されたと言えます。ここでは意図的に有機食品を選びました。その認証は、殆どが食品の生産プロセスに関するものです。

テクノロジーは、これらの種類のプロセスと無関係なものではありません:

理論上は、異なる種類の文書を作成する組織というのを想像することができます。ソースコードのライセンスの代わりに、彼らは「Open Development Certified(オープン系開発認証品)」と言うでしょう。そうしてプロジェクトの申請が可能になり、承認されるか拒否されるかするでしょう。

しかし、この解決策が上手くいくかどうかは分かりません。

1つには、業界の一部で認証が受け入れられていても、ソフトウェア開発者はかなり強い偏見を持っているように感じます。それ以外にも、他に2つの大きな問題があります:誰がこの認証を行うのか、またどのようにして基準を決定するか。何が正しいのかを判断し、大多数の人の賛成を得る提案をする道徳的権限を、誰が持っているのかは明白ではありません。彼らは、それら一連のルールの行く末を決定するという、大きな仕事を与えられるでしょう。それは、ビルトインビジネスモデルの優れた特性を持っており、認証の申請に対して請求を掛けられます。しかしそれには多くの問題もあります。たとえそれらの問題すべてを整理したとしても、私がフリーソフトウェアに関して上で述べたのと同じ「ボイコット」問題に反することになります。この認証は、使用するソフトウェアがOpen Development Certified(オープン系開発認証品)であることが要求される場合にのみ、意味があります。このケースが当てはまるかどうかは分かりません。

もう1つの選択肢は、一種の「開発者組合」です。その開発者たちが働く企業に対し、オープンソースプロジェクトに貢献するよう圧力を掛けます。多くの開発者は過激な反組合派のようで、テクノロジー企業も同じです。今日において、これが現実的な道であるかどうかは分かりません。

では、ここからどこへ向かうのか?

突き詰めると、私はまだ答えよりも多くの疑問を残しています。しかし、私はその問題を特定できているとは思います。それは、多くの開発者がソフトウェアの自由を、再配布を目的とした純粋なライセンスよりも大きなものと考えている、ということです。これは、フリーソフトウェアとオープンソースの運動の目標を拡大しようと考える人々のための、新たなフロンティアです。古いツールは不十分であり、私は必要とされる代替品が機能するのか、あるいは存在するのかさえ確信が持てません。

それでも、検討されるべきものでしょう。

この記事は、著者の許可を得て翻訳しています。なお、原文はこちらです。

新着ピック  






















新着ニュース

LINE「OpenChat」、トークルーム検索機能の再開を延期 「検索精度を上げるため」

バーチャルタレントがスナックのママに--“場所を選ばない接客”の働き方

リザーブドインスタンス(RI)を間違わずに購入したい! それなら AWS CLI を活用してみよう。 -オペ部だより- | DevelopersIO

ローソン、「深夜に店員ゼロ」を実験へ QRコードで入店、セルフレジで決済 遠隔監視で万引き防止

銘菓「ニコンようかん」、ネット販売終了 「裏の主力製品がなくなる」と惜しむ声

WindowsでAWS CDK(C#)の開発環境を整えてみた | DevelopersIO

TC Tokyo超早割チケットは8月末まで!トヨタの自動運転開発子会社TRI-ADのCEOが登壇決定 | TechCrunch Japan

たこ焼きロボからマイクロモビリティまで竹芝埠頭にロボ集結 | TechCrunch Japan

家事代行のベアーズ、マンションにスタッフ常駐の新サービス「MAUCHI」開始

対象店舗でビットコイン決済するとTポイントを付与--bitFlyerとTポイントが業務提携

野村不動産アーバンネット、不動産売買支援システム「Kimar」を導入

Application Load BalancerのリスナールールによるIP制限 | DevelopersIO

Application Load Balancerのリ...

DevelopersIO / 4時間前


最短2日で物件売却のすむたすが直販を開始--「すむたす直販」が担う中古流通比率の引き上げ

ローソン、深夜時間帯を“無人化”する実証実験--横浜で半年ほど実施

Amazon VPC設計時に気をつけたい基本の5のこと | DevelopersIO

ソニー、学校向けプログラミング学習キット「KOOVベーシックキット」を9月に発売

「Zaif」元運営のテックビューロ、仮想通貨交換業を廃業へ

なぜβ版でスタート? 独自プランは? IIJに聞く「eSIM」戦略

Github ActionsのワークフローへCircleCIのワークフロー流用を試してみた | DevelopersIO

ブランドリセール「RECLO」のアクティブソナー、中国企業などから約36億円を調達

もっと見る
ログイン
会員登録
Register
記事をPICKする

会員登録すると、もっと便利に利用できます。