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
* Greg Boyce <[email protected]> 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.
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
On Thu, 18 Oct 2001 16:36:58 +0000 (UTC), Jan Niehusmann
<[email protected]> 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
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
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
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
[email protected] Lindon, UT 84042
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
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
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/
> 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
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 <[email protected]> <Ben_Greear AT excite.com>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
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/
>> 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
<[email protected]>
> 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
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
[email protected] Lindon, UT 84042
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
> [email protected] Lindon, UT 84042
> -
> 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/
--
Ben Greear <[email protected]> <Ben_Greear AT excite.com>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
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
>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
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