Open Letter to the Euro-Office Team

In recent weeks, public discussion around the Euro-Office initiative has focused on licensing and the interpretation of open-source principles.

We have carefully reviewed the public statements issued by Nextcloud and by the Free Software Foundation (FSF), including the broader discussion surrounding GNU AGPLv3. We also submitted a direct request to the FSF on April 6 seeking clarification on specific aspects of AGPLv3. As of today, we have not received a response. In parallel, we have not received clarification from our former partner.

On the interpretation of AGPLv3

GNU AGPLv3 was published in 2007 and has governed ONLYOFFICE as an open-source project for many years.

A central point of discussion is Section 7(b), which allows:

“the preservation of specified reasonable legal notices or author attributions”

At the same time, several important points should be kept in mind:

• the license text itself does not define the term “author attributions”;
• the text of AGPLv3 remains the primary legal source;
• the recent FSF publication of January 2026 offers a later interpretation, not an amendment to the license text.

Recent FSF commentary has described “author attribution” as “an identification of the natural person who is the author of the copyrighted work.” However, this clarification appeared many years after AGPLv3 was published and long after our licensing approach had already been established.

For that reason, we believe the following should be recognized:

• the text of AGPLv3 itself remains the starting point for analysis;
• later interpretations may be informative and persuasive, but they are not automatically dispositive;
• the scope of attribution under Section 7 has always required interpretation.

Presenting a single interpretation as final and unquestionable does not reflect that reality.

A practical and constructive proposal

We propose a simple and transparent approach aimed at clarity for users and fairness for all parties.

1. User-visible origin information

The product should contain a clearly accessible interface, such as an About section or equivalent notice page, providing:

• identification of ONLYOFFICE as the original developer of the software;
• a clear indication that the version in use may be a modified implementation;
• a reference to the applicable open-source license.

This is not about imposing a particular UI structure. It is about ensuring that users can easily access accurate origin and license information.

This proposal is consistent with AGPLv3’s concept of “Appropriate Legal Notices”, which requires a convenient and prominently visible feature showing copyright and license-related information, and with Section 5(d), which states that if a work has interactive user interfaces, each must display Appropriate Legal Notices.

The GNU FAQ further explains that these notices must be readily available to the user in the interface.

2. Source code notices

The source code should retain notices in a form substantially similar to the following:

“This software is based on the original ONLYOFFICE work. Modified versions must preserve notices sufficient to allow users to identify the original developer and the source of the original work.”

This approach is more consistent with AGPLv3 Sections 4 and 5, which require the preservation of copyright and license notices, and with Section 7(b), which permits the preservation of specified reasonable legal notices or author attributions.

Section 5(a) also requires modified works to carry prominent notices stating that they were modified, and giving a relevant date.

3. Accurate public representation

Public materials relating to Euro-Office, including repository descriptions and related publications, should:

• accurately reflect the origin of the technology;
• avoid unsupported or misleading statements;
• clearly distinguish derivative work from the original product.

This is consistent with the broader AGPLv3 structure, under which modified versions must remain identifiable as modified versions rather than being presented in a way that obscures their origin. In particular, Section 5(a) requires prominent notices of modification, and Section 5(b) requires preservation of notices regarding the license and applicable Section 7 terms.

Why this matters

Open source enables reuse, modification, and independent development. We fully support those freedoms.

At the same time, sustainable open-source ecosystems depend on transparency, accurate attribution, and clarity for users. When those elements are missing, confusion replaces trust.

Users should be able to understand what they are using, where it comes from, and whether it is an original product or a modified derivative.

Our position

We fully support open source, including the right to fork, modify, and build independent products.

At the same time, we believe that users must be able to clearly understand the origin of the software they use.

We remain confident in our position, in the legal and ethical importance of transparent attribution, and in the value of what we build.

We remain open to constructive dialogue based on clarity, transparency, and respect for users.

Summary

We support open source, including the right to fork, modify, and build independent products.

Our position is straightforward: users should be able to clearly understand who created the original technology and what they are using.

To ensure transparency, we believe that the Euro-Office project should ensure the following:

1. User-visible attribution. A clearly accessible About section or equivalent interface allowing users to identify ONLYOFFICE as the original developer and understand that the version may be modified. This aligns with the AGPLv3 concept of Appropriate Legal Notices and Section 5(d).
2. Source code attribution. Retention of copyright and origin notices in the code so that the original developer and source of the work remain identifiable, consistent with Sections 4, 5, and 7(b).
3. Accurate public representation. Correction of misleading or unsupported statements about ONLYOFFICE in public materials, including repository descriptions and related publications, and clear identification of derivative works as modified, consistent with Section 5(a).

This is not about restricting the use of code.

It is about clarity, transparency, and respect for users.