The Logo Trap: OnlyOffice's AGPLv3 gambit and what it means for free and open-source compliance

If you are active in the field of IT law or software development, chances are you will be familiar with open source licensing, and specifically the General Public License (GPL) in its various iterations, GPLv1, GPLv2 and GPLv3, as well as closely-related licenses based on them, like the AGPL. It is one of the most ‘copyleft’ licenses in Free (as in Freedom, also clarified with th addition of ‘Libre’) Open Source Software, or F(L)OSS community. It is a wonderful legal document – yes, that is a thing: open source is a legal construct at heart, and brilliant one at that – and someone just tried to hack it...

A little background
In a nutshell, the two political camps in the free software community can be described as the free software movement on the one hand and open-source enthusiasts. The free software movement seeks to safeguard the rights of software users; in its eyes a non-free program is a social problem as an injustice to its users, taking away their freedoms. The open-source camp declines to see the issue as a matter of social justice for the users and focuses more on the practical benefits (e.g. source code availability, code transparency,
security and collaborative aspects).

The GPLv3 and the AGPLv3 licenses are both very much on the copyleft side of the FOSS spectrum, which is to say on the side of the free software movement. The AGPLv3 was developed from GPLv3 to close the SaaS or “server-side loophole” of the GPLv3: running AGPLv3-licensed modified code on a server and allowing users to interact with it requires releasing the modified source code to those users. The GPLv3 does not. Otherwise, the AGPLv3 text is closely related to the GPLv3. More about that later.

Is all this relevant? Yes, it very much is: more and more open-source business models are expressly built on use of the AGPLv3 by projects or companies that wish to have a dual licensing model. In such a model the AGPLv3 can be used to prevent competitors from making their own version of the software without sharing the source code, while the original copyright holder has the option of licensing its own developments under a (usually commercial) closed source license or under the AGPLv3 and into its own open source community around its software.

So, what happened?
On 31 March 2026, two companies in the field of open-source software got into a somewhat surprising row. The open-source office software suite project OnlyOffice2 published a press release announcing the suspension of its partnership with Nextcloud, a German company which provides a suite of client-server software for creating and using file hosting services. The Nextcloud software can integrate with various kinds of office software, such as Collabora Online and OnlyOffice. The stated reason for OnlyOffice’s
announcement was the recent launch of ‘Euro-Office’ - a rebranded fork of OnlyOffice built into Nextcloud's product stack, announced in Berlin by a group of European tech companies without mentioning OnlyOffice by name. Quickly after, a formal legal notice appeared on the OnlyOffice GitHub page, asserting that Euro-Office constitutes a breach of the applicable license under which OnlyOffice is made available.

At first glance, this looks like a straightforward partnership dispute. It is not. Beneath the surface lies a genuinely fascinating legal puzzle about the boundaries of the GNU Affero General Public License v3 (AGPLv3) - specifically about whether a copyright holder can use two explicitly permitted additions to that license in combination to achieve something the license's authors almost certainly never intended: making a compliant fork legally impossible.

AGPLv3 and the Section 7 mechanism
As said, the AGPLv3, drafted by Bradley Kühn of the Free Software Foundation and published in 2007, is a strong copyleft license built on GPLv3 with one crucial addition: it closes the “SaaS loophole.” Under GPLv3, a company can run modified software as a network service without publishing the source code, because running a service does not count as “distribution.” The AGPL was based on the GPLv3, but specifically written to ensure that offering the covered software as SaaS would not exempt one from offering the relevant source code to users. AGPLv3’s section 13 removes this escape route: anyone who deploys a modified version over a network must make the source code available to users.

OnlyOffice has distributed its code under AGPLv3 since 2016. Like GPLv3, the AGPLv3 under section 7 contains a mechanism that allows copyright holders to supplement the license with certain additional terms, namely additional permissions (which any downstream recipient can remove) and additional requirements (which downstream recipients cannot remove). The list of permitted additional terms is closed, however: only the six categories set out in section 7(a) through (f) are allowed. Everything that goes beyond those
categories is defined as a “further restriction” within the meaning of section 10: in short, further restrictions are simply forbidden and any downstream recipients can remove those at will.

According to its own legal notices in its project github pages, somewhere in 2021, OnlyOffice added two conditions in its license file, invoking section 7 of the AGPLv3. Those read as follows:

