Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

On Friday 15 June 2007 05:17:44 David Woodhouse wrote:
On Fri, 2007-06-15 at 04:58 -0400, Daniel Hazelton wrote:
If the module is distributed 'as a separate work', _then_ what you say
is true: the only reason you'd have a right to the source is if the
module is considered a 'derivative work'.

But when you distribute the same module as part of a whole which is a
work based on the kernel, the distribution of the whole must be on the
terms of GPL, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote
it.

-ELOGIC

What's logic got to do with it? It was fairly much a direct quote from
the licence. You have _read_ the licence, haven't you?

Hrm... Perhaps I misread your post originally. Let me read it again and see if
I didn't encounter a parsing error somewhere... Nope. Error of omission. The
text you cut changes the meaning of the passage in its entirety.

Here, I'll quote it, in it's entirety:

These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote it.

In other words, it applies to *SECTIONS* of the code, not to individual object
code files. This is why kernel modules can have their own, separate license
from the kernel. It isn't until the code is shipped as a *standard* part of
the kernel that it has to be GPLv2. (Dynamic Linking, being a totally
mechanical process, cannot create a derivative work under US copyright law,
so please, don't try that old saw)

What this means is that it doesn't matter that a non-GPL module is shipped,
in "object code" form with the "object code" form of the linux kernel it is
designed to interface with - it *still* doesn't become automatically covered
by the GPL.

The words you used were 'with the kernel', which could actually mean
either of the above. In the case of embedded Linux-based firmware
though, it's definitely the latter. It's a coherent whole, and it
contains both the kernel and the module. Thus the GPL extends to each
and every part, regardless of who wrote it. Including the module.

Just because two things are bundled together doesn't put them under the
same license or copyright. Take a look at the GPL, which specifically
mentions that "mere aggregation" does not cause something to fall under
the GPL. Not that the GPL can even change the law - in the US copyright
law specifically states that "mechanical translation" and "mechanical
processes" *CANNOT* create a "new" work. Since the process of compiling
source into a binary is, by definition, a *mechanical* process then the
binary can't suddenly become covered by a different copyright license
than the source code merely because of the medium on which its
distributed or the manner in which it is distributed.

You're confused.

Nope. Not confused at all.

If I grant you a licence on the condition that you give me money, would
you object on the basis that the money is not a 'derived work' of my
code? No. It's just a condition of the licence, and you're not allowed
to use my code unless you give me money.

But you obviously are. After all, what does this have to do with whether the
GPLv2 can "magically" change the law?

If I grant you a licence on the condition that you sacrifice your
first-born son to Satan, would you object on the basis that your son is
not a 'derived work' of my code? No. It's just a condition of the
licence. If you don't do it, you don't have the right to use my code.
(You may be able to get me locked up, but you still don't get to use my
code without a licence).

If I grant you a licence on the condition that you release _everything_
you write this year under the GPLv2, would you object on the basis that
your code is not a 'derived work' of my own? No. It's just a condition
of the licence, which you choose to accept or not.

Again, what does this have to do with your apparent belief that me putting a
binary of a kernel module that isn't GPL'd on a disc with the Linux kernel
causes that module to become covered by the GPL?

If I grant you a licence on the condition that anything you release in
_combination_ with my code must also be released under the GPL, would
you object on the basis that you code is not a 'derived work' of my own?
No. Again, it's just a condition of the licence. If you don't want to
obey the licence, you don't get to use the kernel in the first place.

Talking about how your code can't possibly be a derived work is just a
red herring. The GPL explicitly talks about works which are 'independent
and separate works in themselves', to which the GPL does not apply 'when
you distribute them as separate works'.

And it also says:
In addition, mere aggregation of another work not based on the Program
with the Program (or with a work based on the Program) on a volume of
a storage or distribution medium does not bring the other work under
the scope of this License.

In other words, even though I've built a program that isn't GPL'd, I can still
put it on the same "volume of storage or distribution medium" as a GPL'd work
and not have to put it under the GPL. Imagine that.

And again, I have to point out that, no matter what RMS and the rest of the
people that wrote the GPLv2 may believe, it can't change the law on which it
is based. If the law says "mechanical translation or processes cannot produce
a new work", then no matter what the GPLv2 says, I can write a parser
skeleton in the "YACC" language, run it through Bison and *NOT* need
the "exception" that the FSF "thoughtfully" provides. Why? Because the
*skeleton* I wrote carries the copyright - not the output of Bison, despite
what the GPL *might* say on this in Section 0. A license *cannot* change the
law, because it gets all its power from the law.

But when you distribute the same sections as part of a whole which is a
work based on the Program, the distribution of the whole must be on the
terms of this License, whose permissions for other licensees extend to
the entire whole, and thus to each and every part regardless of who
wrote it.

Hrm... I see, you've included the section unmolested here - but you still seem
unable to read it correctly. Perhaps I'm wrong though.

It's your choice -- you're not _forced_ to use the kernel, and you're
not _forced_ to distribute a product which combines it with other code
of your own. But if you do, you're bound by the licence. And whether
your code is a 'derived work' has nothing to do with it.

And is this what the process of making a module does? Because that *IS* what I
had mentioned. If the mail I'm responding to was a response to that mail then
you are sadly confused as to what I was talking about.

Yes, there are exceptions for mere aggregation onto a storage medium --
if the kernel and your own work are next to each other on a backup tape
or your laptop's hard drive, or even both burned to a 'Gratis Software'
CD as _separate_ works, then that doesn't count. But we're talking about
a product which has a Linux kernel, a module built specifically for that
kernel, and cannot function unless both of them are present. That ain't
"mere aggregation on a storage medium".

Yet it still doesn't make them a "combined work". If it did then the simple
act of me installing a copy of the ATI or NVidia modules makes them GPL'd.
But it doesn't - if it did I'm sure that somebody would have filed a lawsuit
over this already.

DRH


--
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: Artistic License (license to steal?) - Open Source copyrights
    ... as GPL. ... of what's actually in the licence you agree to by using the software. ... Although theoretically either license could be changed, ... labels Perl's artistic license as potentially viral," said Wall, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Story Time
    ... In this case, the General Public License says that "you" can freely use "his" code, but that if you distribute the subsequent binaries to anyone else, you must share your changes with "them". ... the GPL encourages you to charge money for shipping your code to your distributees. ... difference ins the kernel between the two versions. ...
    (comp.os.vms)
  • Re: module license taints kernel.
    ... that *I* need to comply with the GPL, ... But if some entity wants to distribute the GPL:ed kernel, ... they get the right to do so by obeying the license. ... are you copying or distributing the kernel, ...
    (comp.os.linux.development.system)
  • RE: GPL weasels and the atheros stink
    ... under the ISC licence, OR the GPL licence. ... GPLv2 into code that is licensed under the dual license and distribute the ...
    (Linux-Kernel)
  • Re: From the LuxAsm list.
    ... > No. I'm not asking anything about GPL. ... >> have no other License but the one choosen by the Programmer. ... see clause 5 of the RosAsm licence. ...
    (alt.lang.asm)