GPL issues

GPL issues

[Ramakanth Gunuganti]

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


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: GPL issues

[Jesper Juhl]

On 4/11/06, Ramakanth Gunuganti <rgunugan@yahoo.com> wrote:
> 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:
>

Note: The answers to the questions below are based on my own personal
understanding of the GPL and the policies of the Linux kernel.
Also contacting a lawyer would probably not be a bad idea.


> (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?

No. Applications that merely use the services the kernel provides need
not be 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?
>
Again, a userspace application that merely use kernel services need not be 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).
>
If the application is to be included in the mainline kernel tarball
and distributed from kernel.org, then I would say it would need to be
GPL.
If it's a tarball you provide with a modified kernel with all kernel
modifications released under GPL, then a userspace application bundled
in the tarball would not nessesarily need to be 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?
>
Not in the mainline kernel.


> 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?
>
No idea.

> 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
>


--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: GPL issues

[Martin Mares]

Hello!

> > 1. If an application is built on top of this modified
> > kernel, should the application be released under GPL?
> 
> No. Applications that merely use the services the kernel provides need
> not be GPL.

However, this doesn't necessarily apply to cases where the kernel
modifications just export internal kernel stuff to userspace. In such
cases, the userspace application is very likely to be a derived work
of the kernel, so GPL applies there as well.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"I don't give a damn for a man that can only spell a word one way." -- M. Twain

Re: GPL issues

[Kyle Moffett]

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

Re: GPL issues

[Ramakanth Gunuganti]

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

--- Kyle Moffett <mrmacman_g4@mac.com> wrote:

> 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
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: GPL issues

[Ramakanth Gunuganti]

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

--- Kyle Moffett <mrmacman_g4@mac.com> wrote:

> 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
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: GPL issues

[linux-os (Dick Johnson)]

On Tue, 11 Apr 2006, Ramakanth Gunuganti 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?
>
> 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.
>
[See bottom. Please do not top-post.]

> -Ram
>
> --- Kyle Moffett <mrmacman_g4@mac.com> wrote:
>
>> 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
>>
>>
>

Nobody can produce a definitive answer because nobody knows
what you are doing. You could be making a module that exposes
the entire contents of the kernel to user-space, then writing
user-space programs that manipulate the kernel. Such user-space
programs are then <probably> derived works and would need a GPL
License.

On the other hand, you could be making a Hexagrid-confuser(tm)
that runs a Pyrosynchrogem(tm), both proprietary items your
company manufactures for the Red Sox. You need to make a kernel
driver to interface with it, plus a whole bunch of proprietary
user-mode software to help the Red Sox win another world series.
In this case, only the driver needs to be GPL as long as it
doesn't extend or modify the established Unix/Linux API. BUT,
you imply that you need to modify the kernel in addition to
writing a driver. This means that you are extending the API,
which just __might__ require that any code that interfaces
with that extension be GPL as well. That's why you __need__
a lawyer if you are going to change the kernel to run your code.

Easiest way out is to make a conventional driver to interface
with your device. Then write proprietary code that interfaces
with it. Do not make any kernel changes, and do publish your
driver under a GPL license.

For non-US readers, the Red Sox are a baseball team.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.15.4 on an i686 machine (5589.42 BogoMips).
Warning : 98.36% of all statistics are fiction, book release in April.
_
\x1a\x04

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: GPL issues

[Adrian Bunk]

On Tue, Apr 11, 2006 at 08:49:44AM -0700, Ramakanth Gunuganti 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? 

There is none:

The kernel has _many_ people holding a copyright on part of the kernel, 
and there's no ultimate authority except for the COPYING file shipped 
with the kernel sources.

The GPL is just a licence, and if you distribute your product to N 
countries, this means you can potentially be sued in N countries based 
on N different copyright laws.

There are things that are clear. E.g. if you'd have read the COPYING 
file shipped with the kernel sources, you could have answered at least 
one of your questions yourself.

But the exact borders of what is a "derived work" work and what is not 
are not well-defined and therefore unknown unless there have been court 
cases in all N countries you are distributing your product to.

Many things have never been challenged in court, and might never be, but 
remember that e.g. Harald Welte recently has much success with enforcing 
the GPL in cases of obvious violations at for products shipped in 
Germany at German courts.

> 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. 

I am not a lawyer, but the distribution alone shouldn't be a problem - 
that is similar to what most Linux distributions are doing.

