Ancestors

Toot

Written by Software Freedom Conservancy on 2025-01-10 at 16:53

Great write up in @theregister about our recent AVM case: https://www.theregister.com/2025/01/10/german_router_maker_avm_lgpl/

=> More informations about this toot | More toots from conservancy@sfconservancy.org

Descendants

Written by Karl Auerbach on 2025-01-10 at 17:20

@conservancy @theregister I read this as a German court requiring that not only must the GPL'ed code itself be handed over, but also the toolchains needed to build it.

That seems odd to me, especially if the GPL code uses toolchain components with a different license, or even a proprietary license, to generate.

Given that building toolchains often requires, potentially multiple, deeper levels of toolchains, one might begin to wonder how far this decision requires one to unravel the build system.

In theory this could mean that even the methods and masks to fab-build the chipsets for the underlying ARM or X86-64 processors must be handed over.

=> More informations about this toot | More toots from karlauerbach@sfba.social

Written by jon ⚝ on 2025-01-10 at 18:39

@karlauerbach

I like the idea and maybe this way they were pointing out a flaw in the GPL itself. Could be interesting to think through until the end.

@conservancy @theregister

=> More informations about this toot | More toots from yala@degrowth.social

Written by Raphael on 2025-01-11 at 11:52

@karlauerbach @conservancy @theregister It's not that odd when looking at the special terms of the LGPL. The LGPL explicitly requires a library used in a way that the end user is able to swap out the library in the final product. Sharing the build toolchain is one way to solve that, dynamically linking the library from a place where the user can just swap out the file would be another example.

=> More informations about this toot | More toots from rami@chaos.social

Written by aspragg on 2025-01-11 at 23:31

@karlauerbach @conservancy @theregister My first thought - why would someone releasing a GPLd program require a proprietary toolchain?

But with this case, where the original code might rely on "any C compiler", but a redistributor might patch it to require extensions only (currently) supported by one proprietary C compiler. Is releasing all the code and makefiles and install scripts, but not the compiler, compliant?

Note: compilers are explicitly listed under GPLs "system libraries" exception

=> More informations about this toot | More toots from aspragg@ohai.social

Written by Karl Auerbach on 2025-01-12 at 07:36

@aspragg @conservancy @theregister I can't remember when I've hit proprietary tool chain dependencies, it certainly isn't very often.

My bigger issue is about versions - I still run into a lot of stuff that uses Python 2.7 and many distros have tried to root out Python 2.7 root and branch - and rebuilding that and its packages can be a pain. And then I run into "small" differences that aren't really small like gmake vs Unix make or Cmake (or Unix sh vs bash). And sometimes the configuration settings for a package (like the Linux kernel) need to be "just so". Perhaps the toolchain dependency that has driven me most crazy is openssl.

=> More informations about this toot | More toots from karlauerbach@sfba.social