Linus Torvalds first released the Linux Kernel in September of 1991 under a very restrictive license requiring that the source code must always be available, and that no money could ever be made off of it. A few months later, he switched to the GPL, or GNU General Public License, the license that has been used for the Linux kernel source code ever since. A recent thread on the lkml discussed some of the gray areas of legality where it's not explicitly clear what the GPL allows. Alan Cox [interview] was one of many kernel developers to offer some insights:

"The boundary of the GPL is what is called a 'derivative work'. This is the basic concept in law used by copyright and essentially asks 'is this work created in such a way that it is based on the original work in some meaningful fashion'. Its a complex area of law and only a lawyer can give definitive answers."

"The simple 'application for Linux' case is clear. The simple 'kernel modification' case is also clear. In the middle is the vague area that is for lawyers."

From: Ramakanth Gunuganti [email blocked]
To:  linux-kernel
Subject: GPL issues
Date:	Mon, 10 Apr 2006 23:31:27 -0700 (PDT)

I am trying to understand the GPL boundaries for
Linux, any clarification provided on the following
issues below would be great:

As part of a project, I would like to extend the Linux
kernel to support some additional features needed for
the project, the changes will include:
  o  Modification to Linux kernel.
  o  Adding new kernel modules.
  o  New system calls/IOCTLs to use the kernel
modifications/LKMs.

All kernel changes including LKMs will be released
under GPL.

Questions:

(Any reference to GPL license while answering these
questions would be great)

1. If an application is built on top of this modified
kernel, should the application be released under GPL?
Do system calls provide a bounday for GPL? How does
this work with LKMs, all the code for LKMs will be
released but would a userspace application using the
LKMs choose not to use GPL?

2. If the application has to be packaged with the
Linux kernel, example: tarball that includes kernel +
application, can this application be released without
GPL. (The changes to Linux kernel are already released
under GPL).

3. How does this work if this application + kernel has
to run on a proprietary system on a seperate interface
card? Can I assume that once there is a clear hardware
boundary rest of the software for the system does not
have to be released under GPL? The software for the
interface card will be built and distributed
seperately from the rest of the software.

4. Can the GPL code and non-GPL code exist under the
same source tree?

5. In case of litigation, will there be pressure to
open up other parts of the software (non-GPL) running
on the same system but on other hardware components
interacting with this new package on a different
interface card?

Anyone trying to build a new application to work on
Linux must have these issues clarified, if you can
share your experiences that would be great too.

Thanks,
Ram



From: Alan Cox [email blocked]
Subject: Re: GPL issues
Date:	Wed, 12 Apr 2006 00:12:19 +0100

On Llu, 2006-04-10 at 23:31 -0700, Ramakanth Gunuganti wrote:
> 1. If an application is built on top of this modified
> kernel, should the application be released under GPL?
> Do system calls provide a bounday for GPL? How does
> this work with LKMs, all the code for LKMs will be
> released but would a userspace application using the
> LKMs choose not to use GPL?

The boundary of the GPL is what is called a "derivative work". This is
the basic concept in law used by copyright and essentially asks "is this
work created in such a way that it is based on the original work in some
meaningful fashion". Its a complex area of law and only a lawyer can
give definitive answers.

The usual case is releasing an application for the Linux OS. It is
unlikely that using system calls could be considered "derivative" and in
case there is doubt the copying file with the Linux kernel specifically
excludes this case because the authors don't want some peculiar legal
interpretation to suddenely try and claim rights on applications running
on Linux.

Your questions really come into the realm of lawyers not programmers
however especially the various fringe areas.

The simple "application for Linux" case is clear. The simple "kernel
modification" case is also clear. In the middle is the vague area that
is for lawyers.


From: "Pramod Srinivasan" [email blocked]
Subject: Re: GPL issues
Date:	Wed, 12 Apr 2006 00:01:02 -0700

> 3. Userspace code that uses interfaces that was not exposed to userspace
> before you change the kernel --> GPL (but don't do it; there's almost
> always a reason why an interface is not exported to userspace)

