tech journal

Thoughts on AGPLv3

I asked Manus AI to help me research and put this together. I also reviewed it myself.

Understanding AGPLv3: Correcting the Misconceptions About "Viral" Licensing

Disclaimer: This article is provided for informational and educational purposes only. The content does not constitute legal or professional advice of any kind. Readers should consult with qualified professionals or experts in the relevant field before making decisions or taking actions based on the information presented here. The author and publisher disclaim any liability for any loss or damage arising from the use of this information.

Introduction: The AGPLv3 Myth

The GNU Affero General Public License version 3 (AGPLv3) has acquired a certain reputation in technology circles. Many developers and companies incorrectly believe the myth that merely using AGPLv3-licensed software in any capacity will "infect" all their other software with AGPLv3 obligations. There is also a perception that AGPLv3 is only for non-commercial use and that a separate license has to be obtained for commerical use.

This article aims to clear up some of those misconceptions purely from a legal perspective. It does not attempt to discuss how industry treats, or should treat, the license.

The reality is far more nuanced—and far less alarming—than the myth suggests.

This article clarifies what AGPLv3 actually requires by examining its key provisions, with verbatim quotes from the license text. We focus on three critical areas: the derivative works definitions, the aggregate works clause, and the remote network interaction clause (Section 13). We also analyze the only known (to me) judicial interpretation of these provisions—the 2018 Beijing Intellectual Property Court decision in Digital Heaven v. Pomelo—to understand how courts apply these rules in practice, and discuss how a U.S. court might approach the issue.

Part 1: AGPLv3 Derivative Works Provisions – What Actually Triggers Copyleft

Before examining the remote network clause, it is essential to understand what AGPLv3 means by "derivative works" and when those obligations are triggered. The license contains specific operative provisions that define this.

AGPLv3 Section 0: Definitions

The license defines a "covered work" as follows:

"A 'covered work' means either the unmodified Program or a work based on the Program."

It defines modification as:

"To 'modify' a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a 'modified version' of the earlier work or a work 'based on' the earlier work."

These definitions are crucial. A work is only a "covered work" (and thus subject to AGPLv3) if it is either the AGPLv3 software itself or a work "based on the Program." The question of what constitutes "based on" is where the aggregate works analysis becomes relevant.

AGPLv3 Section 5: Conveying Modified Source Versions

Here is the operative copyleft provision:

"You may convey a work based on the Program, or the modifications to produce it from the Program, under the terms of section 4, provided that you also meet all of these conditions: ... You must license the entire work, under this License, to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged."

This is the key sentence: "You must license the entire work, under this License." This is AGPLv3's copyleft mechanism. If you create a derivative work (a work "based on" the AGPLv3 software), you must license that entire work under AGPLv3.

Critically, however, this obligation applies only to "a work based on the Program." If your software is not based on the AGPLv3 software—if it is merely an aggregate of separate and independent works—then this provision does not apply.

What the License Actually Says

AGPLv3 incorporates the aggregate works provision from GPLv3. Here is the verbatim text from the chausette of Section 5:

"A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an 'aggregate' if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate."

Breaking this down:

First, the threshold: For AGPLv3 to apply to your other software, that software must be either:

  1. A derivative work of the AGPLv3 software, or
  2. A covered work combined with the AGPLv3 software "such as to form a larger program."

Second, the safe harbor: If your software is merely an aggregate—meaning it is separate and independent—then AGPLv3 does not apply to it, even if it is distributed alongside AGPLv3 software.

This distinction is commonly misunderstood. The license does not say, "if you use AGPLv3 software, you must open-source everything." It says that copyleft applies only if you create a derivative work or combine software into a larger program.

What Counts as an "Aggregate"?

The license describes an aggregate as consisting of "separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program."

This raises a practical question: how tightly can software be coupled before it becomes a derivative work rather than an aggregate?

This is where the Chinese case becomes instructive.

Part 3: The Beijing Court's Aggregate Works Analysis – A Real-World Factual Matrix

The Case: Digital Heaven v. Pomelo Technology (2018)

In 2018, the Beijing Intellectual Property Court issued a decision that directly addressed the aggregate works provision of GPL-3.0. While the case involved GPLv3 rather than AGPLv3, the aggregate works analysis is identical—AGPLv3 incorporates the same provision.12

The Factual Setup

The plaintiff, Digital Heaven Internet Technology, developed HBuilder, an integrated development environment (IDE). HBuilder contained multiple modules:

These proprietary modules had no open-source licensing terms.

The defendant, Pomelo Technology (also known as Grapefruit Technology and Grapefruit Mobile Technology), allegedly copied these three proprietary modules and incorporated them into its own product, APICloud, without permission.

The Defendant's GPL Defense Strategy

Facing clear evidence of infringement, the defendant advanced an aggressive argument: because one module in HBuilder was GPL-licensed, the entire codebase must be GPL. If correct, the proprietary plugins would themselves be GPL-covered works, and copying them would not constitute infringement.

This argument reflects the common misconception that GPL copyleft operates as a legal virus. The defendant attempted to weaponize the GPL against the copyright holder.

The court rejected this argument as "ungrounded."

The Court's Factual Investigation

The court examined HBuilder’s actual architecture. A critical factual finding was that:

"The plug-ins were deemed to exist in three separate folders."3

The court noted that the proprietary plugins existed in separate files, did not include GPL license documents, and that the root directory of HBuilder did not contain the GPL license. This physical and legal separation was decisive.

On this basis, the Beijing court held:2

"The relationship between the modules developed by the plaintiff to the GPL licensed Aptana is aggregation only, and thus the plaintiff's modules need not be licensed under GPL 3.0."

In short: separate modules in separate folders were treated as an aggregate, not derivative works.

Why This Matters for AGPLv3

The decision offers concrete guidance on what "separate and independent" can mean in practice. That said, the court’s reliance on folder structure is arguably simplistic. A U.S. court would likely adopt a more conceptually grounded approach.

A U.S. Comparative Approach

A U.S. court analyzing Digital Heaven v. Pomelo would begin by asking whether the proprietary plugins were derivative works of the GPL-licensed Aptana framework under 17 U.S.C. § 101. The analysis would focus not on directory structure alone, but on whether the plugins incorporated or transformed Aptana’s protectable expression.

Functional interoperability, plugin architectures, and API usage would generally be treated as non-expressive elements unless they involved copying creative code. Under Computer Associates v. Altai and Oracle v. Google,4 such interface-based interaction would likely be filtered out as functional rather than expressive.

On the reported facts, the plugins appear to be independently authored works that merely interface with Aptana through defined extension points. Absent evidence of code copying or expressive incorporation, a U.S. court would likely characterize the software as an aggregate rather than a derivative work.

The outcome would align with the Beijing court’s holding, but the reasoning would rest on expressive incorporation and transformation, not physical separation.

A Suggested Analytical Approach

Under U.S. law, AGPL’s aggregate exception applies only if the non-AGPL components are "separate and independent works," meaning they would not qualify as derivative works under 17 U.S.C. § 101.

  1. Factors pointing away from aggregation (toward AGPL copyleft) include incorporation of protectable expression from the AGPL program, reliance on non-standard or implementation-specific integration, shared internal control flow or data structures, or lack of independent originality.

  2. Factors pointing toward aggregation include the absence of expressive copying, interaction through standard APIs or protocols, independent control flow and data models, and independent copyrightability.

  3. Factors such as directory layout, runtime dependence, packaging, or separate licensing may be relevant as circumstantial evidence but are not determinative.

Part 4: The Remote Network Interaction Clause – Understanding Section 13

What the License Actually Says

The provision that distinguishes AGPLv3 from GPLv3 is Section 13:

"Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version..."

The Critical Trigger: "If You Modify the Program"

The key phrase is "if you modify the Program."

Section 13 does not apply merely because you use AGPLv3 software. It applies only if you:

  1. Modify the AGPLv3 software, and
  2. Make that modified version available through remote network interaction.

