From: "David Schwartz" <davids@webmaster.com>
To: "Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>
Subject: RE: GPL Violation?
Date: Sat, 19 Aug 2006 16:01:14 -0700 [thread overview]
Message-ID: <MDEHLPKNGKAHNMBLJOLKEEEJNOAB.davids@webmaster.com> (raw)
In-Reply-To: <20060819113052.GC3190@aitel.hist.no>
> Now, if someone actually distributes a closed-source module that
> circumvents EXPORT_SYMBOL_GPL, or relies on an accompagnying
> open source patch that removes the mechanism, this happens:
> 1. By doing this, they clearly showed that their module is outside the
> gray area of "allowed binary-only modules". They definitively
> made a "derived work" and distributed it.
How do you figure? This seems to me to be an amazing leap with no rationale
of any kind to justify it.
> 2. Anybody who received this module may now invoke the GPL
> (and the force of law, if necessary) to extract the
> module source code from the maker. And then this source
> can be freely redistributed to all interested.
A trivial patch to the kernel just to remove a deliberate incompatibility
isn't sufficient alone to change the status of the module. The patch to
remove EXPORT_SYMBOL_GPL could even be developed by a completely different
group of people from the kernel module, with no overlap of any kind, so it
is absurd to say that the kernel patch somehow changes the status of the
module.
To give you an analogy, suppose I made a closed-source filesystem for
FreeBSD. Somebody made a patch to the Linux kernel to allow it to emulate
the BSD filesystem interface well enough that with that patch, Linux can use
my module. By any stretch of the imagination, can this Linux patch change
the copyright status of my module, given that it was developed by different
people?
Yes, the patch to modify the kernel is clearly a derivative work, but the
module the patch is needed for is still not if it wasn't before.
In fact, any arguments you could make before, you can still make. But no
new ones arise. For example, if you could argue that the kernel and the
module were too tightly integrated in their design to be considered separate
works or that the module includes too much of the kernel, you still can. But
those are the arguments you'd need to make, and needing a kernel patch that
is independent of the module (authorwise) doesn't strengthen any of them.
> So the rights management system works really well - it provides an
> enforceable "the price for using these symbols is your code".
It can't do that. The module must be GPL'd if and only if it's a derivative
work of the Linux kernel. This has to do with whether it contains portions
of the Linux kernel beyond what is covered by things like fair use and
scenes a faire. How does EXPORT_SYMBOL_GPL change that?
> The mechanism itself is not protected by laws like the DMCA, because
> its removal is explicitly allowed. The great thing is, protection
> of the _content_ is not lost when this happens.
Huh?
I do agree with the point that you do need to explicitly act to circumvent
EXPORT_MODULE_GPL and that pointing out that you did that may be helpful in
subsequent legal fights that may arise. But I don't think anyone today can
specify precisely how. (Perhaps if someone claimed they had no idea that
they might be making their module a derivative work, that they must have
known could affect a damage award.)
DS
next prev parent reply other threads:[~2006-08-19 23:01 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-17 5:48 Anonymous User
2006-08-17 6:14 ` Arjan van de Ven
2006-08-17 9:38 ` Ben B
2006-08-17 12:02 ` linux-os (Dick Johnson)
2006-08-17 16:11 ` Stefan Richter
2006-08-17 19:21 ` James Courtier-Dutton
2006-08-17 23:26 ` Ian Stirling
[not found] ` <20060817193540.dc819396.seanlkml@sympatico.ca>
2006-08-17 23:35 ` Sean
2006-08-18 0:32 ` Alan Cox
2006-08-18 7:23 ` Xavier Bestel
2006-08-18 12:23 ` Ian Stirling
2006-08-18 9:04 ` Helge Hafting
2006-08-17 6:42 ` Patrick McFarland
2006-08-17 6:54 ` Arjan van de Ven
2006-08-17 7:32 ` Patrick McFarland
2006-08-17 8:02 ` Adrian Bunk
2006-08-17 9:03 ` Patrick McFarland
2006-08-18 17:56 ` Adrian Bunk
2006-08-17 12:39 ` Grzegorz Kulewski
2006-08-17 13:41 ` Alan Cox
2006-08-17 13:31 ` Grzegorz Kulewski
2006-08-17 15:52 ` Theodore Tso
2006-08-18 2:03 ` Chase Venters
2006-08-17 8:32 ` Stefan Richter
2006-08-17 9:36 ` Patrick McFarland
2006-08-17 11:25 ` Alan Cox
2006-08-17 11:48 ` Neil Brown
2006-08-17 9:37 ` David Woodhouse
2006-08-17 23:45 ` Ian Stirling
2006-08-18 8:28 ` David Woodhouse
2006-08-18 12:52 ` Ian Stirling
2006-08-18 8:53 ` Bernd Petrovitsch
2006-08-18 9:04 ` David Woodhouse
2006-08-18 9:15 ` Bernd Petrovitsch
2006-08-20 22:05 ` Andrea Arcangeli
2006-08-20 22:20 ` Arjan van de Ven
2006-08-18 9:51 ` David Schwartz
2006-08-18 16:52 ` Alan Cox
2006-08-18 22:42 ` David Schwartz
2006-08-19 10:48 ` David Greaves
2006-08-19 16:29 ` Patrick McFarland
2006-08-19 17:28 ` David Greaves
2006-08-19 11:30 ` Helge Hafting
2006-08-19 15:44 ` Michael Buesch
2006-08-19 23:01 ` David Schwartz [this message]
2006-08-20 3:20 ` Chase Venters
2006-08-21 7:58 ` Helge Hafting
2006-08-21 11:27 ` Stefan Richter
2006-08-21 13:06 ` Alan Cox
2006-08-21 14:59 ` Horst H. von Brand
2006-08-17 9:30 ` Alan Cox
2006-08-17 9:29 ` Patrick McFarland
2006-08-17 14:52 ` Helge Hafting
2006-08-17 14:58 ` Anonymous User
2006-08-17 15:52 ` Stefan Richter
2006-08-17 16:19 ` Michiel de Boer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=MDEHLPKNGKAHNMBLJOLKEEEJNOAB.davids@webmaster.com \
--to=davids@webmaster.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome