オープンソースを理解し、GPLを知らない人はほとんどいません。
1983年、自由ソフトウェアRMS（Richard Matthew Stallman）の父は、ある意味でオープンソースの始まりと見なすことができる「GNUプロジェクト」を立ち上げました。RMSの哲学では、知的財産は社会的エンパワーメントであり、権利所有者は、契約により、コピー、変更、再配布する権利などのソフトウェアの権利を自由に譲渡できるようにする必要があります。
これは「コピーレフト」と呼ばれます。この概念の実装をサポートするために、1989年にRMSと弁護士グループは、世界初のオープンソースソフトウェア契約であるGNU General Public License（GNU General Public License 、GPLとも呼ばれます）を起草しました。ソースライセンス。
一般に、「著作権」に対する「コピーレフト」から、自由ソフトウェア運動全体に至るまで、RMSはもともとプロプライエタリソフトウェアに反対することを目的としていました。これはまた、将来のオープンソースと他の力との間の非準拠への道を開いた。この一例は、Webおよびクラウドコンピューティングの台頭に続くオープンソースの世界への影響によって引き起こされる一連の摩擦です。
新しいモデルの侵入に直面して、オープンソースの世界は静止していませんでした、そして、AGPL（GNU Affero General Public License）はこの理由で生まれました。AGPLのより厳しい制限の下で、メーカーは確かに恐れ始めています。
しかし、それは裏目に出ました。AGPLは、ほとんどのオープンソース企業によって効果的な方法とは見なされておらず、取り残され始めています。GNUの関係者でさえ、 AGPLは「SaaSS 、ソフトウェア代替としてのサービス」の問題を解決しないと言っています。
AGPLは本当に「失敗」したのでしょうか？
01「抜けの修正と欠員の補充」1回
前世紀に生まれたGPLが予期していなかったことは、ソフトウェアの配布モデルが21世紀に大地を揺るがす変化を遂げることでした。
GPLは主に、Microsoftに代表される従来のソフトウェア配布ビジネスモデルを対象としています。その制約が有効になるための前提条件は、ソフトウェアを「リリース」することです。つまり、ソフトウェアはインターネットまたはCD-ROMを介してリリースする必要があります。はGPLによって制限されています（どちらも当てはまりません）。制限は、関連するソースコードを明示的に添付する必要があり、配布するソフトウェアもGPLである必要があることです。
Googleに代表されるインターネットサービスプロバイダー（アプリケーションサービスプロバイダー）の出現により、この条項は適用されなくなりました。彼らはソフトウェアを配布していないからです！Googleのビジネスモデルは、顧客にネットワークサービスを提供することです。それを配布しない場合は、基本的に制約のない彼のプライベートソリューションをオープンソース化する必要はありません。
これをGPL脆弱性Webサービスループ全体と呼びます。
同様に、SaaS（サービスとしてのソフトウェア、サービスとしてのソフトウェア）も同じです。SaaSは、クラウド上でソフトウェアサービスを提供しますが、「配布」しないという抜け穴もあります。クラウドコンピューティング企業は、コミュニティと変更を共有しないことで一定の利点を得ることができます。たとえば、AmazonのAuroraMySQLはMySQLに基づいています。
その結果、一部の自由ソフトウェアのイデオロギーは、GPLライセンス条項の内容を変更するようにプッシュし始めました。
2002年、フリーソフトウェアファウンデーション（FSF）の同意を得て、AfferoはGPLv2に基づくAGPLの初期バージョンをリリースしました。2007年のGPLv3のリリースに伴い、AGPLはGPLv3に基づいてAGPLv3も再更新しました。さて、AGPLについて話すとき、私たちはこのバージョンを意味します。
AGPLは、GPLの「ギャップを埋める」と言えます。AGPLはGPLのすべての条件を継承し、これに基づいて1つ追加します。ライセンスに基づくソフトウェアがネットワークを介してユーザーとやり取りする場合は、ソースコードをユーザーに提供する必要があり、すべての変更もユーザーに提供する必要があります。 。
基本的に、AGPLはWebベースのアプリケーション用です。当初はGoogleなどのネットワークサービス会社が主な観測対象でしたが、クラウドコンピューティングの台頭により、Amazonなどのクラウドベンダーが新しい対象となり、オープンソースのSaaSアプリケーションコードへの変更がフリーダムソフトウェアに確実にフィードバックされるようになりました。コミュニティ。
あなたが自由ソフトウェアがお金を稼ぐことができないと思うなら、あなたは間違っています。
オープンコアモデルは、オープンソースのビジネスモデルです。簡単に言うと、無料のコミュニティエディションをオープンソース化し、クローズドソースの商用エディションに課金することです。
オープンコアモードでは、AGPLは完全に実行可能です。たとえば、モールを開発する場合、GPLでオープンソースの場合、競合他社はプログラムを直接利用してSaaSサービスを提供できます。AGPLでは、関連するプログラムを展開するがオープンソースを望まない場合は、商用を購入する必要があります。著作権。
2018年11月、Neo4jは、クラウドプロバイダーが無駄に利益を得ることを望まなかったため、正式にOpen Coreモデルに移行しました。これは、Neo4jバージョン3.5以降、エンタープライズバージョンは商用ライセンスでのみ利用可能であり、ソースコードは廃止されたことを発表しました。 Neo4jコミュニティでは、Githubで利用できます。このバージョンは、引き続きAGPLv3でオープンソース化されます。
AGPLの有効性は明らかですが、それでも「裏切られ」ています。
また、2018年に、RedisLabsはRedisモジュールのライセンスをAGPLからCommonsClauseを使用してApachev2.0に変更しました。その中で、コモンズ条項はオープンソース契約ではなく、商取引を明示的に禁止しています。「ライセンスによって付与される権利には、ソフトウェアを販売する権利は含まれず、付与されません。」
コモンズ条項だけではありません。ほぼ同時に、MariaDB CorporationはBSLを作成しました。これは、本質的にクローズドソースモデルとオープンコアオープンソースモデルの「中間モデル」です。BSLで指定されたレベル未満の使用は常に完全に無料であり、指定されたレベルを超える使用には必要です。商用ライセンスであり、BSLは、プロジェクトのすべての使用が無料になると、ある時点で「真の」オープンソースになることを保証します。MongoDBはSSPLを作成しました。これは、AGPLよりも、製品を他の人にサービスとして提供する場合、管理者のソースコードとともに変更を公開する必要があります。
その中で、BSLとSSPLはオープンソースプロトコルではなく、OSI（Open Source Intiative）認証にも合格していません。
オープンソースの観点から、AGPLのOSI承認のオープンソースライセンスは使用されていませんが、なぜこれらのオープンソース企業は、オープンソースの世界で認識されていない「非オープンソースライセンス」を作成し始めるのですか？
AGPLがうまく機能していない可能性がありますか？
02武道の「対決」AGPLについて話さないでください
AGPLは使い勝手が悪いと言うよりも、ビジネスの世界での競争は「武道ではない」と言ったほうがいいでしょう。AGPLをビジネスの観点から見ることは、まったく別のことです。
まず第一に、AGPLは営利企業には人気がありません。
明らかに、AGPLのような強力なコピーレフトライセンスは伝染性であり、保守的な傾向のある営利企業は当然AGPLに疑問を抱いています。
たとえば、AppleはGPL /AGPLライセンスソフトウェアをAppStoreに表示することを許可しておらず、GoogleはAGPLを禁止していることで有名です。MongoDBによる以前のAGPLの使用も、米国の3大クラウドベンダーであるAmazonによってクラウドサービスから除外されました。 、MicrosoftおよびGoogle。。
承認されるとGPLを取り消すことはできず、AGPLはさらに悪いため、ユーザーはソフトウェアを使用して承認をトリガーするだけです。AGPLプログラムを実施している多くの企業は、AGPLの使用は企業の方針に反しているため、大企業からより寛容なライセンスに切り替えるよう求められています。
一部の弁護士は、多くの企業がGPL / AGPLを恐れており、自己開発したコードへの感染を心配していると述べています。
第二に、大企業は、オープンソースであるかどうかに関係なく、ケーキを手に入れます。
おそらくそれはAGPLに対する抵抗の精神に基づいているか、あるいはビジネス界の利益が最初に来るのかもしれません。大企業が「ケーキ」をつかむとき、彼らはしばしば見栄えが悪くなります。
ドキュメントデータベース市場は巨大ですが、Mongo DBはAGPLライセンスモデルを採用しているため、他のクラウドベンダーの巨人はオープンソースのMongoDBを直接使用できませんでしたが、それでもこの市場に参入する方法を考え出しました。Microsoftは、MongoDBのAPIと互換性のある方法でMongoDBをサポートする製品DocumentDBを最初にリリースしました。この製品は後にCosmosDBにアップグレードされました。これは、MongoDB以外の一連の他のオープンソースインターフェイスをサポートします。アマゾンはそのドキュメントDBサービスでそれに続いた。
MongoDBがSSPLを立ち上げて以来、AGPLは効果がないことが知られているというコメントがあります。クラウドサービスは、SaaSモデルでオープンソースを商品化する多くのスタートアップの前で両刃の剣になりました。顧客はデータとコンピューティングをオープンソース企業に引き渡し、オープンソースのサービス品質（パフォーマンス、スケーラビリティ、可用性を含む）を提供します。企業クラウドサービスプロバイダー（AWS、Alibaba、Microsoftなど）に依存し、そのコードはパブリック環境にも公開されています。規模の経済とサービス品質の観点から、後者には当然、インフラストラクチャレベルで特定の利点があります。
その結果、不平等が生じました。ITの巨人の状況に基づいて、オープンソースのスタートアップが抵抗することは困難です。同時に、オープンソースはますます商業活動から切り離せなくなります。
AmazonがElasticsearchを処理するためにフォークを使用したとき、Elasticsearchの動作を怒って非難し、「偽のオープンソース」と呼ぶ記事を公開しました。もう1つの例はDockerです。Dockerは今日のコンテナテクノロジーの事実上の標準になりつつありますが、GoogleのKubernetesが上位レベルのコンテナオーケストレーションエコシステムを支配しています。Dockerは実際にはそれから多くを得ることができません。
最後に、AGPLに違反するコストは高くなく、権利を行使することは困難です。
OSIによって認定されたオープンソース契約として、AGPLは法的効力を持たなければなりません。しかし、企業が法的手続きを通じて権利を擁護することはめったにないことに気付いたことがありますか？
害が利益を上回るか、結果が予測不可能であり、執行のコストが高すぎる場合、AGPL侵害に対して法的措置を取る意味がありません。
一方で、多くのAGPL侵害者は、あまり興味深いコードを提供できない可能性があります。侵害者のコードが非常に悪い可能性が非常に高いです。ライセンス要件に従ってコードを開示するよう相手に依頼すると、コードを維持します。また、AGPL違反者の大多数は、一般的に賠償金を支払うお金がほとんどありません。
一方、大企業を訴えたい場合は、訴訟費用が高額であり、相手方が裏付けとして強い経済力を持っているため、侵害などの訴訟は非常に長くなります。 VMwareに対する訴訟は5年間続いた。久しぶりに、原告は上訴を断念した。
さらに、AGPL違反は国境を越えたものになる傾向があり、国境を越えた訴追はより困難です。
したがって、AGPLの契約違反については、誰もが道徳的なレベルからそれを非難します-オープンソースの結果を楽しむことはコミュニティに還元されるべきです。
03自由の理想は崩壊しましたか？
「私たちはライセンスについて過度に懸念しているという異端的な見方をしています。特に、オープンソースコードを使用してクローズドソース開発を行う人々を罰するために、相互ライセンス、GPLのようなライセンスは必要ないと思います。」
2009年、「伽藍とバザール」の著者であり、オープンソース世界の第一人者であるエリックS.レイモンドは、ロングアイランドLinuxユーザーグループのミートアップで、オープンの珍しい方法を考えると、GPLライセンスはもはや必要ないと宣言しました。ソースの動きが動作します。
これはオープンソースの世界についての真実を開きます：フリーソフトウェアとオープンソースソフトウェアの間には亀裂があります。
AGPLはオープンソースライセンスですが、より重要なアイデンティティは次のとおりです。自由ソフトウェアライセンス。AGPLの焦点は、ソフトウェアが完全に100％無料でなければならないという観点からであり、以前のオープンソースプロジェクトの確立の核心であるオープン性とソフトウェアの自由に焦点を合わせています。
ただし、その後、開発フォーマットが更新され、オープンソースプロジェクトのコアが変更されました。今日のオープンソースプロジェクトでは、自由などはそれほど重要ではないかもしれません。オープンソースとは、注文を完了するか、特定のソフトウェアのコンポーネントを開くことです。
この側面から、AGPLを「無効」にするのは、ビジネスの「包囲と抑制」ではなく、理想の崩壊です。
実際、AGPLはビジネスにおいて完全に避けられないわけではありません。AGPLの規則では、変更された部分のみがオープンソースである必要があります。AGPLには、集約して公開することをクローズドソースにすることができるなど、多くの例外もあります。同時に、AGPLはカプセル化も可能であり、標準インターフェースを介して呼び出すことも、動的リンクを使用してプログラムのモジュールを相互に分離し、コードを区別するための独立したファイルを形成することもできます。多くの企業はそれを回避することができます。たとえば、GoogleGMSはソースを開くことができません。
今日でも、AGPLファンになることを選択するオープンソース企業があります。
2021年4月、Grafana Labsは、コアオープンソースプロジェクト（Grafana、Grafana Loki、Grafana Tempo）のライセンスがApacheLicense2.0からAGPLv3に変更されることを発表しました。Grafana Labsは、これがより公正なアプローチであり、より強力なコミュニティの構築に役立つと考えています。
GrafanaLabsのCEOであるRajDuttは、AGPLが他のライセンス（SSPLなど）と同程度に製品を「保護」していないことも知っていると述べましたが、一定のバランスが達成されたと信じており、このバランスはGrafanaLabsでした。長期的な調査-オープンソースとコミュニティの「価値創造」と商業化戦略の「価値獲得」のバランスをとる方法。オープンソースは常にGrafanaLabsの中心であり、AGPLv3を採用することで、コミュニティとユーザーが常に享受してきた自由を持ち続けることができると彼は信じています。
2021年6月、ThingsPanelはオープンソースライセンス契約をAGPLv3に変更しました。ThingsPanelによると、Grafana、Loki、TempoがAGPLv3ライセンスに切り替わったというニュースは、ThingPanelプロジェクトの開発をより促進するために、商用とオープンソースのバランスをさらにとる新しいインスピレーションを与えたとのことです。ThingPanelには、最大のオープンソースが最適なオプションです。
実際、AGPLv3プロトコルは14年間存在し、実行されています。ウィキペディアには 、AGPLv3 オープンソースプロトコルを採用しているオープンソースプロジェクトの特別なリストがあります。
Redis LabsはRedisモジュールをAGPLから、Apache2.0とCommonsClauseを組み合わせたライセンスに移行しましたが、Redisの作者であるantirezは次のように述べています。
「Disqueのように開発するRedisモジュールには、AGPLを選択します。私たちはクラウド時代に生きているため、新しいライセンスを使用すると、他のSaaS企業が改善点を再提出する必要があります。」
自由を持った永続性またはビジネスとの妥協、おそらくこれが問題の核心です。