Using AGPLv3 software as-is carries no Section 13 obligation.

What "Modify" Means

Section 0 defines modification as copying from or adapting the work in a way that requires copyright permission. Using, running, or linking to software does not constitute modification; changing its source code does.

The Purpose: Closing the "SaaS Loophole"

Under GPLv3, running modified software on a server without distributing it does not trigger source disclosure obligations. AGPLv3 closes this gap. If you modify AGPLv3 software and provide it as a network service, you must make the source code available to users.

What Section 13 Does Not Require

Section 13 does not require you to:

Interaction with Aggregate Works

If your proprietary software is an aggregate—separate and independent—then even when Section 13 is triggered, only the modified AGPLv3 software must be disclosed. Your proprietary modules remain unaffected.

The Actual Copyleft Trigger

The real legal risk lies not in using AGPLv3 software, but in how tightly your software is coupled to it.

Your software is more likely to be covered if it is:

  1. Tightly coupled (shared data structures or control flow)
  2. Derivative (based on or adapted from AGPLv3 software)
  3. Combined into a larger program with AGPLv3 software

By contrast, your software is unlikely to be covered if it is:

  1. Loosely coupled
  2. Independently authored
  3. Distributed as part of an aggregate

A Practical Framework

Factors supporting aggregation:

Factors supporting derivative status:

The Practical Question

The right question is: How tightly coupled is my software to the AGPLv3 software?

Part 6: Correcting the Misconceptions

Misconception 1: "Using AGPLv3 Software Infects All My Code"

Reality: Copyleft applies only to derivative or tightly coupled works.

Misconception 2: "If I Use AGPLv3 Software, I Must Open-Source Everything"

Reality: Only modified AGPLv3 software and derivative works must be disclosed.

Misconception 3: "Section 13 Makes AGPLv3 Unusable in Production"

Reality: Section 13 applies only to modified software offered over a network.

Misconception 4: "AGPLv3 Is Unenforceable or Ambiguous"

Reality: Courts have enforced GPLv3-style copyleft through ordinary copyright analysis.

Misconception 5: "AGPLv3 Is Only for Non-Commercial Use and Requires a Separate Commercial License"

Reality: AGPLv3 expressly permits commercial use. It does not restrict commercial activity, require payment, or mandate a separate commercial license.

Nothing in the AGPLv3 text distinguishes between commercial and non-commercial use. The license regulates how modified software may be conveyed or offered over a network—not whether it may be used in a for-profit context. Running a business, charging fees, or offering services built on AGPLv3 software is fully permitted under the license.

This misconception arises from the common practice of dual licensing, where copyright holders offer the same software under AGPLv3 and a separate proprietary license. The proprietary license is not required because AGPLv3 forbids commercial use; it is offered as an alternative for users who wish to avoid AGPL’s copyleft obligations (such as source disclosure upon modification and network deployment).

In other words, the choice is not between “non-commercial AGPL” and “commercial proprietary.” It is between complying with AGPLv3’s conditions or paying for a license that removes those conditions. The existence of a paid alternative does not transform AGPLv3 into a non-commercial license.

Conclusion: AGPLv3 Is Not as Scary as the Myth Suggests

AGPLv3 is often misunderstood as a legal virus. In reality:

  1. Copyleft applies only to derivative works.
  2. Aggregation is expressly permitted.
  3. Section 13 targets modified network services, not mere use.
  4. The real risk lies in architectural coupling, not license choice.

With thoughtful architecture and clear separation, AGPLv3 software can be used safely and predictably.

References

  1. Heather Meeker, "First GPL Case in China — or Is It?", Copyleft Currents (April 30, 2018).↩

  2. Lucen C.H. Lin & Niuya Shen, "GPL-3.0 in the Chinese Intellectual Property Court in Beijing," IFOSSLR Vol. 10 No. 1 (2018).↩

  3. Lexology, "China's courts pass controversial rulings on open-source licensing" (Oct 17, 2018).↩

  4. Pamela Samuelson, "Functionality and Expression in Computer Programs" (BTLJ).↩