AGPLに関するFAQ集

概要¶

プリザンターCommunity Editionは、GNU Affero General Public License v3（GNU AGPLv3）のもとで公開されているオープンソースソフトウェア（OSS）です。AGPL v3はGPL v3をベースとしたコピーレフトライセンスです。ソフトウェアを改変した場合にソースコードの開示義務が生じる点はGPLと共通しますが、ネットワーク経由でサービスとして提供する場合にも同義務が適用されるという重要な特徴を持ちます（AGPL §13）。この規定により、改変版をサーバ上で運用してエンドユーザへ提供する事業者も、ソースコード開示の対象となります。

一般社団法人Open Source Group Japanが公開するAGPLの日本語参考訳（翻訳：八田真行）

プリザンターを社内業務システムとして利用する場合や、改変を加えずにそのまま使用する場合は、一般的にソースコード開示義務は生じません。一方、改変を加えたうえで社外向けにサービス提供を行う場合は、AGPLv3の義務が及ぶ可能性があります。自社製品・サービスへの組み込みや商用利用を検討される場合は、株式会社インプリムが提供する商用ライセンスを検討してください。

本FAQは、こうしたAGPLv3に関して寄せられる疑問を整理し、株式会社インプリムの考え方・回答を示すものです。また、AGPLのFAQについても併せてまとめています。

プリザンターのAGPLに関するFAQ¶

Q1．スクリプト、サーバスクリプト、スタイルで書いた業務ロジックやデザインに開示義務は生じるか？¶

プリザンターの標準機能であるスクリプト、サーバスクリプト、スタイルを使って独自の業務ロジックやデザインを追加しました。これらもAGPLの影響を受け、ソースコードを公開しなければなりませんか？

A1．¶

いいえ、開示義務は生じません。 画面上から設定するスクリプト、サーバスクリプト、スタイルは、プリザンター本体のソースコードの改変ではなく、プリザンター上で処理される「データ」として扱われます。そのため、これらを用いて記述した自社独自のコードやノウハウはAGPLの制約（ソースコード開示義務）を受けることはなく、非公開のまま安全に利用・提供することが可能です。

Q2．プリザンターとのAPI連携時はAGPLの制約を受けるか？¶

外部の自社システムから、プリザンターのAPIを呼び出してデータ連携をしています。自社システムもAGPLの制約を受けますか？

A2．¶

いいえ、制約を受けません。 REST APIなど、標準的なネットワーク通信プロトコルを介して独立したシステム同士がデータをやり取りする場合、それは「改変」や「派生物（静的リンクなど）」には該当しません。したがって、APIを利用して連携する外部システムにAGPLの効力が及ぶことはありません。

Q3．どのようなケースでソースコードの開示義務が生じるか？¶

どのようなケースでAGPLの開示義務が発生するのですか？

A3．¶

プリザンターの「本体のソースコード（C#などで書かれたコアシステム）」を直接書き換えたり、機能拡張（独自プラグインの組み込みなど）を行った上で、そのシステムをネットワーク経由で第三者にサービス提供（SaaS化など）する場合です。この場合、改変した部分を含むプリザンター全体のソースコードをAGPLのもとで利用者に公開する義務が生じます。

AGPLに関するFAQ¶

Q1．AGPL（GNU Affero General Public License）とはどのようなライセンスですか？¶

A1．¶

AGPLは、GPL（GNU General Public License）をベースにしたコピーレフト型のオープンソースライセンスです。最大の特徴は、ソフトウェアを改変してネットワーク経由でサービスとして提供（SaaSなど）する場合でも、ユーザに対してソースコードの開示・提供義務が生じるように設計されている点です。

Q2．GPLとAGPLの主な違いは何ですか？¶

A2．¶

従来のGPLでは、ソフトウェアのバイナリを物理的またはダウンロード等で「配布」した場合にのみ、ソースコードの開示義務が生じます。そのため、サーバ上でソフトウェアを実行し、ネットワーク越しに機能を提供するだけ（SaaS）では開示義務が生じませんでした。AGPLはこれに対処し、ネットワーク経由での利用であっても、改変したソースコードを利用者に提供する義務を課している点が異なります。

Q3．なぜAGPLが作られたのですか？（「SaaSループホール」とは何ですか？）¶

A3．¶

クラウドコンピューティングの普及により、一部のサービスプロバイダやクラウドベンダがGPLソフトウェアを改変してサーバ上で実行し、ソースコードをコミュニティへ公開せずに利益を得る「SaaSループホール（抜け穴）」が問題になりました。AGPLは、この抜け穴を塞ぎ、ソフトウェアをサービスとして提供する企業にもコミュニティへの還元（ソースコードの共有）を促す目的で作られました。

Q4．一部の企業がAGPLソフトウェアの利用を警戒する傾向があるのはなぜですか？¶

A4．¶

企業が自社のプロプライエタリ（独自の）コードとAGPLコードを統合してネットワーク経由で提供した場合、自社の独自コードまでAGPLの条件下で開示義務が生じる可能性があるためです。

Q5．AGPLソフトウェアを自社製品で安全に利用する方法はありますか？¶

A5．¶

AGPLコンポーネントと自社の独自コードの間に明確な境界線（技術的・論理的な隔離）を引くことが推奨されます。具体的には、AGPLソフトウェアを独立したコンテナ（Dockerなど）で実行し、ネットワークAPI経由でのみ通信させる方法や、サイドカー・パターンを活用する手法があります。これにより、法的な「結合（派生物）」とみなされるリスクを低減し、独自コードへのライセンス波及を防ぐことができます。

Q6．AGPLソフトウェアを商用利用することは可能ですか？¶

A6．¶

はい、可能です。AGPLはオープンソースライセンスであり、ソフトウェアの商用利用自体を禁止していません。ただし、自社の商用SaaSなどに組み込んでネットワーク経由で提供し、かつソフトウェアを改変している場合には、その改変部分を含むソースコードをユーザに開示する義務を遵守する必要があります。

Q7．「デュアルライセンス」とは何ですか？　AGPLとどのように関係しますか？¶

A7．¶

デュアルライセンスとは、同じソフトウェアを複数の異なるライセンス形態で提供する仕組みです。多くのOSS企業は、オープンソースのコラボレーションを促すためにAGPLで無償提供する一方、自社の独自コードを公開したくない企業向けには、有償の「商用ライセンス」を提供しています。これにより、開発元はオープンソースの理念を保ちながら収益を確保することができます。

Q8．AGPLのライセンス条件に違反した場合、どのようなリスクがありますか？¶

A8．¶

ライセンス違反は著作権侵害とみなされ、損害賠償請求や製品の出荷停止、サービス提供の差し止めなどの重大な法的リスクを伴います。また、M&A（企業の合併・買収）の際のデューデリジェンスにおいて、自社製品へのAGPLコードの意図しない混入が発覚した場合、知的財産権の価値が著しく損なわれたり、買収自体が破談になったりするビジネス上のリスクもあります。

更新情報¶