GPL modules for a differently licensed OS'

Posted Sep 5, 2007 12:01 UTC (Wed) by madscientist (subscriber, #16861)
In reply to: GPL modules for a differently licensed OS' by and
Parent article: Relicensing: what's legal and what's right

Well, I simplified things a bit because my intent was not to discuss the GPL per se, but rather the meaning of "derived from" in a legal sense.

Your issues are addressed by two clauses in the GPL. The first is the "mere aggregation" clause which confirms the FSF's belief that just putting two unrelated programs together on a CD (or on a hard disk) doesn't constitute a derived work. The FSF's position, as far as it can be collapsed into a single sentence, is that if the virtual runtime image in RAM of a program requires GPL'd code, then the total is a derived work.

Second, there is the "system library" exception clause, which says that if the GPL'd program requires libraries that are shipped as part of the underlying operating system (but the GPL'd program is NOT shipped as part of the underlying operating system) then the system libraries don't need to be under the GPL. The "mere aggregation" clause is really just an explicit statement of what most people think is true anyway; the "system library" clause, however, is a true exception to the GPL. It was really created for the days before Linux, when GPL'd software all ran on proprietary operating systems like SysV variants, SunOS, etc. but it works just as well for Windows for example.

Finally, your comment about GPL'd software using LGPL'd shared libraries is correct, actually: when the GPL'd software uses LGPL'd libraries the combination IS technically under the GPL. But that's OK, because the LGPL explicitly allows that it can be distributed under the strict GPL.

to post comments

GPL modules for a differently licensed OS'