> 4. Userspace code that only uses existing interfaces --> choose
> license yourself (but of course, GPL would be nice...)

> 5. Userspace code that depends on interfaces you added to the kernel
> --> consult a lawyer (if this interface is something completely new,
> you can *probably* use your own license for the userland part; if the
> interface is more or less a wrapper of existing functionality, GPL)

An example could be helpful in clarifying the GPL license.

Suppose I use the linux-vrf patch for the kernel that is freely
available and use the extended setsocket options such as SO_VRF in an
application, do I have to release my application under GPL since I am
using a facility in the kernel that a standard linux kernel does not
provide?

Suppose my LKM driver adds a extra header to all outgoing packets and
removes the extra header from the incoming packets, should this driver
be released under GPL.? In a way it extends the functionality of
linux, if I do release the driver code under GPL because this was
built with linux  in mind, Should I release the application  which
adds intelligence to interpret the extra header under GPL?

Thanks,
Pramod



From: Jan Engelhardt [email blocked]
Subject: Re: GPL issues
Date:	Wed, 12 Apr 2006 11:06:33 +0200 (MEST)


<obligatory_ianal_marker>

>Suppose I use the linux-vrf patch for the kernel that is freely
>available and use the extended setsocket options such as SO_VRF in an
>application, do I have to release my application under GPL since I am
>using a facility in the kernel that a standard linux kernel does not
>provide?
>

If vrf has no other uses besides your proprietary application, I'd shudder.

>Suppose my LKM driver adds a extra header to all outgoing packets and
>removes the extra header from the incoming packets, should this driver
>be released under GPL.? In a way it extends the functionality of
>linux, if I do release the driver code under GPL because this was
>built with linux  in mind, Should I release the application  which
>adds intelligence to interpret the extra header under GPL?
>

I don't know an answer (not even a rough one), since there is AFAICS one 
example of what you describe: the CiscoVPN kernel module. The source is 
available (so you have a chance to run it on any kernel you like), but it's 
got a typical EULA. No sign of GPL.



Jan Engelhardt



From: Alan Cox [email blocked]
Subject: Re: GPL issues
Date:	Wed, 12 Apr 2006 10:28:55 +0100

On Mer, 2006-04-12 at 11:06 +0200, Jan Engelhardt wrote:
> I don't know an answer (not even a rough one), since there is AFAICS one 
> example of what you describe: the CiscoVPN kernel module. The source is 
> available (so you have a chance to run it on any kernel you like), but it's 
> got a typical EULA. No sign of GPL.

A matter some people have on their list of targets...


From: David Weinehall [email blocked]
Subject: Re: GPL issues
Date:	Wed, 12 Apr 2006 01:06:42 +0200

OK, simplified rules; if you follow them you should generally be OK:

1. Changes to kernel --> GPL

2. Kernel driver --> GPL

3. Userspace code that uses interfaces that was not exposed to userspace
before you change the kernel --> GPL (but don't do it; there's almost
always a reason why an interface is not exported to userspace)

4. Userspace code that only uses existing interfaces --> choose
license yourself (but of course, GPL would be nice...)

5. Userspace code that depends on interfaces you added to the kernel
--> consult a lawyer (if this interface is something completely new,
you can *probably* use your own license for the userland part; if the
interface is more or less a wrapper of existing functionality, GPL)

And of course, I'm not a lawyer either...


