Looking Forward to It [LWN.net]

Looking Forward to It

Posted Aug 28, 2026 11:11 UTC (Fri) by paulj (subscriber, #341)
In reply to: Looking Forward to It by muase
Parent article: An ongoing 3D-printer AGPL violation

> For example, how would it legally differ from a bundled CLI that is executed and communicates via stdin/stdout? I mean, I know the in-memory/process-space argument; but e.g. according to our company lawyer, this is a technical detail that doesn’t really translate into different legal concepts – she would be really surprised if courts would be willing to see a difference here (at least in Germany/EU, because that’s her area of expertise).

My experience with counsel at a large corp ages ago is similar. We got advice on whether it would be permissible to integrate some piece of code under one licence with other parts of the system under another licence, if the 'bridge' between that piece of the code and the other parts of the system were via some described protocol over a socket. The advice was that if the other parts of the system depended on that piece of code, then it would raise licensing issues - the counsel was explicit that the technicalities of the integration, be it a C API and static or dynamic linking, or a protocol over a socket, were not really significant to their advice.

to post comments

Looking Forward to It

Posted Aug 28, 2026 12:57 UTC (Fri) by bkuhn (subscriber, #58642) [Link] (5 responses)

paulj wrote:

My experience with counsel at a large corp ages ago is similar.

In part because they are so often ignored my management, BigCorp lawyers work really hard to find specious legal reasons to get to conclusions that their management want to hear. To quote the Big Lebowski: “that's just, like, their opinion, man”. As is what I wrote below just, like, my opinion, man — and IANAL and TINLA:

I've never seen anyone publish a detailed outcome of any of the legal tests for questions of combined/derivative works in the USA (such as the AFC test) on a dynamic linking situation done any GPLv2-or-later work. Have any of you?

Also, note the text in AGPLv3/GPLv3 is drafted in a materially different fashion on this specific point. While GPLv2 talks about “work based on the Program”, and then defines that (in part) as a derivative work, AGPLv3 says:

To "modify" a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a "modified version" of the earlier work or a work "based on" the earlier work.

Thus, AGPLv3 doesn't hang the question of whether or not the entire work is a derivative work of Prusa Slicer, but rather on whether or not they “copy from or adapted … part of the work in a fashion requiring copyright permission”.

Bambu Lab clearly didn't just make an exact copy of PrusaSlicer, and they definitely adapted it to combine with their no-source-available .so files. No need for an AFC test on derivative works; it's q.e.d.

But, ultimately, what I, or paulj, or muase, or some BigCorp lawyers think about this doesn't move the question further. We don't know what a Court will decide and this question (if it ever gets there) will be a question of law for the Court to decide. The folks involved will make our best arguments and hope the Court agrees with us.

Looking Forward to It

Posted Aug 28, 2026 13:11 UTC (Fri) by paulj (subscriber, #341) [Link] (4 responses)

> We don't know what a Court will decide and this question (if it ever gets there) will be a question of law for the Court to decide.

Indeed. There's just not much authoritative decisions in this space, right?

Also, specifically on:

" the counsel was explicit that the technicalities of the integration, be it a C API and static or dynamic linking, or a protocol over a socket, were not really significant to their advice."

What do you make of that? In technical forums, programmers discussing licensing issues often put a lot of emphasis on the technical details of how one work uses or depends on another. I thought that was important too, and was surprised a bit by that lawyer's advice not really caring much about the fine technical details. Would you have a view on that yourself? (outside of licences that explicitly limit their scope to some specified technical boundary).

Looking Forward to It

Posted Aug 28, 2026 13:55 UTC (Fri) by marcH (subscriber, #57642) [Link] (1 responses)

> What do you make of that? In technical forums, programmers discussing licensing issues often put a lot of emphasis on the technical details of how one work uses or depends on another. I thought that was important too, and was surprised a bit by that lawyer's advice not really caring much about the fine technical details.

I never understood why copyright, "derived work" etc. should depend on such technical details. Compared to linking, a socket-based communication is just serializing data, that's just an obscure implementation detail. It says nothing about how much "intellectual property" and creative work gets imported in the project. While it's not the most common, you can have a much more intricate coupling and stronger dependency with a socket than with a library. So the interaction details do not say anything.

Copyright is not an exact science at all. It's fuzzy by design. That does not make it completely useless: if you copy something 80% verbatim then the violation is obvious.

Looking Forward to It

Posted Aug 28, 2026 14:57 UTC (Fri) by farnz (subscriber, #17727) [Link]

I think it comes from us engineers preferring a world with clear-cut lines set by technical means, rather than fuzzy rules that care about some quite complex legal concepts (but completely ignore the technical concepts).

Add in the work imposed on you by being involved in a copyright case (not thinking about financial costs here, just the workload it adds as you talk with lawyers about what needs to be proven, what has to be disclosed/in discovery/whatever your local terms are), and it's not surprising that we want something clear and technical that we can point to and say "because of that barrier, it can't be copyright infringement".

And, of course, there's a huge incentive to be allowed to copy something otherwise than in accordance with its licence, so there's always going to be people who want to say "this barrier means that there's no infringement, therefore I can do the thing I want to do" (e.g. sell a proprietary GCC frontend for a new language with a binary-only GCC build), even though there's no legal backing for that position.

Looking Forward to It

Posted Aug 28, 2026 17:19 UTC (Fri) by rgmoore (✭ supporter ✭, #75) [Link]

What do you make of that?

This makes sense with what I've seen about the law. A lot of smart people who are unfamiliar with the law think they're the first ones to try looking for loopholes, or at least that because their loophole is new and original the law will have to let them get away with it because it isn't specifically written into the rules. In reality, lawyers are very familiar with this approach, and our whole society would break if the legal system weren't capable of dealing with it. Part of the way they deal with it is exactly the kind of "details are unimportant, only the effects" approach you're describing.

Programmers mostly do not understand law

Posted Sep 1, 2026 17:52 UTC (Tue) by NYKevin (subscriber, #129325) [Link]

In my experience, most people talking about copyright law make absolutely no effort to find out what the law actually says. They blindly assume that the law works the way they intuitively think it ought to work, and then derive whatever conclusions they want to derive based on that assumption. This is not specific to programmers - I have seen the same behavior with artists and other creative types, especially when talking about generative AI.

In the case of programmers, there's a tendency to assume that law is like code. It runs on formal logic, everything is a bright-line rule, nothing is ever subjective, etc., and therefore you can "just" code your way around the law whenever it poses an inconvenience (in the same way as you can "just" code around an inconvenient API or whatever). This is not how the law actually works, so much programmer discourse about the law is hopelessly misguided or outright wrong. I say this as a programmer myself.

See also (much more succinctly): https://xkcd.com/1494/

In the specific context of (A)GPL and derivative works, the test is very fuzzy and not at all a bright line. bkuhn's reference to the AFC test is a good place to start if you're curious about the specifics. Another complicating factor is that copyright protects creativity, not functionality. APIs and other integration points may be seen as less creative and more functional, so their copyright protection is weaker or possibly nonexistent (see Google v. Oracle).