Posted Sep 5, 2007 13:08 UTC (Wed) by and (guest, #2883) [Link] (7 responses)

> The first is the "mere aggregation" clause which confirms the FSF's
> belief that just putting two unrelated programs together on a CD (or on
> a hard disk) doesn't constitute a derived work. The FSF's position, as
> far as it can be collapsed into a single sentence, is that if the
> virtual runtime image in RAM of a program requires GPL'd code, then the
> total is a derived work.

Agreed. But this isn't this definition consistent with my original point:
if a OS is *BSD licensed and one of its drivers is GPL, the OS per se runs
fine without the driver (except that it has reduced functionality, but
that is also the case for a non-GPLed OS running GPLed user space
programs) and is thus not a derived work in this sense. The "code shares
the same address space" definition is also not really applicable, because
the kernel also has access to all user space memory, so GPLed user space
would still be impossible on top of non-GPL kernels. If the "system
library" is applied to prevent this, it sounds to me that it can then
equally be applied to the drivers, but IANAL.

On the other hand drivers can't run without the OS so they are clearly a
derived work. That's why non-GPL linux kernel modules are not
distributeable, strictly speaking. Or am I still missing something? In any
case it's damn muddy business ;)

GPL modules for a differently licensed OS'

Posted Sep 5, 2007 19:55 UTC (Wed) by madscientist (subscriber, #16861) [Link] (6 responses)

Yes, I see your point. I think the answer is that as long as you only ship the OS, then you're fine because the entirety of the OS doesn't contain any (is not derived from) GPL'd code. However, you would not be able to distribute both together because the combined work would contain GPL'd code. Then the question becomes, what if you get the GPL'd driver from somewhere else, not from the OS vendor? Then they OS vendor is not distributing GPL'd code, and the GPL ONLY deals with distribution, not use: you can use GPL'd code any way you want personally without any requirements. The answer here depends on the license the OS was under: if the license was not compatible with the GPL then the answer probably is that whomever distributed the driver to you was doing something illegal, because the driver is a derived work of the OS (even if they weren't shipped together) and there's no way to distribute code that satisfies both licenses. If the OS was under a GPL-compatible license such as the BSD license, then I don't see any problem with that. BUT, I don't think it can be provided as a standard part of the base OS, without the entire thing coming under the GPL. However, like you, IANAL.

As for your other points: first, I was careful to say the _virtual_ runtime image; I don't think the FSF is speaking of physical memory here. If they were then, ultimately, all software shares physical memory. And in this way, I don't think the kernel's license will impact the licensing of the program the kernel runs, because the kernel is not in the virtual image; it just has access to it. So I don't think the fact that the kernel manages the program's memory is a problem.

Of course, almost every possible program WILL interact with the kernel, through kernel system calls. It could be argued that because of this, every user space program is derived from the kernel. However, regardless of whether you think this is reasonable or not, Linus has made it moot as he has explicitly stated that he doesn't believe that using the user space system call interface brings software under the GPL.

In fact, it is even possible to create kernel modules, that run in kernel space, with licenses that are not compatible with the GPL. There is a certain set of module API interfaces which are explicitly marked as being able to be used this way. Here we get REALLY murky because not even all Linux kernel devs, as far as I've seen, really agree on exactly what this means and how it works.

GPL modules for a differently licensed OS'

Posted Sep 6, 2007 0:09 UTC (Thu) by and (guest, #2883) [Link] (5 responses)

ok, this seems to be a kind of a PHD problem for a law stundent with a
strong computer science background *g*. I'm perfectly aware of the spirit
of the GPL (which I would think is opposed to doing such a thing), though
I'm not sure what the word says. Even if the GPL says something about
the "virtual" ram image, what is that in the first place? Does shared
memory between kernel mode code and user space code constitute an image?
How about architectures which don't sport an MMU like the ones ulinux is
targeting at? (This would have the interesting implication that it would
depend on the processor of whether it is possible to distribute a GPL user
space program with non-GPL kernels and vince-versa, but it would be OK to
ship the GPL user space code for a MMU-enabled platform and compile it
yourself for the MMU-less.) So I think it's basically impossible to
define "derived from" in any meaningful technical sense, except "if code A
can run without requiring code B then A is not a derivative". Also all
definitions are mood if someone writes some kind of minimal GPL kernel
capable of loading the unmodified GPLed modules and shipping it
as "unrelated" software on the same medium...

Also I've got some doubts whether the expressed opinions of Linus and RMS
about the GPL have any relevance legally, especially for code they don't
hold the copyright for. In any case, issues like that make me glad being a
computer scientist and not a lawyer; let's go back coding ;)

GPL modules for a differently licensed OS'

Posted Sep 6, 2007 1:27 UTC (Thu) by madscientist (subscriber, #16861) [Link] (1 responses)

No, of course the GPL doesn't say anything about RAM, virtual or otherwise. I'm just trying to make concrete the various statements about applicability of the GPL that I've seen FSF folks make over time. As you so eloquently show, this is essentially impossible when it comes to technology--which is very likely why they have learned to never do it! Now I've learned that lesson as well :-). I think we'll just have to go with Justice Potter Stewart's definition: "I know it when I see it". Personally I think it's fairly clear what the FSF intends to be covered, and they obviously feel that the GPL enforces that intent. Since we have no judicial decisions, that's the best we can do.

Although you are certainly correct that the expressed opinions of RMS and Linus will have little effect on what a judge may eventually decide, their opinions are actually of critical importance, in this way: it's impossible for a judge to decide anything about the GPL until a case arrives in her courtroom, and it's impossible for a case to arrive until and unless someone with standing brings it. In the case of RMS the situation is extraordinarily clear: the FSF holds sole copyright to ALL GNU programs, and so it's essentially completely up to RMS to bring that case. So what he thinks about what people are doing with GNU software is the single most important factor. Linus doesn't hold sole copyright to the kernel; however it seems highly unlikely to me that a case involving Linux could go anywhere without his agreement, practically speaking.

I do agree we should get back to coding, though. Much more satisfying!

GPL modules for a differently licensed OS'

Posted Sep 22, 2007 13:57 UTC (Sat) by kreutzm (guest, #4700) [Link]

Just a minor note: The cases in Germany involving the Linux kernel were brought forward (and won) by Harald Welte (netfilter) not Linus Torvalds.

GPL modules for a differently licensed OS'

Posted Sep 13, 2007 19:20 UTC (Thu) by nim-nim (subscriber, #34454) [Link] (2 responses)

You have to understand the GPL is based on the "derivative" part of copyright international laws, and these laws are not software-specific, and indeed their roots are older than computers.

Software people do not understand legal concepts and keep trying to reduce derivation to its technical implementations. (because they feel confident that once they've nailed derivation to a particular technical effect they'll be able to find another they can safely use).

The hard truth is derivative is anything that makes use of ideas/code in the protected work. So it does not matter how this use is effected. Using creative indirections does not make derivation moot. If you figure a technical way to use some protected work, the sum of protected work + your stuff is a derived work.

That is unless you can prove your stuff was designed for something else, and this something else was not heavily inspired by the protected work. Of course if that were the case you'd not be trying to squiggle past "derivation" definitions.

GPL modules for a differently licensed OS'

Posted Sep 15, 2007 14:47 UTC (Sat) by sepreece (guest, #19270) [Link] (1 responses)

"The hard truth is derivative is anything that makes use of ideas/code in the protected work."

Well, no. Copyright doesn't protect ideas, it only protects the expression of ideas. You can rephrase those ideas in other language without violating the copyright. However, the Devil is in the details and the analysis is not simple. There are scads of court decisions on specific cases, many of which seem to conflict.

Also, copyright does not control "functional aspects". There is a fair amount of precedent indicating that copyright doesn't apply when a program is simply using or interfacing with another program - that even direct copying of code may be OK when it is necessary to allow interoperation.

scott

GPL modules for a differently licensed OS'

Posted Sep 16, 2007 19:54 UTC (Sun) by nim-nim (subscriber, #34454) [Link]

Ideas in the protected work being idea expressions.

Anyway.

You are not allowed to "rephrase" a copyrighted works idea expressions.

Copyright law allows looking at something to produce something else. Copyright law allows not looking at something to produce the same thing.

But copyright law forbids translation of something in the same something in another language/medium/format whatever. It does not take a judge a lot to decide something else is effectively something else. But mere rephrasing won't do.

Just ask J K Rowling what she thinks about your legal theory. I believe she sent a few rephrasers to jail.