From: David Newall <davidn@davidnewall.com>
To: Greg KH <greg@kroah.com>
Cc: Derek Atkins <warlord@mit.edu>, linux-kernel@vger.kernel.org
Subject: Re: Re-enabling non-GPL driver access to disk partition information
Date: Thu, 04 Feb 2010 01:58:37 +1030 [thread overview]
Message-ID: <4B699625.5040808@davidnewall.com> (raw)
In-Reply-To: <20100203021049.GA17576@kroah.com>
Greg KH wrote:
> On Sat, Jan 30, 2010 at 02:32:20PM +1030, David Newall wrote:
>
>> Greg KH wrote:
>>
>>> On Fri, Jan 29, 2010 at 09:15:09AM -0500, Derek Atkins wrote:
>>>
>>>
>>>> -EXPORT_SYMBOL_GPL(put_device);
>>>> +EXPORT_SYMBOL(put_device);
>>>>
>>>>
>>> No, sorry, [...] I can not, and will not, make this change.
>>>
>>>
>> Derek,
>>
>> Consider writing a GPL wrapper module.
>>
>
> Ah, the old "GPL condom" try. Sorry, but this has been tried many times
> in the past, and have been shut down every time. See the Samba history
> of this for lots of details as to why this does not work.
Samba vs The Money merely shows that The Money failed to put up a
sufficient defence. Good result for FOSS, but I recommend against you
betting your home on it.
Anyway, I was thinking of something a little more substantial that what
you perhaps read into my suggestion. There's usually a substantial gap
between the pure needs of a driver and the facilities offered by an
operating system. In the case in question, for example, the need is to
count the number of partitions, and the facility offered is get_device,
or something. A tiny GPL module that calls get_device and returns a
count sounds eminently defensible.
In addition--and please keep in mind that I'm unfamiliar with the
internals of the kernel--it seems to me there's an obvious similarity
with USL vs BSD, alleging copyright for verbatim copying of macro
constants, amongst other things. A lesson that learned then was that you
can't prevent someone from using provided facilities necessary for use
of the operating system. I don't know what put_device does, but I know
what it sounds like; it sounds like it's something that you have to use,
and so one can use it, even in proprietary code. I imagine this idea
will irritate those who put in the hard yards, but FOSS has to play by
the same rules as the monied end of town. You might want to think about
this carefully, because if it's taken all the way through court and the
GPL-only claim rejected, there may well be a run-on effect on all of the
symbols marked GPL-only. Those who want to thwart proprietary kernel
modules may find it prudent to generously give up this symbol rather
than risking the lot.
next prev parent reply other threads:[~2010-02-03 15:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-29 14:15 Re-enabling non-GPL driver access to disk partition information Derek Atkins
2010-01-29 14:47 ` Al Viro
2010-01-29 15:09 ` Rik van Riel
2010-01-29 15:38 ` Derek Atkins
2010-01-29 15:23 ` Alan Cox
2010-01-29 22:06 ` Greg KH
2010-01-30 4:02 ` David Newall
2010-02-03 2:10 ` Greg KH
2010-02-03 15:28 ` David Newall [this message]
2010-02-04 0:30 ` Robert Hancock
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=4B699625.5040808@davidnewall.com \
--to=davidn@davidnewall.com \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=warlord@mit.edu \
/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