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
It will be ignored by poudriere with "Ignored: License SZIP needs confirmation, but BATCH is defined". Is there any way to avoid this?
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.
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
Committed. Thanks!
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.
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.
(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).
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 <joe.feeley@frontiernet.net> To: 'Jason Bacon' <bacon4000@gmail.com>, ics@ics-rhbd.com, help@hdfgroup.org CC: lowell@lowellmiles.net 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:bacon4000@gmail.com] Sent: Friday, April 19, 2019 4:42 PM To: ics@ics-rhbd.com; help@hdfgroup.org 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
Any updates? We should just start switching to libaec, right?
(In reply to Mateusz Piotrowski from comment #9) I see no reason not to use libaec instead.
(In reply to Mateusz Piotrowski from comment #9) I've submitted a PR to replace science/szip with science/libaec.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=328ae4074233a5b85e0e38efece1af5dcc218160 commit 328ae4074233a5b85e0e38efece1af5dcc218160 Author: Po-Chuan Hsieh <sunpoet@FreeBSD.org> AuthorDate: 2022-06-16 15:06:54 +0000 Commit: Po-Chuan Hsieh <sunpoet@FreeBSD.org> CommitDate: 2022-06-16 15:13:01 +0000 */*: Replace science/szip with science/libaec - Bump PORTREVISION of dependent ports for dependency change szip does not allow redistribution in binary form without proper commercial license. Its LICENSE_PERMS should be set to no-auto-accept which blocks building this port, therefore building dependent ports are also blocked. Switch all dependent ports to science/libaec to avoid conflicts and license issue. PR: 228743, 246097, 250165 astro/oskar/Makefile | 3 ++- audio/csound/Makefile | 4 ++-- biology/kallisto/Makefile | 3 ++- cad/appcsxcad/Makefile | 3 ++- cad/csxcad/Makefile | 4 ++-- cad/gmsh/Makefile | 3 ++- graphics/alembic/Makefile | 3 ++- graphics/qgis-ltr/Makefile | 3 ++- graphics/qgis/Makefile | 3 ++- graphics/vigra/Makefile | 4 ++-- graphics/vv/Makefile | 4 ++-- math/ambit/Makefile | 3 ++- math/armadillo/Makefile | 3 ++- math/flann/Makefile | 3 ++- math/freefem++/Makefile | 3 ++- math/labplot/Makefile | 4 ++-- math/mathgl/Makefile | 4 ++-- math/mdal/Makefile | 3 ++- math/openturns/Makefile | 4 ++-- math/pdal/Makefile | 4 ++-- math/saga/Makefile | 3 ++- misc/adios2/Makefile | 3 ++- science/ALPSCore/Makefile | 4 ++-- science/InsightToolkit/Makefile | 4 ++-- science/abinit/Makefile | 4 ++-- science/ascent/Makefile | 3 ++- science/avogadrolibs/Makefile | 3 ++- science/axom/Makefile | 3 ++- science/cdo/Makefile | 3 ++- science/cgnslib/Makefile | 4 +++- science/cgribex/Makefile | 4 ++-- science/chemps2/Makefile | 3 ++- science/chrono/Makefile | 4 ++-- science/conduit/Makefile | 3 ++- science/dakota/Makefile | 4 ++-- science/dynare/Makefile | 3 ++- science/erkale/Makefile | 3 ++- science/gnudatalanguage/Makefile | 4 ++-- science/hdf/Makefile | 3 ++- science/hdf5-18/Makefile | 4 ++-- science/hdf5/Makefile | 3 ++- science/helfem/Makefile | 4 ++-- science/lammps/Makefile | 3 ++- science/netcdf/Makefile | 3 ++- science/openems/Makefile | 4 ++-- science/openmc/Makefile | 3 ++- science/openmolcas/Makefile | 3 ++- science/py-PyNE/Makefile | 4 ++-- science/qmcpack/Makefile | 4 ++-- science/rmf/Makefile | 4 ++-- science/votca/Makefile | 4 ++-- sysutils/slurm-wlm/Makefile | 3 ++- 52 files changed, 105 insertions(+), 74 deletions(-)