[Pipet Devel] GPL and linking

J.W. Bizzaro bizzaro at geoserve.net
Mon May 1 13:22:34 EDT 2000

*sigh*  I just knew the formatting would be screwy.  This should be easier to


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
Documentation License, but now I plan to get back to it. 

Bruce: The most pernicious example is CORBA, which lets us create derived
works 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 restrictions. 

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
build 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 with 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
separately from the executable. You say that a court would hold those to be
devices explicitly 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 a derived work in the GPL. 

RMS: We have no say in what is considered a derivative work. That is a matter
of 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 it. 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
a combined (i.e. derivative) work. I have an idea for how to change the GPL to
make 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
work available for people to use without distributing it, and thus would be
under no 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
this 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 they 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 job. 



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

More information about the Pipet-Devel mailing list