AGPL Boundary: How We Did OSS Research Legally

AGPL license compliance open source research is one of those topics where most engineers have strong opinions and weak legal grounding. The prevailing belief goes something like this: open source means open. If the code is public, you can read it, learn from it, and build something better. The license just controls distribution, right? You're not distributing AppFlowy's code. You're writing your own. So what's the problem?

I held a version of that belief myself until we started building Nozio and I got serious about what "studying" an AGPL codebase actually means in practice.

The Myth: Reading AGPL Code Is Always Safe

The story engineers tell themselves is that copyright law governs copying, and since they're not copying anything, they're fine. They're just "inspired." They read the source, understand the architecture, close the tab, and write something new. Clean hands.

This is wrong in a specific, important way, and the wrongness has real consequences for anyone building a commercial product.

The GNU Affero General Public License v3 extends the GPL's copyleft provisions to cover software delivered over a network. If your product incorporates or derives from AGPL code and you offer it as a service, you must release your entire corresponding source under AGPL. That's the nuclear provision. It's why companies like Google have internal policies banning AGPL dependencies outright.

But here's the part that bites you before you even write a line of code: copyright protection covers not just literal code but also the structure, sequence, and organization of a codebase. Courts have gone back and forth on where exactly that line sits (the Oracle v. Google saga stretched over a decade), but the practical reality is that if your architecture too closely mirrors an AGPL project's architecture, you have exposure. Reading deeply and then building something structurally identical is not a safe harbor.

Why Engineers Get This Wrong

Part of the confusion comes from how we talk about open source. "Open" implies accessibility and permission. And for many licenses (MIT, Apache 2.0, BSD), the practical freedoms are broad. You genuinely can take MIT-licensed code, modify it, ship it in a commercial product, and owe nothing beyond attribution.

AGPL is different by design. It was written specifically to close the "SaaS loophole" in the GPL. The Free Software Foundation was explicit about this. AppFlowy chose AGPL for exactly this reason: they want competing commercial products to either contribute back or buy a commercial license.

The second source of confusion is that "inspiration" and "derivation" feel qualitatively different to engineers but are legally fuzzy. If I read AppFlowy's document sync architecture and then build a document sync architecture that solves the same problems in the same sequence with the same data flow, a court might not care that I typed every character myself.

There's an analogy here to the AI plagiarism debates happening right now. A BBC story from this week covers a student accused of AI-generated work despite writing everything herself. The accusation rested on output similarity, not on process. Courts applying copyright logic to code can work the same way: if the output looks like a derivative, the process defense is harder than you'd think.

What We Actually Did With AppFlowy

When we started building Nozio, we needed competitive intelligence. AppFlowy is the most serious open-source competitor in the collaborative workspace category. Understanding its architecture, its UX decisions, and its technical tradeoffs was legitimate product research. The question was how to do it without creating legal liability.

We drew a hard line: no one on the Nozio team cloned the AppFlowy repository. Not locally, not in CI, not in a sandbox. We didn't want any git history on any machine that showed AppFlowy code sitting next to Nozio code.

What we did instead:

We read the documentation and public blog posts. AppFlowy publishes detailed technical writeups. Their team has written about their CRDT implementation choices, their Rust backend decisions, their plugin architecture. That content is published for public consumption. Reading it is not a copyright issue.

We used the product. Running AppFlowy as a user and observing its behavior is not derivation. We took notes on UX flows, performance characteristics, and feature gaps. This is standard competitive analysis. Every product team does this.

We read the GitHub issues and pull request discussions. This is underrated. The conversation around code often reveals more about architectural decisions than the code itself. Why did they pick one approach over another? What did they reject and why? That deliberation is public and reading it carries no license obligation.

We read the license-specific headers in individual files without pulling the full repo. GitHub's web interface lets you browse files. We looked at specific, bounded sections of code when we had a concrete question, like "how does AppFlowy structure its block types?" We did not do broad architectural surveys by reading through entire packages.

The distinction matters. Reading a function to understand a data format is different from reading a module to understand a system design. The former is narrow and targeted. The latter starts to look like the kind of deep structural absorption that creates derivation risk.

