Hi Michael,
On 23.04.2012 21:40, Michael Meeks wrote:
Hi Andre,
On Fri, 2012-04-20 at 10:35 +0800, Andre Fischer wrote:
Thanks Michael for your analysis.
No problem :-) hope it helps.
I dont't think that copying the files is a problem. After all we are
already unzipping the zlib tar ball to a location of our choosing. Why
should copying some of the files to yet another location change
anything ?
Copying these files, obscures the fact that unzip.c and another file (I
forget which) come from contrib/minizip and not the normal, well
understood main zlib source, which people are used to having
well-understood and sane licensing.
No, I don't think so. Everything after typing
build <RETURN>
is an intermediate state that only the compiler, linker, and other tools
are working on. Otherwise you could argue that any temporary file
created by the compiler etc. would obscure the situation.
They are not part of the source package and the binary packages will
contain the resulting zlib library anyway, regardless of the location
of any of its source files. But, of course, I am not a laywer.
Of course ! the resulting zlib binary will contained a compiled version
of zlib/contrib/minizip/unzip.c - as I see it anyhow - not for Linux,
but for Windows and Mac. And naturally neither of us are lawyers :-)
Regarding the license issue:
I agree that the licensing may appear to be confusing because the
LICENSE file referenced in unzip.c is missing.
Quite, the question is, what did that file contain ? and/or where is
it ?
But if you look closely
at the text, it says that the license text is also included in zip.h,
and that file exists and contains the same license text that is also
listed in MiniZip64_info.txt (in the same directory.) That license is
...
This text is contained in main/LICENSE at around line 2017. I see no
problem with this.
It seems highly unclear to me; the contrib code is ( I assume ) dropped
in from a separate project / location. The unzip.c header reads:
Well, there are many possible origins, none of which seem important to
me. I am more interested in the status quo which, as I said before,
does not look like a problem.
https://github.com/madler/zlib/blob/master/contrib/minizip/unzip.c#L16
[snip]
Decryption code comes from crypt.c by Info-ZIP but has been
...
See the accompanying file LICENSE, version 2000-Apr-09 or later
(the contents of which are also included in zip.h) for terms of use.
If, for some reason, all these files are missing, the Info-ZIP license
also may be found at: ftp://ftp.info-zip.org/pub/infozip/license.html
[/snip]
There is no LICENSE file in this directory, nor in the minizip
distribution itself ;-) Interestingly api.c also claims to be api.h, and
there is plenty of scope for obsolete / un-audited statements there.
Presumably this is why it lives in contrib/
As we agree, this is somewhat confusing;
No. I said that it may appear confusing. I also pointed out that the
comments in zip.h explicitly state several fallbacks in case the LICENSE
file is missing.
So, no real confusion and no problem there.
however - given that
confusion, we have a handy link to the infozip license embedded, and the
ftp link (to an HTML page!) still resolves, and produces a page
containing:
"This is version 2009-Jan-02 of the Info-ZIP license."
which seems similar to the versioning of the (now gone) file referred
to in the unzip.c file (right?). There are a number of other conditions
there:
ftp://ftp.info-zip.org/pub/infozip/license.html
My suspicion is that, perhaps, that code was copied from infozip's
package, whose download I just hunted down for you here:
http://sourceforge.net/projects/infozip/develop
Which contains a LICENSE file and a different zip.h reference.
Sadly I don't have more time to dig into this for you guys.
No problem, thanks for your work.
Of course,
with luck it's not an issue; it's certainly a rather convoluted one, and
it's only for some rather unclear / small pieces of unzip.c.
I am confident that we don't need luck :-)
And I don't see any unclear items remaining.
Best regards,
Andre
