|Summary:||science/szip: add LICENSE|
|Product:||Ports & Packages||Reporter:||Dmitry Marakasov <amdmi3>|
|Component:||Individual Port(s)||Assignee:||Po-Chuan Hsieh <sunpoet>|
|Severity:||Affects Many People||CC:||0mp, jwb, w.schwarzenfeld|
|Bug Depends on:||250165|
Description Dmitry Marakasov 2018-06-04 15:16:27 UTC
Created attachment 193996 [details] Patch - Add LICENSE. Note that due to it's non-commercial and limited nature, *-sell and auto-accepts perms are disabled
Comment 1 Po-Chuan Hsieh 2018-06-04 18:39:02 UTC
It will be ignored by poudriere with "Ignored: License SZIP needs confirmation, but BATCH is defined". Is there any way to avoid this?
Comment 2 Dmitry Marakasov 2018-06-04 19:04:30 UTC
If you mean port testing, `poudrirere testport` doesn't ignore the port and build it fine. If you mean custom package building, you can add the license to the list of accepted licenses. If you mean regular package building, I don't know of any solutions. My guess is that pkg and infrastructure would need to be taught to _produce_ packages which licenses needing confirmation, but to ask a license on package installation.
Comment 3 commit-hook 2018-06-05 19:01:34 UTC
A commit references this bug: Author: sunpoet Date: Tue Jun 5 19:01:08 UTC 2018 New revision: 471800 URL: https://svnweb.freebsd.org/changeset/ports/471800 Log: Add LICENSE PR: 228743 Submitted by: amdmi3 Changes: head/science/szip/Makefile
Comment 4 Po-Chuan Hsieh 2018-06-05 19:02:57 UTC
Comment 5 Dmitry Marakasov 2018-06-06 13:04:00 UTC
Actually this may require additional actions, as it prevents building packages for many dependees. For instance, it may be worth disabling SZIP option in hdf5.
Comment 6 Antoine Brodin 2018-07-22 08:14:32 UTC
Re-open: Please work on making the science/szip dependency optional and default to off in the ports tree before making it no-auto-accept, otherwise around 400 ports, including libreoffice, openoffice, octave, octave-forge-* are skipped.
Comment 7 Walter Schwarzenfeld 2018-10-20 15:46:54 UTC
(In reply to Dmitry Marakasov from comment #5) see PR #232443 comment6 I had recompile szip (and after this hdf5 for opencv) with CONFIGURE_ARGS+= --with-pic after this opencv builds fine (I don't know if this solves your problem).
Comment 8 Jason W. Bacon 2019-05-25 14:13:21 UTC
FYI, szip cannot be redistributed in binary form. The license text is not clear about this, so I confirmed with upstream via email, see below. We should be able to use libaec as a drop-in replacement, though. Debian packages and pkgsrc already use libaec with hdf5. -------- Forwarded Message -------- Subject: RE: szip license question Date: Thu, 25 Apr 2019 14:18:11 -0600 From: Joe Feeley <firstname.lastname@example.org> To: 'Jason Bacon' <email@example.com>, firstname.lastname@example.org, email@example.com CC: firstname.lastname@example.org Hi Jason, No, this application of szip would circumvent our ability to restrict the use of its encryption capability, and we cannot allow it without a proper commercial license. Best regards, Joe Feeley Joseph J. Feeley, Ph.D. Chief Executive Officer ICs, LLC PO Box 2236 2040 Warren Wagon Road McCall, ID 83638 208 315 0029 -----Original Message----- From: Jason Bacon [mailto:email@example.com] Sent: Friday, April 19, 2019 4:42 PM To: firstname.lastname@example.org; email@example.com Subject: szip license question Good afternoon, I am a pkgsrc developer creating many scientific packages for HPC. There is an existing pkgsrc package for szip, but it is marked as "restricted" so that the system will not generate binary packages. This in turn prevents generating binary packages for dependent software (such as kallisto). Looking at the license terms, it is not clear to me whether this is a necessary restriction. The license only discusses commercial use limitations and makes no mention of binary distribution. Is it allowable to create a binary pkgsrc package to that users can install szip without compiling from source? Thank you, Jason
Comment 9 Mateusz Piotrowski 2020-10-04 20:45:16 UTC
Any updates? We should just start switching to libaec, right?
Comment 10 Jason W. Bacon 2020-10-05 16:20:58 UTC
(In reply to Mateusz Piotrowski from comment #9) I see no reason not to use libaec instead.