Input on the Non-GPL Modules

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

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

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

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

[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

[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

[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

[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 - legal nonsense

[Tim Bird]

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

I keep hearing this type of reasoning.  It flat-out doesn't work
this way in the legal system.  This is similar to arguing that
you didn't really stab someone if you threw the knife instead
of holding it. ("But your honor, once the knife left my hand
it really wasn't under my control...")

If your actions bring about the result, whether
directly or indirectly, you are legally liable for the
consequences.
____________________________________________________________
Tim Bird                                  Lineo, Inc.
Senior VP, Research                       390 South 400 West
tbird@lineo.com                           Lindon, UT 84042

Re: Input on the Non-GPL Modules - legal nonsense

[Ben Greear]

Tim Bird wrote:
> 
> 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....
> 
> I keep hearing this type of reasoning.  It flat-out doesn't work
> this way in the legal system.  This is similar to arguing that
> you didn't really stab someone if you threw the knife instead
> of holding it. ("But your honor, once the knife left my hand
> it really wasn't under my control...")

I'm not advocating this as a good thing to do, but I am curious:  Can someone
else take action against this?  I hope the answer is yes.  This
whole thing begins to look like MS's attempts at securing digital music:
there are just too many ways around it.  Either way,
I've had my say on this topic...and will let it RIP.

Ben

> 
> If your actions bring about the result, whether
> directly or indirectly, you are legally liable for the
> consequences.
> ____________________________________________________________
> Tim Bird                                  Lineo, Inc.
> Senior VP, Research                       390 South 400 West
> tbird@lineo.com                           Lindon, UT 84042
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

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

[Jan Niehusmann]

On Mon, Oct 22, 2001 at 08:30:45AM -0700, Ben Greear wrote:
> I'm not advocating this as a good thing to do, but I am curious:  Can someone
> else take action against this?  I hope the answer is yes.  This
> whole thing begins to look like MS's attempts at securing digital music:
> there are just too many ways around it.  Either way,

Yes, but with a significant difference: 
If somebody breaks MS's stuff, MS will probably try to sue him, but the 
person gets more popular.
If somebody breaks GPL, there may be nobody to sue him, but it can easily
make him a persona non grata in all kinds of free software and open 
source groups. Or, equivalently, if some corporation breaks GPL, this
may cause some very bad PR.

Jan

Re: Input on the Non-GPL Modules - legal nonsense

[David Schwartz]

>I keep hearing this type of reasoning.  It flat-out doesn't work this way in
>the legal system.  This is similar to arguing that you didn't really stab
>someone if you threw the knife instead of holding it. ("But your honor, once
>the knife left my hand it really wasn't under my control...")

	What amazes me is that these legal arguments about the control programmers 
have over their software, are coming from the free software community. If 
Microsoft argued that anybody who wanted to write a program to link with 
Windows system DLLs had to give them 2% of the profits, they'd be blasted by 
the press, yet the free software community wants to argue that programmers 
can't use their APIs if they don't have certain licensing terms?!

	The irony is killing me.

	DS

Re: Input on the Non-GPL Modules - legal nonsense

[Rob Landley]

On Thursday 25 October 2001 02:24, David Schwartz wrote:
> >I keep hearing this type of reasoning.  It flat-out doesn't work this way
> > in the legal system.  This is similar to arguing that you didn't really
> > stab someone if you threw the knife instead of holding it. ("But your
> > honor, once the knife left my hand it really wasn't under my control...")
>
> 	What amazes me is that these legal arguments about the control programmers
> have over their software, are coming from the free software community. If
> Microsoft argued that anybody who wanted to write a program to link with
> Windows system DLLs had to give them 2% of the profits, they'd be blasted
> by the press, yet the free software community wants to argue that
> programmers can't use their APIs if they don't have certain licensing
> terms?!
>
> 	The irony is killing me.

It's not a question of the published APIs.  Binary-only modules ARE allowed, 
and nobody's even questioned userspace applications.

It's aggregating yoru code with GPL code and distributing the result.  That 
violates the terms of the GPL, negating your right to distribute the GPL 
code, and by extension the aggregate work containing the GPL code.

And this isn't specific to free software.  Imagine if Microsoft put royalties 
on the distribution of some of their DLLs (like the big visual basic runtime) 
with your program, or Sun put restrictions on shipping their java runtime 
with one of your java programs.  (Which, in fact, they do.)  Neither 
currently ask for cash, but boy do they put restrictions!  Try distributing a 
modified version of either one of those sometime and see how long it takes 
their lawyers to come after you.  Distributing a patched vbrun.dll?  They'll 
go after you with bazookas.  You can't even unarchive jre.exe, last I 
checked.  The end user has to install it on their machine using Sun's 
installer.  (Maybe this has eased up in the past couple years, I stopped 
paying too much attention to Sun's java distributions shortly after 1.2...)

If your code doesn't include any GPL code, you're fine.  User space 
applications linking against glibc are fine, and binary-only kernel modules 
you wrote from scratch yourself are fine.  (Header files that define APIs but 
don't directly produce binary output code by themselves are a gray area; it's 
sloppy of us to have those as GPL instead of LGPL anyway, but compiling 
against header files probably falls under fair use since the programmer did 
make a distinction between .h and .c files, and being included in other 
programs to allow interoperability with this bit of code is what .h files are 
FOR...  I'd guess It's something that either side of could be successfully 
argued in front of a judge, depending on who had the better lawyer...)

Rob

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

[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

[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

[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