RE: Roaring Penguin's view

On 12 Jun 2002, Martin Wilck wrote:

> The FSF if pretty clear about its viewpoint: Linking (static or shared)
> forms a derived product, communication through IPC mechanisms doesn't.
> The FSF itself states that that's eventually up to a judge to decide.

The boundary isn't that clear, even in the FSF's interpretation.  Writing 
an application to an API that's unique to GPL'd code is a "derived work" in 
their minds.  So is using separate programs and interposing IPC mechanisms, 
if they believe you're doing it for the purpose of circumventing the GPL.

And when you move from simpler forms of cooperating code, like linking to a 
library, to more complex forms like COM objects and Web Services, the line 
gets quite fuzzy indeed.

In general, if in doubt, the FSF will try to claim it's a derived work.  
They know that only a court will be able to decide that, ultimately, but 
the more they can get away with by threatening lawsuits without going to 
court, the more effect their interpretation has for what constitutes a 
"derived work".

Ultimately, it's a matter of copyright law, and not up to the FSF to decide 
what constitutes "derivation", but their approach is to err on the side of 
claiming too much rather than give up ground unnecessarily.  They'd happily 
coerce non-derived code into using the GPL if they could, but they know 
that only derived code has a strong basis in copright law for enforcement.

> In this respect, the GPL is indeed more restrictive than some commercial
> licenses (Microsoft grants you to link with their core DLLs - is that
> true for _all_ DLLs?)

Not necessarily, but it's pretty common for libraries to be licensed in 
such a way that binaries can be linked together and distributed on a 
royalty-free basis.  That's just industry custom, driven by market demand.  
There are certainly cases where some libraries demand a royalty for every 
copy distributed.  It's just that developers tend to prefer royalty-free 
code when possible, so that's the norm.

> Thus, if glibc became LGPL, you could still develop a GPL'd wrapper app 
> that would communicate with your non-free program through e.g. a socket,
> transferring the library calls to glibc, just like wineserver is
> currently doing it for wine (though not for licensing reasons).
> Actually, I am pretty certain that such a wrapper would be among the
> first things created if glibc became GPL, probably by community members
> who'd disagree with that move.

Unlikely.  It's far more likely that someone (or many) would simply 
maintain the LGPL branch indefinitely and never use the GPL version.

Deven