That's true. And, in my understanding, what OO did, falls exactly in paragraph b and d. The license doesn't describe what is the "Appropriate Legal Notices" and OO provided a description for it: its logo and its trademark.
No, logos and trademarks are neither "legal notices" nor "author attributions". It's simply not what those words mean. A "legal notice" is some sort of legally relevant document. An "author attribution" is a plaintext recognition of the original copyright holder.
If you look at the repo, it looks like the did fail to include author attributions, as far as I can see. The source files need to say they were originally written by OO. That's what author attribution means.
> [you may] supplement the terms of this License with terms:
>
>[...]
>
> b) Requiring preservation of specified reasonable legal notices or
> author attributions in that material or in the Appropriate Legal
> Notices displayed by works containing it; or
>
> c) Prohibiting misrepresentation of the origin of that material, or
> requiring that modified versions of such material be marked in
> reasonable ways as different from the original version; or
>
> d) Limiting the use for publicity purposes of names of licensors or
> authors of the material; or
>
> e) Declining to grant rights under trademark law for use of some
> trade names, trademarks, or service marks;
So the requirement of branding and attribution aren't "further restriction" (which, in this context, means a restriction that is not in the AGPLv3 license text). It's after section 7's list of allowed restrictions, which, paragraph b, contains "require preservation of [...] legal notices or [...] attributions", paragraph d is made to prevent misuse of the original author reputation, and paragraph e to prevent misuse of trademarks, so they, IMHO, are all legitimate.
The branding requirement is a further restriction because that isn’t one of the permitted changes by 7(b) - it is neither an author attribution nor a ALN.
This is bullshit. Read section 7 paragraph b of the AGPLv3 license, and you'll see that OnlyOffice did what they were allowed to do. The Nextcloud blog here is spreading FUD on their partner which will likely cause more damage to them if OO's lawyer starts to have a look on this. People don't read license text, but they should, because they think AGPL is like GPL which is not the case, they are additional restrictions to the former.
I think you're claiming wrong stuff here. AGPLv3 section 7 paragraph b) expressively authorize the author to require an attribution in the derived work or copy. What Nextcloud did was to remove this attribution, so they actually mooted their own right to use the code under that license. There's nothing related to trademark or branding violation here. If OnlyOffice attacked Nextcloud for using their TM or brand for respecting the license, they would be debunked at a trial (if it even reach a trial), since they expressively allowed the use of the attribution in distributing their work with this license. Note: This license doesn't give you the right to use the branding of OnlyOffice on a derived product and claim it's yours or you're acting as them, that's a complete different usage case here.
> you must retain the original Product logo when distributing the program
I understand "retain" in the way that you have to display the logo anywhere where the original OnlyOffice displays it. So I think you actually have to "use the branding of OnlyOffice".
----
> What Nextcloud did was to remove this attribution
Did they? If including the logo anywhere counts as attribution, I don't think they did. The logo is still present in several places:
AGPL allows for compatibility with a requirement for attribution but it doesn’t not allow (and explicitly says people can ignore) any further requirements beyond that.
A copyright attribution is e.g: “Copyright 2026 kube-system”. Attribution does not mean the same thing as “logo” or “branding”
The OnlyOffice license is ultimately a terrible crayon license. Those two requirements they wrote in are self contradictory… in consecutive sentences even. I kind of doubt that any court is gonna take that super seriously. It seems to be intentionally misleading or malicious, which is frowned upon.
> 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.
> Pursuant to Section 7 § 3(b) of the GNU AGPL you must retain the original ONLYOFFICE logo in the upper left corner of the user interface when distributing the software.
IANAL, but from the wording above it appears that OnlyOffice has modified it in a way that makes it impossible to fork as a new project.
They’re mistakenly conflating “attribution” with “branding” or “trademark”. They’re different things. In the context of a copyright license, attribution is something like “// Copyright 2012 <whoever> Corporation” that you might see in a source file.
This use doesn’t violate trademark because you aren’t pretending to be them, you are attributing them as the source. Just like I can say “the Big Mac is a sandwich at McDonalds” and my comment is completely legal.
Even if “attribution” didn’t already mean something different — this reading of the AGPL is laughably stupid — first of all, you can’t compel someone to break the law in a contract anyway... and second, that’s an illogical interpretation of that section. Why would it be intentionally self contradictory? Clearly that isn’t right.
Requiring specific branding is not provided for in 7 § 3(b) and it is specifically forbidden by the the sentences that immediately follow:
> All other non-permissive additional terms are considered "further restrictions" within the meaning of section 10. 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.
What they should do is make sure they keep all attribution in source files and tell them to pound sand about their bogus branding claims.
You're right, the branding claim here is BS but attribution requirements are legit. I only took a cursory glance at their repo, but I don't see any copyright notices for OnlyOffice in EuroOffice. There should be.
I think you're confused by the term "permissions". You can give more freedom to the license and a copier can remove them as long as it doesn't remove the freedom that are in AGPLv3. The OnlyOffice team claim comes from the next paragraph of section 7:
> Notwithstanding any other provision of this License, for material you add to a covered work, you may [...] supplement the terms of this License with terms:
> b) Requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it; or
c) Prohibiting misrepresentation of the origin of that material, or requiring that modified versions of such material be marked in reasonable ways as different from the original version; or
This is what they did and what the other part stripped from their blatant copy. So no, removing the logo or the OnlyOffice terms therefore seems forbidden by the license itself, revoking it for the other part, thus they are now making a counterfeit.
“Making exceptions to conditions” and “adding additional conditions” are literally opposed concepts, and the AGPL explicitly distinguishes between “additional permissions” and “further restrictions”. So, were OpenOffice bound by the original license without its additions, that would be problematic.
Author attribution, legally, doesn't refer to brands or logos. They're different things... e.g. the difference between [the disney logo] and "Copyright 2026 The Walt Disney Company"
Since there's a single provider of this "specification", which is more or less Google, why even bother calling it a standard? Even more that Google's implementation is not following the published standard, breaking potential competing implementation in so many subtle ways.
No you can't. dlopen signature takes a file path, not a memory range. And if you start to save the libraries to the filesystem before opening them, there's no difference to shipping an archive directly and skip the trouble of your own archive code.
I don't get why you process the whole connector board at once. If I understand correctly, you're connecting individual & identic boards to your board. So each connector on you giant board is actually dealing a bunch of small board right?
In that case, can't you exploit the inherent symmetry in the design here to only route a quarter of your connectors and then mirror/rotate the result for the other one? Or, if you have a X*X matrix, route one size minus the corners and replicate to the other sides?
Also, with such a huge connection board, it smells a NIH issue here. I think you'd better serialize the IO to a bus (whatever) and few lines and perform the connection in software (in a GoWin FPGA for example, both extremely cheap and quite powerful). Just think of the harness you'll need to build to fit the connectors in. The obvious routing bugs, and so on. Any maintenance will be a nightmare, if you need to swap 2 pins on a connector or re-run the routing.
Hi, author here, for this project, the backplane is as much of the computer as the 'daughter cards'. Think of it like the wire-wrap boards of _really old_ minicomputers. I'm using the PDP straight-8 as an analogy here because that's the oldest computer I've been inside of, but the backplane connects the different daughter cards together in a way such that the backplane _is_ the computer.
As far as symmetry goes, there really isn't any. For example, Board 0 conects to 1, 2, 4, and 8. Board 1 connects to 0, 3, 5, and 9. Board 3 connections to 1, 2 , 7, and 11.
There's one way I can think of to make this routing easier. Of of the 16 daughter boards, make the pinout unique to each daughter board. If I was doing this as a product, for manufacturing, this is exactly what I would do. I'd rearrange the pins on each daughter card so it would be easier to route. The drawback of this technique is that there would be 16 different varieties of daughter cards; not economical if you're just building one of these things.
So, with those constraints the only real optimization I have left is ensuring that the existing net plan is optimal. I already did that when I generated the netlist; used simulated annealing to ensure the minimal net length for the board before I even imported it into KiCad.
And yeah, serializing the IO would be better, but even better than that would be to emulate the entire system in a giant black box of compute. But then I wouldn't have written a GPU autorouter. I'm trying not to, but there is some optimization for _cool_ here, you know?
No you can't since the compiler will likely inline the syscall (or vsyscall) in your functions. So there's no way to know the instruction pointer is in the right section. The only way is to pay for no-inline cost and have a wrapper that's calling the syscall, so it's a huge cost to pay for a very rare feature (cancelling a thread abruptly is a no-no in most coding conventions).
I'm afraid that every part of what you just wrote was wrong.
> No you can't since the compiler will likely inline the syscall (or vsyscall) in your functions.
Do you mean the SYSCALL instruction? The standard practice is to make syscalls through glibc's wrappers. The compiler can't inline stuff across a shared library boundary because it doesn't know what version of the shared library will be requested at runtime. Using alternate non-inlineable wrappers (with some extra EINTR magic) does not newly impose the cost of out-of-lined functions.
It'd be possible to allow this instruction to be inlined into your binary's code (rather than using glibc shared library calls), but basically no one does, because this cost is insignificant compared to the context switch.
In general, inlining can be a big performance win, but mostly not because of the actual cost of the function call itself. It's more that sometimes huge optimizations are possible when the caller and callee are considered together. But these syscall wrappers don't have a lot of expense for the compiler to optimize away.
Do you mean the actual syscall (kernel code)? This is a different binary across a protection boundary; even more reason it can't be inlined.
vsyscall (or its modern equivalent, vDSO) is not relevant here. That's only for certain calls such as `gettimeofday` that do not block and so never return EINTR and (in pthread cancellation terms) are not "cancellation points". There is just no reason to do this for them. And again, the compiler can't inline it, because it doesn't know what code the kernel will supply at runtime.
> The only way is to pay for no-inline cost and have a wrapper that's calling the syscall, so it's a huge cost to pay for a very rare feature (cancelling a thread abruptly is a no-no in most coding conventions).
It's an insignificant cost that you're already paying.
The article is proposing a much safer alternative to cancelling a thread abruptly: using altered syscall wrappers that ensure EINTR is returned if a signal arrives before (even immediately before) entering kernel space. That's the same thing my sigsafe library does.
reply