TechView: Linus Torvalds, Inventor of Linux (Huffington Post)

Posted May 25, 2014 1:37 UTC (Sun) by khim (subscriber, #9252)
In reply to: TechView: Linus Torvalds, Inventor of Linux (Huffington Post) by madscientist
Parent article: TechView: Linus Torvalds, Inventor of Linux (Huffington Post)

I have no opinion on whether anonymous "people" want to "get involved" or not, or what they feel about "clear separation between GPL and BSD" (is there any other sort of separation? I'm not sure what this is supposed to mean).

Yes, sure. I'll show you.

What you think it means, or I think it means, or even what lawyers or the courts think it means is totally irrelevant unless the FSF initiates a legal action, and they've made clear that they don't consider compiling programs with GCC and distributing them under a license which is not compatible with the GPL (any version) to be infringement of GCC's copyright.

Right. It's Ok to distribute a program linked to libstdc++.so because of Runtime Library Exception. It says quite clearly that You have permission to propagate a work of Target Code formed by combining the Runtime Library with Independent Modules, even if such propagation would otherwise violate the terms of GPLv3, provided that all Target Code was generated by Eligible Compilation Processes.

But what about libstdc++.so itself? When you distribute it you distribute something build not from combination of Runtime Library and Independent Modules, but something built solely from sources of the Runtime Library! Exception is not in play and pure GPL applies. Which, as we all know, includes anti-Tivozation clause. Which means that BSD OS with libstdc++.so included is affected by GPLv3: one must provide a way to replace libstdc++.so on the device because that's requirement of GPLv3 and Runtime Library Exception is not in play.

Does it look like The GPL is isolated to the compiler itself, not the whole distribution? I think not.

One could cope with this problem by refusing to provide libstdc++.so (that's how Android solves this problem, e.g.), but it's clearly simpler and more robust to not ship libdtc++ at all and use libc++. Which implies LLVM.

TechView: Linus Torvalds, Inventor of Linux (Huffington Post)

Posted May 26, 2014 14:41 UTC (Mon) by andza (guest, #72692) [Link] (1 responses)

Hm, that's an interesting thought about libstdc++.so itself being GPLv3. I've never thought of the implications of this, especially concerning the world of embedded Linux.

TechView: Linus Torvalds, Inventor of Linux (Huffington Post)

Posted May 26, 2014 22:45 UTC (Mon) by simlo (guest, #10866) [Link]

Me neither.

I understand that FSF want to avoid that people lock down devices with crypto. But I have a problem with mandating to document a way to update the GPLv3 parts:

A typical practice within embedded is to make a complete filesystem image including GPL'ed and non-GPL'ed parts and mount it read-only. The only way to update the system is to update the full image, through a very specific upload procedure, for instance via a USB stick or via ftp.
Now if the user wants to update libstdc++.so, either some kind of ftp, scp access have to be given to the user, the system needs to be mounted rw. The hardware might even not support that.

Or the user shall be able to build his own image and from the bits already on the device + the newly build libstdc++.so.

Neither solution are practical for the device manufactures - which might be some small company making a small Linux device, it does not have to be a big phone company.

I would prefer that FSF softenes the language, such that it shall be forbidden to make obstacles to updating GPL parts by using crypto or checksums to avoid booting the modified software, but not mandating that there should be an manual for how to update it.
The way "device hackers" would be able to update it as they would for a non-crypted GPLv2 device, but not normal persons.

PS. I work with embedded Linux, but it does not fall under "User Products", so I am not worried about it.

TechView: Linus Torvalds, Inventor of Linux (Huffington Post)

Posted May 27, 2014 11:59 UTC (Tue) by madscientist (subscriber, #16861) [Link]

> Does it look like The GPL is isolated to the compiler itself,
> not the whole distribution? I think not.

You are arguing a straw-man here. I made no comments about "whole distributions". Yes, it's true that even though GCC's license doesn't apply to your binary that doesn't mean you can distribute libstdc++.so itself without obeying its licensing restrictions, which are GPLv3. But, that has no relationship to what the original poster claimed, and what I was replying to, which was:

> The gcc-compiled binaries can not be licensed freely under any licence
> you like (binaries will be linked against libraries which are part of
> the compiler, and the viral nature of GPLv3 means that the resulting
> programs have to be licensed under GPLv3).

However, regarding your issue you have these options: either don't distribute libstdc++.so yourself and rely on the distribution to provide it (that's what virtually all GNU/Linux proprietary programs do), or distribute libstdc++.so yourself and obey the licensing restrictions for that library (which still do not apply to your binary, and are not more onerous than GPLv2 except in very specific circumstances where things like TiVo-ization come into play), or don't distribute libstdc++.so as an independent library (that is, statically link libstdc++.a).