Re: [tlug] Free versus open: a rant

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

>>>>> "Joe" == Joe Larabell <larabell@?jp> writes:

    Joe> I don't believe that's true.

Unfortunately, both rms and his lawyer disagree with you, as does
Larry Lessig, assuming I understood them correctly.

For the purpose of exposition, I'm just going to make flat statements,
but, although I believe the statements made to accurately reflect what
a real lawyer might say, everything between here and the .sig
separator should be qualified with "I am not a lawyer.  This is not
legal advice.  Before making any decisions based on understanding
gleaned from this discussion, consult a qualified lawyer."

    Joe> So long as you don't actually distribute the proprietary
    Joe> "warez" with your product, there should be nothing wrong with
    Joe> making the function call.

That depends.  If this condition:

    Joe> That would be even more clear (legally) if there were a known
    Joe> API through which this chunk of warez were hooked into the
    Joe> application (which is probably the case here).

PLUS "there exists free software which can be accessed by the same
API" is true, then it is OK for the free software to make the function
call.

    Joe> For example, if you had a 100% GPLed browser with an API for
    Joe> plugins. And if I wrote a whiz-bang plugin to do sojme kind
    Joe> of 3D rendering -- but being a major a**, I released it under
    Joe> a proprietary license -- would that have any effect on the
    Joe> browser's "Free" status just because it can call my plugin?

No, because the browser's plugin API was preexisting.

    Joe> I tought it had already been established that GnomeMeeting
    Joe> could work with other codecs and that this one was options,
    Joe> albeit necessary for certain functions.

That much has been established.  _If_ the calling convention for the
proprietary codec is identical to that for the others, you're OK.  If
not, you can't redistribute the product containing code _specific_ to
the proprietary codec without separate permission of the copyright
owner; the GPL does not permit it, because the unavoidable conclusion
(according to all the lawyers I've asked or seen comment on it,
including Larry Lessig and Eben Moglen) is that the "work" in question
includes all code that will be linked in a single address space.

    Joe> However, if it didn't exist you *still* couldn't access those
    Joe> pages so the existance of the non-Free plugin doesn't have
    Joe> any effect on the application itself.

Practically, you're right.  Legally, you're wrong.  It is possible,
depending on how the interface is written, that legally the plugin
will be considered part of the derivative work.  The GPL does not
prohibit users from combining GPL code with proprietary code and
running in any way they see fit, as long as that doesn't somehow
result in distribution to a second party.

However, according to the FSF, if the code is clearly intended to link
specifically to a proprietary code and they will be executed in the
same address space, then _loading the code into the address space
constitutes creation of a derivative work not permitted under the GPL._

    Joe> But other than discouraging developers from writing
    Joe> proprietary stuff in the first place, there is no legal
    Joe> reason not to add support for it into your Free application
    Joe> if the benefit is great enough.

That's simply not true if the original work is under strong Copyleft
such as the GPL.  You have to jump through certain hoops, in
particular, the proprietary code must load into a separate address
space.

    >> ... Ie, just embed a patented algorithm in hardware and you can
    >> distribute a derivative of a strong copyleft program
    >> specialized to that "hardware", emasculating the GPL, no?

    Joe> I don't think that's unique to hardware. Nvidea distributes
    Joe> non-Free drrivers for their video cards, they follow the
    Joe> cconventions for video device drivers, their drivers work
    Joe> well with Linux, but Linux is still Free even though it calls
    Joe> the drivers as soon as it sees an Nvidea card.

What happened is that Linus said "my interpretation of the GPL is that
it's OK to write binary drivers as modules", rms said, "I'm sorry, but
you are not allowed to interpret the GPL that way", and Linus said,
"OK, the kernel is under the GPL, _but_ you may also distribute binary
(proprietary) drivers as modules as long as they use the public module
interface."  Everyone happy.

    Joe> Speaking of which, isn't the hardware of nearly every video
    Joe> card on the market proprietary? What's the difference?

"The ones I know of are" and "none".

Moving proprietary 3d code from (eg) the X drivers into a video card's
firmware has exactly the same effect: what was prohibited for GPL
software to link to is OK to call via the (proprietary) hardware ABI.

    >> Also, suppose Shawn were to spend JPY 1 million to acquire a
    >> commercial license for the algorithm, and wrote a software
    >> driver, which he most generously plans to give away, libre and
    >> gratis.  Guess what?  _He can't._ He has to buy the whole
    >> patent (well, the right to distribute it as free software,
    >> which is effectively the whole patent), or he can't distribute
    >> the driver under GPL.  But if it's hardware, it's OK!

    Joe> No... Even if the algorithm were embedded in the hardware, he
    Joe> still could not distribute the RTL source code from which
    Joe> that hardware chip was fabricated (not under most hardware IP
    Joe> licenses at least).

I didn't mean he could distribute the onboard firmware.

What I meant is that as long as the proprietary part is implemented in
hardware, he can write a driver to its ABI and distribute that,
because the proprietary algorithm executes in a separate address space
in the peripheral hardware.  On the other hand, even if he has a
commercial license for a software implementation, the GPL prevents him
from distributing a derivative of the application that directly calls
the software library; there has to be a free library that implements
the same API.

    Joe> It's like buying a commercial C compiler, you can use the
    Joe> function libraries in your product and distribute the
    Joe> binaries but you cannot re-sell the libraries as such.

The issue is not the commercial compiler's license, it is the GPL.  We
know the proprietary license is going to be restrictive; what's
surprising to most people is how restrictive the GPL is.

To the extent that the compiler's accompanying library implements the
C language (eg, "helper" functions for long long arithmetic on a
platform that doesn't have instructions to do it directly), you may
create a derivative of GPL code that you don't own that must link to
those libraries, and distribute it (including the library if the
compiler license permits).  However, if the library implements
non-standard extensions, you may not use those in your derivative and
redistribute the result under the GPL; you need the permission of the
owner of the GPL'ed work.  The only standard exception is for
operating system facilities, and it has been established (though not
tested in court) that the FSF decides what those are.  (Otherwise
Microsoft could link Emacs to Internet Explorer....)

    Joe> Same thing in hardware and/or software. I think the
    Joe> difference lies in whether you're distributing the source
    Joe> which implements the patented algorithm (ie: the actual IP)
    Joe> or simply using the algorithm in a product and distributing
    Joe> the product. You can buy the rights to one without the
    Joe> other. In fact, most intellectual property licensing works
    Joe> that way.

Of course.  But the language that I contend prohibits redistributing
the derived work is in the GPL, not in the proprietary licenses.  That
language requires distribution of the _entire_ work under the GPL,
which of course can't be satisfied if you are linking to code under a
proprietary license.


-- 
Institute of Policy and Planning Sciences     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.