• Pursuant to Section 7(b) of the License you must retain the original Product logo when distributing the program.
• Pursuant to Section 7(e) we decline to grant you any rights under trademark law for use of our trademarks.

The meaning of these two additional terms is quite clear: the first condition requires any downstream recipient to retain the original “OnlyOffice” product logo. The second condition expressly makes doing so a little difficult since OnlyOffice declines to grant any rights under trademark law for use of its trademarks.

The paradox: keep the logo, but you cannot use it
This is where it gets interesting. Taken individually, each of the two additions appears to be on solid ground. Section 7(b) expressly permits requiring the preservation of “specified reasonable legal notices or author attributions.” Section 7(e) expressly permits declining to grant trademark rights. Both are in the closed list of what is allowed.

But in combination, these two terms create a paradox. To distribute a fork of OnlyOffice in compliance with the license, you must retain the original OnlyOffice logo. Yet as a downstream recipient, you have no trademark license to display that logo. Displaying a trademark without a license is, in most jurisdictions, trademark infringement. The fork therefore cannot comply with section 7(b) without simultaneously infringing OnlyOffice's trademark rights - rights the section 7(e) addition deliberately withholds.

The practical effect is that it becomes legally impossible to create and distribute a compliant fork. The right to modify and convey derivative works - a core right granted by AGPLv3 - is rendered unexercisable. In substance, if not in form, this is a restriction on forking.

OnlyOffice's position: indivisibility
OnlyOffice's GitHub legal notice argues that the license terms form a “single, indivisible, and enforceable legal framework.” The argument runs as follows: the right to create and distribute derivative works arises solely from the license grant; that grant is conditional and includes the section 7 additions; therefore, any derivative work that strips those additions has no valid license at all, and distributing it constitutes copyright infringement. The notice explicitly states that the argument for distributing under a “pure” AGPLv3 without the section 7 additions is “legally unfounded.”

This is, in itself, a fairly coherent legal position and should not be dismissed out of hand. It is true that any rights under the license flow from the copyright holder's grant, and both added terms appear within the expressly permitted list in section 7. So far, so good, for OnlyOffice.

The counter argument: section 10 and the 'further restrictions' security mechanism
The GPLv3, and the AGPLv3 based on it, set out a pretty strong and clear ‘copyleft’ goal: users should be able to get the source code of software they use under those licenses and they should be able to create derivative works, such as forks. This mechanism underpins most of the software revolution of the last decades and meddling with that core mechanic is more than frowned upon.

Free and open source Software evangelist Richard Stallman of the Free Software Foundation, the organization behind the GPL and AGPL licenses, views Section 7 of the GNU General Public License version 3 (GPLv3) as a critical mechanism for balancing license compatibility with the core principles of free software. While GPLv2 generally prohibited adding any new terms, Stallman explains that GPLv3 formalized the practice of allowing specific “additional permissions” or “additional requirements” to ensure compatibility with other licenses (like Apache 2.0) without compromising the freedoms guaranteed by the GPL. Section 10 of the AGPLv3 states plainly: “You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License.” Crucially, section 7 itself provides a remedy: “If the Program as you received it, or any part of it, 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.”

The question, then, is whether the combination of the 7(b) and 7(e) additions constitutes a “further restriction” within the meaning of section 10. There is a strong and quite clear argument to be made that it does. While each individual term may appear within the permitted list, their combined operation produces a result that directly curtails the right to convey derivative works - which is the paradigmatic example of what section 10 prohibits. The common thread in section 10's examples is that they make the exercise of granted rights more burdensome or impossible. The ‘logo paradox’ that OnlyOffice created achieves exactly this.

There is also a textual hook within section 7(b) itself: the requirement must be for reasonable legal notices or author attributions. A logo retention requirement that is impossible to satisfy without trademark infringement is, at minimum, arguable as unreasonable. Section 7(b) was plainly designed for text-based copyright notices and attribution statements, not for brand identity elements whose display is independently regulated by trademark law. Extending 7(b) to cover product logos stretches the term well beyond its natural scope and arguably beyond what the FSF ever intended.

So, did the drafters of the (A)GPLv3 foresee such a trap?

The drafting history of section 7 in the (A)GPLv3

Yes, they very much did.

