- replies
- 1
- announces
- 69
- likes
- 54
@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.
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.
@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.
@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
@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.