Re: GPL question

[David Kastrup]

richard@cogsci.ed.ac.uk (Richard Tobin) writes:

> In article <85fy5w2y70.fsf@lola.goethe.zz>, David Kastrup  <dak@gnu.org> 
> wrote:
>>So you say: "Big deal, I won't link it then.  The customer has to do
>>it".  Now if the only conceivable use of the software _is_ to link it
>>to a free version of the software, the linking is an integral part of
>>the whole activity, and the customer does the linking _on_ _behalf_ of
>>the software producer, in order to complete the deal.  Since the
>>customer is acting on behalf of the producer, it does not actually
>>matter that the producer does not himself do the assembly: he is still
>>responsible for it.
>
> The case I am thinking of did indeed involve readline.  The program
> was (IIRC) distributed as source but not under the GPL (probably
> under a non-commercial or educational licence), and the author added
> an optional readline interface.

If the interface is optional, it sounds like there is code in it which
_only_ serves the purpose of interfacing to readline and does not make
any sense otherwise.  In that case, it is hard to claim that the whole
kaboodle was not intended to be linked with readline.

> It seems far from clear that what was distributed constituted a
> derivative work - has there been a test case?  It seems quite
> plausible that it's the customer who creates the derivative work
> when he builds the system with readline.  Otherwise, surely any
> program written to use a Windows-specific API would be a derivative
> work of Windows.
>
> Is Aquamacs a derivative work of MacOS X?  As far as I know, there is
> no alternative implementation of Apple's user interface libraries.
>
> This theory would also mean that whether something is a derivative
> work can be changed by the actions of an independent third party.

No.  It means that when the derivative is _created_ (and the binary
in-memory image _is_ a derivative of the parts loaded into it) by a
_dependent_ third party, some of the responsibility for that act might
still lie with the distributor.

The source code is _not_ a derivative work when written to an API.  In
a similar vein, distributing "buy your own bomb" kits will make the
distributor liable for some of the consequences, even if the kits are
completely harmless before you fill in powdered sugar acquired
elsewhere.  The _intended_ and _documented_ use comes into play here.

Even if you can perfectly well use your bomb kit to, say, fertilize
your back yard, and assemble a small set of firecrackers for New
Year's eve.

If there is no documentation about how to use readline, and just some
stubs happen to be organized in the same way, responsibility is much
less clearcut.

For one interesting case about this fine line of intent, there was a
game called something like "Grand Andreas auto theft" or something
where the game play included sexual acts and stuff, but this stuff was
_disabled_.  Included, but disabled.  A simple patch allowed to enable
it.  Even though the producer actually never handed out any such
instructions, some people found out and the patch circulated.

In the end, the producer actually was fined and punished for
distributing stuff that had the _potential_ to infringe Puritan morals
and the customer's involvement in the act of creating such an
infringing piece of software more or less consisted in _unlocking_ it.

While I consider this particular ruling rather absurd, it at least
illustrates the kinds of thing that may actually fly in court and/or
regulative committees.

A somewhat more interesting example would be, say, export controls on
computer hardware concerning clock speeds and memory size.  What will
be sanctioned as non-sufficient compliance?

a) setting the BIOS parameters to values that make the system
underperform
b) the same, and adding a simple password
c) the same, and adding a password considered secure
d) creating solder bridges that throttle the performance
e) disabling half of the memory (but not removing it) with a solder
bridge or BIOS setting

and so on.  When is the excuse "I could not have anticipated the
customer doing this&that" valid?

It will depend on the court whether they will agree that your hands
are clean from the final assembly step, in this case the act of
creating a binary image interacting with the readline library.

Since it will depend on the court, I doubt that you will find the FSF
sue for a violation of the readline GPL as long as the terms _not_
concerned with derivatives are heeded.  It is not like the FSF has
much of a track record of suing, anyway, since they prefer bringing
people into compliance by convincing them, and have quite good results
doing that.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum