Bug 467175 - Review Request: perl-Set-Object - Set of objects and strings
Review Request: perl-Set-Object - Set of objects and strings
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Tibbitts
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-16 04:33 EDT by Gerd Hoffmann
Modified: 2009-01-13 18:27 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-13 18:27:22 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
tibbs: fedora‑review+
dennis: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Gerd Hoffmann 2008-10-16 04:33:23 EDT
Spec URL: http://kraxel.fedorapeople.org/osm/perl-Set-Object/perl-Set-Object.spec
SRPM URL: http://kraxel.fedorapeople.org/osm/perl-Set-Object/perl-Set-Object-1.25-2.fc9.src.rpm
Description:

This modules implements a set of objects, that is, an unordered
collection of objects without duplication.

The term *objects* is applied loosely - for the sake of Set::Object,
anything that is a reference is considered an object.
Comment 1 Gerd Hoffmann 2008-10-16 04:38:52 EDT
Note 1: This is used by the openstreetmap.org map rendering software.

Note 2: License isn't clear to me.  http://search.cpan.org/dist/Set-Object/ just says "Artistic", without specifying which version of the license ...

Note 3: http://kraxel.fedorapeople.org/osm/fedora9/$basearch/ has repositories with binary packages.
Comment 2 manuel wolfshant 2008-10-16 06:32:17 EDT
Quote from http://search.cpan.org/src/SAMV/Set-Object-1.26/lib/Set/Object.pm

=head1 LICENCE

Copyright (c) 1998-1999, Jean-Louis Leroy. All Rights Reserved.
This module is free software. It may be used, redistributed
and/or modified under the terms of the Perl Artistic License

Portions Copyright (c) 2003 - 2005, Sam Vilain.  Same license.

Portions Copyright (c) 2006, 2007, Catalyst IT (NZ) Limited.  Same
license.


So the license is the same Artistic as perl is.
Comment 3 Gerd Hoffmann 2008-10-16 07:50:32 EDT
See https://fedoraproject.org/wiki/Licensing

There is Artistic 1.0 (*not* FSF free, http://www.perl.com/pub/a/language/misc/Artistic.html).

There is Artistic 2.0 (FSF free, http://www.perlfoundation.org/artistic_license_2_0).

Perl itself is (as I read it) Artistic 1.0 or GPLv1+ (http://dev.perl.org/licenses/), which is FSF free too.

So the question is: what does the term "the Perl Artistic License" refer to?
Same license as perl (both GPL and Artistic)?  Artistic only?  If the later, which of the two version?

Given that the creation of the package predates the Artistic License 2.0 it probably isn't that one ...
Comment 4 manuel wolfshant 2008-10-17 06:17:27 EDT
How about getting in touch with the author and asking for clarifications and/or relicensing if needed ? maybe he wants to follow Perl's license, so he might agree with the current one used by Perl.
Comment 5 Jason Tibbitts 2008-10-17 16:00:41 EDT
It seems pretty obvious that this is under the plain Artistic license, which is not acceptable for Fedora.  Please contact the author (who is obviously active as a new version has come out) and see if they would be willing to license under either the same license as Perl or either Artistic 2.0 or the clarified Artistic license (or any of the other acceptable licenses).

I'll go ahead and block FE-Legal; I'm sure spot will correct me if I've erred somewhere.
Comment 6 Gerd Hoffmann 2008-10-17 18:53:31 EDT
email to the author has been send already earlier today, no response so far.
Comment 7 Gerd Hoffmann 2008-10-22 05:48:24 EDT
Answer from Sam Vilain <sam@vilain.net>:

AFAIK the original author has not responded to requests for relicensing
under GPLv2.  Which is odd, given that another of their projects,
Tangram was *only* available under the GPL, and it *required*
Set::Object.  Hmm..

Could get a notary public to serve them notice of the intention to
relicense Set::Object as GPL under the requirements of the license for
Tangram.  If they don't make claim, then it should be able to be
relicensed, I'd guess.

Cheers,
Sam.
Comment 8 Gerd Hoffmann 2008-10-22 05:57:41 EDT
I'll try to contact the original author (Jean-Louis Leroy) first.
Commments from fedora-legal on the notary idea are welcome nevertheless.
Comment 9 Tom "spot" Callaway 2008-10-22 16:51:51 EDT
(In reply to comment #7)
> Answer from Sam Vilain <sam@vilain.net>:
> 
> AFAIK the original author has not responded to requests for relicensing
> under GPLv2.  Which is odd, given that another of their projects,
> Tangram was *only* available under the GPL, and it *required*
> Set::Object.  Hmm..
> 
> Could get a notary public to serve them notice of the intention to
> relicense Set::Object as GPL under the requirements of the license for
> Tangram.  If they don't make claim, then it should be able to be
> relicensed, I'd guess.

I'm not sure that would hold up in the US. The original authors are fully permitted to create something that is license incompatible and not redistributable by anyone other than them.
Comment 10 Gerd Hoffmann 2008-10-24 08:38:05 EDT
One more mail from Sam Vilain on (re-)licensing:

<quote>

> Given you apparently tried already to get it re-licenced I assume you
> are fine with GPL, right?
> 
> What about "Catalyst IT (NZ) Limited" listed in the man-page?  Given you
> are still listed as maintainer @ CPAN I assume this is the company you
> are working for?

Yes, I can speak for that copyright holder, and they are happy to
license under any FSF-approved Free Software license, including the Perl
Artistic/GPL disjunction.

</quote>

Sent mail to the original author (Jean-Louis Leroy) now.
Comment 11 Gerd Hoffmann 2008-10-31 06:08:55 EDT
No reply so far.  Mail was sent to jll@skynet.be, found in tarball.
Tried again with other email address now: jll@soundobjectlogic.com, from cpan.
Comment 12 Gerd Hoffmann 2008-10-31 06:40:39 EDT
Hmm, bounces:

<jll@soundobjectlogic.com>: This address no longer accepts mail.
Comment 13 Tom "spot" Callaway 2008-11-06 11:34:59 EST
Try: jl@yorel.be
Comment 14 Gerd Hoffmann 2008-11-07 04:47:33 EST
Mail sent, lets see ...
Comment 15 Gerd Hoffmann 2008-11-11 05:10:15 EST
Got a reply, progress on the licensing front ;)

Hello Gerd.
I agree to relicense Set::Object under the same terms as (current) Perl itself - which is probably the choice between two licenses: Artistic 2.0 and GPL.
Cordially,
Jean-Louis
Comment 17 Tom "spot" Callaway 2008-11-11 08:47:42 EST
Please include a copy of your correspondence with the copyright holders on relicensing as a flat text file in this package (and put it in %doc), so that it is clear to others why we have it licensed like this when the source doesn't match.
Comment 18 Tom "spot" Callaway 2008-11-13 11:30:15 EST
(In reply to comment #17)
> Please include a copy of your correspondence with the copyright holders on
> relicensing as a flat text file in this package (and put it in %doc), so that
> it is clear to others why we have it licensed like this when the source doesn't
> match.

Once you've done this and posted a new SRPM/SPEC, I should be able to lift FE-Legal.
Comment 20 Jason Tibbitts 2008-12-06 17:35:48 EST
FE-Legal is still there, but it seems that you've done what spot asked so I'll go ahead and review this.  I'll just pass over the license bits and let spot indicate whether things are done properly.

It's a bit odd to see a perl specfile that wasn't autogenerated with cpanspec like almost all of the other perl packages in the distro.  Not a problem, of course; I just have to check everything a bit closer.

rpmlint complains:
  perl-Set-Object.x86_64: W: incoherent-version-in-changelog 1.26-2.fc9 
   ['1.26-2.fc11', '1.26-2']
We don't generally include the dist tag in changelog entries, as they are generally not correct.

Is there some reason you do not run the included test suite?  It needs to be run in a %check section if possible.  (The specfile generators do this for you.)  It seems to run fine for me as long as I add build dependencies on Test::More, Test::Pod and Test::Pod::Coverage.

Your %files section could be a whole lot simpler:
  %files 
  %defattr(-, root, root, 0755)
  %doc Changes.pod META.yml README license.txt
  %{_mandir}/man3/*.3*
  %{perl_vendorarch}/auto/Set/
  %{perl_vendorarch}/Set/

I guess you can obsfucate if you really want to, but I'm not sure why as it just makes things tougher on the next person who looks at th epackage.

* source files match upstream.  sha256sum:
   b2c2b5c2a5af1dae37b241c50a553a6044070db2fe23c6d47b6acf8e78e6a3c3  
   Set-Object-1.26.tar.gz
* package meets naming and versioning guidelines.
* specfile is properly named and uses macros consistently.
* summary is OK.
* description is OK.
* dist tag is present.
* build root is OK.
* latest version is being packaged.
 BuildRequires are proper.
* compiler flags are appropriate.
* %clean is present.
* package builds in mock (rawhide, x86_64).
* package installs properly.
* debuginfo package looks complete.
X rpmlint has a valid complaint.
* final provides and requires are sane:
   Object.so()(64bit)
   perl(Set::Object) = 1.26
   perl(Set::Object::Weak)
   perl-Set-Object = 1.26-2.fc11
   perl-Set-Object(x86-64) = 1.26-2.fc11
  =
   perl(:MODULE_COMPAT_5.10.0)
   perl(AutoLoader)
   perl(Carp)
   perl(DynaLoader)
   perl(Exporter)
   perl(Set::Object)
   perl(Set::Object::Weak)
   perl(base)
   perl(strict)
   perl(vars)

X %check is not present, but should be.
* no shared libraries are added to the regular linker search paths.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* no generically named files
* code, not content.
* documentation is small, so no -doc subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* no headers.
* no pkgconfig files.
* no static libraries.
* no libtool .la files.
Comment 21 Gerd Hoffmann 2008-12-09 09:39:26 EST
New version uploaded:

http://kraxel.fedorapeople.org/osm/perl-Set-Object/perl-Set-Object.spec
http://kraxel.fedorapeople.org/osm/perl-Set-Object/perl-Set-Object-1.26-3.fc10.src.rpm

I didn't start from scratch but took an existing package, thats why I didn't generate a specfile.  To me it looks like it was created by an older cpanspec version.  Picked up some stuff from a fresh generated file version, so it is closer now.

Seems rpmlint got smarter wrt. dist tag, a while back it used to complain about changelog entries without dist tag.  Fixed it up.

Also added a %check section (+buildrequires needed for that).
Comment 22 Jason Tibbitts 2008-12-10 13:20:33 EST
Thanks.  Builds fine and rpmlint is silent.  The test suite passes:
  All tests successful.
  Files=40, Tests=453,  1 wallclock secs ( 0.12 usr  0.06 sys +  0.83 cusr  0.17 
   csys =  1.18 CPU)

Everything else looks good.

APPROVED
Comment 23 Gerd Hoffmann 2008-12-11 15:30:15 EST
New Package CVS Request
=======================
Package Name: perl-Set-Object
Short Description: Set of objects and strings
Owners: kraxel
Branches: F-9 F-10
Comment 24 Kevin Fenzi 2008-12-14 00:13:54 EST
Spot: care to make sure FE-Legal should be ok to remove here?
I will process cvs once thats done.
Comment 25 Tom "spot" Callaway 2008-12-14 09:32:19 EST
Lifted FE-Legal, sorry. :)
Comment 26 Dennis Gilmore 2008-12-15 15:50:17 EST
CVS Done
Comment 27 Jason Tibbitts 2009-01-13 18:27:22 EST
This seems to have been pushed out to the release branches, so I see no reason not to close this ticket.

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