Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <4F9606D8.4000905@a-w-f.de>
Date: Tue, 24 Apr 2012 09:50:16 +0800
From: Andre Fischer <af@a-w-f.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: ooo-dev@incubator.apache.org
Subject: Re: OOo / zlib license oddness ...
References: <1334852072.19712.29.camel@linux-yjtf.site>
  <4F90CB74.7010306@a-w-f.de> <1335188452.19712.161.camel@linux-yjtf.site>
In-Reply-To: <1335188452.19712.161.camel@linux-yjtf.site>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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