Tiny C Compiler is relicensing to MIT | Hacker News Reader

Tiny C Compiler is relicensing to MIT

repo.or.cz

31 pointsstevefan199918 comments

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?

Is there more context to this? Why are they doing this relicensing?

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.

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.

what's so hard about providing the object code? you already generate it. how does providing the object code hinder your ability to sell your product or keep it secure?

It isn’t really that hard it is just extra work.

One option is instead of shipping all your .o files, you can merge all the non-LGPL objects into one using `ld -r`. That way you don’t have to ship a complex script or Makefile to link all your object files, and you can hide more internal details of the non-LGPL part.

You could use an approach like this:

(1) have an initial link step in your build process which links all the the non-LGPL object files into one

(2) have a second link step which statically links the output of (1) with all the LGPL static library archives to produce an executable

(3) still release the executable output by (2) as a release artefact as normal

(4) separately, create an archive (ZIP/TAR/etc) containing all the object file inputs to (2), and release that archive as a release artefact as well

(5) also include in the archive (4) a shell script which does the equivalent of (2) at the end-user site

(6) also for each LGPL library in the archive (4), include its source code

Now, for each released version, you make available both the executable from (2) (maybe incorporated into an installer or package) - and also the archive from (4). Almost nobody is ever going to download and use that “link kit” archive. But by making it available, you are legally complying with your obligations under the LGPL.

So this is the thing - there is nothing technically difficult here, it is just extra work to set it up and maintain it and make sure it doesn’t break and fix it if it breaks. And all that extra work is being done, not for any real end-user requirement, just for technical legal compliance. You can see why a more attractive option would be either to just use dynamic linking (if possible), or else look for a non-LGPL alternative under a more permissive license-either way, you don’t have to bother with all this extra busywork.

> just for technical legal compliance.

no, the reason is to respect the rights of end users when you make use of other people's work under lgpl. it's perfectly okay to choose a different library to base your profit-making product on.

How many users have ever sought to relink a statically linked closed source app with an updated version of an LGPL library? I’m sure somebody has done it somewhere. But I think it is so very rare, to the point that for the vast vast majority of people (even people with the necessary technical skills to do it), it is a theoretical right rather than a practically relevant one.

In fact, I think this would technically comply with the LGPL: package with the software an offer to supply this “link kit” on request, but don’t bother actually creating it until such time as a request is received. Significant chance nobody ever requests it, and hence you never have to do the work of creating it. And in the unlikely event someone does eventually ask for it, you could always collect the object files manually rather than some automated process as I suggested.

I think your plan is a good one, assuming you still have access to the build system/compilers, etc when the request is made.

>(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.

You could optionally ship object files, along with a script or Makefile to relink them, as a separate “link kit”-I believe that would comply with the letter of the LGPL. 99.99% of your users would never download it, but so long as you make it available to them to download, you’d be complying with your obligation under the LGPL.

But of course, this is extra work just to comply with the letter of a license. If they switch to MIT, you don’t need to do that. Indeed, it appears you can already swap the license to MIT provided you remove certain features (such as 32-bit ARM code generation and COFF support), and you might not need those features in your use case

> But as I said you will lose technical control of the project, if not legal control of it, by distributing the source

Proprietary software is sometimes shipped to customers in source form: once upon a time it was very common-prior to 1983, it was standard for IBM to ship source code to their copyrighted mainframe software products to customers. A lot of other products used to offer source code, sometimes for an additional license fee (e.g. AIX, OpenVMS, pre-open-source Solaris). It still isn’t unheard of for products targeted at professional, embedded or enterprise use - e.g. many commercial ERP systems are shipped, maybe not with complete source, but with source for large chunks of the business process code. Many of the background processes (such as payroll) in PeopleSoft HRMS are written in COBOL, and Oracle ships the COBOL source code to them, and customers are allowed to modify that code and recompile it (although of course Oracle strongly discourages that, especially nowadays, it is still permitted)

A closed source product is still closed source even if you ship the source code to paying customers, so long as the license prohibits them from sharing that source code with the general public

>A closed source product is still closed source even if you ship the source code to paying customers, so long as the license prohibits them from sharing that source code with the general public

There is an important distinction between having legal protection and having technical protection. Giving up the code may not cause you to lose legal protection, but it can certainly lead you to lose control of your product in fact.

As for the notes about how software used to be shipped, that's OK. But it does not disprove anything I said. Shipping a shared library and a program that loads it is simpler than anything else you can think of involving object files or whatever (that complies with LGPL). It is an approach that works on basically all platforms, requires no additional tools, and is often extremely easy to implement. Library compatibility issues are also minimal, if you are careful.

Of course switching to MIT eliminates these issues, but can cause other issues with people not contributing back to the libraries.

It's not a new development. It started in 2013:

https://lists.nongnu.org/archive/html/tinycc-devel/2013-05/m...

Glöckner appears to be exhibiting undefined behaviour.

The last man standing against the sellout. Good man

Reply on news.ycombinator.com