Comment by dijit
6 months ago
weird tangential question then: when does GPL stop being infectious?
I would understand in a modular system like an operating system: one can argue that the kernel is a single component.
But if you're buying an appliance, the OS is effectively one single unit: all linked together.
Why does a binary executable and a binary image seem to operate differently in this space - both are inscrutable?
The FSF has always been pretty clear on this: you use a linker (static or dynamic) = it applies; you don't = it doesn't. They even wrote LGPL with this distinction in mind, and introduced exceptions to yacc (bison) to accommodate non-free software.
In case of binary releases, you can request the sources of the relevant subcomponent (e.g. the kernel). The component boundaries are pretty clear wrt Linux: Torvalds has made it quite clear early on, that the kernel's GPL2 does not apply to anything in the user space.
Here also, the important distinction between GPL 2 & 3: with GPL3, it would be a breach of the license to ship code on a device that does not allow the end user to update that code. Which has effectively pushed everyone away from GPL3-licensed software.
IMHO the move to GPL3 has likely caused more harm than good to the FOSS ecosystem; in some alternative universe, GPL3 never happened, most of Android's userspace is GPL2, and we get the source for everything. In both universes we still don't get to deploy changes to devices we own, so IMHO the GPL3 won us nothing.
The FSF considers linking to be a definite example of derived works in general, but I don't believe they consider lack of linking to prove that something isn't a derived work.
The goal of the GPL is to flip draconian copyright maximalism on its head, and copyright laws don't talk about linkers so that can't be the deciding factor. Not to mention that it would be trivial to work around linking by creating a stub and calling the GPL code as a subprogram (in kernel contexts a spiritually similar setup is called the "GPL condom" and my impression is that most lawyers not employed by NVIDIA consider this to not be a get-out-of-jail-free card).
> (in kernel contexts a spiritually similar setup is called the "GPL condom" and my impression is that most lawyers not employed by NVIDIA consider this to not be a get-out-of-jail-free card).
The whole thing with Linux's conception is that it's predicated on any and all unlicensed usage of GPL-only interfaces being copyright infringement of other usage in the kernel source. This is an extremely broad claim to make in general (especially in light of Google v. Oracle), and the 'GPL condom' approach is just to further ensure that the unlicensed side is textually unrelated to the kernel. When there's no infringement, the copyright holders can't do a single thing, except to technologically make it harder on you.
Meanwhile, the whole GPL idea of linking vs. statically embedding is only applicable when you're shipping someone else's GPL-licensed code alongside your non-licensed code, in which case you're bound by its terms. If you're not shipping someone else's code, then there's plenty of ways to force a particular build, etc., in the manner that the GPL is trying to prevent. Heaven knows I've likely violated the spirit of the GPL before just through Hyrum's law.
6 replies →
That is explicitly mentioned in GPL FAQ:
https://www.gnu.org/licenses/gpl-faq.html#MereAggregation
Note that all FOSS OSes for embedded systems none of them are GPL based, Linux kernel is the only remaining GPL project amongst the alternatives.
Eventually everything comes to past, us in this realm, and the legacy left behind, eventually other projects will take Linux place, it can even be an heavily forked Linux.
The short answer is copyright law and jurisprudence. The whole purpose of copyleft is to flip draconian copyright regimes over and make them protect users instead, so the GPL generally has the most maximalist stance allowed by copyright law. If copyright law would say that combining or extending software in a particular way is not fair use then the GPL generally would render the combination GPL.
In practice, GPLv2 would not be viral in the way you describe unless you can show that all of Android is a derived work of Linux (not true). GPLv3 would require users be avle to replace components under said license which has an impact on how such an appliance need to work (though the GPLv2 does also have somewhat related text about "the scripts which control installation") but wouldn't expand the scope of code under the license, just the terms.
Sadly, the layperson's and lay developer's interpretation of the GPL has been watered down over the years, and the GPL wasn't maximalist enough to begin with - see AGPL, SSPL for extensions created by people who saw new kinds of linking that didn't appear to be covered by the GPL. Of course big corporations preferably use these new kinds of linking that aren't covered, which is why new licenses are necessary.
> the OS is effectively one single unit: all linked together
If your appliance runs linux it has separate components just like desktop linux.
You want to do as little as possible in kernel space, and depending on the appliance there isn't even any need for it.
So, like desktop linux, you can have closed source binaries on top of the kernel.
I just don’t see the distinction as clearly when it’s a single binary that cannot be decoupled or introspected.
Why is it if I build a static binary with GPL code and distribute it I must open source my changes; but if you do the same as a whole OS it’s not necessary.
Feels like it should all be fine or none of it is fine somehow.
If you go that way, every bash script you've ever written should also be under the GPL.
And R code, at a quick glance.
1 reply →
There's a concept of "separate works", see for example https://www.gnu.org/licenses/gpl-faq.html#GPLCompatInstaller .
Tangentially, I assumed that the GPL must have some built-in exception for running non-GPL userspace programs on top of a GPLed kernel (similar to the System Library exception). However, it seems like it doesn't, since the Linux kernel has its own exception to allow this: https://spdx.org/licenses/Linux-syscall-note.html.
Note that the Linux syscall exemption is actually not the license of the entirety of Linux, because most code contributed to Linux is under the standard GPLv2. It's just a red herring -- there is no need for such an exemption because the generally held view is that such programs are not derived works of Linux (from a copyright law perspective) in the first place.
> when does GPL stop being infectious?
Either a) when the license has an explicit exemption (such as at glibc or the kernel's userspace interfaces) or b) when something ceases to be a "derivative work" in copyright terms (which is ultimately a legal question for lawyers).
Or existing on the other end of ipc.
No. The FSF takes the position that a program that is deeply entangled with another is a derivative work and can be subject to the GPL, even if that deep entanglement takes place over IPC.