Re: cygwin.dll license (was Re: FreeQt ?)
>
> On 2 Jun 1997, Mark Eichin wrote:
>
> > For some more perspective on the "interface" argument, go back and see
> > some of the flaming a year or two ago about the GNU "libmp" (multiple
> > precision integer math library.) See also the discussion of just a
> > week or three ago about a company shipping a commercial package that
> > uses GNU RCS underneath -- but since GNU RCS is built as a DLL (and
> > they ship sources for those changes, and gnu rcs itself) they don't
> > have to ship the program sources (and have allegedly run this past
> > the FSF for confirmation that it was OK....) Recall that RCS is
> > GPLed, not LGPLed.
>
> Hm, that's very interesting. Someone I was talking with a time back used
> the example 'Putting GZIP in a dll and then linking to it still makes your
> code GPL'. But if the FSF says that it is okay to do that then it is okay
> to do that ;>
I'm not familiar with the RCS debate, but I was reading
gnu.misc.discuss during the libmp situation. Based on that debate, I
can see why rcs.dll might be allowed, but gzip.dll might not.
The issue in the libmp was a package containing a midified RSAREF that
could be linked to libmp. Libmp is aparantly faster than the standard
multiprecision library available. Libmp also has a slightly different
interface, so it isn't a simple drop-in replacement for the standard
library (as glibc or libc5 (theoretically) is). The FSF contended that
the resulting modified package (which was not distributed with binaries
or source for libmp) must be GPLed, since the -product-, namely the
executable binaries, must contain GPLed code (the libmp library), so
must be GPLed. The source is merely the preferred distribution method
for the product. In this case, the product was being distributed in
two pieces. The justification for this position was that libmp had a
unique interface. Any program written to use that interface had no
choice but to use libmp, and thus the resulting binary was derived from
libmp. In this particular case, the program was thus subjected to both
the GPL -and- the license on RSAREF, which are incompatable licenses.
The FSF objected to the distribution of the modified package -at all-,
since it would be impossible to fulfill the requirements of both
licenses.
That particular package is now distributed with a simple
libmp-compatable non-GPLed multiprecision integer package (thus
avoiding the unique interface issue, since now there are two libraries
with the same documented interface), and instructions to link it with
the FSF libmp, because it is a much better library. RMS agreed that
this would solve the problem.
Applying that to rcs.dll, it seems to me that as long as the dll
doesn't rely on any GNU-specific RCS feature, then it would be
providing a non-unique, standard interface. Two dll's could exist --
one based on GNU rcs, and the other that makes the appropriate system()
calls (or whatever the Windows equivilant is) to do the job. If the
latter is in fact what the dll does, requiring separate installation of
an appropriate RCS package, then it obviously doesn't have the same
encumberance problems as the libmp did.
However, the unique interface issue does exist with regard to gzip,
since that is purely a GPLed product. I think a libgzip or a gzip.dll
would run into the same issues as the libdb did.
> I really must admit I find the GPL very cryptic, it's hard to say exactly
> what it means if you look at very small detail. I do think that it makes
> sense however that you should be able to put RCS in a dll and link to the
> dll. The debate around that is all based on the question of what is a
> derived work. One could even argue executing gzip in a pipeline makes
> other elements in the pipeline 'derived' somehow from gzip. The GPL just
> doesn't make that perfectly clear!
There are a lot of unclear issues, unfortunately. I think that there
are at least 4 different issues here: 1) what the FSF and RMS want, 2)
what their lawyers think they can get away with using the license, 3)
reasonable lay interpretations of the license, and 4) judicial
interpretation of the license. The second point implies subterfuge on
the part of the lawyers or RMS. I don't think so. I think RMS has
made it perfectly clear what he wants: a complete overhaul of the
intellectual property system with regards to software in the vain hope
of returning to the free and open early days of the labs at MIT. But
his lawyers must work -within- the existing IP system to subvert it.
They believe (and are staking their professional reputation on it) that
the GPL represents the closest approximation of RMS's desires (of a
complete subversion of IP law) within the framework of existing law.
It is always tricky to subvert a structure from within, and that is why
the GPL is so tricky to interpret.
However, it is item 4) that is the key, and the GPL has (to my
knowledge) never been tested in court.
Perhaps it is time for a GPL version 3? But would it/could it be any
clearer?
>
> Jason
>
--
Buddha Buck bmbuck@acsu.buffalo.edu
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: