AGPL
是否将 Copyleft 概念延伸至网络上自由软件所交付的服务是个复杂问题，自由软件社区已经就此讨论了很久。用户基本自由权中的第 0 条要求允许用户自由地出于任何目的运行程序，这当然也包括向他人提供计算服务。基本自由权中的第 2 条要求尊重私有修改权。这两项要求结合起来就是任何人都能够以提供计算服务为目的，运行私有修改的 GPL 程序。
但当服务提供方利用修改后的自由软件提供服务时，开发用于提供网络服务（尤其是提供网络应用基础架构服务）的软件的程序员希望让用户也享有与修改者同样的权利，而该权利是最初开发者就授予修改者的。联合或“自由”服务平台均受益于此许可模式。
自由软件基金会并未努力解决单个许可证的内部冲突，而是在较长时间里尝试不同的许可证来使此类“Copyleft 服务”软件可与 GNU GPL 达到部分兼容。目前已发布并使用的两个此类许可证分别是 AGPLv1 和 AGPLv3，这两者的体系结构不同，但意图相同。⑧ AGPL 中的“A”代表“Affero”， 这是 FSF 董事 Henry Poole 开创的某个软件项目的名称。AGPLv1 由 FSF 编写，发布于 2003 年，专门用于 Affero 项目。AGPLv3 则与 GPLv3 同时设想和起草，旨在进一步统一这些许可证之间的关系，并允许用户在 AGPLv3 项目中使用 GPLv3 代码。
在 GPLv2 许可证中，“分发”和分许可是产生 Copyleft 义务的条件，GPLv3 中又增加了“发布”条件，而 AGPL 许可证的共同特点是除了这些条件外，还另外规定了一个单独的产生条件。AGPL 许可证的 Copyleft 范围与各版本 GPL 的 Copyleft 范围相同。只有导致提供对应源码义务的条件和许可证文本有所变化。
AGPLv1
AGPLv1 在 GPLv2 文本上增加了一项附加要求，参见 §2(d)：
如果您获得的软件用于通过计算机网络与用户交互，且该版本可使用户请求获得该软件的完整源码，那么您不得从您修改的软件版本或基于该软件的作品中删除此附加服务，并且必须向通过计算机网络与该软件交互的所有用户提供平等机会，让他们能够请求通过 HTTP 立即传输修改版本或其他衍生作品的完整源码。
此要求与 GPLv2 §2(c) 中的“在交互使用中保留声明”要求类似，是 Bradley Kuhn 在担任自由软件基金会执行董事期间首创的。此要求的合规方法很简单：如果“用于通过计算机网络与用户交互”的软件中存在请求服务器端源码功能，不将其删除即视为合规。
AGPLv3
AGPLv3 在 GPLv3 的文本上增加了一项附加要求，此要求包含在 AGPLv3 §13 中。与 AGPLv1 类似，AGPLv3 也没有对 Copyleft 的范围进行任何修改。在决定按照 AGPLv3 §6 提供或表示愿意提供何种“对应源码”时，只需了解同一程序以非源码形式通过物理介质分发时需提供何种源码即可。
AGPLv3 的附加激发条件如下：
⑧AGPLv2（2007 年发布）是一个过渡性的许可证“存根”，允许任何许可证持有人基于 AGPLv3 条款下的 AGPLv1 程序分发作品。
如果您修改了该程序，修改后的程序必须明确地向所有交互用户提供机会，来使其能够通过计算机远程网络（如果您的版本支持此类交互）接收该版本的对应源码，即通过一些方便用户复制软件的标准或常用方法在网络服务器上免费提供对应源码。此处所述的对应源码包括按照以下规定纳入 GPLv3 所涉作品的对应源码。
合规要求：如果您修改的软件版本中包含通过远程网络与用户交互这一体系结构，就必须为用户提供机会，以便其能够通过网络接收服务器端的对应源码。如果对应源码档案本身是编写软件过程中的“生成目标”（对于所有 Copyleft 作品，均建议如此操作），那么有关早期绑定语言的合规十分简单，运行中的软件在收到相关请求时将此源码档案（也可能包括同一系统中其他运行程序的源码文件档案）作为固定数据输出到通信流中即可。这种技术性的合规方法也解决了以早期绑定编译语言编写的软件的“Copyleft 范围”问题：如果运行时程序的组件是在生成时就已决定的，那么用于生成该程序的代码在去掉系统库和其他任何特例代码后即为对应源码。
总之，GPLv3 §13 和 AGPLv3 §13 ¶2 规定了组合 GPLv3 许可代码和 AGPLv3 许可代码的兼容结构。GPLv3 允许其许可证下的代码与 AGPLv3 代码相组合，而且每个部分适用各自的许可证。如果没有各自版权持有人的允许，AGPLv3 代码不能在 GPLv3 下重新许可，反之亦然。在这两种许可证代码组合成的任何作品中，GPLv3 源码都属于对应源码的一部分。