lkml.org 
[lkml]   [2003]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: People, not GPL [was: Re: Driver Model]
Date

> I invite you to read the COPYING file included in each and every
> kernel tarball. There is exactly ONE exception granted in the
> linux kernel copyright:
>
> This copyright does *not* cover user programs that use kernel
> services by normal system calls - this is merely considered
> normal use of the kernel, and does *not* fall under the
> heading of "derived work".

You are mistaken about what this is. This is not an exception being
granted. Nobody has the authority to grant GPL exceptions unless they are
the sole author and the Linux kernel does not have a sole author.

> All the noise in the world about other exceptions is precisely
> that, since the license granting use of the Linux kernel does
> not contain any additional provisions.

This is not a license provision, it's a license interpretation. If you can
show me why the interpretation doesn't apply to kernel modules, please do.

> Anything that can be identified as a "user program" that "use[s]
> kernel services by normal system calls" is, by virtue of the above
> license grant, doing so with permission and is therefore within
> its rights. So you can make all the closed source user space
> only One True(tm) iSCSI stacks you want.

Except it's not a license grant. If it is a license grant, please tell me
who had the authority to grant it.

> Anything that is not a "user program" (and I think everyone can
> agree a kernel module is not a "user program") is therefore a
> derivitive work.

Hahahahhahaha! Oh, that's too funny. "All dogs are mammals" means things
that aren't dogs aren't mammals? My pencil isn't a "user program". Is it a
derivative work of the Linux kernel in your opinion?

> Anything that is linked into the kernel (and I think everyone can
> agree a kernel module is linked into the kernel) and is therefore
> interfacing with kernel internals, rather than using "kernel
> services by normal system calls" is therefore a derivitive work.
>
> Laugh at people, mock people, rant, rave, wantever you want.
> When you are done making noise, please have your laywer explain
> how a closed source binary only product that runs within the
> context of the Linux kernel is not a derivitive work, per the
> very definition given in the kernel COPYING file that grants you
> your limited rights for copying, distribution and modification,

The same way a user program that runs within the context of the Linux
operating system is not a derivative work. A defined interface creates a
license boundary. If you can draw a line between the two works, neither is
derivative of the other.

And you are still ignoring the entire point, which is that it doesn't
matter whether or not such modules are derivative works. The GPL puts no
restrictions whatsoever on the creation or usage of derivative works that
are not distributed. The GPL does not say that you cannot make derivative
works unless you GPL them.

So the restriction GPL_ONLY places is *not* a restriction that exists in
the GPL which is the *only* license. Hence it does not enforce a license
restriction. It really is that simple.

And when it comes to respecting the author's wishes, I respect the wishes
of the many people who contributed to the Linux kernel expecting the GPL to
ensure that usage remained unrestricted. I don't not respect the wishes of
the people who try to impose usage restrictions on other people's GPL'd code
and I thoroughly disrespect those who would wield the DMCA to restrict
modifications to code placed under the GPL.

DS


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:48    [from the cache]
©2003-2011 Jasper Spaans