Mail Archives: cygwin/2001/08/27/16:03:56
> -----Original Message-----
> From: Christopher Faylor [mailto:cgf AT redhat DOT com]
> Sent: Monday, August 27, 2001 8:37 PM
> To: cygwin AT cygwin DOT com
> Subject: Re: On Cygwin package naming and a setup.exe bug
>
>
> On Mon, Aug 27, 2001 at 08:01:59PM +0200, Bernard Dautrevaux wrote:
> >> -----Original Message-----
> >> From: Christopher Faylor [mailto:cgf AT redhat DOT com]
> >> Sent: Monday, August 27, 2001 7:39 PM
> >> To: cygwin AT cygwin DOT com
> >> Subject: Re: On Cygwin package naming and a setup.exe bug
>
> >> Who made the offer to continue to include the sources to
> whatever is
> >> being distributed? Not me. I don't want to have to track the PRC
> >> project and make sure that I don't delete, say, the Cygwin 1.3.2
> >> sources because they are still using them.
> >
> >I think there'(s a bit of misunderstanding here: What john
> says was that it
> >was distributing:
> > several binary distributions of PRC-tools (as cygwin tarballs
> > and RPMs) source distribution of PRC-tools (as a
> source tarball)
> >
> >He thus complies with the GPL.
>
> Unless you have downloaded everything and inspected it, you
> can't make a
> statement like that.
Just a question of terminology: for me a binary distribution *for* Cygwin of
some package expects to be installed on a running Cygwin installation (or do
you expect a binary linux application package to contain a glibc binary
distribution?).
I would have understood your worries about complying with the GPL wrt Cygwin
if it says he were distributing a standalone Windows version of PRC-tools
that use Cygwin. But in this case it would probably have packaged it with
some Windows package manager, not Cygwin's one; at least that the way I
would have worked: if I don't want my user to see cygwin, I don't use the
cygwin installer. If I use it, that's because I expect to find it already on
the system.
However I must admit that, having read the original posting again, it does
not positively says what is in the binary PRC-tools cygwin package; we just
understand the term differently it seems.
>
> >Note that he explicitely says he was NOT distributing
> Cygwin, just provide a
> >proper setup.ini so that the setup.exe used to install
> Cygwin from the
> >official cygwin web site (or any other source AFAAIC).
>
> John did not use the word DLL anywhere. So, I assume that it
> is possible
> that he is including the DLL. He mentions a "Cygwin binary
> package". I
> don't know what is in this package. I just offered an advisory note.
>
> I'm not actively downloading the packages and inspecting them for GPL
> violations so that I can call FSF/Red Hat lawyers. I'm just offering
> my usual caveat about this because people get it wrong all of
> the time.
> They make the same assumptions that are being made in this thread and
> get hot and bothered about things that are really cut and dry.
>
> >I don't see where there would be ANY GPL concern with this
> (although, as
> >usual, IANAL).
>
> And as far as I can tell, you don't even have in-depth knowledge about
> what is being offered.
OK, that's sure; I don't scrutinize the PRC-tools binary package (I don't
even know if it's available online fro now). I just try to read and
understand a message but obviously do not understand the same as you. Of
course ANY binary package expected to run under Windows (and especially if
it runs also under Unix) could be the target of a warning about the need to
comply with the GPL if it includes some Cygwin stuff.
However, I think that someone that build open source code could be expected
to know what it does. Note that what you said in your first posting (and
that was the very beginning of your text) was:
* And a cygwin source package, hopefully, if you want to be in compliance
* with the GPL. If you are providing cygwin1.dll, you must provide sources
* for cygwin1.dll. If you are providing any other binaries that use
cygwin1.dll
* you most provide sources for them, also.
What I've think a bit rude is jumping immediately to what can be read as a
reprimand: you do not ask if it includes cygwin code, you say first it
should include cygwin sources, then explain it in a way that, by the
negative, explains that it may be OK if it does not provides cygwin1.dll or
any other cygin-using binary.
>
> >> >You shouldn't give John a hard time; the PRC-Tools
> project is a free
> >> >software project in much the same spirit as Cygwin. In
> fact, the two
> >> >projects are very similar: a GCC port to a non-Unix
> >> platform, for making
> >> >binaries native to that platform.
> >>
> >> "Why are you giving me a hard time! I'm a free software
> >> project!". Yes,
> >> we hear this from time to time. The GPL is a legal
> binding document.
> >> If you want to use it, you should be in compliance with
> it. You don't
> >> get to ignore it because you consider yourself "one of the
> good guys".
> >> It would be nice if life worked that way, but it doesn't.
> >
> >IMHO John is perfectly complying with the GPL. What I would
> say is, rather
> >than "don't be ruide with me, I'm a free project programmer"
> would be "Don't
> >start thinking I will not comply with the GPL for your
> product; I'm already
> >complying for mine, so check before ranting :-)"
>
> I was not ranting. I stated a fact. I did not do it rudely.
Unfortunately that was not a statement of fact; that was interpretation of
what he says looking at what can be incorrect. I agree there can always be
incorrect uses of GPLed code. The problem is trying to judge how probable is
the violation. Reading his whole message leave me with the impression that
such a probability was quite low, and that's why I reacted after several
message discussing in which way John could be in violation with the GPL.
Note that in fact I completely agree with your position in this part of the
discussion: if there is ANY piece of GPLed code in an on-line binary
distribution, there MUST be an accompanying source code distribution on-line
on the same server; other ways to comply with the GPL are too much arguable
(note the on-line qualifiers above).
> If you or
> anyone took a statement of fact as rudeness then you have
> reading skills
> problems.
That may be the case as it's a bit late to be still at work here :-)
> There may be a mailing list that will deal with this but
> this is not it.
>
> (In case you are wondering *that* was a rude comment. You
> might want to
> compare and contrast to see if you can see the difference)
I think I may deserve it as I may have been a bit rude myself. In fact I was
merely annoyed to see a problem that was interesting masked by YAGPLD (yet
another GPL discussion) and may have react a bit quickly.
>
> >> >> Not surprising since this isn't a goal for setup.exe.
> >> It's really only
> >> >> intended to install cygwin packages.
> >> >
> >> >What makes PRC-Tools "not a Cygwin package" and, say,
> tcltk "a Cygwin
> >> >package"? Both are programming language systems that
> live within the
> >> >Cygwin environment.
> >>
> >> The PRC-Tools are not distributed from the cygwin web
> site. They are
> >> not an official cygwin package. Do I really have to explain this?
> >
> >So, setup.exe is *restricted* to install *official* cygwin
> packages? a bit
> >too harsh I think.
>
> Wow. Density prevails. (more rudeness)
>
> HANDLING OTHER DISTRIBUTIONS IS NOT A GOAL OF THE CYGWIN
> SETUP UTILITY.
>
> Did you happen to read the part where I said "I"d have to get a ruling
> from the other developers..."?
>
> I also suggested a couple of ways to work around this without
> modifying
> setup.exe. I assume that you missed those, too.
>
> >>It apparently isn't clear to you that "Cygwin's own
> installation tools"
> >>were meant to install, um, the cygwin packages from the
> cygwin web site
> >>and mirrors. They don't have accomodations for using other
> web sites
> >>or being bundled as part of a larger package. That is what I was
> >>saying above.
> >
> >Was that a "for now and ever" position, and are then patches to allow
> >to install "unofficial" cygwin packages with setup.exe forcibly
> >refused?
>
> You've really lost a lot of state from my original message and are
> assigning positions to me that I never took. I said I had "mixed
> feelings", which is certainly my right. I said that it would
> require "a
> ruling" from other developers. This would indicate that I was willing
> to support other distributions.
What I've understood was that you needed rulings from other developpers to
see if such a patch could break something. Perfectly sensible.
You say then you have mixed feelings about modifying setup.exe to support
installation of other packages or making it a general purpose installation
tool.
>
> Any change to setup.exe entails some support overhead. Adding the
> proposed patch may also not be the right way to handle this.
Sure; I never said the opposite. What I was angry about is that then nobody
else talk of the proposal.
> The other
> developers may not want to worry about non-core-cygwin releases. I
> can't believe that I have to keep explaining this.
>
> >I personally would have think of setup.exe as *the* tool to
> manage a cygwin
> >installation, like rpm is *the* tool to manage a Red Hat
> linux install or
> >addpkg is *the* tool to manage a Solaris (or is it an HPux)
> system. That,
> >for me, has meant that i should try to provide my own
> packages in a form
> >suitable for installation/uninstallation by setup.exe.
>
> You can think whatever you want. Since I was the person who got the
> setup.exe program started and have remained an active
> contributor to it
> I think I know what was intended.
Yes, but a lot of packages were successfull just because they were usable in
unexpected (and often unintended) ways... I was not arguing about what was
intended, but about how people may usefully use it.
>
> I am 100% certain that we are not thinking about third-party
> installation
> problems in any of our discussions about setup.exe. What
> that means is
> that it will probably take some discussion before anything like John's
> patch is accepted.
Fine; I was just interested by *this* discussion. In fact if I read the
thread it was due to the subject line and the content of the original
posting (which has nothing to do with the GPL).
>
> >If I'm wrong, I will then try to use RPM or some other fancy
> installer and
> >have to tinker it to be able to pick cygwin configuration
> data so that I
> >install my package in a sensible way, with sensible
> defaults, in an exsiting
> >cygwin install... Phew, do I really need to do that? ;-(
>
> This is an open source project. You can take setup.exe sources and do
> whatever you like with them as long as you adhere to the GPL.
>
> If you want to start a discussion going on how setup.exe can support
> third-party apps, feel free. No one is going to stop you. The flip
> side is that if people are uninterested in this aspect of
> setup.exe, no
> one is going to help you much either.
What I understood in John's post was just trying to open this discussion.
But then the rest of the thread was discussing whether he was perhaps
violating the GPL...
>
> Let me just summarize (again can't believe that I have to):
>
> 1) I'm not mad at John for daring to suggest a change to setup.exe.
I never said that; I said that I would have expected a discussion about the
pros and cons of its proposal, not a "mixed feeling" and "it was not
intended for this use"; these are a bit too vague.
I agree 100% that modifying setup.exe should be done with caution; 4m too
much aware of the complexities of an install manager. But just due to that I
would like to be able to use setup.exe to install "foreign" packages running
under cygwin.
>
> 2) I don't know if there are GPL issues in the PRC-Tools
> release. I was
> just raising the possibility because people are so often
> confused about
> the subject.
I was just willing to argue that, although there may be, it seems to me that
the probability is quite low and deserve probably a more interogative
"statement".
>
> 3) I accepted the bug fix that John suggested.
Sure; I notice it upfront and never said the opposite.
>
> 4) Third-party package setup.exe handling has not been a goal
> for setup.exe.
> A patch which adds something for dealing with third-party
> use does not
> get blindly accepted. It gets discussed.
I was only asking for that: discussing it.
Bernard
--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel: +33 (0) 1 47 68 80 80
Fax: +33 (0) 1 47 88 97 85
e-mail: dautrevaux AT microprocess DOT com
b DOT dautrevaux AT usa DOT net
--------------------------------------------
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -