[Pipet Devel] GPL and linking

J.W. Bizzaro bizzaro at geoserve.net
Mon May 1 13:14:23 EDT 2000

Below is a conversation between Richard Stallman and Bruce Perens about the
GPL and 'linking'.  I think it addresses some of the questions we had, so I
highly recommend reading it.  Jeff


Q: (from Bruce Perens) - I'm concerned that GPL restrictions on derived works
haven't kept up with software technology. 

RMS: I am working on GPL version 3, but this is not something that should be
rushed. I put it aside for most of a year to work on the GNU Free
License, but now I plan to get back to it. 

Bruce: The most pernicious example is CORBA, which lets us create derived
from components that aren't in the same address space at all, yet work
seamlessly as
if they were. I'd rather not see my GPL work end up in somebody's proprietary
program, simply because it's been server-ized to avoid my license

RMS: If people can write non-free software that makes use of free CORBA
components, that is bad in one way: it means that their non-free software can
on our work. But using our free software through CORBA does not make our
programs themselves non-free. So it is not as bad as extending our programs
their non-free code. 

I think it will be hard to claim that a program is covered by our licenses
because it
uses CORBA to communicate with our code. Perhaps in cases of particularly
intimate coupling we could convince a court of that view, but in general I
think we
could not. 

Bruce: A more common problem is dynamic libraries that are distributed
from the executable. You say that a court would hold those to be devices
used to circumvent the license restrictions, but that's rather chancy, and no
substitute for explicit language regarding what is, and what isn't, considered
derived work in the GPL. 

RMS: We have no say in what is considered a derivative work. That is a matter
copyright law, decided by courts. When copyright law holds that a certain
thing is
not a derivative of our work, then our license for that work does not apply to
Whatever our licenses say, they are operative only for works that are
derivative of
our code. 

A license can say that we will treat a certain kind of work as if it were not
derivative, even if the courts think it is. The Lesser GPL does this in
certain cases,
in effect declining to use some of the power that the courts would give us.
But we
cannot tell the courts to treat a certain kind of work as if it were
derivative, if the
courts think it is not. 

I think we have a pretty good argument that nontrivial dynamic linking creates
combined (i.e. derivative) work. I have an idea for how to change the GPL to
it clearer and more certain, but I need to see if we can work out the details
in a way
that our lawyer believes will really work. 

Bruce: There's also the problem of Application Service Providers, who make a
available for people to use without distributing it, and thus would be under
obligation to make the source code of their modifications available. Do I have
to see
my GPL work abused that way as well? 

RMS: I too feel these servers are not playing fair with our community, but
problem is very hard to solve. It is hard for a copyright-based license to
make a
requirement for these servers that will really stick. The difficulty is that
servers are not distributing the program, just running it. So it is hard to
make any
conditions under copyright that affect what they can do. 

I had an idea recently for an indirect method that might perhaps work. I'd
rather not
talk about it until our lawyer figures out better whether it can really do the



                      |           J.W. Bizzaro           |
                      |                                  |
                      | http://bioinformatics.org/~jeff/ |
                      |                                  |
                      |        BIOINFORMATICS.ORG        |
                      |           The Open Lab           |
                      |                                  |
                      |    http://bioinformatics.org/    |

More information about the Pipet-Devel mailing list