Mirrors in GPL violation? + Re: MD5s of setup.exe on mirrors.
Tue May 15 01:04:00 GMT 2007
> On 15 May 2007 00:24, Markus E.L. wrote:
>> is concerned with questions of trust and
> That's the underlying source of your error right there: a false assumption.
So Alex has been concerned with different questions? My apologies if I
read him wrong there.
>> (like: cygwin.com lists the mirrors as source of the
>> software, then declines any responsibility for the actual content of
>> those mirrors
> Yep. Welcome to the internet; google 'autonomous system' to find out more.
>> down to "we cannot be bothered with working with the
>> mirror admins even if they (would) carry the wrong software with our
>> name on it"
> Mirrors get automatically tested and delisted if they aren't
> up-to-date. Apparently only non-trivial discrepancies matter.
All not my problem, really. I know, I'd be interested if someone
pretended to carry my software and actually doesn't. Forgive me my
misunderstanding, but since you say, that isn't anyway what Alex has
been writing about, it's all moot anywhere.
>> -- I wouldn't handle it like that, but YMMV
> Which is precisely why you're wasting time here.
>> I now prefer
>> not to touch this subject, having already gotten flamed my ass off
>> this week (so I'm tending the blisters instead) but I think, Alex'
> You are conflating two entirely different issues here. There is
> absolutely no connection between "what copyrights do I have to
> observe if I want to distribute something" and "some mirrors aren't
There is a connection: The limited resources, both in patience and in
time I have. So, as I said. I'm not interested to continue here, I
just want(ed) to clear up your's and Barry's "confusion" that I have
been asking for setup to work differently. Me, I'm just the guy who
noted a difference between the advertised (md5.sum) and th actual
md5sums. No need to oppose me: The sums were really different.
>> Perhaps they can even lead to a wishlist for the next generation of
> Yes, that's a reasonable discussion, particularly if you're
> volunteering to do the work yourself.
> Much less so if you aren't. However, if you do want to help create
Well -- I didn't push the topic of the thread to the topic of setup
features, actually Even Alex didn't (I think, but I'm much too lazy
now to read the whole bloody thread again). With what my pronouncment
that you quoted above I intended to point out that questioning a
current feature set is not always so outrageous as Barry tries to make
As it is, I'm actually interested in extending setup.exe.
That will not be fast in coming, because I haven't groked all of what
setup does at the moment. So no promises, but I'll keep it in the
queue -- somewhere, somehow.
> such a scheme, patches and discussions about setup.exe should be
> sent to the -apps list.
OK. cygwin-apps it is.
>> strong signed checksums are all the rage
> That isn't exactly a technical argument, is it?
No. It's a reference to the fact that other people have technical
arguments I don't want to rehash here. That other projects have (as
Barry would say it) "put a lot of thought into its design and a lot of
work into [the] (its) coding" of their package managers and have come
up with ways not to have trust the mirrors. Since those people are so
competent it might pay to look at their reasons.
I actually wonder what you're taking me for.
(Warning: This is an explanation that has to be read in the context of
trying to explain the semantics of "are all the rage" in a given
context in a technical discussion. It is no, I repeat no, attempt to
actually insinuate now that setup.exe should be changed in any
way. The original quote stems from another attempt to explain the
legitimacy of discussing the absence of features from programs without
intenting to malign or disparage the original authors of aforesaid
software. The attempt had been made by other people than myself and
its legitimacy been drawn in doubt by other people than myself. I was
not happy with that, so felt the need to point out that I don't agree
with the latter. In no way that constitutes an attempt to solicite for
the changes in question -- just to avoid that specific
>> My concern on the other side was only: "What the hell is md5.sum (on
>> the mirrors) then for, if it doesn't contain the right sums".
> As I explained: transmission checksum.
I never questioned that: There was (obviously) a transmission error. I
pointed that out. Got the answer, neither setup.exe nor it's md5sum
matter anyhow. So why post a wrong md5.sum? To give people the
impression they got a transmission error from the mirror to their
machine? If not -- why not fix it? And stop accusing me off whatever
along the way?
> Not security, not authentication,
> nothing else at all.
I did never say that, sigh.
> Your mistake
Your mistake, Dave, is not reading, what _I_ wrote. I'm not Alex.
> and your fault if you think that it's
> something it's not, just because the md5 algorithm is involved. See AC2 for
> more details on the differences between authentification and identification.
Oh man. And off we go again, by assuming other people are complete
fools. Ahem. Please attack me for what I actually write, not for what
>> If I where the cygwin team
> And if my aunt had balls, she'd be my uncle. But she doesn't, and she
> isn't, and any attempt to reason from contrafactuals is broken before it even
> gets off the ground.
Right. Applies to you too: Don't start arguing with me, what I didn't say,
> Plus, TINCT.
>> and felt so strongly
> And if you were part of the "cygwin team" and /didn't/ feel so strongly?
Well about contra-factuals, and so on: Why do you ask hypothetical questions?
But not to leave out a good answer: I would let setup.exe be
mirrored. If there was a transmission error to the mirrors, I'd fix it
(first by touching the file, which Brian did, thankfully, and which
worked, I'm glad). That's it.
But it's all academic anyway, now that setup.exe has been pulled.
>> about nobody ever
>> running setup.exe from the mirrors, I'd probably pull it from the
>> master sites
> Nobody has ever cared before you and nobody is ever likely to care
> again, but you've gotten that done just to shut this everlasting
> thread down.
No, sorry, I haven't gotten that done and certainly not to shut the
thread down: _My thread was all about md5sums (which had been fixed
one and a half day ago). Other people introduced the topic how
setup.exe doesn't belong on the mirrors and shouldn't be used from
there. And it was (I think) Christopher's decision to pull it
(obviously before I ever said it) -- _I_ didn't force anyone to do
>> and consequently the mirrors) and replace it by a README
>> effectively telling the reader to get/run setup.exe from
>> cygwin.com. This would be in concordance with the fact that setup is
>> already organised as a seperate project.
> You imagine structure, organisation and management where there is none. It
> is neither separate, nor the same, nor a "project".
Sorry. It is not a cygwin package withing cygwin itelf. I imagine
nothing: A program that has a page of it's own is what in this context I
like to call a "separate" project. But I don't want to split hairs:
Let's replace that by "is not in the release/ tree anyway". That's
actually what I meant.
>> Interesting enough, setup seems to be GPL (most of the sources carry a
>> GPL header), but the mirrors don't carry the source (since the source
>> is only on http://cygwin.com/setup). Do they violate the GPL then?
> The copyright owner is at liberty to not give a damn.
That's OK with me. The mirrors though, might not.
>> Is there a well known time limit on threads?
> Yep. Everyone knows that when something gets pointless, boring, and
> unproductively repetitious, the limit has already been reached.
> That's just real life, not computers.
So I wonder why you and Barry ever cared to continue the thread. I
certainly was done with it, until I got included in Barry's reply
(which in my eyes completely distorts what has been said before and by
Regards -- Markus
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
More information about the Cygwin