https://bugzilla.redhat.com/show_bug.cgi?id=1885430 --- Comment #5 from Carl George 🤠 <carl@xxxxxxxxxx> --- > I uploaded the new spec at the same location. The review tool doesn't work with that link. It requires the spec URL to return raw text. It also requires the current SRPM. Please upload the latest spec file and SRPM somewhere online, and make a new comment that follows the initial template. Spec URL: <spec info here> SRPM URL: <srpm info here> > The license of the project is BSD. The library that we are packaging uses (1) some Intel code that is BSD-3-Clause, (2) some Intel code which is dual license (BSD-3-Clause OR GPL-2.0-only) and (3) portions of OpenSSL. > The sample codes, which are not included in this RPM but are built by default, use Intel code which is dual lincese (BSD-3-Clause OR GPL-2.0-only). These link against both OpenSSL and Zlib. > Should the License field stay as BSD or reflect the internal components? > Regarding the INSTALL file in [2], it is not correct. In this project we don't have code that is only GPLv2. We will be updating this file in the next release of the library. The license field must reflect ALL of the licenses of the distributed software, including anything regarded as "internal". Libraries that are dynamically linked do not need to be referenced. Libraries that are bundled should be removed in favor of dynamically linking against the system copies. If this is not possible, the license field must also reference the license of those bundled libraries. There must also be special provides directives for the bundled libraries. Reference the guidelines [0] on how to handle bundled libraries correctly. Based on what you are describing, if you can debundled the OpenSSL parts, I think the correct license text should be: License: BSD and (BSD or GPLv2) Please review the license guidelines [1] yourself to ensure this matches the state of the software. > > - The %pre scriptlet should use the template for dynamic allocation [9]. > Done This is still missing the scriptlet requirement on shadow-utils. Add this line near the other requirements in the spec file: Requires(pre): shadow-utils > > - The `%files devel` section can be trimmed down by using just `%{_includedir}/qat` (which is recursive), rather than the directory and globbing all the files in the directory. > Done. The redundant `%dir %{_includedir}/qat` line is still there, please remove it. > > - The version in the changelog entry (2010u) doesn't match the Version field. > Fixed. While fixing the version, the release was dropped. Please add it back. It should look like this: * Fri Oct 16 2020 Giovanni Cabiddu <giovanni.cabiddu@xxxxxxxxx> - 20.08.0-1 > I need to consult the legal team to check if I can remove the license. For reference, there is already plenty of Intel software in Fedora under various licenses that keep their respective spec file under the default MIT license. Some examples: - intel-clear-sans-fonts (ASL 2.0) [2] - intel-gmmlib (MIT and BSD) [3] - intel-mediasdk (MIT) [4] - intel-mpi-benchmarks (CPL) [5] - intel-undervolt (GPLv3+) [6] - intelhex (BSD) [7] [0] https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/ [2] https://src.fedoraproject.org/rpms/intel-clear-sans-fonts/blob/master/f/intel-clear-sans-fonts.spec [3] https://src.fedoraproject.org/rpms/intel-gmmlib/blob/master/f/intel-gmmlib.spec [4] https://src.fedoraproject.org/rpms/intel-mediasdk/blob/master/f/intel-mediasdk.spec [5] https://src.fedoraproject.org/rpms/intel-mpi-benchmarks/blob/master/f/intel-mpi-benchmarks.spec [6] https://src.fedoraproject.org/rpms/intel-undervolt/blob/master/f/intel-undervolt.spec [7] https://src.fedoraproject.org/rpms/intelhex/blob/master/f/intelhex.spec -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx
