https://bugzilla.redhat.com/show_bug.cgi?id=1529023 --- Comment #7 from David Carlos <ddavidcarlos1392@xxxxxxxxx> --- (In reply to Björn "besser82" Esser from comment #6) > (In reply to David Carlos from comment #5) > > (In reply to Björn "besser82" Esser from comment #4) > > > > - Your License field defines BSD as the package license, but upstream uses > > > > MIT. > > > > I had notices that the upstream setup.py file defines the license as BSD, > > > > but the LICENSE file is MIT. > > > > I don't have enough knowledge about licensing but this appear > > > > a bit inconsistent to me. > > > > > > > [!]: License field in the package spec file matches the actual license. > > > > Note: Checking patched sources after %prep for licenses. Licenses > > > > found: "MIT/X11 (BSD like)", "BSD (unspecified)", "Unknown or > > > > generated", "*No copyright* BSD (unspecified)". 48 files have unknown > > > > license. Detailed output of licensecheck in > > > > /home2/david/rpmbuild/REVISIONS/1529023-python- > > > > validators/licensecheck.txt > > > > > > Well, there is very little difference in these licenses. On Pypi the > > > package is distributed as BSD licensed… That's why I didn't complain about > > > it. > > > > > > The only real difference between those two licenses is: BSD *requires* you > > > to redistribute the license file, MIT does not (It just recommends 'shall > > > be' to do it). > > > > > > For a Fedora package this difference is not relevant, since we require to > > > redistribute the license file along with the SRPM and the binary RPMs by our > > > guidelines. > > > > > > > We are packaging a license file containing a MIT license description, but > > the license spec field defines the license as BSD. If this is relevant or > > not, I really don't know, but is inconsistent. In my point of view this is > > not a packaging problem, but was a decision made by the upstream (in my > > opinion, a inconsistent decision) that is making the license spec field and > > the license file be different. > > Then that *should* be discussed with upstream and changed in a new release > of the package… As I said, it is not a packaging problem, but is a problem that is interfering in how the packaging was made. > > > > > [!]: Package meets the Packaging Guidelines::Python > > > > > > I don't get the reason, why the package doesn't comply to the additional > > > Python guidelines… > > > > William should use the python macros defined on the guidelines, as I pointed > > on the review. > > Mhh… 'should' != 'must' and thus doesn't violate the guidelines. Or is my > logic wrong here? The fedora-review tool not fills this item automatically. Is a reviewer decision if using or not a macro violates the python guidelines. On the guidelines is not explicit defined that not using macros is a violation, but is a rule that I, as a reviewer, always follow. If there is a macro for something, use it. So, for me this is a packaging rule and I should have said 'must' instead of 'should'. In any case, this is a informal review so he can decides by him self this question. -- 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
