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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 04 Feb 2008 02:36:21 +1030
From:	David Newall <davidn@...idnewall.com>
To:	Pekka Enberg <penberg@...helsinki.fi>
CC:	Greg KH <greg@...ah.com>, Christer Weinigel <christer@...nigel.se>,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] USB: mark USB drivers as being GPL only

Pekka Enberg wrote:
> Hi David,
>
> On Feb 3, 2008 5:12 PM, David Newall <davidn@...idnewall.com> wrote:
>   
>> By the way, I'm almost certain that the COPYING file is the first, last
>> and only document specifying licence conditions, and nothing in that
>> prevents a proprietary driver from including a patch that, for example,
>> globally replaces ALL GPL-only symbols by the less restrictive ones.
>>     
>
> So I am going to assume you're not trolling here (although some of
> your snarky remarks make that bit hard).
>   

Thanks.  I'm not trolling.  Perhaps I was a bit snarky; it's an issue I
feel strongly about.  (I'm sure others feel just as strongly, but
differently.)

> And, _if_ you're distributing a derived work that is not under the
> GPLv2, you're breaking the law. I think we can agree on this?
>   

Agreed.

> As there is some controversy over the definition of derived work
> (think Linus' comments on porting a driver or a filesystem from
> another operating system here), we use the EXPORT_SYMBOL_GPL
> annotations as a big warning sign that what you're doing is likely to
> be considered as a derived work.
Let's consider a totally original USB driver.  There are an infinite
number of them, some still to be written.


> If the USB developers want to
> annotate their code with EXPORT_SYMBOL_GPL, why the hell do you want
> to argue about it?
Have I the wrong end of the stick?  Isn't that mark restricting an
interface to GPL _callers_?    Isn't it a technical switch that means,
"Don't use my software if yours isn't (also) GPL"?  As such it's mere
political rhetoric, devoid of any binding power.


> If you want to
> develop for Linux, you're most certainly better off always
> distributing your code under the GPLv2

I agree; but let's not disadvantage applications where regulatory
requirements prohibit GPL code, nor applications where the proprietor
simply chooses to keep the work proprietary.  A proprietary module is
simply a piece of software.  Many people couldn't use Linux if they
couldn't run proprietary software on it.


> But what I don't understand
> is why people insist using the Linux kernel for something it clearly
> can never really properly support (proprietary code)?
>   

That's defeatist.  Of course the Linux kernel can properly support
("run") proprietary code.  It would be a miserable excuse for an
operating system if it couldn't.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