AGPL Disputes: Lessons for Software Buyers

Two AGPL disputes reported in 2026 illustrate procurement risks around branding, forks, and closed components. AGPL can require source access, including for modified versions used over a network. Read the license and integration details before drawing a conclusion about the scope. ONLYOFFICE suspended its eight-year partnership with Nextcloud on March 31, 2026, after Nextcloud and IONOS launched a fork of ONLYOFFICE's editors called Euro-Office. Seven weeks later, on May 18, 2026, the Software Freedom Conservancy (SFC) announced it had confirmed two separate AGPLv3 violations by Bambu Lab, the 3D-printer maker. That came after Bambu threatened a developer over a community fork of its slicer software.

Both cases are worth walking through. They illustrate contested boundaries that buyers need to examine.

ONLYOFFICE vs. Euro-Office: the fork was never the issue

Nextcloud and IONOS built Euro-Office as a "sovereign" alternative to Microsoft Office, forked directly from ONLYOFFICE's AGPL-licensed editors. ONLYOFFICE's objection was never the fork itself. AGPL permits a fork subject to its license conditions, including a fork motivated by reducing reliance on the original vendor.

The objection was that Euro-Office stripped ONLYOFFICE's branding and logos. ONLYOFFICE's CEO Lev Bannov argued the license doesn't permit that: "we do not grant anyone the right to remove our branding or alter our open source code without proper attribution."

The mechanics behind that claim matter. ONLYOFFICE had added a branding requirement as an AGPLv3 Section 7 "additional term." Section 7 permits specific narrow terms, including preserving reasonable legal notices or attributions and declining to grant certain trademark rights. ONLYOFFICE argues its branding term fits those provisions; whether the logo requirement does so is the disputed question.

But Section 7 also carries what practitioners call the self-cleaning clause: if a work you received "contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term." Nextcloud's position is that the branding requirement is precisely that kind of removable restriction.

The sources cited here do not report a resolution. ONLYOFFICE kept its Nextcloud connector running for existing customers even after suspending the partnership. And outside legal commentary has landed on both sides of the Section 7 question.

The one thing both companies agree on is cleaner than the fight itself: trademark law and copyright license are different regimes. A copyright license can decline to grant trademark rights, but it can't summon trademark obligations that don't otherwise exist. Whether ONLYOFFICE's specific term survives the self-cleaning clause is genuinely unsettled. That the fork itself was allowed never was.

SFC vs. Bambu Lab: no exception for "we didn't really distribute it"

Bambu Studio is built on AGPLv3-licensed PrusaSlicer. Bambu bundles it with a proprietary networking library, libbambu_networking, without publishing that library's source. SFC's assessment is direct: shipping the combined program without Corresponding Source for every component in it "constitutes an egregious and ongoing violation of AGPLv3."

There's a second, separate finding. When independent developer Paweł Jarczak published an OrcaSlicer fork that restored features without Bambu's proprietary connector, Bambu sent him a cease-and-desist. SFC treats that legal threat as its own violation: AGPLv3 Section 10 bars imposing "further restrictions on the exercise of rights granted" by the license. Pressuring a downstream user over code they had every right to build on fits that description.

SFC evaluates distribution of a combined program and restrictions on downstream rights. Its assessment is not a court ruling. Distribution obligations differ from AGPL Section 13, which requires a source offer for remote users of a modified version. Whether a library forms part of a covered combined work depends on the integration, not its label as a helper.

A recipe analogy can illustrate access to a copy, but it does not determine the legal trigger. Assess distribution of the covered work separately from the source offer required for modified versions used over a network.

In the cited announcement, SFC proposed an engineering response rather than announcing a lawsuit. It opened a fund and a project to reverse-engineer the missing library and maintain an independent fork instead. That's its own lesson: enforcement doesn't need a courtroom to cost a vendor real engineering time and public trust.

What AGPL actually restricts

Three corrections, drawn straight from both disputes:

1. Separate the right to fork from compliance with other terms. Copyleft protects further development while the applicable license conditions still need to be met. Neither dispute challenges Nextcloud's or Jarczak's right to fork. Both challenge something stacked on top of it: a branding term in one case, an undisclosed proprietary library in the other.
2. Attribution means copyright notices, not your logo. AGPL requires preserving copyright and license notices. Requiring a fork to keep displaying your brand is a separate ask. Whether a licensor can attach that as a Section 7 term that survives the self-cleaning clause is exactly what ONLYOFFICE and Nextcloud are still arguing about.
3. Check the trigger and scope. AGPL Section 13 addresses modified versions and remote network interaction. Distribution has separate requirements. Internal use, linked libraries, and separate programs need an assessment of the actual integration; sharing a server does not by itself require opening the entire product.

Evaluating an AGPL component before you adopt it

What matters is not just what the license text says, but what your actual deployment plans to do with it. Before pulling an AGPL dependency into anything you intend to run as a service:

• Confirm whether you're modifying it. Unmodified use with no redistribution carries far less exposure than a fork you plan to operate yourself.
• Map every component that will ship or run alongside it, including internal glue code and any proprietary connectors. That's exactly the gap that caught Bambu Lab out.
• Decide before the architecture hardens whether "serve it as AGPL" or "buy a commercial license" is the outcome you actually want. I've covered the second path from the vendor's side in dual licensing an AGPL product. That piece explains the rights and dependency checks the model requires.
• If a licensor has attached branding or attribution terms beyond the standard notice requirement, read them against Section 7 first. Don't assume they're binding, or that you're free to ignore them.

For the wider map of what different licenses actually obligate, AGPL included, see what open-source licenses actually require in commercial software.

The takeaway

The cited reports do not establish a final resolution. That's fine — the lesson doesn't depend on who wins. Copyleft's core promise, that a fork can't be locked away, is intact in both cases.

What's contested is everything built around it: branding terms, undisclosed proprietary libraries, and whether threatening a downstream user is itself a license violation. Read AGPL for what it actually says before you accept either the maximalist or minimalist version someone quotes at you.