From: Mark Salisbury <mbs@mc.com>
To: Jason Wohlgemuth <jswkernel@triad.rr.com>, linux-kernel@vger.kernel.org
Subject: Re: GPL Question
Date: Fri, 27 Oct 2000 13:16:10 -0400 [thread overview]
Message-ID: <00102713233415.00688@pc-eng24.mc.com> (raw)
In-Reply-To: <39F9AF0E.70406@triad.rr.com>
In-Reply-To: <39F9AF0E.70406@triad.rr.com>
On Fri, 27 Oct 2000, Jason Wohlgemuth wrote:
> Consider this:
>
> A subsystem that is statically built into the Linux Kernel is modified
> to allow the registration of a structure containing function pointers.
>
> The function pointers corrolate to a set of functions within that subsystem.
> If the new structure of pointers has been registered, the original
> functions will call the new functions in the structure passing all
> arguments and returning the return value of the new function.
>
> With this said, if no structure has been registered, then no
> functionality is degraded within the kernel. Only the loss of some cpu
> time to check the pointers at the top of the old functions.
>
> Now, if a module is loaded that registers a set of functions that have
> increased functionality compared to the original functions, if that
> modules is not based off GPL'd code, must the source code of that module
> be released under the GPL?
>
> Thanks in advance,
> Jason Wohlgemuth
the api of the module would be a reimplementation of a GPL'd api
(the function names may have changed, but the base behaviors must be equivalent)
so the question in simple terms might phrased as:
is the API under GPL, or is it the code or are both?
I think the answer is both.
--
/*------------------------------------------------**
** Mark Salisbury | Mercury Computer Systems **
** mbs@mc.com | **
**------------------------------------------------**
** "WYGIWYD - What You Get Is What You Deserve" **
**------------------------------------------------*/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2000-10-27 17:27 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-10-27 16:36 GPL Question Jason Wohlgemuth
2000-10-27 16:31 ` David Weis
2000-10-27 17:21 ` Alan Cox
2000-10-27 17:26 ` Matthew Dharm
2000-10-27 17:56 ` Somewhat different " Christopher Friesen
2000-10-27 18:06 ` Rik van Riel
2000-10-27 20:49 ` Alan Cox
2000-10-27 17:16 ` Mark Salisbury [this message]
2000-10-27 17:23 ` Alan Cox
2000-10-27 18:53 ` David Schwartz
2000-10-27 18:56 ` Rik van Riel
2000-10-27 20:53 ` Alan Cox
2000-10-27 19:17 ` James Sutherland
2000-10-27 21:08 ` Brian F. G. Bidulock
2000-10-27 20:52 ` Alan Cox
2000-10-30 12:27 ` Helge Hafting
-- strict thread matches above, loose matches on Subject: below --
2004-06-28 22:13 GPL question ca_tex-kernel
2004-06-29 11:01 ` David Weinehall
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=00102713233415.00688@pc-eng24.mc.com \
--to=mbs@mc.com \
--cc=jswkernel@triad.rr.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