So it looks like at least one contributor of `arm-gen.c` does not want to relicense. Does that mean that the architecture I'm compiling for dictates what license I should refer to? Or would I need to compile a version of tcc without `arm-gen.c` present at all so I could be confident that I'm using MIT licensed software?
I wouldn't call it a sellout as they are being asked to grant everyone more rights. More ignorance or carelessness? of who they are helping like those on certain export control lists.
MIT is a more permissive license, which obviously appeals to some people.
I believe one issue in particular is around static vs dynamic linking – you can use an LGPL library from non-GPL code (even proprietary code) via dynamic linking, but LGPL only allows you to static link if all code in the executable is under a GPL-compatible license.
Okay, maybe that isn't technically true – from what I understand, the LGPL will let you statically link LGPL code with GPL-incompatible code, provided you either (a) make the GPL-incompatible code source-available, or (b) at least ship object files for the GPL-incompatible code so the end-user can relink the executable. The point is that the LGPL requires you to make it possible for the end-user to modify the LGPL bits, even if they aren't allowed to modify the rest of the executable. But, many people don't see these two approaches as acceptable.
So it looks like at least one contributor of `arm-gen.c` does not want to relicense. Does that mean that the architecture I'm compiling for dictates what license I should refer to? Or would I need to compile a version of tcc without `arm-gen.c` present at all so I could be confident that I'm using MIT licensed software?
Glöckner appears to be exhibiting undefined behaviour.
The last man standing against the sellout. Good man
I wouldn't call it a sellout as they are being asked to grant everyone more rights. More ignorance or carelessness? of who they are helping like those on certain export control lists.
Is there more context to this? Why are they doing this relicensing?
It's not a new development. It started in 2013:
https://lists.nongnu.org/archive/html/tinycc-devel/2013-05/m...
They are relicensing from LGPL to MIT.
MIT is a more permissive license, which obviously appeals to some people.
I believe one issue in particular is around static vs dynamic linking – you can use an LGPL library from non-GPL code (even proprietary code) via dynamic linking, but LGPL only allows you to static link if all code in the executable is under a GPL-compatible license.
Okay, maybe that isn't technically true – from what I understand, the LGPL will let you statically link LGPL code with GPL-incompatible code, provided you either (a) make the GPL-incompatible code source-available, or (b) at least ship object files for the GPL-incompatible code so the end-user can relink the executable. The point is that the LGPL requires you to make it possible for the end-user to modify the LGPL bits, even if they aren't allowed to modify the rest of the executable. But, many people don't see these two approaches as acceptable.
> But, many people don't see these two approaches as acceptable.
why's that? I don't see the issue myself.
[dead]