Re: [tlug] Proprietary code linked with GPL code

["Stephen J. Turnbull" <stephen@example.com>]

>>>>> "Jim" == Jim  <jep200404@example.com> writes:

    Jim> Stephen J. Turnbull wrote:

    Jim> How can one legally ship a product that links a proprietary
    Jim> driver to a GPL kernel?

    >> By putting it in a loadable module.

    Jim> Well, that's pretty easy.

Yep.  I should be careful to make it explicit though: this only
applies to the Linux kernel (AFAIK), and only because Linus says so.
According to rms and the FSF's lawyer, the act of loading a dynamic
module proves ipso facto that the kernel + the module is a derivative
work of the kernel.  Thus the GPL would apply, except that Linus has
explicitly limited the applicability of the GPL terms to code
statically linked to the Linux kernel.

    Jim> So it is the customer that (perhaps unknowingly) does the
    Jim> linking when they use the device, and the customer would not
    Jim> be allowed to ship the linked stuff (which disappears each
    Jim> time the thing is turned off)?

No.  Linking is not the act that violates the GPL; linking is just
prima facie evidence that it's a derivative work.  The violation is
creating the derivative work (by legal definition, copying) and
distributing the copy.  The customer makes no prohibited copies (he
does make copies, can you spell L2 cache, children? I knew you could! 
but the courts have _explicitly_ decided that distributing software
implies a license to copy from RAM to on-chip cache, and a bunch of
similar copies pursuant to normal execution of the software).

    Jim> When the customer turns off the device (and the linked stuff
    Jim> goes poof), then the customer no longer possesses linked
    Jim> stuff in the device and can then distribute the device?

No.  According to rms and his lawyer, the fact that you _can_ link
makes it a derivative work, unless _you_ can show there is another
purpose for the code you've written.  It is likely that a court would
consider any purpose frivolous, though, with the single exception of
linking to another program that implements the same API or ABI.

Around 1999 Aladdin was shipping its AFPL product with a Makefile that
contained a single stanza that (1) had a rule to build a glue object
and (2) added the object and "-lreadline" to the linker command.  The
FSF forced them to remove that code, even though Aladdin did not
distribute the glue source with Ghostscript, on the grounds that this
made Ghostscript a derivative of readline, which is GPL code.

I can't fault the FSF's legal reasoning.

    Jim> So a customer could not distribute a running device that has
    Jim> linked proprietary and GPL code?

He can, if he is simply passing along an object that he has received
in conformance to the terms of the GPL.  This is more interesting than
it looks at first blush, however.  Specifically, this would arguably
apply to a reseller, I believe.  The GPL specifically exempts
recipients from punishment for the sins of upstream as long as they
comply with the GPL.  But copyright applies to making new copies, not
transfer of originals.  So since the reseller makes no copies, he is
automatically in compliance!

Of course if the reseller contracted for the device knowing that it
violated the GPL's terms, he would bear some legal responsibility for
the copying.

    Jim> I don't think it's moot. Embedded Linux devices have no
    Jim> special requirement for static linking, except perhaps for
    Jim> stuff needed very very early.

I didn't mean that there was a requirement, just that it seems likely
to me that the kernel drivers would be statically linked to avoid
nitpicky order dependencies.

    Jim> I would expect the proprietary modules to be loadable and the
    Jim> proprietary *.o files seem to corroborate this. Am I missing
    Jim> something?

Yes.  Infinite human stupidity.<wink>  If the vendor is smart, they'll
take advantage of the loadable module exception.  As far as I know
there's little harm in the embedded world to distributing the source
code.  Look up "snort" and "sourcefire", and reflect on the fact that
they are the same product---the latter a company that recently sold
for $220 million.  (If Google says something different, I'll check and
give you the straight dope later.)

In most cases, it's simply not that hard to reproduce software that's
derivative of an open source product.  So _really_ hiding it is just
dumb, it exposes you to legal and social risk without hindering your
competitors all that much.


-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.