Re: Input on the Non-GPL Modules

Re: Input on the Non-GPL Modules

[Mike Borrelli]

On Thu, Oct 18, 2001 at 05:08:13PM +0000, Tony Hoyle wrote:
> This is still a GPL violation, as the small module couldn't then be
> linked with the proprietary module.  Most companies aren't prepared to
> get into the legally murky ground that that sort of thing entails.

Where (in the conceptual layering of the kernel) does the code cease to be
a derived work and become a "normal use" as allowed in the clase added by
Linus:

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

Cheers,
-Mike

Re: Input on the Non-GPL Modules

[Matti Aarnio]

On Thu, Oct 18, 2001 at 11:52:36AM -0700, Mike Borrelli wrote:
> Where (in the conceptual layering of the kernel) does the code cease to be
> a derived work and become a "normal use" as allowed in the clase added by
> Linus:
> 
>   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".

  "XFree86 server" is "normal use", as is XFree86 loadable device driver,
  but kernel DRI driver module is not.

> Cheers,
> -Mike

/Matti Aarnio

Re: Input on the Non-GPL Modules

[Alan Cox]

> And even if yes, one could just implement the "shim GPL piece" as a server 
> with an exported binary access interface (use of a CORBA implementation 
> springs to mind for example) and the non-GPL code then functions as a 
> client to the server. Nobody can say that that is not legal. Otherwise you 
> would have to demand that all network clients accessing Linux servers 
> become open source which could never be upheld...

It would depend on the derivative nature of the work. "Linking" is not a 
programming thing here. The objective C case was two seperate binaries for
example

Re: Input on the Non-GPL Modules

[Craig Milo Rogers]

>> What prevents the author of a non-GPL module who needs access to a
>> GPL-only symbol from writing a small GPLed module which imports the 
>> GPL-only symbol (this is allowed, because the small module is GPL), 
>> and exports a basically identical symbol without the GPL-only
>> restriction?
>
>The fact that it ends up GPL'd to be linked (legal derivative work sense)
>to the GPL'd code so you can link it to either but not both at the same time

	The fact is that the GPL (version 2, June 1991) does not
constrain linking so long as the linked work is not copied or
distributed (section 2).  The fact is that "The act of running the
Program is not restricted" (section 0).  Other than that, we run out
of "facts", because the whole area is untested legally, and the courts
have a fair amount of latitude.

	I believe that the following statement is true: The GPL
permits linking GPL'ed code with not-GPL-comformant code so long as
the resultant derived work is not distributed.

	I believe that the "user-does-the-link" strategy is consonent
with the text of the GPL version 2, although it might not have been
intended by the document's author(s).  I believe that individual
symbol names are not covered by copyright (although they could be
trademarked).  In my opinion (I am not a lawyer, etc.), there is no
compelling reason (other than being nice people) for non-GPL-compliant
module writers to not link against a list of "GPL-only" symbols.

	Furthermore, I suspect that using a GPL-only symbol strategy
