Compiling on Windows, and a question of policy

Paul Wright paul.wright@pobox.com
Tue Dec 3 13:19:39 UTC 2002


On Mon, 2 Dec 2002, Vernon Schryver wrote:
> There are some maintenance issues.  Because Cygwin is entangled with
> the GPL, I dare have little to do with it, lest the FSF make claims
> on the DCC.  That probably forecloses the obvious possibility of my
> including a Cygwin version of dccproc with the DCC source.

The licence issue with Cygwin is that by linking against Cygwin's
GPL'd DLL, the requirements of the GPL apply to the resultant binary,
i.e. the source for the entire binary cannot be licensed under a more
restrictive licence than the GPL itself (so one cannot produce a closed
source application linked against the Cygwin library, for example).
Since your licence is not more restrictive and you provide source I
don't think there's a problem. 

I see from <http://cygwin.com/faq/faq_8.html#SEC134> that there's a
further allowance from Cygwin themselves for open source projects: if
you statically (rather than dynamically) link against the Cygwin library,
and your app is already Open Source according to the Open Source
Definition (which includes your licence), you can basically ignore the
fact that cygwin is there.

There's also the mingw32 toolkit, which is not encumbered in the same
way as Cygwin, however, I'm not certain that the Unix emulation is good
enough to build dccproc. I'll give it a go later.

> Perhaps you could talk James Farmer into tracking DCC changes.
> 
> Note that the DCC client code must be able change to deal with
> efforts by spammers to evade the checksums.

The client will be using the same code as dccproc under Unix, so a new
release of dccproc would just require me to recompile. To get that into
the hands of existing users, it'd be nice to have some sort of
auto-update mechanism. Spampal has one for the main program, so perhaps
it could be exposed to plugin authors.

> >                I've not looked at the equivalent of pipes under Windows
> > yet, which is what it'd take to meet the Cygwin GPL).
> 
> What do you mean?  If it's relevant, as long as I'm involved, DCC
> source is unlikely to have a GPL instead of BSD style license.

The problem is that Spampal is closed source and plugins are DLLs. The
problems of plugins have been the subject of long discussions on
gnu.misc.discuss, according to Google. It is possible to read the GPL as
requiring that GPL'd code for plugins would somehow require Spampal to
be GPL'd, since it links against the plugin. That can't hurt Spampal, I
think, because nothing I do can legally compel James Farmer to open his
own work, but if I use someone else's GPL'd code (such as the Cygwin
stuff) in a plugin, it's possible they might come after me. 

However, talking to a GPL'd excutable via a pipe is always OK. So what I'd
do is write a plugin DLL which opened a pipe to dccproc. There are then
two binaries, dccproc subject to the GPL (because of Cygwin, not because
of your licence) and the plugin not. Only the one which is not subject
is linked to Spampal. Everyone's happy.

There's also the open source escape clause for statically linked Cygwin,
above, which might mean I could produce a BSD licensed plugin using the
dccproc code and Cygwin all in one binary, although I'd plan to ask
first before assuming that was OK in this case.

It's a shame that I seem to have to spend more time thinking about
licences then writing code. :-(

-- 
Paul Wright | http://pobox.com/~pw201 |




More information about the DCC mailing list

Contact vjs@rhyolite.com by mail or use the form.