From: Jamie Lokier <jamie@shareable.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Chris Wedgwood <cw@f00f.org>, Diego Calleja <diegocg@gmail.com>,
jmerkey@wolfmountaingroup.com, mrmacman_g4@mac.com,
legal@lists.gnumonks.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, garbageout@sbcglobal.net
Subject: Re: blatant GPL violation of ext2 and reiserfs filesystem drivers
Date: Fri, 23 Dec 2005 04:25:00 +0000 [thread overview]
Message-ID: <20051223042500.GA4698@mail.shareable.org> (raw)
In-Reply-To: <Pine.LNX.4.58.0512222233430.32123@gandalf.stny.rr.com>
Steven Rostedt wrote:
> If I were to receive a binary kernel, that happens to have
> implemented the same API as Linux, is it a violation of the GPL. As
> long as it doesn't use any of the same code and does a "clean room"
> kind of implementation of the API it is perfectly legal.
Some would say it is not possible to make a "clean room"
implementation of the "Linux kernel API" for modules - especially
modules that need to use symbols marked as "GPLONLY" - because there
isn't a well-documented API, and to define the API you'd have to study
the kernel in such detail that you'd be making a derived work.
(Then again, the same applies to ("not") emulating Windows in WINE...).
There is a de facto understanding, in the form of an uneasy
compromise, that that binary modules which only use standard exported
symbols, not including GPLONLY symbols, are permitted, provided they
are distributed separately from the binary kernel, and loaded at run
time.
But not all kernel copyright holder subscribe to that: some are on
record saying they believe all distributed binary-only modules are
infringing. So in principle there is no guarantee that distributing
such a binary module is safe from legal consequences, but if you're
into taking business risks based on what most of the relevant people
recommend implicitly or explicitly, then distributing binary modules
which fit the above pattern is what I recommend. (This is not an
informed legal opinion, and I'm not a lawyer etc.)
Unlike modules, which can do all sorts of dirty things and it's not
really an API, the system call interface is well-documented and
well-defined (and easily emulated), and so using that doesn't imply
making a derived work. Furthermore, kernel authors have declared
(starting from Linus' preamble to the license) that there should be no
doubt about programs using only the system call interface, so esoteric
legal masturbation does not apply to this anyway.
This sort of thing has been analysed to death a thousand times on
gnu.misc.discuss, and on linux-kernel, in far more detail than will be
done here, so look there to continue the questioning or see where
these questions have lead before.
> So now if I have this binary kernel, and I myself compile a GPL module, I
> don't see anything in the GPL that would prevent me from linking it in.
The GPL does not apply any restrictions to anything about linking.
Only distribution.
> This is where it gets to be a problem with binary modules. They only
> implement up to the API (granted, it shouldn't include code in the
> headers), but it's the user that's linking and not the distributor. That
> is where the gray area lies.
It's been discussed to death a thousand times, with reference to other
GPL programs, not just Linux. Search for "user does the link" or similar.
And "indirect infringement".
-- Jamie
next prev parent reply other threads:[~2005-12-23 4:25 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-22 16:08 blatant GPL violation of ext2 and reiserfs filesystem drivers Robert W. Fuller
2005-12-22 18:01 ` Kyle Moffett
2005-12-22 20:27 ` Steven Rostedt
2005-12-22 23:12 ` Jeff V. Merkey
2005-12-23 2:56 ` Chris Wedgwood
2005-12-23 3:15 ` Diego Calleja
2005-12-23 3:28 ` Chris Wedgwood
2005-12-23 3:38 ` Steven Rostedt
2005-12-23 3:49 ` Matthew Wilcox
2005-12-23 4:25 ` Jamie Lokier [this message]
2005-12-23 3:30 ` Adrian Bunk
2005-12-23 15:35 ` Ben Slusky
2005-12-23 19:34 ` Bryan Henderson
2005-12-23 20:16 ` Scott Mansfield
2005-12-23 22:00 ` Bryan Henderson
2005-12-24 1:48 ` Horst von Brand
2005-12-24 2:41 ` Peter Williams
2005-12-24 3:25 ` Jamie Lokier
2006-01-04 11:09 ` Harald Welte
2006-01-04 11:54 ` Jamie Lokier
2006-01-04 13:18 ` Harald Welte
2006-01-04 13:46 ` Matthew Wilcox
2006-01-04 17:46 ` Harald Welte
2006-01-04 23:03 ` Gene Heskett
2006-01-04 22:43 ` Jeff V. Merkey
2006-01-04 14:16 ` Jamie Lokier
2006-01-04 14:45 ` Matthew Wilcox
2006-01-04 15:57 ` Jamie Lokier
2006-01-04 17:42 ` Harald Welte
2006-01-05 17:52 ` Bryan Henderson
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=20051223042500.GA4698@mail.shareable.org \
--to=jamie@shareable.org \
--cc=cw@f00f.org \
--cc=diegocg@gmail.com \
--cc=garbageout@sbcglobal.net \
--cc=jmerkey@wolfmountaingroup.com \
--cc=legal@lists.gnumonks.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mrmacman_g4@mac.com \
--cc=rostedt@goodmis.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