to *restrict* runtime linking is itself PROHIBITED by GPL version 2
section 6 (the notorious "You may not impose any further restrictions
on the recipients" clause).

	Having said my piece, I refuse discuss this topic in the
immediate future on linux-kernel.  I'll be happy to converse offline
via email.

					Craig Milo Rogers
					<rogers@isi.edu>

Re: Input on the Non-GPL Modules

[Anton Altaparmakov]

At 23:08 20/10/2001, Ben Greear wrote:
>Alan Cox wrote:
> >
> > > What prevents the author of a non-GPL module who needs access to a
> > > GPL-only symbol from writing a small GPLed module which imports the
> > > GPL-only symbol (this is allowed, because the small module is GPL),
> > > and exports a basically identical symbol without the GPL-only
> > > restriction?
> >
> > The fact that it ends up GPL'd to be linked (legal derivative work sense)
> > to the GPL'd code so you can link it to either but not both at the same 
> time
>
>If you own the copyright to the small shim GPL piece, can anyone else
>take legal action on your part?  If not, then all you have to do is not
>sue yourself for the double linkage and no one else can sue you either....

And even if yes, one could just implement the "shim GPL piece" as a server 
with an exported binary access interface (use of a CORBA implementation 
springs to mind for example) and the non-GPL code then functions as a 
client to the server. Nobody can say that that is not legal. Otherwise you 
would have to demand that all network clients accessing Linux servers 
become open source which could never be upheld...

Lets face it. (Wo)Man is intelligent enough to be able design at least one 
circumvention technique for every prevention technique one can think of, 
all one can do is make it awkward to circumvent but trying to prevent 
circumvention at all costs is an exercise in futility IMHO.

Just my 2p. sorry for jumping into the middle of a discussion...

Anton


-- 
   "Nothing succeeds like success." - Alexandre Dumas
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

Re: Input on the Non-GPL Modules

[Ben Greear]

Alan Cox wrote:
> 
> > What prevents the author of a non-GPL module who needs access to a
> > GPL-only symbol from writing a small GPLed module which imports the
> > GPL-only symbol (this is allowed, because the small module is GPL),
> > and exports a basically identical symbol without the GPL-only
> > restriction?
> 
> The fact that it ends up GPL'd to be linked (legal derivative work sense)
> to the GPL'd code so you can link it to either but not both at the same time

If you own the copyright to the small shim GPL piece, can anyone else
take legal action on your part?  If not, then all you have to do is not
sue yourself for the double linkage and no one else can sue you either....

Ben

-- 
Ben Greear <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: Input on the Non-GPL Modules

[Alan Cox]

> What prevents the author of a non-GPL module who needs access to a
> GPL-only symbol from writing a small GPLed module which imports the 
> GPL-only symbol (this is allowed, because the small module is GPL), 
> and exports a basically identical symbol without the GPL-only
> restriction?

The fact that it ends up GPL'd to be linked (legal derivative work sense)
to the GPL'd code so you can link it to either but not both at the same time

Re: Input on the Non-GPL Modules

[Rik van Riel]

On Thu, 18 Oct 2001, Jan Niehusmann wrote:
> On Thu, Oct 18, 2001 at 11:29:57AM -0400, Greg Boyce wrote:
> > However, with the addition of GPL only symbols, you add motivation for
> > conning.  Not by end users, but by the developers of binary only
> > modules.  If they export the GPL license symbol, they gain access to
> > kernel symbols that they may want to use.  Since no code is actually being
> > stolen, would this kind of trick actually cause a licensing violation?
>
> What about a different way of circumventing the GPL only symbols?

> Then he could use this new symbol from his non-GPL module.

And he'd lose his rights to use Linux by violating the license
he acquired Linux under.

regards,

Rik
-- 
DMCA, SSSCA, W3C?  Who cares?  http://thefreeworld.net/  (volunteers needed)

http://www.surriel.com/		http://distro.conectiva.com/

Re: Input on the Non-GPL Modules

[Tim Bird]

Jan Niehusmann wrote:
> 
> On Thu, Oct 18, 2001 at 05:08:13PM +0000, Tony Hoyle wrote:
> > This is still a GPL violation, as the small module couldn't then be
> > linked with the proprietary module.  Most companies aren't prepared to
> > get into the legally murky ground that that sort of thing entails.
> 
> Why not? It is obviously allowed to write proprietary modules, as long
> as they dont use GPL-only interfaces.

This is not true from both the standpoint of what Linus has
said and what copyright law says.

Linus made an exception for proprietary modules, but also
made an exception to the exception in the case of modules
providing "essential" functionality.  I don't have his
exact wording, but it was something to the effect that
using dynamic loading purely as a dodge on the GPL was not
kosher.

My belief is that proprietary modules are "allowed" (tolerated
might be a better word), when they meet several criteria
(including but not limited to):
	- another module of the same type is proprietary, and:
		- it is included in kernel.org source, or
		- there is a long-standing precedence for
		proprietary modules of this kind
	- no portion of the kernel which is statically linked
	relies on the loadable module.
	- the module does NOT provide an essential facility
	of the OS (such as sheduling, baseline memory management,
	etc.)

Unfortunately, all of this is fairly nebulous and subjective.

On the second point, copyright law doesn't make the same types
of distinctions on derivative works that programmers appear
prone to make (eg. does it link statically or dynamically?).
Dynamic linking matters a whole lot less for copyright law
than other factors, like whether there are multiple
implementations of the interface available or what the
purpose of the interface is.

Finally, I am NOT a laywer and I'm not Linus.  Take what I
say on this list with a grain of salt.
____________________________________________________________
Tim Bird                                  Lineo, Inc.
Senior VP, Research                       390 South 400 West
tbird@lineo.com                           Lindon, UT 84042

Re: Input on the Non-GPL Modules

[Borrelli, Michael J]

On Thu, Oct 18, 2001 at 05:08:13PM +0000, Tony Hoyle wrote: 
> This is still a GPL violation, as the small module couldn't then be 
> linked with the proprietary module. Most companies aren't prepared to 
> get into the legally murky ground that that sort of thing entails.

Where, in the conceptual layers of the kernel, does a peice of code cease to
be a derived work which must also be GPL'ed and become a "normal use" of the
kernel as is allowed by Linus's clause:

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

Cheers,
Mike

Re: Input on the Non-GPL Modules

[Jan Niehusmann]

On Thu, Oct 18, 2001 at 05:08:13PM +0000, Tony Hoyle wrote:
> This is still a GPL violation, as the small module couldn't then be
> linked with the proprietary module.  Most companies aren't prepared to
> get into the legally murky ground that that sort of thing entails.

Why not? It is obviously allowed to write proprietary modules, as long
as they dont use GPL-only interfaces. 

Jan

Re: Input on the Non-GPL Modules

[Tony Hoyle]

On Thu, 18 Oct 2001 16:36:58 +0000 (UTC), Jan Niehusmann
<jan@gondor.com> wrote:


>What prevents the author of a non-GPL module who needs access to a
>GPL-only symbol from writing a small GPLed module which imports the 
>GPL-only symbol (this is allowed, because the small module is GPL), 
>and exports a basically identical symbol without the GPL-only
>restriction?
>
>Then he could use this new symbol from his non-GPL module.

This is still a GPL violation, as the small module couldn't then be
linked with the proprietary module.  Most companies aren't prepared to
get into the legally murky ground that that sort of thing entails.

Tony

Re: Input on the Non-GPL Modules

[Jan Niehusmann]

On Thu, Oct 18, 2001 at 11:29:57AM -0400, Greg Boyce wrote:
> However, with the addition of GPL only symbols, you add motivation for
> conning.  Not by end users, but by the developers of binary only
> modules.  If they export the GPL license symbol, they gain access to
> kernel symbols that they may want to use.  Since no code is actually being
> stolen, would this kind of trick actually cause a licensing violation?

What about a different way of circumventing the GPL only symbols?

What prevents the author of a non-GPL module who needs access to a
GPL-only symbol from writing a small GPLed module which imports the 
GPL-only symbol (this is allowed, because the small module is GPL), 
and exports a basically identical symbol without the GPL-only
restriction?

Then he could use this new symbol from his non-GPL module.

Jan

Re: Input on the Non-GPL Modules

[M. R. Brown]

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

* Greg Boyce <gboyce@rakis.net> on Thu, Oct 18, 2001:

> 
> However, with the addition of GPL only symbols, you add motivation for
> conning.  Not by end users, but by the developers of binary only
> modules.  If they export the GPL license symbol, they gain access to
> kernel symbols that they may want to use.  Since no code is actually being
> stolen, would this kind of trick actually cause a licensing violation?
> 

Yeah, but the GPL requires availability of source, so I don't see how they
could get around that (it would no longer be a closed-source module and might
as well be GPL'd).

Hmm, does MODULE_LICENSE() actually state that the module is covered under
the GPL?  If not, could something like this work?

--- module.h.orig	Thu Oct 18 10:56:09 2001
+++ module.h	Thu Oct 18 10:58:43 2001
@@ -286,7 +286,11 @@
  
 #define MODULE_LICENSE(license) 	\
 static const char __module_license[] __attribute__((section(".modinfo"))) =   \
-"license=" license
+"license=" license; \
+static const char __module_license_blurb[] __attribute__((section(".modinfo"))) = \
+"license_blurb=This module is covered under the GPL v2 or any later version. " \
+"Please see the file COPYING in the toplevel directory of the source archive " \
+"of this module."
 
 /* Define the module variable, and usage macros.  */
 extern struct module __this_module;


Of course this can still be circumvented by removing that string from
include/linux/module.h, but you'd still be able to identify renegade
modules, since they perpetrate as GPL'd modules.

M. R.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Input on the Non-GPL Modules

[Greg Boyce]

Hello,

I've been following the various mail threads regarding the non-GPL
compatable modules, and I had a bit of feedback on the situation.

Last week someone brought up the the notion that if the kernel was marked
as tainted due to proprietary modules being loaded, that people would just
end up modifying the bug report to remove the tainted mark.  

Alan had responded with:
"Well for the moment Im working on the basis that the problem isnt people
trying to con anyone, its people who don't know better - and thats backed
up by my bug queue."

I agree with this fully.  Most people that would be filing bug reports
fall under one of two catagories.  People who don't realize what the
tainted mark means, or people who realize that the kernel developers won't
be able to help them with the proprietary module loaded.  Therefore there
is no motivation for someone to attempt a con.

However, with the addition of GPL only symbols, you add motivation for
conning.  Not by end users, but by the developers of binary only
modules.  If they export the GPL license symbol, they gain access to
kernel symbols that they may want to use.  Since no code is actually being
stolen, would this kind of trick actually cause a licensing violation?

All in all, I find people to be generally honest.  I don't always have
that sort of trust in corporations though.  Just something to think about.

--

Gregory Boyce