https://bugzilla.redhat.com/show_bug.cgi?id=2051874 --- Comment #12 from Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> --- (In reply to Fabio Valentini from comment #10) > > Are you sure? MIT + GPLv3 is effectively GPLv3, and License specifies the > > effective license [https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_license_field]. > > I have not checked the entire dependency tree, just the direct dependencies. > But whether the resulting "effective license" is still GPLv3 or not, my > point is that this needs to be *checked* and *documented*. I agree only partially. Yes, the maintainer should check the licensing, but we can't really require the maintainer to do a full license review. In my reviews I check two things: - is the *declared* license acceptable for Fedora - does this declared license *match* the license files and/or headers in source files (i.e. the checks that fedora-review implements) To be really comprehensive, a full review would include checking the headers and history of each file, and figuring out if any of the licenses of dependencies might create a licensing conflict. My understanding is that we trust the upstream authors to do the right thing, i.e. specify the licensing truthfully and in a way that is compatible with all the dependencies, also for the resulting binary artifact. Occasionally I'll try to do such a check if something looks suspicious or strange, but I think it is too much to *require* for every review. > You can use the following script in a mock shell, after doing a mock build > with "--without check" to list all crate licenses in the buildroot: > > for i in $(rpm -qa | grep "rust-.*-devel"); do > rpm -q $i --qf "%{LICENSE}\n"; > done | sort | uniq > > (Side note: For Rust packages, we actually usually don't even collapse > things like "GPLv3 and MIT" into "GPLv3". Speaking for myself, I don't want > to get involved in the intricacies of license compatibility matrices, so I > just specify the non-collapsed versions explicitly.) In the particular case of MIT + GPLv3, the resulting license on the binary artifacts is effectively GPLv3. MIT is generally interpreted to require the MIT software license text to be preserved along the source, so the requirements of the MIT-licensed deps are fully satisfied by the way how we distribute rust-*-devel files. (A somewhat similar case: many packages have build scripts that have different licensing than the source code. The licensing of the full source can be quite complicated, with a dozen different licenses… But we don't distribute the build scripts in the binary package, just a few compiled artfifacts, and the License field describes just the contents of the binary packages, so the licensing of the build scripts is not relevant to License.) (In reply to Yu Watanabe from comment #11) [...] > So, functionalities not related to ifcfg files should be dropped from the > code. Yeah, that matches my suspicions. Strictly speaking, details of behaviour are not part of review, i.e. the review could be approved even if the new code does the wrong thing in some cases. But I'd prefer to fix the code first. The package description and summary will also change, and I think it'd be nicer to improve it before the review is finalized. -- You are receiving this mail because: You are always notified about changes to this product and component You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2051874 _______________________________________________ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
