linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Craig Milo Rogers <rogers@ISI.EDU>
To: "Eric S. Raymond" <esr@snark.thyrsus.com>
Cc: torvalds@transmeta.com, linux-kernel@vger.kernel.org
Subject: Re: Controversy over dynamic linking -- how to end the panic
Date: Thu, 21 Jun 2001 13:34:20 -0700	[thread overview]
Message-ID: <1110.993155660@ISI.EDU> (raw)
In-Reply-To: Your message of "Thu, 21 Jun 2001 14:14:42 EDT." <200106211814.f5LIEgK04880@snark.thyrsus.com>

	IANAL.  I also dislike fencepost errors.  Hence, these
comments.

	The GNU GPL Version 2, June 1991, (hereafter the GPL), applies
"to the modified work as a whole".  Consequently:

>2. A driver or other kernel component which is statically linked to
>   the kernel *is* to be considered a derivative work.

	The kernel image, including the statically-linked device
driver, is the primary derived work licensed by the GPL.  That portion
of the kernel image that represents some actual device driver binary
code (continuing the example above, and assuming that the device
driver's unlinked object code isn't already subject to the provisions
of the GPL), may or may not be a derived work under copyright law,
depending upon what modifications the linker made to the binary code
during linking. If the device driver didn't become a derived work
during compilation, and it didn't (for example) resolve any kernel
symbols during linking, it would not be a derived work under copyright
law, right?  Of course, right.

>3. A kernel module loaded at runtime, after kernel build, *is not*
>   to be considered a derivative work.

	The in-core kernel image, including a dynamically-loaded
driver, is clearly a derived work per copyright law.  As above, the
portion consisting only of the dynamically-loaded driver's binary code
may or may not be a derived work per the GPL.  It doesn't much matter
under the GPL, anyway, so long as the in-code kernel image isn't
"copied or distributed".

	Looking to the future, what if Linux is enhanced with the
ability to take a snapshot of a running system (including any
dynamically-loaded driver modules), and the snapshots are copied and
distributed by, say, a PDA vendor to make an instant-on Linux system?
I think it's reasonable to argue that the GPL requirements must apply
to all parts of the distributed kernel image, even the parts that were
derived from pre-snapshot dynamically-loaded modules.


	The act of "copying and distributing" a linked kernel image
containing GPL'ed code and, say, a non-GPL'ed device driver, requires
that the distributor follow the requirements of the GPL as applied to
the work as a whole, which means that source code must be available
for *all* portions of the linked kernel, which means that source code
for the driver must be made available... under the terms of sections 1
and 2 of the GPL.  The GPL's source code availability requirement
applies even to those identifiable sections of the linked kernel image
which themselves are not derived (per copyright law) from GPL'ed
sources.

	Remember, however, that the GPL, as written, imposes
requirements upon the the *distributor* of a combined work, not upon
the owner of the non-GPL'ed portions that were included in the
combined work.  It is the distributor's responsibility to make source
code available as require by the GPL.  This is *not* the same as
saying that any non-GPL'ed source code in question has, automatically,
itself become licensed under the GPL (sections 1 and 2).

					Craig Milo Rogers

  parent reply	other threads:[~2001-06-21 20:34 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-06-21 18:14 Controversy over dynamic linking -- how to end the panic Eric S. Raymond
2001-06-21 18:30 ` Alan Cox
2001-06-21 19:17   ` Eric S. Raymond
2001-06-21 19:51     ` Andrew Pimlott
2001-06-21 20:13       ` Eric S. Raymond
2001-06-21 20:46         ` Andrew Pimlott
2001-06-21 21:02         ` Timur Tabi
2001-06-21 21:05           ` Andrew Pimlott
2001-06-21 21:17           ` Timur Tabi
2001-06-21 20:17       ` David S. Miller
2001-06-21 20:29       ` Timur Tabi
2001-06-21 18:39 ` Jeff Golds
2001-06-21 18:51   ` Jeff Mahoney
2001-06-21 20:02   ` Steve Brueggeman
2001-06-21 18:46 ` Timur Tabi
2001-06-21 19:03   ` Timur Tabi
2001-06-21 19:53     ` Erik Mouw
2001-06-21 19:04   ` Mike Harrold
2001-06-21 19:14     ` Alan Cox
2001-06-21 20:12       ` Marco Colombo
2001-06-21 21:14         ` Alan Cox
2001-06-21 20:31       ` Timur Tabi
2001-06-21 19:08   ` Timur Tabi
2001-06-21 19:17     ` Alexander Viro
2001-06-21 20:01   ` Wei Weng
2001-06-21 19:06     ` Alan Cox
2001-06-21 19:34       ` Jonathan Lundell
2001-06-21 20:17         ` D. Stimits
2001-06-22 11:32   ` Rob Landley
2001-06-21 20:34 ` Craig Milo Rogers [this message]
2001-06-21 21:35   ` Controversy over dynamic linking -- how to end the panic (long) Alex Bligh - linux-kernel
2001-06-22 12:32   ` Fair Use (Was Re: Controversy over dynamic linking -- how to end the panic) Rob Landley
2001-06-22  1:29 ` Controversy over dynamic linking -- how to end the panic Andrea Arcangeli
2001-06-22 10:44 ` David Woodhouse
2001-06-23 20:11 ` Fabrice Gautier
2001-06-21 19:22 Disconnect
2001-06-21 19:24 ` Alan Cox
2001-06-21 19:25 Jesse Pollard
2001-06-21 21:43 Timur Tabi
2001-06-22  3:05 Rick Hohensee
2001-06-22  4:05 ` kumon
2001-06-23 22:29 ` Scott Wood

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=1110.993155660@ISI.EDU \
    --to=rogers@isi.edu \
    --cc=esr@snark.thyrsus.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.com \
    /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;
as well as URLs for NNTP newsgroup(s).