We know this because the aforementioned author of the AGPLv3, Bradley Kühn, lifted the veil of the Chatham House Rules of confidentiality from the (A)GPLv3 drafting sessions and revealed that this provision was specifically designed for the situation where the original, sole copyright holder/licensor added additional restrictions. He and Richard Fontana, who was involved earlier as a lawyer for the FSF with drafting the GPLv3, also pointed to the rationale given in the official drafting notes regarding section 7 for the GPLv3, where the difference between additional permissions and additional requirements is further explained:

[...] Unlike additional permissions, additional requirements that are allowed under subsection 7b may not be removed. The revised section 7 makes clear that this condition does not apply to any other additional requirements, however, which are removable just like additional permissions. Here we are particularly concerned about the practice of program authors who purport to license their works under the GPL with an additional requirement that contradicts the terms of the GPL, such as a prohibition on commercial use. Such terms can make the program non-free, and thus contradict the basic purpose of the GNU GPL; but even when the conditions are not fundamentally unethical, adding them in this way invariably makes the rights and obligations of licensees uncertain.

- [Emphasis added by author]

Even though the intent of the drafters in an open-source license might perhaps not in every system of law be the end-all answer to how a court would read the license in practice, it does carry a lot of weight. This background does show very clearly how the (A)GPLv3 was set up with an implicit hierarchy clause: anything that limits the core rights and freedoms of the downstream recipient was clearly meant to fall under the further restrictions mechanism in section 10, so anyone can remove it.

What this means in practice
For IT lawyers advising clients who build on or integrate free and open-source software, this dispute carries several practical lessons.

First, “licensed under AGPLv3” tells you less than you may think. The OnlyOffice additions were appended in 2021, quietly, at line 655 of the license file, without changing the headline label. Any client building on OnlyOffice code after that date - or integrating it in a product where rebranding was commercially important - should have been advised to read the full license, including section 7 additions. Due diligence on free and open source must go beyond simple identifiers.

Second, the timing matters. Recipients who obtained copies before the terms were included (according to OnlyOffice: May 2021) received the software under a different set of terms. Whether OnlyOffice could retroactively bind them to the new additions is itself a contested question - separate from and additional to the section 7 validity issue discussed above.

Third, there is a broader pattern worth watching. As said out above, the AGPLv3 has increasingly been used as a vehicle for “dual licensing” strategies: publish under AGPL to discourage commercial forks, while offering proprietary licenses to paying customers. OnlyOffice's construction pushes this model further than any prior publicly known case. If courts accept it, copyright holders will have a powerful new tool to control the fork ecosystem while maintaining an open-source label. If this matter would come to court and the court would reject OnlyOffice’s position, then the section 10 removal mechanism will be confirmed as a real right that downstream recipients can genuinely exercise. Such court cases provide important legal ‘proofing marks’ that would support lawyers worldwide in their analysis.

Conclusion
The dispute between OnlyOffice and Nextcloud is not simply about a broken partnership. It poses a question that the AGPLv3's drafters did not fail to anticipate: can two individually permitted section 7 additions, when combined, create a practical impossibility that amounts to a “further restriction” within the meaning of section 10?

The answer is clear: yes, they can be.

In my view, the logo trap that OnlyOffice has attempted to put into its project licensing terms clearly is a further restriction. The logo retention requirement, stripped of a trademark license, does not merely add a condition to the fork - it creates a condition that cannot be met without independently violating trademark law. Trademark law infringement comes with a host of ‘interesting’ (read: very powerful and effective) enforcement options that can pose very real and expensive problems for open-source developers. As such, in my view it is an attempted hack: two permitted terms combined in such a way that was clearly designed to shut the door on the freedoms that the AGPLv3 seeks to safeguard. That is not a permissible additional term. It is a trap. And a trap that would effectively stop a downstream recipient from exercising their right under the (A)GPLv3 is, by any reasonable reading, a restriction on the exercise of rights that the AGPLv3 grants. The authors of the (A)GPLv3 built sections 7 and 10 to safeguard against such attempts and as such, the founding members of the Euro-Office project appear to have been quite right in removing them.

Whether a court will agree remains to be seen, but - on a personal note as a lawyer, a litigator and a software - I for one would be more than happy to plead this one in court. This is clear, but still unsettled (and frankly, somewhat unsettling) legal territory, and the open-source community - along with its legal enthusiasts and supporting lawyers - will be watching closely.