stefankuehnel

Before they even explain what the project is or what it does, you're immediately greeted with a "Legal note". It literally takes up the whole screen. It feels like a "WARNING. Private Property. NO TRESPASSING. Violators will be prosecuted!" sign rather than an invitation to explore a supposedly "free and open-source" software project.

And then, of course, they add a "Contributors welcome!" section. Sure. They're happy to accept free work from the free and open-source software community, but the rights that community is supposed to get under the AGPL v3.0 license? Those rights are ignored, as per their own convenience.

But don't worry, they do mention the "open-source" nature of their project with a hint at the license at the end:

> ONLYOFFICE is distributed under the AGPL v3.0 license, ensuring transparency and commitment to the open-source community.

What a joke!

---

Just a note: I have no problem with a software developer deciding under what conditions to distribute their software to users. If users become aware of the software project, it is up to them to decide whether or not they agree to those conditions. Because of the benefits that free and open-source software offers users and developers, I believe strongly in free and open-source software. Here, however, "free" does not mean "free of charge", but rather "free" as in "freedom". While I won't applaud someone who doesn't redistribute their software as "free and open-source software", I also don't hold a grudge against them.

However, I have a problem with the fact that, on the one hand, software is marketed as "free and open-source" software (apparently because it sounds good) while, on the other hand, the rights of the "free and open-source" software community are disregarded, abused, and trampled upon in such a despicable manner!

Enabled = You will have access to the feature

Disabled = You won't have access to the feature

As if handing over your data for free is a perk. Kinda hilarious.

Search for “Americans are spending like never before: Retail sales are booming — up 5% over last year, far outpacing inflation — as Americans spend in record amounts.” [1]

The phrase “up 5%” links directly to archive.ph.

[1] https://www.whitehouse.gov/articles/2025/09/the-economy-is-b...

https://text.npr.org/

Now, I don't know if minimal or text only counts as design. But I think these types of news sites are very appealing.

For example, one reason why people do these kinds of merges is because they are starting to do some new development for the next release, and that new development then depends on fixes or infrastructure that they had in another branch (like a "for-linus" branch in case of fixes).

So then they - mindlessly - just do a "git merge that-branch" and the end result looks very much like what you sent me.

In a slightly better world, they then actually write an explanatory commit message for that merge, knowing that I ask for them, and the merge commit message ends up being exactly that kind of slightly odd

  "Now I'm starting a new thing that depends on the fixes
   I already sent upstream, so I'm merging that branch"

And that will them maybe make you then go "Ahh, I'm doing things wrong".

Because the "nice git way" to do that kind of thing is to actually realize "oh, I'm starting new work that depends on the fixes I already sent upstram, so I should just make a new topic branch and start at that point that I needed".

And then - once you've done all the "new work" that depended on that state, only at THAT point do you merge the topic branch.

And look - you have exactly the same commits: you have one (or more) normal commits that implement the new feature, and you have one merge commit, but notice how much easier it is to write the explanation for the merge when you do it after the work.

Instead of having to waffle about "future work depends on this feature that was in another branch, so I'm merging this branch", your merge commit now makes sense. You're not merging some old state in order to create new features, you are literally just merging the completed new feature.

So this is one reason I want people to really think about, and explain, their merges. Because it may be that having to explain it makes you go "Oh, I'm doing this wrong".

Now, in your case, I don't actually think you needed that merge for any "future new work" at all. I think you just randomly did a merge to just get the same warning fixes that you had already sent me. So in this case, it smells like the merge was just entirely superfluous.

Those kinds of superfluous merges can be ok - it's just annoying to have a development branch that still shows some artifact that you already fixed elsewhere.

But they still need the explanation. And for that case, I want the explanation partly to make it clear that you really thought about it, and partly just so that I can see why you did it.

Because we have a very real history where people did mindless daily back-merges like this "just because" with absolutely no rhyme or reason, just because they wanted to start each day with the most recent base, and it really gets very ugly. The development history can go from a DAG that actually visualizes the different development streams nicely to a spider-net maze of inexplicable merges very quickly.

         Linus

   JSON Pointer defines a string syntax for identifying a specific value
   within a JavaScript Object Notation (JSON) document.