Re: Simple header cleanups

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 27 Apr 2006 04:00:30 BST, David Woodhouse wrote:
> On Wed, 2006-04-26 at 19:27 -0700, Gerrit Huizenga wrote:
> > Plus, do we really want Apache or other licensed software directly
> > including GPL header files?  Oh what a tangled web we weave when we
> > suck GPL headers into other applications. 
> 
> libstdc++ is GPL too. Why's that not a problem? Because it has an
> exception explicitly allowing you to use it _without_ becoming covered
> by the GPL, in certain circumstances. A bit like this one:
> 
>    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".
 
 This is not in conflict with the GPL in any way - just a clarification
 of the address boundary between running applications and the kernel
 address space.  In other words, if running any application on a GPL
 kernel virally infected those applications, very few people would ever
 use a GPL'd kernel.  Same is true with a GPL application - it clearly
 could not infect the kernel it was running on.  I believe this is
 nothing but a clarification of an interpretation of the GPL as it
 stands today (well, GPL and copyright law).

 This does not say that you can #include files from any source, including
 the kernel, which are released/licensed under the GPL.  The GPL
 specifically locks out any changes to the GPL so even if you wanted
 to provide an exception.  Keep in mind that this is inclusion into
 a source from which you build a binary and then redistribute that
 binary, such as in an rpm.  That is different from the libstdc++
 exception below, which is a *runtime* exception, not a compile time
 exception.

> Of course, the libstdc++ exception was written a bit more carefully than
> ours, but ours seems to be perfectly sufficient.
> 
> http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/license.html

 The little suggestion of speaking to a lawyer (since I am not one,
 have never played one on TV, and would never admit to speaking to
 one) is a good suggestion.  However, note that you can build a
 free software *library* with this code because of this exception
 (which is purportedly replicated in every related header file)
 but this does not mean that you could include those files directly
 in an application.  Also, this is not the exception that is currently
 associated with the kernel header files so I'm not sure that I
 see a way to retroactively apply it.

 I think the technically correct "legal" approach is to create a
 set of header files which contain only user level APIs, release those
 under the LGPL as part of the kernel tree (I don't know if they need
 to be dual licensed LGPL/GPL but I think not) and maintain them as
 though they are the published, official API to the kernel.  Typically,
 structure definition, trival #define's and the like are not usually
 viewed as something that can be copyrighted (my believe, confirm with
 someone who actually knows something about copyright law).  Those
 new header files are not subject to copyright at least and I'm
 not sure that they would necessarily count as a "derived" work.

 This stuff is ugly.

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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux