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
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.
>(a) make the GPL-incompatible code source-available
I think this is incorrect, and you must actually release the other code as GPL. Even if it isn't, the intention is to permit people to compile the application, and you would lose physical/technical control of your application at that point.
That’s not true. The text of the LGPL is quite explicit that you only need to either link dynamically, or distribute object files that can be relinked: https://www.gnu.org/licenses/old-licenses/lgpl-2.1.html (not the latest version, but the one tcc uses - anyway, the newer version has updated wording but the substance is largely the same on this point)
> Even if it isn't, the intention is to permit people to compile the application, and you would lose physical/technical control of your application at that point.
You can distribute your app as object files and then allow the customer to relink them. That was a common method of software distribution in the 1980s and 1990s, especially for commercial Unix software. Oracle RDBMS still does that (or at least it still did in version 11, I’ve never installed any of the newer releases)
You can distribute object files but nobody does that because it's harder to do than simply using a dynamic library. The main reason people want static linking is for simplicity or to explicitly prevent the kind of alteration that LGPL protects anyway. If the result of statically linking to an LGPL library is objectively more complex than using a shared library, nobody will do it.
Distributing full source also satisfies the requirement. But as I said you will lose technical control of the project, if not legal control of it, by distributing the source along with an LGPL library.
> But, many people don't see these two approaches as acceptable.
why's that? I don't see the issue myself.
The issue in both cases is that you have to give up a certain amount of control over your application which may hinder your ability to sell it or keep it secure. It is also much easier to arrange for a library to be dynamically linked than to provide code or object files to swap the LGPL product.
[dead]