[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 

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 

> 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: