Re: About GPL and proprietary software - Mailing list pgsql-general

Martijn van Oosterhout wrote:
> > Right, dynamic linking is a case where RMS would like the GPL to spread
> > the the closed-source binary, but I don't think he can legally do that.
> >
> > We do have that issue with our linking in of libreadline.  We may adopt
> > libedit someday for that very reason.
>
> I was under the impression that the GPL only covers distribution, not use
> (as seems normal for copyright). In other words, as long as you don't ship
> readline with PostgreSQL you're fine. If the user wants to install it on
> their machine with readline linked in that's their problem entirely.
>
> Now, I think that people have tried to argue that if a library is the *only*
> implementation of the interface then it should be considered linked in
> because otherwise you're just using dynamic linking to get around the GPL.
>
> But since PostgreSQL doesn't depend on readline (it is optional after all) I
> don't see the issue. However, for the MySQL client library since the
> software strictly depends on that library, the fact that it's distributed as
> a separate tarball does not absolve you of the GPL requirement.
>
> Obviously MySQL wouldn't have done their license this way if they didn't
> think it was enforceable. Maybe they have themselves an exception or
> variation on the GPL? But it's still confusing.

The FSF would _like_ dynamic linking to pass the GPL to the
closed-source binary, but that doesn't make it so --- I would like a lot
of things but wanting it to happen isn't enough.

Their FAQ says (http://www.gnu.org/licenses/gpl-faq.html):

    What is the difference between "mere aggregation" and "combining two
    modules into one program"?

        Mere aggregation of two programs means putting them side by side on
    the same CD-ROM or hard disk. We use this term in the case where they
    are separate programs, not parts of a single program. In this case, if
    one of the programs is covered by the GPL, it has no effect on the other
    program.

        Combining two modules means connecting them together so that they
    form a single larger program. If either part is covered by the GPL, the
    whole combination must also be released under the GPL--if you can't, or
    won't, do that, you may not combine them.

        What constitutes combining two parts into one program? This is a
    legal question, which ultimately judges will decide. We believe that a

    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    proper criterion depends both on the mechanism of communication (exec,
    pipes, rpc, function calls within a shared address space, etc.) and the
    semantics of the communication (what kinds of information are
    interchanged).

You can bet that RMS, control freak that he is, wouldn't have put that
disclaimer in there if he felt he had much chance of making the GPL
dynamic linking restriction enforceable.

A more exotic issue is:  what if you create a libreadline library that
has the same linking signature as GNU readline, but it does nothing.
Can you then say the binary doesn't _require_ GNU readline?  As you can
see, saying something _requires_ something else to run is a very hard
argument to make, and even if the argument can be made, saying that the
function calls themselves force the GPL is a great reach, I think.

It isn't even clear that the GPL is enforceable in saying you can't
modify the source code and ship a closed source version.  But if it is,
reaching from there to say you can't dynamically call a GPL library is
really strange.  How is that different from calling the Linux kernel,
which is GPL?  In fact, most system calls are accessed through a libc
function call.  Of course, GNU libc is LGPL, but it makes calls to a GPL
kernel.  Does the LGPL kernel remove the GPL dynamic linking restriction
to the kernel?  I don't think so.  In fact, I don't think a line can
clearly be drawn, and hence the unenforceable of a the dynamic linking
GPL restriction.

On a (very) side note, there are some things that you grow to like more
and more over time (hopefully PostgreSQL), while there are others you
grow to like less and less over time (GPL, RMS).  The RMS case is
particularly poignant because new folks to open source really seem to
like him, but the longer they are involved in open source, the less they
seem to like him.  I have seen this regularly in my travels.  In fact,
when someone wrote a biography of RMS, the author was most surprised
that he could find so few of his acquaintances who would talk about him.

Another big part of the success of PostgreSQL is that people seem to
like us more and more over time, while proprietary vendors seem to
generate the opposite effect.  :-)

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073