From: "David Schwartz" <davids@webmaster.com>
To: "Ramakanth Gunuganti" <rgunugan@yahoo.com>
Cc: "Kyle Moffett" <mrmacman_g4@mac.com>, <linux-kernel@vger.kernel.org>
Subject: RE: GPL issues
Date: Fri, 14 Apr 2006 04:39:59 -0700 [thread overview]
Message-ID: <MDEHLPKNGKAHNMBLJOLKAEFLLFAB.davids@webmaster.com> (raw)
In-Reply-To: <Pine.LNX.4.61.0604112055380.25940@yvahk01.tjqt.qr>
> One thing that is clear in the GPL: If you link the kernel with something
> else to an executable, the resulting blob (and therefore the
> sources to the
> proprietary part) must be GPL.
Actually, that is *far* from clear.
First, the GPL cannot set its own scope. The GPL could say that if you
stored a program in the same room as a GPL program, the program must be GPL.
So *nothing* the GPL says will answer this question -- the question is, can
the GPL attach by linking?
The contrary argument would be that linking two programs together is an
automated process. There is no creative input in the linking process. So it
does not legally produce a single work, but a mechanical combination of the
two original works.
The proof that the executable is not a work for copyright purposes is this
simple -- could a person who took two object files out of the box and linked
them together claim copyright in the new derivative work he just produced? I
think the answer would be obvious -- the executable is not a new work, it's
just the two original works combined.
Note that this does not mean that *designing* a program specifically to
link to another program can't make it a derivative work of the work you
designed it to go with. Just that the linking itself cannot always do so
automatically.
In any event, to give my answer to the original question -- if a kernel
module and a userspace program are developed together, and are not both
derived from an API that is independent of the Linux kernel, then they are
probably going to be considered a single work.
On the flip side, you should be okay if you develop an API for a kernel to
communicate with user space and then develop a user space program that could
work on any kernel (Linux or not, theoretically) that supported that API.
This should ensure that the user space program is derivative only from the
API and not from the Linux kernel.
Note that you will not be okay if the API looks like what just happen to be
Linux kernel internals. The API itself must be independent of the Linux
kernel internals.
DS
next prev parent reply other threads:[~2006-04-14 11:41 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-11 6:31 Ramakanth Gunuganti
2006-04-11 8:42 ` Jesper Juhl
2006-04-11 10:51 ` Martin Mares
2006-04-11 17:46 ` Horst von Brand
2006-04-11 13:49 ` Kyle Moffett
2006-04-11 15:49 ` Ramakanth Gunuganti
2006-04-11 16:07 ` linux-os (Dick Johnson)
2006-04-11 16:29 ` Stefan Smietanowski
2006-04-11 16:13 ` Adrian Bunk
2006-04-11 16:15 ` Kyle Moffett
2006-04-11 16:23 ` Dave Neuer
2006-04-11 18:58 ` Jan Engelhardt
2006-04-14 11:39 ` David Schwartz [this message]
2006-04-14 14:54 ` linux-os (Dick Johnson)
2006-04-14 17:50 ` David Weinehall
2006-04-14 18:56 ` David Schwartz
2006-04-15 11:55 ` Alan Cox
2006-04-15 13:04 ` Steven Rostedt
2006-04-15 18:49 ` David Schwartz
2006-04-11 15:49 ` Ramakanth Gunuganti
2006-04-11 23:06 ` David Weinehall
2006-04-12 2:38 ` Joshua Hudson
2006-04-12 3:18 ` Mark Lord
2006-04-12 5:00 ` Kyle Moffett
2006-04-12 5:31 ` Arjan van de Ven
2006-04-12 5:45 ` jdow
2006-04-12 6:01 ` David Weinehall
2006-04-12 6:26 ` jdow
2006-04-12 9:13 ` Stefan Smietanowski
2006-04-12 11:33 ` Olivier Galibert
2006-04-12 14:51 ` Arjan van de Ven
2006-04-13 22:07 ` Mark Lord
2006-04-15 11:14 ` Arjan van de Ven
2006-04-13 22:17 ` Mark Lord
2006-04-15 11:15 ` Arjan van de Ven
2006-04-11 23:12 ` Alan Cox
2006-04-12 7:01 Pramod Srinivasan
2006-04-12 8:16 ` David Weinehall
2006-04-12 9:06 ` Jan Engelhardt
2006-04-12 9:22 ` Stefan Smietanowski
2006-04-12 9:40 ` Martin Mares
2006-04-12 9:28 ` Alan Cox
2006-04-14 11:39 ` David Schwartz
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=MDEHLPKNGKAHNMBLJOLKAEFLLFAB.davids@webmaster.com \
--to=davids@webmaster.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mrmacman_g4@mac.com \
--cc=rgunugan@yahoo.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
all inboxes | Powered by JetHome®