[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

On Thu, Apr 14, 2005 at 09:18:46AM -0300, Humberto Massa wrote:
> >    Then all the people who think that creating a binary
> >kernel module requires creating a derivative work and hence
> >can be restricted by the GPL are wrong.  Take that argument
> >up with them.
> I took. Google my name on lkml and you'll see. They ARE wrong.
> Linus himself studied carefully the situation and came to the
> conclusion they are wrong,

"Linus himself" is, as far as I understand, a programmer, not a lawyer.
His opinion and study of this topic has no more weight on this issue
than any other "armchair lawyer", and far less than Eben Moglen, for

(I'm not claiming he's right or wrong--just that it's not useful to cite
"Linus himself" as a source about legal issues just because he's a well-
known programmer.)

The FSF FAQ says that *all* software linking against GPL libraries must
GPL-compatible[1].  [2] contradicts the above even more directly.

Now, it's possible that they're wrong; there's the obvious theory, for
example, that they've long since realized this, but have no way of
fixing it without admitting to a "loophole" in the GPL.  I've seen lots
of these "derivative work" arguments (and others, such as whether the
GPL is a contract), and have never seen a reply from the FSF addressing
them; given their potential severity, that at least raises an eyebrow.

Of course, I've never raised these with them personally, since I'm not
even qualified to tell which arguments have enough grounding in reality to
avoid wasting their time, and I don't know whether anyone else has; so
I don't place too much weight in that particular theory.  (I don't believe
they're unaware of the arguments, though, and dispelling misconceptions
about the GPL is entirely in their interest, so I'd expect to see responses
to these things.)

> If you make a kernel module that only uses something
> EXPORT_SYMBOL()'d from the kernel, you are NOT in principle
> writing a derivative work. If you use EXPORT_SYMBOL_GPL()'d
> symbols, then you are incurring in (b) above and your kernel
> module is most certainly a derivative work.

The notion that what is a derivative work changes based on whether a symbol
was declared with EXPORT_SYMBOL or EXPORT_SYMBOL_GPL seems fundamentally
absurd to me.  (If somebody is reimplementing the Linux kernel API, he
might just as easily reimplement the "EXPORT_SYMBOL_GPL" symbols, for
compatibility with drivers that need them, for example.)

> PS: yes, the "broken threads" thing p*sses me off too, but I
> can't prevent it.

Er, it's your own mailer that's doing it, so you have solutions: fix
your mailer or get a new one.  Breaking threads breaks conversations,
especially in larger threads, where threading is fundamental.  It takes
just one person to wreck the whole thread, and "I can't prevent it" is
just not a reasonable response.

[1] http://www.fsf.org/licensing/licenses/gpl-faq.html#IfLibraryIsGPL
[2] http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLModuleLicense

Glenn Maynard

Reply to: