incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andre Fischer>
Subject Re: OOo / zlib license oddness ...
Date Tue, 24 Apr 2012 01:50:16 GMT
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.

> [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:
> [/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:
> 	My suspicion is that, perhaps, that code was copied from infozip's
> package, whose download I just hunted down for you here:
> 	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,

View raw message