Bug 573917 - Review Request: perl-NetPacket-SpanningTree - Assemble and disassemble IEEE 802.1D Spanning Tree protocol packets
Review Request: perl-NetPacket-SpanningTree - Assemble and disassemble IEEE 8...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ruediger Landmann
Fedora Extras Quality Assurance
:
Depends On: perl-NetPacket 573918
Blocks:
  Show dependency treegraph
 
Reported: 2010-03-16 03:26 EDT by Jan Klepek
Modified: 2012-04-30 14:33 EDT (History)
5 users (show)

See Also:
Fixed In Version: perl-NetPacket-SpanningTree-0.01-3.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-04-18 19:01:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
r.landmann: fedora‑review+
limburgher: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Jan Klepek 2010-03-16 03:26:36 EDT
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.
Comment 2 Ruediger Landmann 2011-03-21 01:16:36 EDT
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
Comment 3 Jan Klepek 2011-03-21 08:15:50 EDT
Sorry, I missed it somehow, upstream was contacted to clarify this issue.
Comment 5 Ruediger Landmann 2011-03-21 18:18:48 EDT
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
Comment 6 Ralf Corsepius 2011-03-22 02:20:07 EDT
(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.
Comment 7 Jan Klepek 2011-03-22 03:01:11 EDT
(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.
Comment 8 Ralf Corsepius 2011-03-22 03:19:28 EDT
(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.
Comment 9 Ruediger Landmann 2011-03-22 18:20:57 EDT
(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
Comment 10 Ruediger Landmann 2011-03-22 19:23:27 EDT
(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.'
Comment 11 Ruediger Landmann 2011-03-23 02:27:53 EDT
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
Comment 12 Tom "spot" Callaway 2011-06-30 13:03:00 EDT
Any update here?
Comment 14 Tom "spot" Callaway 2011-07-25 11:05:38 EDT
Lifting FE-Legal.
Comment 15 Ruediger Landmann 2011-07-27 21:56:24 EDT
(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
Comment 16 Jan Klepek 2011-07-28 06:35:14 EDT
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
Comment 17 Gwyn Ciesla 2011-07-28 08:01:54 EDT
Git done (by process-git-requests).
Comment 18 Fedora Update System 2012-04-09 13:16:59 EDT
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
Comment 19 Fedora Update System 2012-04-09 13:17:11 EDT
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
Comment 20 Fedora Update System 2012-04-09 13:26:32 EDT
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
Comment 21 Fedora Update System 2012-04-09 13:26:42 EDT
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
Comment 22 Fedora Update System 2012-04-10 16:15:32 EDT
perl-NetPacket-SpanningTree-0.01-5.fc17 has been pushed to the Fedora 17 testing repository.
Comment 23 Fedora Update System 2012-04-18 19:01:49 EDT
perl-NetPacket-SpanningTree-0.01-5.fc17 has been pushed to the Fedora 17 stable repository.
Comment 24 Fedora Update System 2012-04-27 01:53:23 EDT
perl-NetPacket-SpanningTree-0.01-5.fc15 has been pushed to the Fedora 15 stable repository.
Comment 25 Fedora Update System 2012-04-30 14:30:48 EDT
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.
Comment 26 Fedora Update System 2012-04-30 14:33:45 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.