I make "modifications" to the kernel, then create a user land library to access
these "modifications". Obviously my kernel "modifications" are then GPL, but
what is the opinion of the kernel developers as far as the license of this
library? Does that user land library have to be GPL also?
Thanks
Mark
Ar Iau, 2006-10-26 am 05:45 -0400, ysgrifennodd Mark Hounschell:
> I make "modifications" to the kernel, then create a user land library to access
> these "modifications". Obviously my kernel "modifications" are then GPL, but
> what is the opinion of the kernel developers as far as the license of this
> library? Does that user land library have to be GPL also?
Ask your lawyer. It depends on the legal definition of "derivative
work", which isn't something a kernel developer can really answer.
Alan
Alan Cox wrote:
> Ar Iau, 2006-10-26 am 05:45 -0400, ysgrifennodd Mark Hounschell:
>> I make "modifications" to the kernel, then create a user land library to access
>> these "modifications". Obviously my kernel "modifications" are then GPL, but
>> what is the opinion of the kernel developers as far as the license of this
>> library? Does that user land library have to be GPL also?
>
> Ask your lawyer. It depends on the legal definition of "derivative
> work", which isn't something a kernel developer can really answer.
>
I'm sure every lawyer will have his own opinion. In the end won't it come down
to the intent of the kernel developer? Surly the definition of "derivative work"
has to be, or has been already, defined by someone other than a lawyer or court
that knows nothing of "kernel development"?
Mark
Ar Iau, 2006-10-26 am 07:28 -0400, ysgrifennodd Mark Hounschell:
> I'm sure every lawyer will have his own opinion. In the end won't it come down
> to the intent of the kernel developer? Surly the definition of "derivative work"
> has to be, or has been already, defined by someone other than a lawyer or court
> that knows nothing of "kernel development"?
"Derivative work" is a term of law, and it defines the boundaries of
copyright in most situations.
Alan
On 10/26/06, Mark Hounschell <[email protected]> wrote:
> I'm sure every lawyer will have his own opinion. In the end won't it come down
> to the intent of the kernel developer? Surly the definition of "derivative work"
> has to be, or has been already, defined by someone other than a lawyer or court
> that knows nothing of "kernel development"?
Please, consult a lawyer for legal advice, not the LKML.
On Thu, Oct 26, 2006 at 07:28:58AM -0400, Mark Hounschell wrote:
> Alan Cox wrote:
> > Ask your lawyer. It depends on the legal definition of "derivative
> > work", which isn't something a kernel developer can really answer.
> >
>
> I'm sure every lawyer will have his own opinion. In the end won't it come down
> to the intent of the kernel developer? Surly the definition of "derivative work"
> has to be, or has been already, defined by someone other than a lawyer or court
> that knows nothing of "kernel development"?
"Derivative work" is defined by copyright law, not by some random
kernel hackers. You should really consult a lawyer.
If legal advise is too expensive, then your Most Holy IP apparently
isn't worth that much and you'd rather release it under GPL.
Erik
--
+-- Erik Mouw -- http://www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
Erik Mouw wrote:
> On Thu, Oct 26, 2006 at 07:28:58AM -0400, Mark Hounschell wrote:
>> Alan Cox wrote:
>>> Ask your lawyer. It depends on the legal definition of "derivative
>>> work", which isn't something a kernel developer can really answer.
>>>
>> I'm sure every lawyer will have his own opinion. In the end won't it come down
>> to the intent of the kernel developer? Surly the definition of "derivative work"
>> has to be, or has been already, defined by someone other than a lawyer or court
>> that knows nothing of "kernel development"?
>
> "Derivative work" is defined by copyright law, not by some random
> kernel hackers. You should really consult a lawyer.
>
> If legal advise is too expensive, then your Most Holy IP apparently
> isn't worth that much and you'd rather release it under GPL.
>
>
> Erik
>
Any Holy IP I might have would be GPL. It's just I know of some that isn't and I
can't understand why it isn't. I'm not looking for legal advise. Just opinions.
Some code is added directly to the kernel source tree. A user land library is
written to access the changes. It is not GPL or LGPL. Simple scenario. No? I
thought so at least.
With all the complex and detailed (way over my head) discussions of the GPL-V2
vs. V3 that the list has had recently, I don't understand how something so
simple as this scenario would require legal advise to know if it were OK or not.
Thanks anyway
Mark
Ar Iau, 2006-10-26 am 09:11 -0400, ysgrifennodd Mark Hounschell:
> Some code is added directly to the kernel source tree. A user land library is
> written to access the changes. It is not GPL or LGPL. Simple scenario. No? I
> thought so at least.
It isn't a simple scenario because it depends what you are adding and
how the two parts interact, eg how generic they are.
Take a memory allocator - if I put a malloc implementation in the kernel
for some strange reason that provides malloc/free/realloc then a library
making use of those clearly isn't very closely tied - they are generic
functions.
Now suppose I have a device driver that is part kernel and part user
space that calls from one to the other for very specific functions that
are only of use to that driver.
In the usual case it doesn't matter, much stuff is GPL anyway, and for
the usual system calls/C library stuff not only is the law probably
fairly well established but there is an explicit statement with the
kernel that we don't want to claim such rights for a normal system call
which would guide a Judge if a case ever came up.
Alan
Alan Cox wrote:
> Ar Iau, 2006-10-26 am 09:11 -0400, ysgrifennodd Mark Hounschell:
>> Some code is added directly to the kernel source tree. A user land library is
>> written to access the changes. It is not GPL or LGPL. Simple scenario. No? I
>> thought so at least.
>
> It isn't a simple scenario because it depends what you are adding and
> how the two parts interact, eg how generic they are.
>
Thats one of the things I don't understand. How could a lawyer be qualified
enough to actually give proper advise on this. And how will a court be able to
make a proper decision if it had to. It seems to me they both would have to ask
you all.
> Take a memory allocator - if I put a malloc implementation in the kernel
> for some strange reason that provides malloc/free/realloc then a library
> making use of those clearly isn't very closely tied - they are generic
> functions.
>
> Now suppose I have a device driver that is part kernel and part user
> space that calls from one to the other for very specific functions that
> are only of use to that driver.
>
Hmm.
> In the usual case it doesn't matter, much stuff is GPL anyway, and for
> the usual system calls/C library stuff not only is the law probably
> fairly well established but there is an explicit statement with the
> kernel that we don't want to claim such rights for a normal system call
> which would guide a Judge if a case ever came up.
>
>
That's sort of what I was in search of. Where is this "explicit statement" found
BTW.
Thanks
Mark
Ar Iau, 2006-10-26 am 11:02 -0400, ysgrifennodd Mark Hounschell:
> > In the usual case it doesn't matter, much stuff is GPL anyway, and for
> > the usual system calls/C library stuff not only is the law probably
> > fairly well established but there is an explicit statement with the
> > kernel that we don't want to claim such rights for a normal system call
> > which would guide a Judge if a case ever came up.
> >
> >
>
> That's sort of what I was in search of. Where is this "explicit statement" found
> BTW.
COPYING file in the top directory of the kernel.
NOTE! 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".
Also note that the GPL below is copyrighted by the Free Software
Foundation, but the instance of code that it refers to (the Linux
kernel) is copyrighted by me and others who actually wrote it.
Also note that the only valid version of the GPL as far as the kernel
is concerned is _this_ particular version of the license (ie v2, not
v2.2 or v3.x or whatever), unless explicitly otherwise stated.
Linus Torvalds
On Thursday 26 October 2006 08:02, Mark Hounschell wrote:
> Alan Cox wrote:
> > In the usual case it doesn't matter, much stuff is GPL anyway, and for
> > the usual system calls/C library stuff not only is the law probably
> > fairly well established but there is an explicit statement with the
> > kernel that we don't want to claim such rights for a normal system call
> > which would guide a Judge if a case ever came up.
>
> That's sort of what I was in search of. Where is this "explicit statement"
> found BTW.
COPYING file in top-level directory.
> Thanks
> Mark
-- Vadim Lobanov