> -Ram

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: GPL issues

[Kyle Moffett]

On Apr 11, 2006, at 11:49:44, Ramakanth Gunuganti 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?

Once again, as I said before, a lawyer.  There are currently very few  
GPL-related precedents, and none on that particular topic.  The best  
place to get advice is a lawyer.   Think of it as though you were  
licensing some code from another proprietary company for inclusion in  
your product; there you would _definitely_ talk to a lawyer.  The  
"ultimate authority" is your local/regional/national courts, a local  
lawyer is best able to use your particular set of laws to interpret  
what your courts are likely to decide and advise you accordingly.   
Nobody on this list can give you that kind of legal advice, at least  
not for free.

> Since it's the Linux kernel that's under GPLv2, any work done here  
> should be released under GPLv2.

Any "Derivative Work" of the Linux kernel must be licensed under the  
GPL.  The definition of "Derivative Work" is hard to resolve in  
detail.  Most kernel developers (including Linus himself) believe  
that all kernel modules are derivative works due to the unique and  
variable nature of the in-kernel APIs.  It is almost always held that  
userspace-only programs are _not_ derivative works.  On the other  
hand, if you export some kernel-internal API directly to userspace  
through a syscall, any program that uses it might be considered a  
derivative work.

> Can we just claim that part of the package is under GPL and only  
> release the source code for the kernel portions.

It really depends, which is why I suggest you contact a lawyer versed  
in this field.  Virtually none of the people on this list can give  
you any definitive answers, especially without access to the product  
itself, and even then they would most likely just tell you of their  
personal opinion which has no legal weight whatsoever.

Cheers,
Kyle Moffett

Re: GPL issues

[Dave Neuer]

On 4/11/06, Ramakanth Gunuganti <rgunugan@yahoo.com> 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

Re: GPL issues

[Stefan Smietanowski]

[-- Attachment #1: Type: text/plain, Size: 3277 bytes --]

linux-os (Dick Johnson) wrote:
> On Tue, 11 Apr 2006, Ramakanth Gunuganti 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?
>>
>>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.
>>
> 
> [See bottom. Please do not top-post.]
> 
> 
>>-Ram
>>
>>--- Kyle Moffett <mrmacman_g4@mac.com> wrote:
>>
>>
>>>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
>>>
>>>
>>
> 
> Nobody can produce a definitive answer because nobody knows
> what you are doing. You could be making a module that exposes
> the entire contents of the kernel to user-space, then writing
> user-space programs that manipulate the kernel. Such user-space
> programs are then <probably> derived works and would need a GPL
> License.
> 
> On the other hand, you could be making a Hexagrid-confuser(tm)
> that runs a Pyrosynchrogem(tm), both proprietary items your
> company manufactures for the Red Sox. You need to make a kernel
> driver to interface with it, plus a whole bunch of proprietary
> user-mode software to help the Red Sox win another world series.
> In this case, only the driver needs to be GPL as long as it
> doesn't extend or modify the established Unix/Linux API. BUT,
> you imply that you need to modify the kernel in addition to
> writing a driver. This means that you are extending the API,
> which just __might__ require that any code that interfaces
> with that extension be GPL as well. That's why you __need__
> a lawyer if you are going to change the kernel to run your code.
> 
> Easiest way out is to make a conventional driver to interface
> with your device. Then write proprietary code that interfaces
> with it. Do not make any kernel changes, and do publish your
> driver under a GPL license.

Might be worth mentioning that if you intend to write a driver
that interfaces with any kernel under any license (bar any
kernel that you write yourself), be it Windows, Linux, *BSD,
etc you SHOULD talk to a lawyer as every license has it's
quirks and gotchas.

This is NOT specific to the GPL or the Linux kernel.

// Stefan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

Re: GPL issues

[Horst von Brand]

Jesper Juhl <jesper.juhl@gmail.com> wrote:
> On 4/11/06, Ramakanth Gunuganti <rgunugan@yahoo.com> wrote:
> > 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:

> Note: The answers to the questions below are based on my own personal
> understanding of the GPL and the policies of the Linux kernel.

IANAL either.

> Also contacting a lawyer would probably not be a bad idea.

Essential, not just a good idea. Just pick one who /does/ have a grasp of
GPL and like issues.

> > (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?
> 
> No. Applications that merely use the services the kernel provides need
> not be GPL.

But AFAIU there is a fine line here... at least /in spirit/, adding system
calls and IOCTLs and... just for the particular use of a particular closed
source application is definitely wrong. It might be legally OK (I don't
know; the opinion here is divided on that kind of matter, see f.ex. the
regularly scheduled flamefest about binary modules), but morally it is at
least suspicious.

> > 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?

> Again, a userspace application that merely use kernel services need not
> be GPL.

As long as it uses the standard system calls. Adding special system calls
might (should?) change that...
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: GPL issues

[Jan Engelhardt]

>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.

One thing that is clear in the GPL: If you link the kernel with something 
else to an executable, the resulting blob (and therefore the sources to the 
proprietary part) must be GPL.

Linking by making certain parts shared libraries is already a gray zone.

If in doubt, release everything. It also offers users the possibility to 
find your bugs.


Jan Engelhardt
-- 

Re: GPL issues

[David Weinehall]

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 <tao@acc.umu.se> /) Northern lights wander      (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/    (/   Full colour fire           (/

Re: GPL issues

[Alan Cox]

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.

Re: GPL issues

[Joshua Hudson]

On 4/11/06, David Weinehall <tao@acc.umu.se> wrote:
> 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...
Excellent summary except for one case. Propriatary binary allowed in initramfs?
Not that I care.

Re: GPL issues

[Mark Lord]

Joshua Hudson wrote:
> On 4/11/06, David Weinehall <tao@acc.umu.se> 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

Re: GPL issues

[Kyle Moffett]

On Apr 11, 2006, at 23:18:04, Mark Lord wrote:
> Joshua Hudson wrote:
>> On 4/11/06, David Weinehall <tao@acc.umu.se> 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.

Not necessarily, there may be grey area.  The new splice() syscall,  
for example; does any other software have a syscall that even  
remotely resembles it?  Could a piece of software that uses the splice 
() syscall be said to stand on its own as a separate work?  Those are  
the questions you should be asking.  For that particular case, the  
answers are probably yes; _especially_ if the program in question has  
an abstraction library for file IO.  Now let's discuss a binary  
program specifically designed to read and write several sysfs files.   
Does any other operating system have anything like sysfs?  Could that  
program be said to stand on its own?  Would it work without  
linux-2.6?  It doesn't even work on linux-2.4!  Would that be  
considered a "derivative work"??  I don't know the answers to these  
questions, and I suspect it would depend a _lot_ on what the software  
did with those interfaces, how it used the functionality, etc.

A program that doesn't use more than standard SysV/UNIX/POSIX/ANSI/ 
etc functionality, or provides an abstraction layer so that it works  
on more than just Linux is definitely OK.  It stands distinct from  
the kernel; does not strictly depend on a particular version of a  
particular operating system.  A module that links directly into the  
kernel and messes with its internals is most certainly NOT ok.  The  
grey area in between is exceptionally unclear.  I don't think we can  
state for certain until a legal case comes up in the courts, but  
let's just hope it never comes to that.

Cheers,
Kyle Moffett

Re: GPL issues

[Arjan van de Ven]

On Tue, 2006-04-11 at 23:18 -0400, Mark Lord wrote:
> Joshua Hudson wrote:
> > On 4/11/06, David Weinehall <tao@acc.umu.se> 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....

Re: GPL issues

[jdow]

> On Tue, 2006-04-11 at 23:18 -0400, Mark Lord wrote:
>> Joshua Hudson wrote:
>> > On 4/11/06, David Weinehall <tao@acc.umu.se> 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

Re: GPL issues

[David Weinehall]

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 <tao@acc.umu.se> 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 <tao@acc.umu.se> /) Northern lights wander      (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/    (/   Full colour fire           (/

Re: GPL issues

[jdow]

From: "David Weinehall" <tao@acc.umu.se>
> 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 <tao@acc.umu.se> 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

Re: GPL issues

[Pramod Srinivasan]

> 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

Re: GPL issues

[David Weinehall]

On Wed, Apr 12, 2006 at 12:01:02AM -0700, Pramod Srinivasan wrote:
> > 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?

As I said above, you need to consult a lawyer in unclear cases.
The examples you list above seems innocent enough, but again, I am not a
lawyer.  A lot has to do with intent.  Are you exporting things to
userland just to workaround the GPL?  If so, you're likely violating
the GPL... =)


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

Re: GPL issues

[Jan Engelhardt]

<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
-- 

Re: GPL issues

[Stefan Smietanowski]

[-- Attachment #1: Type: text/plain, Size: 2811 bytes --]

David Weinehall wrote:
> 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 <tao@acc.umu.se> 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

IANAL But I don't think that makes any difference at all.

The INTERACTION between syscalls and userspace is not a topic for
discussion really. Otherwise we'd have to put the boundary at
"syscalls that the Linux Gurus added" vs "syscalls someone else added
cause they thought they were neat".

NONE of the ones in the "neat" category are ever to be used ever by
ANY non-GPL program.

That is what it boils down to. I add a syscall to the kernel, you don't
like it? Tough, it's GPL so I can distribute it, etc etc.

A program emerges that uses that syscall? You don't like that ?
Equally tough. It doesn't matter if I wrote both parts or just one,
we're not looking at INTENT here. Either programs can be non-GPL
or they can't.

Btw, no I'm not jumping at anyone here, I am just trying to show
a point.

// Stefan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

Re: GPL issues

[Stefan Smietanowski]

[-- Attachment #1: Type: text/plain, Size: 999 bytes --]

Jan Engelhardt wrote:
> <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.

So in order for you not to shudder the vrf people have to write a GPL'd
program or convince someone else to write one?

That sounds .. really odd.

Or more to the point, someone ONLY writes kernelmode stuff, doesn't
touch userspace at all. A proprietary app shows up that uses it,
and all of a sudden this guy's kernelmode whatever is disliked
cause noone wrote any GPL'd program for it?

That's almost forcing the person who wrote the kernel part to write
a GPL'd program JUST because there is a proprietary program using
his stuff - and THAT is insane.

// Stefan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

Re: GPL issues

[Alan Cox]

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...

Re: GPL issues

[Martin Mares]

Hello!

> That's almost forcing the person who wrote the kernel part to write
> a GPL'd program JUST because there is a proprietary program using
> his stuff - and THAT is insane.

If the kernel part does something, which can work _separately_, i.e.,
do something useful without the proprietary program, then it's very
likely OK. Otherwise, the proprietery program cannot be considered
a work separate from the kernel part.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
If Bill Gates had a nickel for every time Windows crashed... ..oh wait, he does.

Re: GPL issues

[Olivier Galibert]

On Wed, Apr 12, 2006 at 11:13:17AM +0200, Stefan Smietanowski wrote:
> A program emerges that uses that syscall? You don't like that ?
> Equally tough. It doesn't matter if I wrote both parts or just one,
> we're not looking at INTENT here. Either programs can be non-GPL
> or they can't.

Intent is clearly taken into account by courts.  And in any case check
the history of the objective C frontend in gcc.

  OG.

Re: GPL issues

[Arjan van de Ven]

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 <tao@acc.umu.se> 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.

Re: GPL issues

[Mark Lord]

/usr/src/linux/COPYING:

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".

Re: GPL issues

[Mark Lord]

Arjan van de Ven wrote:
> On Tue, 2006-04-11 at 23:18 -0400, Mark Lord wrote:
>> Joshua Hudson wrote:
>>> On 4/11/06, David Weinehall <tao@acc.umu.se> 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....

Neither the GPL nor the kernel's COPYING file restricts anyone
from making kernel changes.  In fact, the GPL expressly permits
anyone to modify the kernel.  So how the syscalls get there is
of zero relevance here.

Now, the syscall interface itself appears to be expressly exempted
from any GPL considerations by the kernel's COPYING file:

>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".

Heh.. but the lawyers are not completely out of their hourly fees yet,
since Linus unfortunately included that little undefined "normal" word.

Cheers

RE: GPL issues

[David Schwartz]

> 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?

	Almost definitely not. Here you have two works that provide two distinctly
different functions and communicate across a well-defined boundary. In
theory, the two works could have been developed completely independently, so
one cannot be a derivative work of the other.

	The thing you need to remember is that the API that userspace uses to
communicate with the kernel is itself a work. In this case, it almost
certainly is purely functional and contains no protectable, copyrightable
content. Both the kernel changes and the user-space code take only from the
API. They do not take from each other.

	DS

RE: GPL issues

[David Schwartz]

> One thing that is clear in the GPL: If you link the kernel with something
> else to an executable, the resulting blob (and therefore the
> sources to the
> proprietary part) must be GPL.

	Actually, that is *far* from clear.

	First, the GPL cannot set its own scope. The GPL could say that if you
stored a program in the same room as a GPL program, the program must be GPL.
So *nothing* the GPL says will answer this question -- the question is, can
the GPL attach by linking?

	The contrary argument would be that linking two programs together is an
automated process. There is no creative input in the linking process. So it
does not legally produce a single work, but a mechanical combination of the
two original works.

	The proof that the executable is not a work for copyright purposes is this
simple -- could a person who took two object files out of the box and linked
them together claim copyright in the new derivative work he just produced? I
think the answer would be obvious -- the executable is not a new work, it's
just the two original works combined.

	Note that this does not mean that *designing* a program specifically to
link to another program can't make it a derivative work of the work you
designed it to go with. Just that the linking itself cannot always do so
automatically.

	In any event, to give my answer to the original question -- if a kernel
module and a userspace program are developed together, and are not both
derived from an API that is independent of the Linux kernel, then they are
probably going to be considered a single work.

	On the flip side, you should be okay if you develop an API for a kernel to
communicate with user space and then develop a user space program that could
work on any kernel (Linux or not, theoretically) that supported that API.
This should ensure that the user space program is derivative only from the
API and not from the Linux kernel.

	Note that you will not be okay if the API looks like what just happen to be
Linux kernel internals. The API itself must be independent of the Linux
kernel internals.

	DS

RE: GPL issues

[linux-os (Dick Johnson)]

On Fri, 14 Apr 2006, David Schwartz wrote:

>
>> One thing that is clear in the GPL: If you link the kernel with something
>> else to an executable, the resulting blob (and therefore the
>> sources to the
>> proprietary part) must be GPL.
>
> 	Actually, that is *far* from clear.
>
> 	First, the GPL cannot set its own scope. The GPL could say that if you
> stored a program in the same room as a GPL program, the program must be GPL.
> So *nothing* the GPL says will answer this question -- the question is, can
> the GPL attach by linking?
>
> 	The contrary argument would be that linking two programs together is an
> automated process. There is no creative input in the linking process. So it
> does not legally produce a single work, but a mechanical combination of the
> two original works.
>
> 	The proof that the executable is not a work for copyright purposes is this
> simple -- could a person who took two object files out of the box and linked
> them together claim copyright in the new derivative work he just produced? I
> think the answer would be obvious -- the executable is not a new work, it's
> just the two original works combined.
>
> 	Note that this does not mean that *designing* a program specifically to
> link to another program can't make it a derivative work of the work you
> designed it to go with. Just that the linking itself cannot always do so
> automatically.
>
> 	In any event, to give my answer to the original question -- if a kernel
> module and a userspace program are developed together, and are not both
> derived from an API that is independent of the Linux kernel, then they are
> probably going to be considered a single work.
>
> 	On the flip side, you should be okay if you develop an API for a kernel to
> communicate with user space and then develop a user space program that could
> work on any kernel (Linux or not, theoretically) that supported that API.
> This should ensure that the user space program is derivative only from the
> API and not from the Linux kernel.
>
> 	Note that you will not be okay if the API looks like what just happen to be
> Linux kernel internals. The API itself must be independent of the Linux
> kernel internals.
>
> 	DS
>


Unfortunately copyright law is all about books, papers,
and publishing. It has been adapted to software while,
in fact, it is not relevant to software. That's the
problem.

When attempting to adapt copyright law to software one
needs to "interpret" irrelevant law. This means, that
it means, what a certain judge thinks it means, on a
particular day after hearing some boring arguments.

But there are some things about licensing that are
perfectly clear because they are not about copyright
law at all. Let's say that because I hate Microsoft,
I decide to provide a license to some software that
reads: "This software can be used by anybody, except
Microsoft, for any purpose whatsoever."

Microsoft could use this software because the
license contains an illegal exclusion that
represents "restraint of trade." As much as
you think that excluding a particular company
from using your software is correct and proper,
it is, in fact, illegal in the United states.

It is illegal because the owner of some property
(software) cannot exclude one company from using
that property unless it excludes all companies
from using it.

This is not just about companies. If K-MART was
selling or even giving away some particular item,
they couldn't refuse to give or sell to you the
same item, no matter how badly they hated you.

So, let's say that you wrote a module that allowed
a user-mode program to perform some useful thing
that had never been done before. You are certainly
not going to publish that program or you will
lose your intellectual property and be out of
business.

Some kernel-creeper decides that they will prevent
you from installing your module unless you release
all your source-code under GPL. If you were to take
this to court, you would have two problems:

(1) Who do you sue?
(2) How do you recover damages.

Instead, you make a work-around. You patch the kernel
so your module will work and you ignore the kernel-
creeper. The kernel-creeper is powerless, even in a
suit, because he tried to use illegal restraint of
trade to prevent you from using intellectual property
that belonged to you.

But, the kernel-creeper has lots of money and invective.
He hires the best lawyers in the world, keeps postponing
discovery, gets a temporary restraining order preventing
you from using you own property, then forces you into
bankruptcy.

You lost, even though you were perfectly morally, and
legally correct!

There is a work-around for this, too. Use BSD software.
Many business decisions are all about trade offs. One
of the reasons why Linux has been slow in being accepted
by industry is because some kernel-creeper can cause
a company a lot of damage. This is something to remember
as Linux developers continue to remove essential symbols
from the kernel and continue to re-write build procedures
so that industry-standard methods will no longer work
for building modules.

BSD software might not be so "great", but it works and
we can all use it.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.15.4 on an i686 machine (5589.54 BogoMips).
Warning : 98.36% of all statistics are fiction, book release in April.
_
\x1a\x04

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: GPL issues

[David Weinehall]

On Fri, Apr 14, 2006 at 04:39:59AM -0700, David Schwartz wrote:
> 
> > One thing that is clear in the GPL: If you link the kernel with something
> > else to an executable, the resulting blob (and therefore the
> > sources to the
> > proprietary part) must be GPL.
> 
> 	Actually, that is *far* from clear.
> 
> 	First, the GPL cannot set its own scope. The GPL could say that
> 	if you stored a program in the same room as a GPL program, the
> 	program must be GPL.  So *nothing* the GPL says will answer this
> 	question -- the question is, can the GPL attach by linking?
> 
> 	The contrary argument would be that linking two programs
> 	together is an automated process. There is no creative input in
> 	the linking process. So it does not legally produce a single
> 	work, but a mechanical combination of the two original works.
> 
> 	The proof that the executable is not a work for copyright
> 	purposes is this simple -- could a person who took two object
> 	files out of the box and linked them together claim copyright in
> 	the new derivative work he just produced? I think the answer
> 	would be obvious -- the executable is not a new work, it's just
> 	the two original works combined.

[snip]

Ahhh, but you're missing the whole point of the GPL.  The GPL is
not really a normal license, it's a copyright license.  Basically,
copyright law doesn't allow you to do *anything* with someone elses
work without permission.  The GPL grants you such rights.
However, in exchange for this, you agree to follow the license when
redistributing your software that you built against the GPL:ed
software.

So, in essence, *if* you choose to redistribute your work, you must
abide by the GPL.  And the GPL tells you to GPL your work too, if it
falls within the scope that the GPL defines.  It thus have nothing
to do with whether the programs are a mechanical combination of
two original works or not.  The only point where this comes in is
where the GPL defines its scope.

Thus, if the GPL said that all programs distributed on the same CD
as a GPL:ed program needs to be licensed under the GPL, and you
redistribute your software on that CD, you must license your software
under the GPL, unless you want to be in violation with the license.

Again, I'm not a lawyer...


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

RE: GPL issues

[David Schwartz]

> Ahhh, but you're missing the whole point of the GPL.  The GPL is
> not really a normal license, it's a copyright license.  Basically,
> copyright law doesn't allow you to do *anything* with someone elses
> work without permission.  The GPL grants you such rights.
> However, in exchange for this, you agree to follow the license when
> redistributing your software that you built against the GPL:ed
> software.

	Bluntly, you're just completely wrong. If this were so, I could put up a
billboard with a poem and then sue everyone who read it.

	You should read http://www.copyright.gov/circs/circ1.html

	Notice, for example, that the rights granted under copyright do *not*
include the right to restrict the *use* of a work.

	Far from copyright law starting out with the premise that you can do
nothing with a work, it basically restricts copying or distribution of a
work and the production of works based on that work other than what's
necessary for ordinary use.

	Specifically, copyright does not protect ordinary use. If you buy a CD, you
get the right to use that CD simply by virtue of the fact that you lawfully
possess a lawfully made of the music on that CD.

	DS

Re: GPL issues

[Arjan van de Ven]

On Thu, 2006-04-13 at 18:07 -0400, Mark Lord wrote:
> /usr/src/linux/COPYING:
> 
> 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".

emphasis on "normal"

Re: GPL issues

[Arjan van de Ven]

On Thu, 2006-04-13 at 18:17 -0400, Mark Lord wrote:
> Arjan van de Ven wrote:
> > On Tue, 2006-04-11 at 23:18 -0400, Mark Lord wrote:
> >> Joshua Hudson wrote:
> >>> On 4/11/06, David Weinehall <tao@acc.umu.se> 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....
> 
> Neither the GPL nor the kernel's COPYING file restricts anyone
> from making kernel changes.  In fact, the GPL expressly permits
> anyone to modify the kernel.  So how the syscalls get there is
> of zero relevance here.

it IS relevant is the change that adds them is seen as being part of the
other work. See clause 2 :)

RE: GPL issues

[Alan Cox]

On Gwe, 2006-04-14 at 11:56 -0700, David Schwartz wrote:
> 	Specifically, copyright does not protect ordinary use. If you buy a CD, you
> get the right to use that CD simply by virtue of the fact that you lawfully
> possess a lawfully made of the music on that CD.

The rights you get automatically for "use" depend a lot on the actual
thing itself and also the jurisdiction (local and national) and may even
in some ludicrous cases depend on even the size of the cark park your
building has.

To lawfully use the CD you must also not be violating the DMCA, own any
appropriate patent rights, not be using it for the purpose of committing
a crime, not using it to incite violence and on and on and on, down to
not using it loudly enough to disturb your neighbours excessively.

To "use" it for a public performance also generally falls under
copyright license restrictions (performance rights).

What you say may have been true two hundred years ago but the IPR laws
of the world have been growing ever more tangled and self contradictory
since then, like a badly maintained perl script.

Alan

--
Sick of rip off UK rail fares ? Learn how to get far cheaper fares
                http://zeniv.linux.org.uk/~alan/GTR/

RE: GPL issues

[Steven Rostedt]

On Sat, 2006-04-15 at 12:55 +0100, Alan Cox wrote:
> O
> What you say may have been true two hundred years ago but the IPR laws
> of the world have been growing ever more tangled and self contradictory
> since then, like a badly maintained perl script.
> 

Please don't insult perl by associating it with IPR laws ;-)
(even if it is true)

-- Steve

RE: GPL issues

[David Schwartz]

> On Gwe, 2006-04-14 at 11:56 -0700, David Schwartz wrote:

> > Specifically, copyright does not protect ordinary use. If
> > you buy a CD, you
> > get the right to use that CD simply by virtue of the fact that
> > you lawfully
> > possess a lawfully made of the music on that CD.

> The rights you get automatically for "use" depend a lot on the actual
> thing itself and also the jurisdiction (local and national) and may even
> in some ludicrous cases depend on even the size of the cark park your
> building has.

	There are certainly ludicrous cases, but in most of the cases you cite, the
right to ordinary use is actually superior to the restriction. In other
words, the restriction does not apply if the use is the ordinary intended
use. (Sadly, courts don't always seem to understand this.)

> To lawfully use the CD you must also not be violating the DMCA,

	That the use is the ordinary, intended use of a lawfully-acquired work is
supposed to be a valid DMCA defense. That doesn't mean courts will always
see it that way or agree with you on what the ordinary use is.

> own any
> appropriate patent rights,

	That's true. However, that's kind of like saying you're not entitled to
ordinary use of a bat because you can't beat someone else over the head with
it. The context was restrictions imposed by copyright, not by everything
else in the world.

> not be using it for the purpose of committing
> a crime, not using it to incite violence and on and on and on, down to
> not using it loudly enough to disturb your neighbours excessively.

	Of course, but we were talking about rights to do things against rights
acquired under copyright.

> To "use" it for a public performance also generally falls under
> copyright license restrictions (performance rights).

	It's very hard to know what that means in a software context. I suppose one
could theoretically argue that using Linux to run a web server that's
accessible to the public and intended for public use is a public
performance.

> What you say may have been true two hundred years ago but the IPR laws
> of the world have been growing ever more tangled and self contradictory
> since then, like a badly maintained perl script.

	Fair enough. Your rant makes lots of good points about how absurd and
non-obvious the law can be and I certainly share a lot of the frustration
behind it -- *especially* about the DMCA. However, none of the cases you
mentioned affects the cases we were talking about here in any significant
way.

	DS