[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netbsd-tech-pkg
Subject:    Re: archivers/szip license
From:       Jason Bacon <outpaddling () yahoo ! com>
Date:       2019-04-20 15:36:19
Message-ID: f52a3038-06fb-058c-16b6-58fbc44f0423 () yahoo ! com
[Download RAW message or body]

On 2019-04-19 09:03, Greg Troxel wrote:
> Jason Bacon<outpaddling@yahoo.com>  writes:
>
> [crossposting pruned]
>
>> I think the license restrictions listed in Makefile are wrong:
>>
>> https://support.hdfgroup.org/doc_resource/SZIP/Commercial_szip.html
>>
>> I don't see anything to indicate that it cannot be redistributed in
>> binary form, only that certain types of commercial use are not allowed
>> without permission.
> That's not how copyright works; failing to find a "restriction" does not
> mean that copying is permitted.  One needs an affirmative license to
> copy.  And binary packages are derived works, so one needs a license to
> create and distribuute those.
>
> The text only grants permission to "use", which is not a right reserved
> to the copyright holder, so that should probably be construed as a
> patent grant.
>
>> Any objections to changing it so we can generate binary packages?
> I don't think we have a license to do so.  You could write them and ask
> them to clarify.   I would expect that in this case, the copyright has a
> fairly high likelihood of being will to grant the license we need for
> source and binary redistribution.
>
Thanks, I have reached out to them and will report if/when they respond.

In the meantime, I found another implementation, libaec, which contains 
the following reference to the patents:

https://github.com/erget/libaec/blob/cmake-install-instructions/doc/patent.txt

This seems to eliminate patent issues for any implementation, although 
the szip software itself may still have its own restrictions.

The libaec implementation has what looks like a 2-clause BSD license.

FreeBSD has both an szip and a libaec package with binary packages, 
Debian has only libaec and the Debian hdf5 package depends on it, rather 
than the original szip implementation.

I'll create wip/libaec shortly.  Perhaps we can leave this issue behind 
by using libaec instead.  If not, I can try to verify whether the 
FreeBSD szip port is really complying with the license terms.
[prev in list] [next in list] [prev in thread] [next in thread]