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

[Hans-JÃrgen Koch]

Am Fri, 08 Feb 2008 03:20:26 +1030
schrieb David Newall <davidn@xxxxxxxxxxxxxxx>:

> Hans-JÃrgen Koch wrote:
> > Am Fri, 08 Feb 2008 01:01:24 +1030
> > schrieb David Newall <davidn@xxxxxxxxxxxxxxx>:
> >   
> >>> It is not legally meaningless if copyright holders publicly state
> >>> how they interpret the license and what they consider a license
> >>> violation. 
> >>>       
> >> Copyright-holders' opinions mean nothing.  In the particular case
> >> of EXPORT_SYMBOL_GPL, copyright-holders' opinions are clearly
> >> flawed because they make a statement about code that they do not
> >> even know of. 
> >>     
> >
> > What are you talking about? That's what every GPL-licensed library
> > does. By putting a library under the GPL, the copyright-holder
> > clearly states that he considers all programs that link against
> > that library a derived work. And that he therefor requires these
> > programs to be GPL, too, no matter if these programs already exist
> > or not. 
> 
> Your last sentence, above: That is what EXPORT_SYMBOL_GPL attempts to
> do.  The place to state such a requirement is in the licence, not in
> the source code.  That is what I am talking about.  I can't provide
> you with software under a licence that says, "you are free to use
> this software in any way you want," and later say, "oh, but in the
> source code is tells you that you must take a break every two hours
> of use."

The license says that derivative work has to be GPL. Naturally, every
sensible and practically usable license has gray areas. We know that
and we live with that. But if there's room for interpretation, it's
perfectly OK and helpful, if the copyright holder states what his
interpretation is. If you use an EXPORT_SYMBOL_GPL symbol in non-GPL
code, you know that the owner of the work doesn't agree with you
license-wise. You had to cheat, e.g. by setting your MODULE_LICENCE to
"GPL", and deliberately acted against the wishes of the copyright
holder. Here in Germany, the GPL is enforceable, and such evidence
will at least weaken your position. You won't get away with just
saying you didn't know the copyright holder's position. Even
printouts of some mails in this thread could be used to prove that
you knew.   
IANAL, there hasn't been such a case AFAIK, and you might well leave
the court unharmed. But can you (or anyone else) be sure? That's what
it's all about.

> 
> 
> >> Less there be further confusion: I am not an advocate for binary
> >> drivers.  
> >>     
> >
> > Nice to hear. So, if you're an advocate for open source drivers,
> > why do you have problems making them GPL?
> >   
> 
> I don't, but EXPORT_SYMBOL_GPL doesn't do that.  It makes an ambit
> claim, that might coerce an author into making a driver GPL, but might
> also cause them to exit the Linux market.  I have a problem with
> driving manufacturers away from Linux.
> 
> > Using a symbol from a library means linking to it, and that creates
> > a derived work. Why should it be different when using kernel
> > symbols?
> I don't agree with your claim, but I'm going to explain something
> else: The GPL doesn't require software that *uses* GPL code to itself
> be GPL. 

Yes it does. Chapter 2b requires any part that is derived from a GPL
work to be GPL, too. As you well know.
Just to help you a bit: The only argument you could use is that a
kernel module, even if it uses GPL'ed kernel code, is not a derivative work.
You _might_ succeed with that interpretation, even before a German
court, and even if it can be proven that you knew that the original
author doesn't agree with you. Come on, try it!

> It requires software that is *distributed* as part of a GPL
> work to itself be GPL.  At time of distribution, a kernel module is
> neither using nor linked to the kernel.

Oh, come on! You cannot turn a derived work into an original work just
by distributing them seperately.

Thanks,
Hans

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/