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

[Marcel Holtmann <marcel@holtmann.org>]

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