linux-kernel - Re: [PATCH] USB: mark USB drivers as being GPL only

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]

Message-Id: <1202058820.15090.60.camel@violet>
Date:	Sun, 03 Feb 2008 18:13:40 +0100
From:	Marcel Holtmann <marcel@...tmann.org>
To:	David Newall <davidn@...idnewall.com>
Cc:	Pekka Enberg <penberg@...helsinki.fi>, 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

Hi David,

> > 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 a new drivers is originally written for Linux, then you are breaking
the GPL. There is no other way to name this. Using EXPORT_SYMBOL or
EXPORT_SYMBOL_GPL make no difference here. You driver was meant to be
running as Linux kernel module and thus it is derivative work. While
there is a gray area, but this case has always been pretty clear.

> > 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.

What are you arguing here. It makes no difference if it is technical or
not. The EXPORT_SYMBOL_GPL gives you a clear hint that when using this
symbol, you have to obey to the GPL. Even the EXPORT_SYMBOL is protected
by the same GPL license. And thus both has the same binding power to be
used from GPL modules only.

At this point I would strongly advise to talk to lawyer since you are
obvious missing the point here.

> > 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.

First of all we are talking about kernel modules here. Not the
userspace. So stop this FUD.

> > 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.

In userspace, yes, the kernel would "run" proprietary code fully legally
without any problem. As a kernel module, the only safe answer is no. And
in case of EXPORT_SYMBOL_GPL, it is pretty clear. You would obviously
violate the license.

Regards

Marcel

--
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/