序文Elasticsearch が有名なオープンソース検索エンジンであることは誰もが知っていますが、もはやオープンソースソフトウェアではなくなったことをご存知ですか？一体どうしてそうなったのでしょうか？ 今年初め、Elasticは主力製品であるElasticsearch検索エンジンとKibana視覚化プラットフォームのライセンスをApache 2.0から、MongoDBが2018年に開始した疑似オープンソースライセンスであるSSPL（Server-Side Public License）に変更しました。数日後、AWSはフォークを発表してこれに応えました。これはAWSが独自のシステムを作成することを意味し、AWSは独自のバージョンこそが真のオープンソースであるとさえ主張しました。 Elasticはなぜこれを行っているのでしょうか？SSPLとは何ですか？なぜオープンソースではないのですか？ Elasticは公式ウェブサイトで次のように説明しています: 2 過去3年間で市場は進化し、オープンソース企業が高い投資水準とイノベーションを維持するには、自社のソフトウェアをより適切に保護する必要があることをコミュニティは徐々に認識するようになりました。配信モデルがSaaSへと移行する中で、一部のクラウドサービスプロバイダーはオープンソース製品を悪用し、コミュニティに何も還元することなくサービスとして提供しています。こうした行為は、本来製品に再投資できる資金を逸失させ、ユーザーとコミュニティの利益を損なっています。 次期Elastic 7.11リリース以降、現在Apache 2.0ライセンスで提供されているElasticsearchとKibanaのソースコードを、デュアルライセンスモデル（SSPL + Elasticライセンス）に変更します。これにより、ユーザーはニーズに最適なライセンスを選択できます。SSPLは、MongoDBによって作成されたソースコード共有ライセンスです。オープン性の原則を体現すると同時に保護機能も備えており、パブリッククラウドプロバイダーがコミュニティへの貢献なしにオープンソース製品をサービスとして提供することを防ぎます。SSPLでは、製品のソースコードを自由かつ無制限に使用および改変できますが、SSPLライセンスでは、製品をサービスとして提供する場合、改変部分と独自の管理システムのソースコードも公開する必要があります。 簡単に言うと、Elastic は、一部のクラウドベンダーが Elasticsearch と Kibana を使用して多額の利益を上げながら、Elastic に何も還元していないことに不満を抱き、ライセンスを変更することを決定しました。 Apache 2.0 ライセンスによれば、クラウド プロバイダーがフィードバックを提供しないことは合法かつ準拠であるため、クラウド プロバイダーにフィードバックを提供するよう強制するにはライセンスを変更する必要があります。 クラウドベンダーは屈服しません。 SSPL は偽のオープンソースライセンスですか?OSI の Web サイトでは、SSPL は偽のオープンソース ライセンスであると明記されています。 OSI（オープンソース・イニシアティブ）は、1998年2月に、著名なブルース・ペレンズ氏と「ハッカーの長老」と呼ばれるエリック・S・レイモンド氏によって設立されました。OSIは、オープンソース定義（OSD）と承認済みオープンソースライセンスのリストを管理しています。<sup>4</sup> OSIの目標は、オープンソースソフトウェアとオープンソースコミュニティの促進と保護です。 OSI の声明は実際には Elastic に向けられたもので、次のように述べています。 疑似オープンソースライセンスに切り替えた企業は、自社製品は新しいライセンスの下でも「オープン」なままであると主張しているが、実際には新しいライセンスはユーザーの権利を奪っている。 Elastic の今回の動きは、同社のオープンソース ライセンス モデルの失敗や不十分さを意味するものではなく、単に Elastic の現在のビジネス モデルがオープンソース ライセンスの設計と一致しておらず、独自のライセンス (ソース コードも入手可能) が必要であることを示しているに過ぎません。 OSI は、SSPL の経営陣が OSI 認証を申請したが、認証される可能性が低いと気付き、申請を取り下げたと述べています。 SSPLを具体的に調べてみたところ、GPLとかなり似ていて、1つか2つの小さな違いがあるだけです。全体的に見ると、SSPLでもソースコードが公開され、改変やリリースが許可されています。しかし、OSIの観点から見ると、それだけでは不十分です。 どのようなライセンスがオープンソースライセンスと呼べるのでしょうか? OSI（オープンソース協会）は、公式ウェブサイトでオープンソース（OSD）を明確に定義しています。したがって、ライセンスがオープンソースかどうかを判断するには、OSDに準拠しているかどうかを確認する必要があります。 これまで紹介してきたMITライセンス、Apache 2.0（以下Apache）、GPL v2、v3はいずれもOSDに準拠しており、オープンソースライセンスです。 それでは、OSD について学んでみましょう。 オープンソースの定義ソフトウェアがオープンソースであるかどうかは、ライセンスの条件によって決まります。ライセンスが以下の10の要件を満たしている場合、オープンソースとみなされます。 以下の文章において、「ソフトウェア」、「プログラム」、「作品」はすべて、ライセンスによって保護されるソフトウェアを指します。「ライセンシー」、「受領者」、「ユーザー」はすべて、ソフトウェアを使用する個人（法人を含む）を指します。「リリース」、「公開」、「配布」はすべて同じ意味です。 OSD1。無料で配布可能ライセンスは、ソフトウェアの配布の一部としてソフトウェアを販売または配布することを制限してはならず、また、そのような販売に対してロイヤルティやその他の料金を請求してはなりません。 諺にもあるように、「他人があなたのソフトウェアを販売することを制限すべきではないし、無料で配布することを制限すべきでもない。誰かがあなたのソフトウェアを販売した場合、あなたは金銭を要求することはできない。」 1. 自由な再配布 ライセンスは、複数の異なるソースからのプログラムを含む集合的なソフトウェア配布物の一部として、当該ソフトウェアを販売または無償で提供することをいかなる者も制限するものではありません。また、ライセンスは、そのような販売に対してロイヤルティその他の料金を要求するものではありません。 コメント: 無料でこれを行うのは非常に高潔なことだとしか言えません。ライセンスを変更した人のように、それができない人はたくさんいます。 正直に言うと、一見すると少し混乱しました。「コンポーネント」「アグリゲート」「ソフトウェアディストリビューション」「複数の異なるソース」とは一体何のことでしょうか？後になって、OSDはDebianフリーソフトウェアガイドライン（DFSG）に由来し、DebianはLinuxディストリビューションであることに気づきました。Linuxディストリビューションには、当然のことながら多くのフリーソフトウェアやオープンソースソフトウェアが含まれています。そのため、OSIの観点から見ると、たとえオリジナルの作者が作成したディストリビューションであっても、ほぼすべてのオープンソースソフトウェアが何らかのディストリビューションに含まれているように見えます。 OSD1では、これがスタンドアロンのオープンソースソフトウェアに適用されるかどうかは明確に述べられていませんが、文脈から判断すると、適用される可能性が高いでしょう。業界の専門家数名に相談したところ、全員が、たとえソフトウェアディストリビューションの一部でなくても販売されていると回答しました。この点から見ると、OSDの文言は厳密ではありません。 では、MIT、Apache、GPLのすべてがこのルールを満たしているかどうかを見てみましょう。MITは第1段落、Apacheは第3段落、GPL v2は第1段落、GPL v3は第4段落にあります。いずれもソースコードまたはオブジェクトコードを販売できることを明確に述べています。 さらに、GPL v3の第4条、第5条、第6条（第5条と第6条は第4条を参照）では、ソースコードを配布する場合は、任意の料金を請求できると規定されています。ただし、ターゲットコードを販売する場合は、ソースコードに最大限でもコピー料金を請求することができます。これは、ターゲットコードを販売する際にソースコードを引き渡さない人がいることを防ぐためです（ターゲットコードに料金を請求することは許容されますが、ソースコードに法外な料金を請求することは許容されます）。 OSD2. ソースコードソフトウェアにはソースコードが付属する必要があり、ソースコード形式またはオブジェクトコード形式のいずれでも配布が許可されなければなりません。ソースコードがリリースに含まれていない場合は、合理的な複製料金で入手できるように、広く宣伝された方法が用意されていなければなりません。理想的には、インターネットからの無料ダウンロードが挙げられます。ソースコードを意図的に隠蔽することは許可されません。提供されるソースコードは、プログラマーがプログラムを変更する際に最も好む形式でなければなりません。同じ理由で、前処理または翻訳されたソースコードも許可されません。 諺にもあるように、プログラムには必ずソースコードが付属します。ソースコードのないソフトウェアはオープンソースではありません。ソフトウェアをリリースする際にソースコードが含まれていない場合は、無料または非常に低価格で人々に提供する必要があります。ソースコードを提供する場合は、惜しみなく提供すべきであり、惜しみなく提供すべきではありません。
解説：再配布の要件は、ソースコードまたはオブジェクトコードの形式で配布できることであり、ソースコードを含める必要はないことに注意してください。MITやApacheのような寛容なライセンスは、再配布時にソースコードを含めることを要求しないため、この要件を満たすことができます（一方、GPLはソースコードを含めることを要求します）。 OSD3. 派生作品他者が作品の改変や派生作品を作成することを許可し、それらを同じライセンスの下で配布することを許可する必要があります。 よく言われるように、「人々に何かを変えてもらうには、それを配布する能力も必要です。」他者が他のライセンスで配布することを望まないのであれば、少なくともあなたのライセンスで配布できるようにすべきです。
コメント: 改変を許可しないなら、それはオープンソースではありません。あまり閉鎖的にならないで。 MIT、Apache、GPLはいずれも改変および派生作品の制作を許可しており、同じライセンスの下での再配布も許可しています。MITは最初の段落でサブライセンスの許可を明記しており、Apacheは2番目の条項でサブライセンスの許可を明記しており、同じライセンスが認められていることを示しています。しかし、GPL v2の第6条とGPL v3の第10条では、下流のアプリケーションは自動的にGPLライセンスを取得すると規定されています。 注：ブラック法律辞典によると、サブライセンスとは「元のライセンスに基づいてライセンシーに付与された権利の一部または全部を第三者に付与するライセンスまたは契約」です。言い換えれば、サブライセンスとは、元のライセンスを付与した者が、取得した権利の全部または一部を第三者にサブライセンスできることを意味します。 OSD4. オリジナル作者のソースコードの完全性。「ソースコードを変更できない」という要件を課すことは可能ですが、「ソースコード＋パッチ」を含む配布シナリオに限られます。ライセンスは、変更されたソースコードから構築されたソフトウェアの配布を明示的に許可する必要があります。ライセンスによっては、派生作品に異なるソフトウェア名やバージョン番号を付与することを義務付ける場合があります。 簡単に言えば、変更したコードを元の作者のコードと明確に区別することを要求できます。変更したコードを他の人が配布できるようにすることができます。異なる名前やバージョン番号を使用するように要求できます (もちろん、この要求は行わない方がよいでしょう)。
解説：これは妥協案です。OSIモデルは元々「任意の変更を許可する」ことを推奨していました。しかし、オープンソースの作者の中には完全性に非常にこだわる人もいることを考慮し、OSDでは、他者による低品質な変更によって元の作者の評判が損なわれるのを防ぐため、ライセンスにそのような要件を追加することを許可しています。 OSD5. 個人またはグループに対する差別は行いません。いかなる個人またはグループも差別されてはならない。 諺にもあるように、特定の人だけが使えるとか、特定の人が使えないとか言うことはできません。特に、中国人が使えないなどと言うのは絶対に許されません。 法的問題を考慮し、OSD 5 の注釈では輸出制限について具体的に言及しており、次のように述べています。「一部の国（米国を含む）では、特定の種類のソフトウェアに輸出制限が課せられています。ライセンスには、ライセンシーに法律遵守の義務を思い出させる警告を含めることができますが、ライセンス自体にはそのような制限を含めないでください。」
解説：これはOSI（社会科学機構）の人道主義精神を反映しており、すべての人を平等に扱います。しかし、どこにいても法律は遵守されなければなりません。 OSD6. いかなる分野に対しても差別をしない。プログラムの使用を特定の分野に限定することはできません。例えば、商用利用は禁止、遺伝子研究には利用禁止などとすることはできません。 諺にもあるように、この業界には許可しておいて、あの業界には許可しないということはできません。特に、商用利用やクラウドサービスには使用できないと言うことはできません。
解説：商用利用が許可されていないソフトウェアは、明らかにオープンソースソフトウェアではありません。これは、OSIが商用アプリケーションの価値を理解しているからです。 例を挙げると、2018 年に米国で ICE 廃止イベントが開催され、その際に OSD6 に違反する人物がいました。 9.11同時多発テロ後に設立されたICE（移民税関捜査局）は、主に国内における移民関連の捜査と法執行を担当しています。ICEは不法移民を拘留し、国外追放する権限を有しています。ICEは「親子分離」と呼ばれる政策を採用しており、不法移民の逮捕時に大人と子供を引き離します。その結果、多くの子供が両親と連絡が取れなくなり、さらに数百人の子供が両親と疎遠になり、米国の養子縁組制度に頼らざるを得なくなりました。この政策は国民の激しい反発を招き、「ICE廃止」運動へと発展しました。 ICE廃止の過程で、ICEが技術的に先進的であり、大手インターネット企業やソフトウェア企業がサービスを提供していることが明らかになりました。ソフトウェアからAIまで、あらゆるハイテクソリューションを駆使し、人材採用においてかつてないほどの効率性を実現していました。これらのソフトウェアの大部分は、オープンソースソフトウェアやフリーソフトウェアに基づいて開発されていました。そのため、大手ベンダーへの抗議に加え、オープンソースコミュニティ内では「ICEによるプログラム利用を阻止する方法を見つけられないか」という議論が始まりました。 JavaScriptパッケージマネージャであるLernaは、オープンソースライセンスを修正し、MicrosoftやAmazonを含む多数の企業を「ICE支援による禁止」カテゴリに追加した最初の企業となりました。これは明らかにOSD6に違反しており、Eric Raymondは「非差別はオープンソースソフトウェアの中核的価値である」と記した記事を執筆しました。翌日、Lernaは元のMITライセンスに戻し、謝罪しました。 —上記は「RMS、オープンソース、フリーソフトウェアをめぐる2つの「戦争」」6より抜粋 OSD7. ライセンス配布ソフトウェアが再配布されると、すべての受領者はライセンスに記載されているとおりにソフトウェアの権利を取得します。受領者は、これらの権利を取得するために追加の契約に従う必要はありません。 簡単に言えば、オープンソースソフトウェアは配布プロセスを経ます。オリジナルの作者が最初のユーザーにリリースし、そのユーザーがさらに次のユーザーにリリースするといった形で、継続的に流通していきます。この再配布プロセスにおいて、オリジナルの作者が受領者に付与した権利は仲介者によって裁定されることはなく、また、ソフトウェアを入手するために受領者に追加のプロトコルに従うよう要求することもできません。
解説:オープンソースソフトウェアの元の作成者からユーザーに付与された権利を譲渡する場合、追加の要件を付すことはできません。 注釈付きOSDから判断すると、この条項はオープンソースプロジェクトのソースコードが閉鎖されるのを防ぎ、自由な配布を保証するために使用されているようです。GPL v2の第6条を詳しく見ると、この条項は本質的にGPLの精神を凝縮したものであることがわかります。 GPL v2 の第 6 条と GPL v3 の第 10 条はどちらもこの意味を明確に表現しています。 しかし、MITやApacheのようなパーミッシブライセンスの場合、再配布時に元のライセンスが使用されるとOSD7の要件を満たします。しかし、再配布がクローズドソースであったり、ライセンスが変更されたりした場合（つまり、MITやApacheが他者によるコードの追加を許可している場合）、この条件は満たされません。したがって、これら2つのライセンスのOSD7への準拠性は非常に弱いと言えます。 したがって、OSD7 は十分に厳密ではないと思います。 OSD8。ライセンスは特定の製品に限定することはできません。ライセンスによって受領者に付与される権利は、特定のソフトウェア配布物に結び付けられるべきではありません。プログラムがどのソフトウェア配布物から取得されたかに関わらず、そのユーザーは元のソフトウェア配布物を受け取ったユーザーと同じ権利を有します。 分かりやすく言えば、例えばwu-ftpdというソフトウェアがあるとします。そのライセンスには、「このソフトウェアをKali Linuxディストリビューションから入手した場合、権利は1、2、3となります。Rcoky Linuxから入手した場合、権利は3、4、5となります。このソフトウェアをwu-ftpdのウェブサイトからダウンロードした場合にのみ、すべての権利が得られます」と記載することはできません。
解説: オープンソースは特定の製品に縛られておらず、世界から独立して存在することを誇りとしています。 OSD9。ライセンスは他のソフトウェアを制限することはできません。ライセンスは、一緒に配布される他のソフトウェアを制限することはできません。例えば、同じメディアでリリースされる他のすべてのプログラムがオープンソースソフトウェアであることをライセンスで義務付けることはできません。 簡単に言えば、たとえば、wu-ftpd は、同じ CD 上にある Li-httpd や mi-gui などのソフトウェアに対して要求を行うことはできません。なぜなら、それらはユーザーのソフトウェアではないため、ユーザーにはそのような要求を行う権利がないからです。
コメント: 自分の仕事をきちんとやり、他の人に何かを頼まないでください。 OSD10。特殊なテクノロジーやインターフェースを使用してライセンスを完了することはできません。ライセンスの条件は、特定のテクノロジーまたはインターフェース スタイルに限定されるものではありません。 言い換えれば、ソフトウェアのライセンスを付与する際に、ユーザーに「同意します」や「承諾します」といったボックスをクリックさせるべきではありません。従来、ソフトウェアはFTP、CD、あるいはWebミラーリングを介して配布されており、ユーザーは何もクリックする必要がありません。ライセンスにクリックが必要なら、ユーザーが慣れ親しんだ、あるいは好む方法でソフトウェアを配布することができず、非常に煩わしい状況になります。
コメント: ユーザーをより良く扱い、形式主義を避けてください。 総合評価ある友人が、OSD が他の 10 個の基準ではなく、これらの 10 個の基準を選んだのはなぜかと尋ねました。 私は、以下の 10 項目を選んだことは、OSI 創設者 (および彼らが代表するオープンソースの人々) の道徳的優位性を反映していると答えました。私たちは、ソース コードを無料で提供し、差別なく提供したいと考えています。オープンソースをあらゆる国、あらゆる地域、あらゆる分野、あらゆる産業に推進したいと考えています。オープンソースが社会と人類に利益をもたらすことを望んでいます。私たちは差別や制限を行いません。私たちは自由と平等を主張しています。私たちが望むのは、全人類の繁栄と進歩です。 大体こんな感じです。 オープンソースは道徳とは無関係だと言う人もいます。しかし、私は、これらの10項目は明らかに道徳、少なくとも人道的な道徳を反映していると主張します。 この背後には陰謀（ビジネス上の陰謀、政治的な陰謀）があると主張する人もいますが、私はそれについては何も言いたくありません。 SSPL はなぜオープンソース ライセンスではないのですか?SSPL を詳しく見てみましょう。全文は次のとおりです。 https://spdx.org/licenses/SSPL-1.0.html 調べてみたところ、第 13 条を除けば、GPL v3 は基本的に同じです (ただし、GPL の自由の精神を説明する「序文」はありません)。 結局のところ、誰もが巨人の肩の上に立ちたいと願っているのです。 では、SSPL の独自性を体現する 13 番目のポイントとは何でしょうか? SSPL 13. プログラムをサービスとして提供
この正しい翻訳は次の通りです。 本プログラムまたは本プログラムの改変版を使用し、第三者にサービスとして提供する場合には、本ライセンスの条項に従い、「サービスのソースコード」をネットワークダウンロードを通じてすべての人に自由に提供する必要があります。本ライセンス条項でいう「第三者へのサービスとして提供」とは、第三者がコンピュータネットワークを介して本プログラムまたは改変版の機能を遠隔的に操作できること、および提供されるサービスの価値が本プログラムまたは改変版に全面的または主として起因していること、またはユーザーに提供されるサービスが本プログラムまたは改変版の本来の目的の遂行に由来することを意味します。 「サービス ソース コード」という用語は、このプログラムまたはその修正版のソース コード、およびこのプログラムまたはその修正版をサービスとして利用するために使用するすべての関連プログラムのソース コードを指します。これには、管理ソフトウェア、ユーザー インターフェイス、アプリケーション プログラミング インターフェイス、自動化ソフトウェア、監視ソフトウェア、バックアップ ソフトウェア、ストレージ ソフトウェア、ホスティング ソフトウェアなどが含まれますが、これらに限定されません。つまり、ユーザーがサービス インスタンスを取得できるようにするために使用するすべてのソース コードを指します。 これを平易に翻訳すると次のようになります。 本プログラム（改変版を含む、以下同様）を配布せず、サービスとしてインターネット上に公開して他者が利用できるようにする場合、本サービスのソースコードを無償でダウンロードできるようにする必要があります。このサービス関連ソースコードには、本プログラムのソースコードだけでなく、管理ソフトウェア、ユーザーインターフェース、アプリケーションプログラミングインターフェース、自動化ソフトウェア、監視ソフトウェア、バックアップソフトウェア、ストレージソフトウェア、ホスティングソフトウェアなど、本サービスを適切に機能させる関連ソフトウェアのソースコードも含まれます。つまり、これらソフトウェアスイート全体がユーザーに完全なサービスを提供するため、これらのソフトウェアスイート全体のソースコードを提供する必要があります。 必須要件: 私のプログラムをサービスとして実行する場合、他の人もこのプログラムに基づいてサービスを提供できるように、このプログラムをサービスとして実行できるようにするすべてのソース コードを提供する必要があります。 言い換えると： サービスにするなら、レシピ全体（フロントエンドとバックエンドを含む）を寛大に渡す必要があります。 評価する： 正直に言うと、これは少し厳しいですね。「このプログラム」は確かにサービスを提供していますが、パッケージ全体の提供も要求しており、少し負担が大きすぎます。これらのサポートコンポーネントのコストは、「このプログラム」のコストよりもはるかに高くなる可能性があります。 これは明らかにOSD9に違反しています。自分のことに集中し、他人に過度な要求をすべきではありません！ もちろん、ライセンスは相互の同意の問題です。誰かが SSPL を受け入れる意思があれば、私たちはそれが実現することを嬉しく思います。 しかし、ほとんどの場合、メーカーはこれを受け入れないでしょう。つまり、SSPLを改変することは、基本的に、他の開発者に商用版を購入するか、独自のブランチを作成して操作する必要があると伝えることになります。 つまり、私にお金を払うか、これをフォークするかです! この引用は、faker.jsのメンテナーであるMarak氏によるものです。彼は悲しみに暮れ、プロジェクトのGitHubリポジトリに「もうフォーチュン500企業で無償で働くつもりはありません。6桁の給与契約を交わすか、このプロジェクトをフォークして自分でメンテナンスするかのどちらかです」と投稿しました。投稿のタイトルは「Marak氏からの無償労働はもう終わりです。報酬を支払うか、フォークするかです」でした。—「オープンソースコミュニティのダークサイド」より抜粋 興味深いのは、最初に返信してくれたのが、当時Huaweiに異議を唱えていたgo-microのメンテナー、asimだったことです。Marakの指摘は的を射ていたようです。 かつて、誰もがオープンソースに関わっていた頃は、皆が何かを貢献し、共に完全なオープンソースの世界を築くという共同作業だったと思います。私たちはそれが理想の社会だと感じていました。金儲けのことなど考えておらず、ただクローズドソースの資本家たちと関わりたくなかっただけなのです。誰もが平等で、誰もが貢献し、誰もが自由で、誰もが自給自足できる、調和のとれた世界を創りたかったのです。しかし今は状況が違います。私たちが共産主義の精神で作り上げたものが、資本家によって金儲けのために利用されているのです。これはすぐに私たちに嫌な思いを抱かせます。 追加の言葉かつて私は誰かに間違ったアドバイスを与えてしまいました。 オープンソースの作者の中には、自分の作品が商業的に利用されることに不快感を覚える人もいるようで、さまざまな不満を抱いています。 不安ならプロトコルを変更すればいいと言いましたよね。例えば、MITを使っているなら、MITに次の行を追加すればいいのです。 「この作品またはその派生作品を商業目的で使用する方は、妥当な評価額の10%を私の口座1XXXXXに積極的に送金してください。」 つまり、まだオープンソースライセンスではないので、私は少し躊躇しました。 OSD1 を詳しく調べてみると、これはロイヤリティ徴収スキームであり、明らかにオープンソース ライセンスではないことが明らかになりました。 でも、それでいいんです。自分が心地よくなれることをすればいいんです。オープンソースをやるように道徳的に脅迫しようとしているわけではありません。 もちろん、この変更が最も期待する効果を生み出すかどうかを検討する必要があります。
正直なところ、Elasticのライセンス変更や、それ以前のMongoDB、CockroachDB、RedisLabs、TimescaleDB、Graylogによるライセンス変更には、特に反応しませんでした。結局のところ、彼らは皆企業であり、利益を上げなければなりません！まずは無料サービスでユーザーを獲得し、その後、状況に応じて料金を請求するのはよくある戦略です。かつては無料で利用できたインターネットアプリケーションが、後になって様々な会員料金を徴収し始めたのと非常に似ています。 この世界は、誰もが無私であることを要求するものではありません。白か黒か、あるいはオープンソースかクローズドソースかという単純な問題でもありません。すべての主体には、自らが適切と考える方法、つまり自らの努力が報われると感じられる方法を見つける権利があります。 ブロックチェーン技術がより成熟した段階に発展し（NFT と DAO はどちらも有益な試みです）、著者がソースコードの使用に基づいて自動的に報酬を受け取ることができるようになれば、オープンソースに革命的な変化をもたらすことは間違いないと思います。 ソフトウェアがオープンソースと見なされるには、OSI による承認を受ける必要がありますか?オープンソースは OSI だけが決定できるものなのでしょうか? 彼らは「オープンソース」という言葉の組み合わせを思いつき、商標登録まで試みました。「开放」（kāngfàng）という翻訳語は、もちろん「オープンソース」に由来しています。 したがって、何かがオープンソースであるかどうかについての OSI の評価は明らかにより信頼性が高いと言えます。 しかし、中国語の「オープンソース」という用語が OSI オープンソースと同じではないと主張するのであれば、私はそれを止めることはできません。 それは人々がそれを認識しているかどうかによります。少なくとも私が見てきた限りでは、業界全体がまだOSDを認識しています。 ちなみに、私の国の Mulan Permissive License は OSI によって認定されており、正当なオープンソース ライセンスです。
この記事はWeChat公式アカウント「微悦人華」から転載したものです。以下のQRコードからフォローできます。転載の許可については、微悦人華公式アカウントまでお問い合わせください。 |