Regards: David Weinehall
-- 
 /) David Weinehall [email blocked] /) Northern lights wander      (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/    (/   Full colour fire           (/



From: Mark Lord [email blocked]
Subject: Re: GPL issues
Date:	Tue, 11 Apr 2006 23:18:04 -0400

Joshua Hudson wrote:
> On 4/11/06, David Weinehall [email blocked] wrote:
>> OK, simplified rules; if you follow them you should generally be OK:
..
>> 3. Userspace code that uses interfaces that was not exposed to userspace
>> before you change the kernel --> GPL (but don't do it; there's almost
>> always a reason why an interface is not exported to userspace)
>>
>> 4. Userspace code that only uses existing interfaces --> choose
>> license yourself (but of course, GPL would be nice...)

Err.. there is ZERO difference between situations 3 and 4.
Userspace code can be any license one wants, regardless of where
or when or how the syscalls are added to the kernel.

Cheers



From: Arjan van de Ven [email blocked]
Subject: Re: GPL issues
Date:	Wed, 12 Apr 2006 07:31:26 +0200

On Tue, 2006-04-11 at 23:18 -0400, Mark Lord wrote:
> Joshua Hudson wrote:
> > On 4/11/06, David Weinehall [email blocked] wrote:
> >> OK, simplified rules; if you follow them you should generally be OK:
> ..
> >> 3. Userspace code that uses interfaces that was not exposed to userspace
> >> before you change the kernel --> GPL (but don't do it; there's almost
> >> always a reason why an interface is not exported to userspace)
> >>
> >> 4. Userspace code that only uses existing interfaces --> choose
> >> license yourself (but of course, GPL would be nice...)
> 
> Err.. there is ZERO difference between situations 3 and 4.
> Userspace code can be any license one wants, regardless of where
> or when or how the syscalls are added to the kernel.

that is not so clear if the syscalls were added exclusively for this
application by the authors of the application....



From: "jdow" [email blocked]
Subject: Re: GPL issues
Date:	Tue, 11 Apr 2006 22:45:55 -0700

> On Tue, 2006-04-11 at 23:18 -0400, Mark Lord wrote:
>> Joshua Hudson wrote:
>> > On 4/11/06, David Weinehall [email blocked] wrote:
>> >> OK, simplified rules; if you follow them you should generally be OK:
>> ..
>> >> 3. Userspace code that uses interfaces that was not exposed to userspace
>> >> before you change the kernel --> GPL (but don't do it; there's almost
>> >> always a reason why an interface is not exported to userspace)
>> >>
>> >> 4. Userspace code that only uses existing interfaces --> choose
>> >> license yourself (but of course, GPL would be nice...)
>> 
>> Err.. there is ZERO difference between situations 3 and 4.
>> Userspace code can be any license one wants, regardless of where
>> or when or how the syscalls are added to the kernel.
> 
> that is not so clear if the syscalls were added exclusively for this
> application by the authors of the application....

Consider a book. The book is GPLed. I do not have to GPL my brain when
I read the book.

I add some margin notes to the GPLed book. I still do not have to GPL
my brain when I read the book.

{^_^}   Joanne Dow



From: David Weinehall [email blocked]
Subject: Re: GPL issues
Date:	Wed, 12 Apr 2006 08:01:22 +0200

On Tue, Apr 11, 2006 at 10:45:55PM -0700, jdow wrote:
> >On Tue, 2006-04-11 at 23:18 -0400, Mark Lord wrote:
> >>Joshua Hudson wrote:
> >>> On 4/11/06, David Weinehall [email blocked] wrote:
> >>>> OK, simplified rules; if you follow them you should generally be OK:
> >>..
> >>>> 3. Userspace code that uses interfaces that was not exposed to 
> >>userspace
> >>>> before you change the kernel --> GPL (but don't do it; there's almost
> >>>> always a reason why an interface is not exported to userspace)
> >>>>
> >>>> 4. Userspace code that only uses existing interfaces --> choose
> >>>> license yourself (but of course, GPL would be nice...)
> >>
> >>Err.. there is ZERO difference between situations 3 and 4.
> >>Userspace code can be any license one wants, regardless of where
> >>or when or how the syscalls are added to the kernel.
> >
> >that is not so clear if the syscalls were added exclusively for this
> >application by the authors of the application....
> 
> Consider a book. The book is GPLed. I do not have to GPL my brain when
> I read the book.
> 
> I add some margin notes to the GPLed book. I still do not have to GPL
> my brain when I read the book.

This is possibly the worst comparison I've read in a long long time...

It's rather a case of:

Consider a book.  The book is GPLed.  You take add one chapter to the
book.  The resulting book needs to be GPLed.

Now, instead of adding to that book, you "export" parts of the book by
copying them into your book.  Your new book wouldn't work without the
copied parts.  Your resulting book needs to be GPLed.

Your "read the book"-case is only comparable to the case of building
a userspace binary for local use that only uses existing interfaces,
vs building one that uses exported private interfaces.  In both cases,
since you're not distributing your modified version, you're free to
do whatever you like.


Regards: David
-- 
 /) David Weinehall [email blocked] /) Northern lights wander      (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/    (/   Full colour fire           (/
-



From: "jdow" [email blocked]
Subject: Re: GPL issues
Date:	Tue, 11 Apr 2006 23:26:37 -0700

From: "David Weinehall" [email blocked]
> On Tue, Apr 11, 2006 at 10:45:55PM -0700, jdow wrote:
>> >On Tue, 2006-04-11 at 23:18 -0400, Mark Lord wrote:
>> >>Joshua Hudson wrote:
>> >>> On 4/11/06, David Weinehall [email blocked] wrote:
>> >>>> OK, simplified rules; if you follow them you should generally be OK:
>> >>..
>> >>>> 3. Userspace code that uses interfaces that was not exposed to 
>> >>userspace
>> >>>> before you change the kernel --> GPL (but don't do it; there's almost
>> >>>> always a reason why an interface is not exported to userspace)
>> >>>>
>> >>>> 4. Userspace code that only uses existing interfaces --> choose
>> >>>> license yourself (but of course, GPL would be nice...)
>> >>
>> >>Err.. there is ZERO difference between situations 3 and 4.
>> >>Userspace code can be any license one wants, regardless of where
>> >>or when or how the syscalls are added to the kernel.
>> >
>> >that is not so clear if the syscalls were added exclusively for this
>> >application by the authors of the application....
>> 
>> Consider a book. The book is GPLed. I do not have to GPL my brain when
>> I read the book.
>> 
>> I add some margin notes to the GPLed book. I still do not have to GPL
>> my brain when I read the book.
> 
> This is possibly the worst comparison I've read in a long long time...
> 
> It's rather a case of:
> 
> Consider a book.  The book is GPLed.  You take add one chapter to the
> book.  The resulting book needs to be GPLed.

I am with you this far.

> Now, instead of adding to that book, you "export" parts of the book by
> copying them into your book.  Your new book wouldn't work without the
> copied parts.  Your resulting book needs to be GPLed.

Nothing is exported except to the reader's brain aka user space. It
is not exported to a new book.

Exporting a new interface is equivalent to making the marginal notes.

You can still READ the book without GPLing your brain or your
application. You can make additional temporary marginal notes,
place data into the kernel which causes the kernel to disgorge
some data.

> Your "read the book"-case is only comparable to the case of building
> a userspace binary for local use that only uses existing interfaces,
> vs building one that uses exported private interfaces.  In both cases,
> since you're not distributing your modified version, you're free to
> do whatever you like.

Either you cannot have a non-GPL program on the kernel OR you can. It
makes no difference if the kernel is modified (the modification is GPL)
or the kernel is not modified. The modified kernel must be distributed
as source if requested. The application does not unless EVERY application
must be distributed with source.

There is apparently no argument with regards to applications that are
not GPL running on LINUX. Therefore there should be no argument with
an application that uses a newly exported API being GPLed.

If you are considering the potential case that the modification is made
to the kernel and then the source for that modification is also used in
user space in an application requiring the application to be GPLed then
you must first prove it was done in that order rather than the other order.
Code can also be released dual licensed. GPL for the kernel and private
for the user space, if it is done so by the owner or creator of the code
in question. Anything else is absurd on its face.

{^_^}   Joanne Dow



From: Arjan van de Ven [email blocked]
Subject: Re: GPL issues
Date:	Wed, 12 Apr 2006 16:51:32 +0200

On Tue, 2006-04-11 at 22:45 -0700, jdow wrote:
> > On Tue, 2006-04-11 at 23:18 -0400, Mark Lord wrote:
> >> Joshua Hudson wrote:
> >> > On 4/11/06, David Weinehall [email blocked] wrote:
> >> >> OK, simplified rules; if you follow them you should generally be OK:
> >> ..
> >> >> 3. Userspace code that uses interfaces that was not exposed to userspace
> >> >> before you change the kernel --> GPL (but don't do it; there's almost
> >> >> always a reason why an interface is not exported to userspace)
> >> >>
> >> >> 4. Userspace code that only uses existing interfaces --> choose
> >> >> license yourself (but of course, GPL would be nice...)
> >> 
> >> Err.. there is ZERO difference between situations 3 and 4.
> >> Userspace code can be any license one wants, regardless of where
> >> or when or how the syscalls are added to the kernel.
> > 
> > that is not so clear if the syscalls were added exclusively for this
> > application by the authors of the application....
> 
> Consider a book. The book is GPLed. I do not have to GPL my brain when
> I read the book.
> 
> I add some margin notes to the GPLed book. I still do not have to GPL
> my brain when I read the book.

wrong comparison

you have a book, book is gpl'd. You have another book with another plot.
THat other book doesn't need to be gpl'd.

you have a book, book is gpl'd. Your other book now requires the first
book to change it's plot so that the two books form a series. This is
where your lawyer will get nervous.

Think of it differently perhaps, and it's a question of "where is the
boundary of the work"

You can see the situation with the syscall change in 2 ways:

1) kernel + modification is a work
   userspace app is a separate work

or

2) kernel is a work
   userspace app and the kernel modification are together one work

in this 2nd case you have a GPL issue. The question is if your lawyer
can convince the judge that the second interpretation is unreasonable.
That may or may not be easy, depending on the exact nature of the
modification.


From: Kyle Moffett [email blocked]
Subject: Re: GPL issues
Date:	Tue, 11 Apr 2006 09:49:39 -0400

On Apr 11, 2006, at 02:31:27, Ramakanth Gunuganti wrote:
> I am trying to understand the GPL boundaries for Linux, any  
> clarification provided on the following issues below would be great:
> [...]
> Anyone trying to build a new application to work on Linux must have  
> these issues clarified, if you can share your experiences that  
> would be great too.

If you're planning to make money off of any code developed based in  
part off of the Linux Kernel, you should definitely contact a lawyer  
familiar with the linux kernel and ask them.  Any advice you get from  
this list should probably come prefixed with "IANAL", and as such  
isn't worth terribly much.

Cheers,
Kyle Moffett



From: Ramakanth Gunuganti [email blocked]
Subject: Re: GPL issues
Date:	Tue, 11 Apr 2006 08:49:44 -0700 (PDT)


Thanks for the replies, talking to a lawyer seems to
be too stringent a requirement to even evaluate Linux.
Who would be the ultimate authority to give definitive
answers to these questions? 

Since it's the Linux kernel that's under GPLv2, any
work done here should be released under GPLv2. That
part seems to be clear, however any product would
include other things that could be proprietary. If
Linux kernel is made part of this proprietary package,
how does the distribution work. Can we just claim that
part of the package is under GPL and only release the
source code for the kernel portions. 

-Ram



From: "Dave Neuer" <mr.fred.smoothie@pobox.com>
Subject: Re: GPL issues
Date:	Tue, 11 Apr 2006 12:23:36 -0400

On 4/11/06, Ramakanth Gunuganti [email blocked] wrote:
>
> Thanks for the replies, talking to a lawyer seems to
> be too stringent a requirement to even evaluate Linux.
> Who would be the ultimate authority to give definitive
> answers to these questions?

A lawyer. The questions you are asking are inherently legal ones, and
any answer you get on this mailing list (which is a technical list,
not a legal one) is not going to be the *real* answer. The "ultimate
authority" you're asking for here is the court system, so if you're
concerned about legal liability for copyright infringement due to a
product you plan to distribute, you need to hire a lawyer.

Dave

• Archive of above thread
• KernelTrap interview with Alan Cox
• KernelTrap interview with David Weinehall