Bug 467175

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.

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.

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 ...

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.

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.

email to the author has been send already earlier today, no response so far.

Answer from Sam Vilain <sam>:

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.

I'll try to contact the original author (Jean-Louis Leroy) first.
Commments from fedora-legal on the notary idea are welcome nevertheless.

(In reply to comment #7)
> Answer from Sam Vilain <sam>:
> 
> 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.

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.

No reply so far.  Mail was sent to jll, found in tarball.
Tried again with other email address now: jll, from cpan.

Hmm, bounces:

<jll>: This address no longer accepts mail.

Try: jl

Mail sent, lets see ...

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

new packages (updated license tag) 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.25-3.fc10.src.rpm

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.

(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.

Done.

SPEC: http://kraxel.fedorapeople.org/osm/perl-Set-Object/perl-Set-Object.spec
SRPM: http://kraxel.fedorapeople.org/osm/perl-Set-Object/perl-Set-Object-1.26-2.fc9.src.rpm
TEXT: http://kraxel.fedorapeople.org/osm/perl-Set-Object/license.txt

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.

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).

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

New Package CVS Request
=======================
Package Name: perl-Set-Object
Short Description: Set of objects and strings
Owners: kraxel
Branches: F-9 F-10

Spot: care to make sure FE-Legal should be ok to remove here?
I will process cvs once thats done.

Lifted FE-Legal, sorry. :)

CVS Done

This seems to have been pushed out to the release branches, so I see no reason not to close this ticket.