This is the mail archive of the
mailing list for the Cygwin project.
Re: Packaging software built with Cygwin
- From: Igor Pechtchanski <pechtcha at cs dot nyu dot edu>
- To: Jay Maynard <jmaynard at conmicro dot cx>
- Cc: cygwin at cygwin dot com
- Date: Tue, 4 Feb 2003 21:31:43 -0500 (EST)
- Subject: Re: Packaging software built with Cygwin
- Reply-to: cygwin at cygwin dot com
On Tue, 4 Feb 2003, Jay Maynard wrote:
> On Tue, Feb 04, 2003 at 06:27:39PM -0500, Igor Pechtchanski wrote:
> > You are aware that linking against the Cygwin DLL automatically makes your
> > software GPL'ed, right?
> Not according to http://cygwin.com/licensing.html:
> "In accordance with section 10 of the GPL, Red Hat permits programs whose
> sources are distributed under a license that complies with the Open Source
> Definition to be linked with libcygwin.a without libcygwin.a itself causing
> the resulting program to be covered by the GNU GPL."
> If, despite this, Hercules is somehow covered by the GPL, then our only
> choice will be to stop distributing a Cygwin version of Hercules, in either
> source or binary form, as relicensing Hercules under the GPL will never
Now, hold on there, no need to jump the gun. I'm not what you may call "a
definitive expert on Cygwin licensing". In fact, whatever that page says
surely overrides what I said earlier.
> > And you are also aware that, if you distribute the Cygwin DLL, you have to
> > distribute it with the source used to build it, correct?
I'm pretty sure of this one, but the definitive answer should probably be
given by Chris Faylor...
> If that's the case, then I won't distribute the DLLs. I can't afford to keep
> around multiple versions of the source code corresponding with the multiple
> versions of the DLLs needed for multiple versions of Hercules.
And why is that? Cygwin DLL is supposed to be backward compatible, either
directly or through options. I'd be surprised if any functionality was
actually *missing* from a newer cygwin1.dll that was present in an older
release (except for the stuff that "nobody used" which got taken out -- if
you did use it, you should speak up for including it back in).
> > However, you don't have to maintain multiple versions of the source code -
> > only the source of the cygwin DLL that you distribute. Thus, if you
> > always update the cygwin DLL on your mirror to the latest available one,
> > you can keep only one (the latest) version of the source there.
> Unfortunately, I keep multiple versions of Hercules around. Since each
> version of Hercules is compiled against a different version of Cygwin, that
> means that I need to keep the corresponding DLLs around (since mixing them
> has proven to be problematical), and that means I need to keep the source,
Remember that linking against some version of libcygwin.a doesn't mean you
have to keep to the corresponding version of cygwin1.dll. Since it's
loaded dynamically, all you need is for the functions you need to be
present in the new DLL. This is generally the case.
> > But don't despair. You can do even better than that. You don't have to
> > distribute the cygwin DLL from your mirror *at all*. All you need to do
> > is include the "cygwin" package and the others you need in the "requires"
> > list for your ("hercules"?) package, and instruct the users to select one
> > of the standard mirrors along with yours in the setup mirror list.
> Erf. This assumes that the user will use the Cygwin setup routine to install
> Hercules. So far, there's been no need for that. Hercules is intended as a
> standalone package which can run with only the required DLLs installed, and
> none of the rest of Cygwin. The Hercules distribution is a self-extracting
> .ZIP, self-contained.
Oh. In that case, yes, you'll either need to distribute the cygwin1.dll
yourself (and make the source available somewhere) or have the users
install the required packages via setup. I assumed you were asking about
the latter, hence the answer. The "hercules" package that I was talking
about doesn't actually have to contain anything except the dependences (or
it could contain a post-install script that would install Hercules from a
separately downloaded .ZIP/.EXE or configure an already installed one).
You may also want to take a look at CVS HEAD setup's command-line options
(only in the source in CVS at the moment, sorry).
> > all the packages that it depends upon (i.e., those in its "requires" list)
> > will also be installed. Of course, this will install all of the
> > "standard" "Base" category, but it's not that large, and, chances are,
> > your package depends on most of it anyway. All you'll have to do is make
> > sure that your package works with the latest cygwin1.dll... ;-)
> In general, when cygwin1.dll changes, Hercules breaks.
> > Hope this made sense,
> It did, but I'm not sure there's a lot of help there...
Sorry to hear that. AFAIK, you do have to provide sources for the
cygwin1.dll that you distribute.
|\ _,,,---,,_ email@example.com
ZZZzz /,`.-'`' -. ;-;;,_ firstname.lastname@example.org
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk!
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html