Spec URL: http://hpejakle.fedorapeople.org/packages/perl-NetPacket-SpanningTree.spec SRPM URL: http://hpejakle.fedorapeople.org/packages/perl-NetPacket-SpanningTree-0.01-1.fc11.src.rpm Description: NetPacket::SpanningTree provides a set of routines for assembling and disassembling packets using the IEEE standard Spanning Tree Protocol. Spanning Tree is a layer 2 protocol defined by the IEEE 802.1D specification. Koji build: NA until packages are available for koji, local build is ok rpmlint output: 2 packages and 1 specfiles checked; 0 errors, 0 warnings.
SRPM URL: http://hpejakle.fedorapeople.org/packages/perl-NetPacket-SpanningTree-0.01-2.fc13.src.rpm
Jan, this looks pretty good: rpmlint is quiet and the package builds cleanly. However, you say in the specfile that the license is "Artistic clarified" -- but the README, SpanningTree.pm, and the upstream at cpan all simply state "Artistic" and link to Artistic 1.0, which we can't use.[0] Is there somewhere else in the source that states that the license is "Artistic clarified"? If not, you need to contact upstream and ask them if they would consider relicensing the package, perhaps as "Artistic or GPL" (ie, the same as Perl itself). If they're happy to do so, please ask them to make a version of the source available with a copy of the GPL included in it. You will then need to rebuild the package to include: * a copy of their email (with full headers) in which they agree to relicense the package * their new source that includes a copy of the GPL Cheers, Rudi [0] http://fedoraproject.org/wiki/Licensing:Main#Bad_Licenses
Sorry, I missed it somehow, upstream was contacted to clarify this issue.
license fixed, attached email from Spec URL: http://hpejakle.fedorapeople.org/packages/perl-NetPacket-SpanningTree.spec SRPM URL: http://hpejakle.fedorapeople.org/packages/perl-NetPacket-SpanningTree-0.01-2.fc14.src.rpm
Thanks for the quick work! Actually, there's one last step we should take, and that's to include a copy of the GPL with the package. (Second dot point in comment #2) From the email, it sounds like it's unlikely that upstream will generate a new tarball for us, so instead could you please contact them again and: * attach a copy of the GPLv1 (not any other version) to the email * ask upstream if they're OK with you including a copy of that document in the Fedora package. We've just had a similar situation arise with another perl module, and the advice above is based on what I got from Spot on legal list.[0] Cheers, Rudi [0] http://lists.fedoraproject.org/pipermail/legal/2011-March/001584.html
(In reply to comment #5) > Thanks for the quick work! > > Actually, there's one last step we should take, and that's to include a copy of > the GPL with the package. (Second dot point in comment #2) Doing so is not mandatory in Fedora. Legally, it's questionable, because a Fedora packager added license file isn't legally binding to upstream (only upstream can do this). > From the email, it sounds like it's unlikely that upstream will generate a new > tarball for us, so instead could you please contact them again and: > > * attach a copy of the GPLv1 (not any other version) to the email Are you sure? This GPLv1 is dead for more than a decade.
(In reply to comment #5) > Thanks for the quick work! > > Actually, there's one last step we should take, and that's to include a copy of > the GPL with the package. (Second dot point in comment #2) > > From the email, it sounds like it's unlikely that upstream will generate a new > tarball for us, so instead could you please contact them again and: > > * attach a copy of the GPLv1 (not any other version) to the email > * ask upstream if they're OK with you including a copy of that document in the > Fedora package. > > We've just had a similar situation arise with another perl module, and the > advice above is based on what I got from Spot on legal list.[0] I was watching that discussion, however my understanding is that if upstream does not supply it, I will be liable if I will add license text and it will be not that one under which upstream released that package. From http://fedoraproject.org/wiki/Packaging:LicensingGuidelines (and similar text in reviewguidelines): If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc. If the source package does not include the text of the license(s), the packager should contact upstream and encourage them to correct this mistake. Therefore I don't see any "must" requirement to include copy of GPL by myself if upstream decide that they will not bundle it with tarball.
(In reply to comment #7) > Therefore I don't see any "must" requirement to include copy of GPL by myself > if upstream decide that they will not bundle it with tarball. This understanding of yours is right - It is the intention of the FPG.
(In reply to comment #6) > Legally, it's questionable, because a Fedora packager added license file isn't > legally binding to upstream (only upstream can do this). Right -- which is why we need to seek upstream's consent to add the file (or, better, ask them to do it themselves for us). > > From the email, it sounds like it's unlikely that upstream will generate a new > > tarball for us, so instead could you please contact them again and: > > > > * attach a copy of the GPLv1 (not any other version) to the email > Are you sure? This GPLv1 is dead for more than a decade. I was initially surprised by this too; but Spot's rationale makes sense to me: "(yes, the GPLv1, not a later version, because the perl licensing they granted is GPLv1 or later. If upstream adds a copy of GPLv2 or GPLv3, that is sufficient for us to distribute to meet this technicality, but if we're going to do it, we're going to do it right.)"[0] [0] http://lists.fedoraproject.org/pipermail/legal/2011-March/001584.html
(In reply to comment #7) > I was watching that discussion, however my understanding is that if upstream > does not supply it, I will be liable if I will add license text and it will be > not that one under which upstream released that package. The risk here is including the *wrong* license text.[0] Which is why it's so important to show upstream the license text that you intend to include in the package, obtain their consent to add that text, and include that consent (with its headers) in the package itself. > From http://fedoraproject.org/wiki/Packaging:LicensingGuidelines (and similar > text in reviewguidelines): > If (and only if) the source package includes the text of the license(s) in its > own file, then that file, containing the text of the license(s) for the package > must be included in %doc. If the source package does not include the text of > the license(s), the packager should contact upstream and encourage them to > correct this mistake. > > Therefore I don't see any "must" requirement to include copy of GPL by myself > if upstream decide that they will not bundle it with tarball. There is no "must" here: if upstream does not want to (or cannot) include it in the tarball, the advice on legal list suggests that we could probably ship the package safely and rely on the copy of the GPL provided with Perl itself. However, best practice (as discussed in that thread) is to include a copy of the GPL with GPL-licensed packages that we ship. In a best case, this is included by upstream itself; less good is to include the license text with the explicit consent of upstream; even less good is to ship without the license text. Because it's not a "must", I will not block the review on this point, but I would strongly prefer it if you asked upstream if you can include a copy of the license if he cannot or will not. He seems to be responsive and friendly -- there's nothing to lose here. If you respond here and tell me that you refuse to ask upstream about this, I will note that in the same legal list thread (just for the purpose of any future reference) and I will continue the review as normal. Sorry to be a pain -- I just think we should always aim high! :) Cheers Rudi [0] 'Now, the reason we simply do not have a policy that says "When a copy of the license text is missing, you must add it" is because there is the possibility that you, the Fedora packager, gets the license wrong, and by including a copy of the incorrect license text, put yourself at potential legal risk when the copyright holder claims you're distributing their software under terms they never gave you permission to use.'
Actually, I take back comment #10 -- I've been doing some more exploring and realise that I was asking for something beyond Fedora's normal requirements+. Include the GPL text if you want to, but I'm not going to push the point. Sorry for the drama. One last thing I noticed however: GPL aside, the developer agreed to Artistic, but in the License line, you put Artistic 2.0, which is something quite different. Please drop the "2.0" and we're done here. Everything else checks out: - = N/A / = Check ! = Problem ? = Not evaluated === REQUIRED ITEMS === [/] Rpmlint output is clean: $ rpmlint SPECS/perl-NetPacket-SpanningTree.spec 0 packages and 1 specfiles checked; 0 errors, 0 warnings. $ rpmlint SRPMS/perl-NetPacket-SpanningTree-0.01-2.fc14.src.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings. $ rpmlint RPMS/noarch/perl-NetPacket-SpanningTree-0.01-2.fc14.noarch.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings. [/] Package is named according to the Package Naming Guidelines. [/] Spec file name must match the base package %{name}, in the format %{name}.spec. [/] Package meets the Packaging Guidelines including the Language specific items [!] Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines. [/] License field in the package spec file matches the actual license. License type: GPL+ or Artistic 2.0 [/] If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package is included in %doc. Email from copyright holder included [/] Spec file is legible and written in American English. [/] Sources used to build the package matches the upstream source, as provided in the spec URL. $ md5sum SOURCES/NetPacket-SpanningTree-0.01.tar.gz bd657ce34022611b22f1882413a74184 SOURCES/NetPacket-SpanningTree-0.01.tar.gz $md5sum ~/Download/NetPacket-SpanningTree-0.01.tar.gz bd657ce34022611b22f1882413a74184 /home/rlandmann/Download/NetPacket-SpanningTree-0.01.tar.gz [/] Package successfully compiles and builds into binary rpms on at least one supported architecture. Tested: http://koji.fedoraproject.org/koji/taskinfo?taskID=2935377 [/] Package is not known to require ExcludeArch [/] All build dependencies are listed in BuildRequires, except for any that are listed in the exceptions section of Packaging Guidelines. [-] The spec file handles locales properly (with the %find_lang macro) [-] ldconfig called in %post and %postun if required. [/] Package does not bundle copies of system libraries [/] Package is not relocatable. [/] Package must own all directories that it creates. [/] Package does not contain duplicates in %files. [/] Permissions on files are set properly [/] %files section includes a %defattr(...) line [/] Package consistently uses macros. [-] Large documentation files are in a -doc subpackage, if required. [/] Package uses nothing in %doc for runtime. [-] Header files in -devel subpackage, if present. [-] Static libraries in -static subpackage, if present. [-] Development .so files in -devel subpackage, if present. [-] -devel packages require base package with full versioning. [/] Package does not contain any libtool archives (.la). [-] Package contains a properly installed %{name}.desktop file if it is a GUI application. [/] Package does not own files or directories owned by other packages. [/] Filenames are valid UTF-8
Any update here?
license fixed http://hpejakle.fedorapeople.org/packages/perl-NetPacket-SpanningTree.spec SRPM URL: http://hpejakle.fedorapeople.org/packages/perl-NetPacket-SpanningTree-0.01-3.fc15.src.rpm
Lifting FE-Legal.
(In reply to comment #13) > license fixed > http://hpejakle.fedorapeople.org/packages/perl-NetPacket-SpanningTree.spec > SRPM URL: > http://hpejakle.fedorapeople.org/packages/perl-NetPacket-SpanningTree-0.01-3.fc15.src.rpm All good; many thanks for bearing with me. Please go ahead and make your SCM request. ACCEPTED
New Package SCM Request ======================= Package Name: perl-NetPacket-SpanningTree Short Description: Assemble and disassemble IEEE 802.1D Spanning Tree protocol packets Owners: hpejakle Branches: f14 f15 el5 el6 InitialCC: perl-sig
Git done (by process-git-requests).
perl-NetPacket-SpanningTree-0.01-3.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/perl-NetPacket-SpanningTree-0.01-3.el5
perl-NetPacket-SpanningTree-0.01-3.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/perl-NetPacket-SpanningTree-0.01-3.el6
perl-NetPacket-SpanningTree-0.01-5.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/perl-NetPacket-SpanningTree-0.01-5.fc15
perl-NetPacket-SpanningTree-0.01-5.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/perl-NetPacket-SpanningTree-0.01-5.fc17
perl-NetPacket-SpanningTree-0.01-5.fc17 has been pushed to the Fedora 17 testing repository.
perl-NetPacket-SpanningTree-0.01-5.fc17 has been pushed to the Fedora 17 stable repository.
perl-NetPacket-SpanningTree-0.01-5.fc15 has been pushed to the Fedora 15 stable repository.
perl-NetPacket-SpanningTree-0.01-3.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.
perl-NetPacket-SpanningTree-0.01-3.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.