The Line Between Inspiration and Derivation in a Full-Stack TypeScript Context

For the backend and full-stack engineers reading this: the risk is higher than you might think when you're working in JavaScript or TypeScript.

In lower-level systems work, the implementation details often diverge significantly from the conceptual design. Two engineers solving the same problem in C will write very different code. In TypeScript, especially with modern patterns (Zod schemas, tRPC routers, Prisma models), the implementation tends to converge. Two teams building a collaborative document editor in TypeScript will independently land on similar type structures, similar event schemas, similar WebSocket message shapes. That convergence is fine when it's genuinely independent. It's risky when one team deeply studied the other's code first.

We made a specific decision on Nozio: our document block schema was designed from our own product requirements, not from reverse-engineering AppFlowy's block schema. We wrote the requirements first. We designed the schema from the requirements. We never looked at AppFlowy's schema during that process.

That sequence is defensible. The inverse (study AppFlowy's schema, then write requirements that happen to match it) is not.

What AGPL Actually Permits for Research Purposes

The OSI's definition of open source and the AGPL text itself don't prohibit reading. You can read AGPL code. You can learn from it. You can understand patterns and approaches. The license restricts what you do with derivative works, not what you absorb as knowledge.

This is the "clean room" concept in reverse. A true clean room implementation means one team studies the original, writes a specification in plain language, and a completely separate team implements from that specification without ever seeing the original code. IBM and Microsoft used this approach with BIOS implementations in the early PC era.

We didn't need a full clean room process for Nozio because our research was bounded. But the mental model is useful: if you can articulate what you learned in prose, and a separate engineer could implement from that prose without the original code, you're probably on the right side of the line. If you need the original code open in another tab to build what you're building, you're not.

The Practical Compliance Checklist We Use

For any AGPL license compliance open source research project at Bedda.tech, we now follow a short protocol before any competitive technical research begins:

First, identify the license. Don't assume. Check the LICENSE file and any per-file headers. AppFlowy is AGPL-3.0. Some projects mix licenses across modules.

Second, decide on research scope before you start. Write down what questions you're trying to answer. "How does AppFlowy handle offline sync?" is a bounded question. "Let's understand AppFlowy's architecture" is not.

Third, prefer documentation, issues, and blog posts over source code. The information density in well-maintained projects is often higher in prose than in code anyway.

Fourth, if you read source code, log what you read and why. This sounds bureaucratic but it takes two minutes and creates a record that your research was targeted, not comprehensive.

Fifth, run your architecture decisions by someone who wasn't involved in the research. If they can explain why you made each decision from first principles, you have independent justification. If they can only say "because that's how AppFlowy does it," you have a problem.

Why This Matters More Now

The broader context here is that the question of what constitutes derivation is getting harder, not easier. AI coding tools are now deeply embedded in how most teams work. If your AI assistant was trained on AGPL code (and most of them were trained on large swaths of public GitHub), and it suggests an implementation pattern that mirrors an AGPL codebase, who owns that derivation risk?

There's no settled answer. The pricing and usage debates around tools like Claude Code are partly about enterprise customers wanting clear provenance and indemnification for exactly this reason. When you're paying 40x the token price for an enterprise tier, part of what you're paying for is the legal backstop.

For AGPL license compliance open source research specifically, I'd argue the AI layer makes the clean-process discipline more important, not less. If you can't trace how a design decision was made, and your AI assistant may have absorbed the codebase you were trying not to copy, you've lost the paper trail that would defend you.

The Actual Takeaway

The myth that reading AGPL code is always safe rests on conflating access with permission. The license doesn't prevent you from reading. It creates liability if your work is substantially derived from what you read. That liability attaches to the output, not just the process.

For Nozio, we got the competitive intelligence we needed. We understood AppFlowy's strengths and weaknesses. We made better product decisions because of that research. And we did it without cloning the repo, without absorbing the architecture through immersive study, and without putting ourselves in a position where a court would need to decide where "inspiration" ended and "derivation" began.

The line is sharper than most engineers think. The process discipline to stay on the right side of it is not complicated. It just requires deciding upfront that the research has constraints, and then actually respecting them.

That's a decision you make before you open the first file. Not after.