linux-kernel - Re: Re-enabling non-GPL driver access to disk partition information

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 03 Feb 2010 18:30:18 -0600
From:	Robert Hancock <hancockrwd@...il.com>
To:	David Newall <davidn@...idnewall.com>
CC:	Greg KH <greg@...ah.com>, Derek Atkins <warlord@....edu>,
	linux-kernel@...r.kernel.org
Subject: Re: Re-enabling non-GPL driver access to disk partition information

On 02/03/2010 09:28 AM, David Newall wrote:
> 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.

The GPL flag on the symbols has no legal weight. What does have legal 
weight is whether whatever you're linking into the kernel can be 
considered a derivative work of the kernel or not. The intent of the 
EXPORT_SYMBOL_GPL flag is to warn that if you're using these symbols, 
then you're hooking into something sufficiently internal that you may be 
considered a derivative work. However, using symbols marked GPL in a 
non-GPL module doesn't necessarily mean you're violating the GPL, nor 
does not using them mean you're not. The only one that can give a 
definitive answer for any particular piece of code is likely a lawyer.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/