Re: Use of GPL'd code with proprietary programs

[telford]

In gnu.misc.discuss Isaac <isaac@latveria.castledoom.org> wrote:

> My theory is that the FSF is forced to use their definition of derivative
> works because without it the provisions of the GPL that prevent exploiting
> code without distributing source code become toothless.  People who want
> to hoard their own code could compile any GPL covered code into a library
> and then call it without being bound by the GPL.

> The typical closed source vendor does not need to do the same thing because
> they maintain control over what users do.  GPL copyright holders have
> disclaimed such limits.

Yes, there is a problem here. The worst thing would be if GPL ended up losing
the protection that was available to other works, thus giving proprietary
developers a one sided bargain where they can take what they like and give
nothing back. In practical terms, if case law did start to give the GPL one
sort of treatment and closed-source licenses another treatment it would at
least give fuel to the political movement because it is the sort of thing
that "ordinary" people would see as unfair.

This is yet another reason for the FSF to push as hard as their proprietary
competitors: the FSF are successfully building up an industry accepted
understanding of what the GPL stands for. This doesn't represent legal
precedent but since all the FSF are asking for is equal treatment, it will
make it more difficult for a court to hand out judgements that don't give
the appearance of being even handed.

>> This is true, but it is still better for the FSF to hold the fear of a
>> potential court case in the air in order to curb GPL misuse.

> It would be even better if the theory used to curb misuse was one
> that was known to be work.

There's a lot of new territory being covered in IT law, the technologists
are always going to be well ahead of the lawyers. Do you know of any
better methods?

I'll also point out that the FSF isn't the only one with this particular
approach to licensing. Consider the Sleepycat license. I'll quote the 
relevant portions for research purposes:

----------------------------------------------------------------------
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.
 * 3. Redistributions in any form must be accompanied by information on
 *    how to obtain complete source code for the DB software and any
 *    accompanying software that uses the DB software.  The source code
 *    must either be included in the distribution or be available for no
 *    more than the cost of distribution plus a nominal fee, and must be
 *    freely redistributable under reasonable conditions.  For an
 *    executable file, complete source code means the source code for all
 *    modules it contains.  It does not include source code for modules or
 *    files that typically accompany the major components of the operating
 *    system on which the executable file runs.
----------------------------------------------------------------------

The relevant clause being "complete source code for the DB software and any
accompanying software that uses the DB software". Unlike the GPL, Sleepycat
state that USAGE is enough to overlap this license with other software.
In many ways, this is even further out on a limb that the FSF is willing
to go but it still has the same basic effect. Despite db4 being a widely
used library, to my knowledge no company with a proprietary product has
been willing to challenge this license and Sleepycat seem to make money on
selling alternative proprietary licenses.

The lack of challenge isn't a precedent but it shows that the idea can
be made to work (for the moment anyhow), probably because no one wants to
take a big risk on making a challenge.

>> I wasn't familiar with Sony vs Connectix. Now I look at it, seems that
>> the battle was mostly faught on patent issues and that Connectix has only
>> achieved a partial victory. Still, it is a good step towards courts realising
>> that IP law should not be allowed to curb product compatibility. Has a 
>> similar
>> case been fought using copyright law?

> I think you need to take a closer look at Sony v. Connectix.  At the
> time of it's appeal to the Ninth circuit there were no patent issues
> being litigated.  Sony was the total and complete loser with respect
> to its copyright and trademark infringement claims.

OK, that's an encouraging sign.

> The main game cases are Sega v. Accolade, Nintendo v. Atari, and
> Sony v. Connectix.   I'd highly recomend looking at the Sega case.

>> Anyhow, I was NOT thinking along the lines of being able to run playstation
>> games on an emulator... I was talking about being able to WRITE your own
>> playstation games and run them on an unchipped playstation. Sony is still

> Maybe that is your interest, but the topic at hand was whether or not
> the court would allow an interpretation of the "based on" that would result 
> in a companies like Sony losing.  I'm not sure why Sony v. Connectix is not
> a good illustration that a Court will find that calling someone else's code
> does not create a derivative work even if that decision hurts Sony.

Generally with cases like the GNU readline library, it is already part of
the target system. The question is whether an application can make full use of
available libraries on the platform. The Connectix emulator case is backwards
because the application is trying to accuse the platform of being unlicensed.
Maybe there is no real legal distinction here, as you say, in either case
two pieces of code are interfacing across an API.

> Sega v. Accolade happens to be a case concerning a vendor manufacturing
> game cartridges for Sega game consoles.  Is that closer to what you are
> interested in? 

Well Sega v. Accolade is closer to the case of proprietary application code
being written for an open source platform and making full use of the available
libraries (such as readline, gdbm and db4). I don't think it likely that anyone
is going to write a proprietary linux-emulator that runs on MS-Windows and
executes GPL applications...

I note that the trademark elements of Sega v. Accolade have minimal relevance
to the FSF or the GPL. I also note that Sega did not try to claim that Accolade
were not entitled call library routines from the Genesis platform, in fact the
court decision seems to presume that the natural case is that Sega have no
legal control over who can use their platform. From my reading, most of the
case content related to locking code that the Genesis platform insists that 
the application contains -- any GPL related case would not have locking code.

>> very successful at controlling the market for the PS2,  they do it by
>> using a boot sequence on the DVD that is encrypted (so you can't write your
>> own). The boot sequence installs a tiny kernel (a bit like VMware) and throws
>> the hardware into a sort of virtual machine mode for the real game to 
>> operate.
>> This means that the programmer never has true access to the machine hardware
>> and it also means that if you want to release your own game you must buy a
>> license from Sony for that boot sequence and VM code or else your program
>> will not run.
>> 
>> Thus, they use copyright law to prevent anyone marketing compatible PS2 games
>> without paying their "Sony tax", in effect they control the entire PS2
>> game development market.

> I suspect that if Sony wants this to work it probably need to invoke the
> DMCA's provisions on anti-circumvention.  This law did not exist at the of
> the cases I cited.  I don't think we can suggest that the FSF's stance is
> motivated by the DMCA without violating causality.

Sony have managed to get mod-chips declared illegal under anti-circumvention
laws. If mod chips were commonplace then they would lose control over their
market because the mod-chip defeats the platform lock. In principle, the Sony
strategy is identical to the Sega strategy in as much as a small chunk of
code must be copied into the application for that application to gain access to
the platform. In many ways, this is also what the FSF are claiming with
the inclusion of symbol tables for library access.

As for causality and the DCMA, it does make sense from the point of view that
the FSF are working from the strategy of claiming the same level of protection
that their competitors claim. Consider the analogy: if I put up a mirror to
your laser beam, it bounces back onto you. Then you come along with an even
bigger laser beam and that also bounces back. My mirror is still a mirror like
it always was but the image visible in the mirror keeps changing.

    - Tel