皆さんはオープンソースソフトウェア（OSS）のライセンスについて、どこまでご存知でしょうか？ 特にAGPL (Affero General Public License)というライセンスをご存知でしょうか。AGPLは「クラウド時代のGPL」とも呼ばれ、WebサービスやSaaSでOSSを利用する際に大きな影響を与えるライセンスです。この記事では、
- AGPLとは何か
- AGPLを採用している有名OSSとその理由
- AGPL製品に組み込める他ライセンスの一覧と可否
- AGPL製品と非AGPLライセンスOSSを組み合わせる実例
- 組み合わせによって起きたトラブル事例
を解説します。
AGPLとは何か？ – GPLとの違いと開示要件
まずはAGPLそのものについて整理しましょう。AGPLは一言で言えば「ネットワーク越しの利用にもソースコード公開義務を課すGPL」です。GPL（GNU General Public License）は強力なコピーレフトライセンスで、プログラムを改変して配布する場合にソースコードを公開する義務があります。しかし、GPLには「ASP（クラウド）提供の場合はソース公開しなくて良い」という抜け穴がありました。自分で改変したOSSをサーバ上でサービスとして提供し、利用者にはバイナリを直接配布しない場合（典型例がWebアプリの提供）、GPLの条件ではソース公開義務が生じないのです。これは「ASP（Application Service Provider）ループホール」と呼ばれ、クラウド時代にGPLの精神を潜在的に損ねるものでした。
AGPL（GNU Affero GPL）は、この抜け穴を塞ぐために作られたGPLの派生版です。具体的には、AGPLはGPLv3をベースに第13条に追加の条項を加えています。その条項は、「もしあなたがプログラムを改変してネットワーク越しにユーザとやりとりさせるなら、そのユーザ全員に対してソースコード入手の機会を提供しなければならない」というものです。平たく言えば、「ソフトウェアをネット経由で提供することも配布と見なす」という宣言です。この違いにより、AGPLではサーバ上で動かしているだけでも（ユーザがネットワーク越しに利用できる状態なら）ソース公開義務が発生します。
では、このAGPLの登場によって具体的に何が変わるのでしょうか？ 例えば、自社開発のWebサービスにOSSを組み込む際、GPLライセンスのソフトであればソース公開義務を回避できていたケースでも、AGPLライセンスのOSSを用いる場合は利用者にソースコードを提供する必要があります。これはクラウド/SaaS全盛の現在、企業にとっては重要なポイントですよね。
まとめると:
- GPL (特にGPLv3) と AGPL は近しい関係にありますが、AGPLは「ネットワーク経由での利用」も配布と見做しソース開示を要求する点で異なります。
- AGPLの開示要件: 改変したAGPLソフトウェアをWebサービス等で公開した場合、利用ユーザに対して改変後のソースコードを入手できる手段を提供する義務があります。具体的には、例えばWebアプリの画面上にソースコードダウンロードのリンクを設置する、などの対応が必要になるでしょう。
- GPLでは不要なケースでもAGPLでは必要: GPLはソフトウェアを「頒布（配布）」したときにのみソース開示義務が発生します。一方でAGPLは「ネット上でソフトウェアを提供した場合」にも義務が発生します。つまり自社サービスのバックエンドで改変GPLソフトを使うだけなら公開不要でしたが、AGPLソフトならコード公開が必要になるのです。
このようにAGPLは「SaaS時代のGPL」とも言える存在であり、クラウドサービス提供者に強い影響を与えます。では、なぜ敢えてこんなライセンスを採用するOSSがあるのでしょうか？ 次章ではAGPLを採用している主なOSSと、その背景にある意図を見ていきましょう。
AGPLを採用している有名なOSSとその理由
AGPLを選択しているオープンソースプロジェクトにはどんなものがあるでしょうか？ 実は年々増えており、その多くは「クラウドサービスとして提供されるOSS」です。代表的な例をいくつか挙げてみます。
- Mastodon（マストドン）: 分散型SNSプラットフォームで、日本でも一時期ブームになりました。MastodonはGNU AGPLv3で配布されています。なぜAGPLなのでしょう？ 分散SNSでは各コミュニティ（インスタンス）が独自にMastodonサーバを立てて運用します。AGPLであれば、各インスタンス管理者がMastodonに手を加えて運用した場合でも、そのソース公開が義務付けられます。結果としてフォークして独自機能を追加しても、その改良点をコミュニティ全体で共有できるわけです。Mastodonの開発者としては、たとえ商用サービスに使われても改変内容がフィードバックされることでソフト自体の発展に繋がるという狙いがあります。
- Diaspora: こちらも分散型SNSで、Facebookに対抗する理念で登場したOSSです。DiasporaはAGPLv3でライセンスされています。理由はMastodonと同様で、ネットワーク上でサービス提供されることを前提に、コミュニティによる継続的な改良共有を促進するためです。中央集権的なSNSへのアンチテーゼとして、「コードも含めて皆で管理するSNS」を実現する意図が読み取れます。
- MongoDB: 人気のNoSQLデータベースMongoDBは、2018年まではAGPLv3で提供されていました（※2018年以降は独自のサーバサイド公共ライセンス(SSPL)に変更）。MongoDB社が当初AGPLを採用した理由は、クラウド時代にデータベースをサービスとして提供するクラウドベンダーに対する抑止力と、コミュニティへの貢献確保です。AGPLであれば、もしクラウド事業者がMongoDBを改造してサービス提供すれば、その改造部分の公開義務が生じます。実際には改造せずそのまま使われるケースも多くAGPLの効果が十分とは言えなかったため、MongoDB社は後により強力なライセンス（SSPL）に移行しましたが、その背景には「クラウドでのただ乗りを防ぎたい」という思想がありました。
- Ghostscript: PDFやPostScriptの処理エンジンであるGhostscriptもAGPLv3で公開されています。Ghostscriptは商用ソフトに組み込まれることが多いため、開発元のArtifex社はデュアルライセンス戦略を採っています。つまり、AGPLでOSSとして無償公開しつつ、AGPLを嫌う企業には有償の商用ライセンスを別途提供する形です。AGPLを選ぶことで、「オープンにしたくないならお金を払ってね」というビジネスモデルを成立させています。これもAGPLの特徴を逆手に取った例と言えるでしょう。
- その他の例: Wikipedia日本語版によると、AGPL採用例としてLaunchpad（Ubuntuの開発プラットフォーム）、OTRS（チケット管理システム）、OpenERP/Odoo（ERPソフトのコミュニティ版）なども挙げられています。これらは主にサーバサイドで稼働しユーザがネット経由で利用するタイプのソフトウェアです。企業がサービス提供に使う場合にも改変共有を強いることで、オープンソースコミュニティへの還元を促す意図があります。また、Black Duck社の調査によれば、2010年頃から新興OSSプロジェクトでAGPLを採用する例が増え始め、クラウド/SaaS分野での利用拡大が示唆されたといいます。
以上のように、AGPLを採用するOSSの多くは「ネットサービスとして動くOSS」です。その理由は一貫しており、クラウド時代においてもOSSの改変共有を徹底することにあります。SaaS提供者がOSSを利用しつつ自社だけが恩恵を享受するのではなく、変更点を必ず公開させてコミュニティに貢献させる。あるいは、嫌なら商用ライセンス料を払わせて開発元のサステナビリティを確保する。AGPLはそのような戦略的意図で選択されているのです。
AGPLプロダクトに組み込めるライブラリのライセンス一覧
では、AGPLライセンスのソフトウェアをプロダクトとして開発・配布する場合、一緒に組み込める他のOSSライブラリのライセンスは何がOKで何がNGなのでしょうか？ ライセンスの組み合わせによる「互換性」の問題を確認してみましょう。ここでは代表的なライセンスごとに、AGPLプロダクトへ組み込み可能かどうかを整理します（※組み込み＝ソフトウェアにリンクして利用するケースを想定）。
以下の図は、GPLv3（AGPLはGPLv3互換）と他ライセンスの互換関係を示した概念図です。緑色の枠内がGPLv3と互換性のあるライセンス群で、矢印は互換（組み合わせ可能）関係を示します。】
上図も参考に、具体的なライセンスを以下に一覧します。
GPLv3
◎組み込み可能です。AGPLv3はGPLv3をベースとしており、FSF（フリーソフトウェア財団）の見解ではGPLv3とAGPLv3は互いに互換性があるとされています。実際、GPLv3テキストの第13条には「このプログラムがAGPLv3の条件で提供されるコードと結合された場合、結合物の頒布を許可する」旨が明記されています。したがって、GPLv3ライブラリをAGPLv3のプログラムにリンクして配布することは許されています（逆もまた然りです）。注意点として、GPLv3コードをそのままAGPLに“変更”して配布すること（ライセンスの付け替え）は許可されませんが、リンクして一体化して配布することは認められます。
GPLv2
×組み込み不可（基本的に非互換）です。GPLv2にはGPLv3第13条に相当する規定がなく、GPLv2とAGPLv3はライセンス上両立しません。そのため、GPLv2で提供されているOSSを改変してAGPLライセンスのソフトに統合することはできません。例えばGPLv2のみで配布されているライブラリをAGPLのプロダクトにリンクすると、どちらかのライセンスに違反してしまうのです。唯一の例外は、そのGPLv2ソフトが「GPLv2 or later（将来のバージョンでも可）」という形で配布されている場合です。この場合、利用者側でGPLv3として扱うことが可能になるため、結果的にAGPLv3との組み合わせも可能となります。ただし「GPLv2のみ」のソフトについてはAGPLとの混在は諦めるか、作者に問い合わせてライセンス変更の許諾を得る必要があるでしょう。
LGPL
◎組み込み可能です。LGPL(Lesser GPL)はGPLの派生で、ライブラリ向けに「弱いコピーレフト」条件を課すライセンスです。LGPLにもv2.1とv3がありますが、基本的にLGPLライブラリはより強いコピーレフト（GPLやAGPL）のソフトとリンク可能です。例えばLGPLv2.1のライブラリはGPLv2ソフトに組み込めますし、同様にAGPLv3のソフトに組み込むことも許容されます。LGPLライブラリを使う際の条件（ライブラリ部分のソース公開や再リンクを可能にする措置など）さえ満たせば、AGPL本体と併せて配布することに問題はありません。実際、多くのGPL/AGPLソフトは内部でLGPLのライブラリ（GUIツールキットやパーサ等）を利用しています。
MIT, BSD（修正BSD）, Apache License 2.0 などの「非コピーレフト系（パーミッシブ）ライセンス」
◎組み込み可能です。これらのライセンスは非常に緩やかで、基本的に他のどんなライセンスのソフトと組み合わせてもOKという性質を持ちます。特にMITライセンスやBSDライセンスはGPL系との互換性も高く、GPLやAGPLのプロダクトにそのコードを含めることが認められています。Apache License 2.0についても、FSFは「GPLv3と互換性がある」と公式に表明しています。つまりApache2.0のコードをAGPLv3ソフトに組み込んで配布することも問題ありません。唯一注意が必要なのは、Apache2.0は特許関連の条項を含むため、AGPL側でもその条件（特許ライセンスの取り扱い）を満たす必要がある点ですが、GPLv3ベースのAGPLはその点も考慮して作られているため大きな障害にはなりません。まとめると、MIT/BSD/Apache2.0といったライセンスのOSSはAGPLプロダクトに安心して取り込めると言えるでしょう。
MPL 2.0 (Mozilla Public License 2.0)
◎組み込み可能（条件付き）です。MPLはファイル単位のコピーレフトと呼ばれる中間的なライセンスで、Mozilla財団が策定しました。MPL 1.1時代はGPLと互換性がなく組み合わせに工夫が必要でしたが、MPL 2.0ではGPLv3やAGPLv3との互換性が考慮され、相互にコードを組み込めるようになっています。具体的には、MPL2.0の条文で「GPLv2やGPLv3（およびAGPLv3）との二次的ライセンスを許可」する旨が規定されており、必要に応じてMPLコードをGPL/AGPL互換ライセンスに切り替えて再配布することが可能です。そのため、MPL2.0のライブラリをAGPLプロダクトに含めることは原則可能です。もっとも、MPLの特徴として「MPL部分の改変コードは公開しなければならないが、他の部分は別ライセンスでもよい」という点があるため、混在させる際には「どのファイルがどのライセンスか」をきちんと整理する必要があります。誤ってMPL部分の改変を非公開にしたり、ライセンス表示を欠落させたりしないよう注意が必要です。
EPL (Eclipse Public License)
△基本的に組み込み不可です。EPLはEclipse FoundationのOSSライセンスで、MPLと同じく「ファイル毎のコピーレフト」型ですが、歴史的にGPLとは互換性がないとされています。特にEPL 1.0はGPLと相互に非互換であり、EPLコードをGPL/AGPLプロダクトに含めることはできません。2017年に策定されたEPL 2.0では「セカンダリライセンス」としてGPLv2/GPLv3を許諾するオプションが導入され、プロジェクトが明示的にそれを許可すればGPL系との混在が可能になりました。しかしこのオプションはプロジェクト次第であり、デフォルトで有効ではありません。そのため、一般論としてEPLのOSSをAGPLプロダクトに組み込むのは避けるべきです。どうしても必要な場合は、そのプロジェクトがGPL互換オプションを採用しているか確認し、場合によっては個別にライセンス許諾を得る必要があります。
CDDL (Common Development and Distribution License)
×組み込み不可です。CDDLはサン・マイクロシステムズ（現Oracle）が策定したライセンスで、一部のOSS（例: OpenSolarisやZFSなど）に使われています。CDDLもファイル単位コピーレフトですが、GPLとは著作権の扱いが異なり非互換です。CDDLコードをGPL/AGPLコードと組み合わせて単一のソフトウェアにすると、どちらかのライセンスに違反する状態になります。これは実際にLinuxカーネル(GPL)とZFS(CDDL)の組み合わせが法的にグレーである問題などにも現れています（ZFS on Linux問題）。従って、CDDLライセンスのライブラリをAGPLプロダクトに含めることはできません。回避策は基本的になく、どうしても必要な機能であれば別実装の利用や、プロセス分離（後述）などで直接コードを組み込まない形にするしかありません。
以上が主なライセンスの互換性一覧です。要約すれば、「GPLv3およびその互換ライセンス（LGPLv3、MIT、BSD、Apache2.0、MPL2.0など）はAGPLと組み合わせ可能。一方、GPLv2（のみ）やGPL非互換のコピーレフト（EPL1.0やCDDLなど）は組み合わせ不可」となります。ライブラリ選定時にはこの点に注意し、必要に応じて代替ライブラリの検討や自作、あるいは次に述べるような工夫が求められます。
AGPLプロダクトと非AGPLライセンスOSSの組み合わせ方
実際の開発では、AGPLライセンスのソフトウェアと、他のライセンスのOSSライブラリを組み合わせなければならない場面もしばしば発生します。その際、前節で述べたような互換性の問題に直面したら、開発者たちはどのような工夫をしているのでしょうか？ いくつか組み合わせ事例と対策を紹介します。
MongoDBサーバとApacheライセンスのクライアントライブラリ
先述の通りMongoDBはサーバがAGPLv3（※2018年まで）でした。一方でMongoDB社は公式のクライアントドライバをApache License 2.0で提供していました。一見すると「AGPLのサーバとApache2.0のクライアントをリンクして使うのはライセンス的に大丈夫か？」と思えます。しかしここでのポイントは、MongoDBクライアントドライバはサーバと直接「静的リンク」するわけではなく、ネットワークプロトコルで通信する別プログラムだということです。クライアント（アプリケーション）から見ればMongoDBは単なる外部サービスであり、その利用自体にはAGPLのコピーレフトは及びません。またApache2.0はGPLv3と互換なのでドライバとサーバを同梱配布しても問題ないという側面もあります。MongoDB社がドライバを敢えてApache2.0にしたのは、利用者（クライアントアプリ開発者）にライセンス面の不安を与えないためでしょう。結果として、「サーバ（AGPL）–クライアント（Apache）」の組み合わせが広く受け入れられ、MongoDBは人気を博しました。この事例から学べるのは、アーキテクチャ上プロセスを分離し、ネットワーク越しのやりとりに留めることで、ライセンスの波及を防ぐというアプローチです。もしAGPLコードと非互換ライセンスコードをどうしても組み合わせたい場合、一体化したバイナリにせず別プロセス・別サービスとして動かすことで、法律上は「別のプログラム」と主張できる可能性があります（※もっともAGPLの場合ネット越し利用も条件範囲なので注意は必要ですが、少なくとも直接リンクよりは安全です）。
オープンソースWebアプリケーションとGPLv2ライブラリ
あるケースとして、AGPLで公開したWebアプリに機能追加する際、使いたいOSSライブラリがGPLv2で提供されていたとします。しかしGPLv2は前述のように非互換なのでこのままでは使えません。こうした場合、開発者はどうするでしょうか？ 一つの解決策は「別のライブラリで代替する」ことです。実際、過去にはGPLv2ライブラリ（例えば画像処理ライブラリなど）を使いたかったけれど、ライセンス問題から機能実装を変更した例があります。たとえば暗号通信に関して、GPLv2ライセンスのOpenSSLを使う代わりに、GPL互換のGNUTLS(LGPLライセンス)に差し替える、といった対応です※。同様に、機能要件を満たす別のOSSがあるなら、ライセンス互換性を優先して選択するのが無難です。
（※補足: OpenSSLの旧ライセンスはApache2.0互換ではなくGPLv2と相容れなかったため、GPLソフトがOpenSSLを使う場合は独自に例外条項を付与するなどの対策が取られてきました。このようにライセンス非互換が判明した場合、開発元が特別許諾（例外）を設けるという対応も稀に行われます。）
AGPLライセンスのフレームワークと商用プラグイン
現在進行中の事例として仮定しましょう。もしあなたがAGPLのWebフレームワークを使って自社サービスを開発していたとして、そのフレームワーク用の便利なプラグインが見つかったとします。しかしそのプラグインは非AGPL（例えば独自ライセンスや商用ライセンス）でした。この場合、プラグインをコードに組み込んでしまうと自社サービス全体がAGPL違反になる可能性があります。対策としては、プラグイン作者に相談し利用許諾を得るか、プラグインと同等の機能を自社で実装することになります。実際、あるOSSプロジェクトでは特定のライブラリがライセンス不適合と判明し、自前で代替実装を行ったケースがあります。短期的には工数増になりますが、ライセンス違反によるリスクと将来のトラブルを防ぐための重要な投資と言えるでしょう。
このように、AGPLプロダクトと他ライセンスOSSの組み合わせでは「ライセンス非互換を避ける工夫」が求められます。主な解決策は以下の通りです。
- 互換ライブラリへの切替: 非互換なOSSが必要になったら、他に互換性のあるライブラリがないか検討する（例: OpenSSL→GNUTLSのように）。
- プロセス分離や外部サービス化: 問題のコードを別プロジェクト・サービスとして切り離し、直接リンクしない形にする。
- ライセンス例外や交渉: 開発元が許すなら「このライブラリとのリンクを許可する」という例外条項を付与してもらう。あるいは作者に直接問い合わせ、二次利用の許諾を得る（商用交渉含む）。
いずれにせよ、ライセンスはソフトウェアの「相性問題」でもあります。技術的な適合性だけでなく、法的適合性も考慮してOSSを選定・組み合わせることが、プロジェクト運営には欠かせません。
AGPLプロダクトに他ライセンスのものを組み込んだ結果のトラブル事例
最後に、実際にAGPLと他ライセンスの組み合わせで起こったトラブル事例を見てみましょう。ライセンス違反は最悪の場合、法的トラブルに発展します。ここでは2つのケースを紹介します。
ケース1: 商用SNSがAGPLコードを無断利用 – TRUTH SocialとMastodon
先ほど例に出したMastodonはAGPLライセンスでした。このMastodonをベースにして立ち上げられたのが、米国のSNSサービス「TRUTH Social」です。TRUTH Socialはトランプ前大統領系の企業が2021年に公開したSNSですが、初期リリース時にMastodonのライセンス条項に違反していることが発覚しました。具体的には、AGPLで提供されているMastodonを改変してサービス運営していたにもかかわらず、利用者に対してソースコードを公開していなかったのです。これは明確なAGPL違反であり、Mastodon創始者は公式に抗議しました。
この件はニュースでも大きく取り上げられ、結果的にTRUTH Social側はMastodon改変部分のソースコードを公開する対応を取ることになりました。実際、問題発覚から約1ヶ月後にTRUTH Socialはソースコードリポジトリを公開し、ライセンス順守の姿勢を示しています。つまり、「サービス側が折れてコードを公開した」形で決着したのです。
この事例からわかるように、AGPLソフトを利用している以上、そのライセンス義務から逃れることはできません。仮に最初隠し通せても、コミュニティの監視の目は鋭く、発覚すれば社会的信用も損ないかねません。「AGPL違反＝即オープンソースコミュニティから指摘・是正要求」と心得ておくべきでしょう。
ケース2: 商用ソフトにAGPLライブラリを組み込み – Hancom社とGhostscript訴訟
もう一つの事例は法廷まで行ったケースです。PDF処理ライブラリのGhostscript（AGPLライセンス）を韓国のソフトウェア企業Hancom社が自社のオフィスソフトに組み込んでいました。しかしHancom社はGhostscriptを改変・同梱しながら、ソースコード公開も商用ライセンス取得も行わなかったため、Ghostscript開発元のArtifex社は訴訟を提起しました。これは「AGPL違反が著作権侵害および契約不履行に当たるか」を問う裁判となり、2017年に米カリフォルニア連邦地裁は「GPL（AGPL）も契約として法的強制力がある」と判断し訴えを棄却しませんでした。最終的にHancom社はArtifex社と和解（おそらくライセンス料の支払い）に至ったとされています。
このケースは、AGPL違反が実際に法的措置の対象となった例として重要です。ポイントは、Ghostscriptがデュアルライセンス（AGPLと商用）だったため、開発元が「ライセンス違反＝無断利用」として損害を主張できたことです。結果として違反者側は金銭的な補償を行う羽目になりました。もし最初からAGPL遵守（つまりソース公開）していれば防げた訴訟であり、ライセンス軽視のリスクが浮き彫りになったと言えます。
以上二つの事例は、「AGPLの制約を無視すると何が起こるか？」を示しています。一つはコミュニティからの指摘と是正要求（社会的圧力）、もう一つは権利者からの法的措置（裁判・和解金）です。どちらも企業にとって大きなダメージとなり得ます。逆に言えば、AGPLを正しく理解して遵守していれば防げるトラブルとも言えます。
おわりに – AGPLの適用と影響を正しく理解しよう
AGPL（Affero GPL）は、クラウド・SaaS時代におけるオープンソースライセンスの重要な選択肢です。GPLの精神をネットワーク越しのサービス提供にも拡張し、利用者と開発コミュニティの権利を守るこのライセンスは、一方で開発者や企業に新たな義務と注意点をもたらします。
本記事では、AGPLの基本とGPLとの違い、具体的な採用例、他ライセンスとの組み合わせ可否、現場での工夫、そして違反時のトラブル事例までを見てきました。最後に、ポイントを振り返ってみましょう。
- AGPLは何のためのライセンスか: ネットワーク経由でソフトウェアを提供する場合にもソースコード公開を義務付け、クラウド時代にもOSSの自由と共有を担保するためのライセンス。ASPループホールを塞ぐためにGPLv3に第13条を追加したもの。
- AGPLを採用するOSSの狙い: MastodonやDiasporaのように分散サービスで改変を共有させる、MongoDBのようにクラウド企業のただ乗りを防ぐ、Ghostscriptのようにデュアルライセンス戦略で収益化する等、改変共有の徹底やビジネスモデル構築といった明確な意図がある。
- ライブラリ組み込みの可否: GPLv3互換のライセンス（GPLv3、LGPL、MIT、BSD、Apache2.0、MPL2.0等）はAGPLソフトに組み込み可能。一方、GPLv2のみやEPL1.0、CDDLなどGPL非互換ライセンスは組み込み不可。必ずライセンスの互換性をチェックし、必要なら代替策を講じる。
- 組み合わせの工夫: 非互換ライブラリが必要なら別プロセス化や代替ライブラリ採用で迂回する。MongoDBの事例ではサーバとクライアントでライセンスを分離し、利用者側への波及を防いだ。OSS開発では互換性を優先して技術選定する視点も重要。
- 違反時のリスク: AGPL違反はコミュニティから糾弾される（TRUTH Socialの例）だけでなく、法的責任を問われ賠償問題に発展する可能性もある（Hancom社の例）。最初からライセンスを順守し、必要なら商用ライセンス取得やソース公開を行うべき。
AGPLは強力なコピーレフトゆえに敬遠されることもありますが、適切に扱えばオープンソースのメリットをクラウド環境でも享受できる素晴らしい仕組みです。大切なのは、ライセンスの意図を正しく理解し遵守すること。そうすれば、開発者・利用者・サービス提供者の全てがWin-Winとなるエコシステムを築けるでしょう。
クラウドが主流の今だからこそ、ぜひAGPLのようなライセンスにも目を向け、自身のプロダクト戦略やOSS利用ポリシーに活かしてみてください。OSSライセンスとの付き合い方を深く理解することが、現代のエンジニアにとってますます重要になっています。今日学んだAGPLの知識が、皆さんの今後の開発活動の一助になれば幸いです。
おまけのグラレコ
