Bug 231774 (perl-DBIx-POS)

Package Review
==============

Key:
 - = N/A
 x = Check
 ! = Problem
 ? = Not evaluated

=== REQUIRED ITEMS ===
 [x] Buildroot is correct
(%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n))
 [x] Rpmlint output: None
 [x] Package is named according to the Package Naming Guidelines.
 [x] Spec file name must match the base package %{name}, in the format %{name}.spec.
 [x] Package meets the  Packaging Guidelines.
 [x] Package is licensed with an open-source compatible license and meet 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 / Artistic
 [-] 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.
 [-] Spec file is written in American English.
 [-] Spec file for the package is legible.
 [-] Sources used to build the package matches the upstream source, as provided
in the spec URL.
     MD5SUM this package    : ecd44d600628a0c3031628c9cc0e7706
     MD5SUM upstream package: ecd44d600628a0c3031628c9cc0e7706
 [x] Package successfully compiles and builds into binary rpms on at least one
supported architecture.
     Tested on: FC-6 / i386
 [-] Package is not known to require ExcludeArch, OR:
     Arches excluded:
     Why:
 [!] 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.
 [-] ldconfig called in %post and %postun if required.
 [x] Package is not relocatable.
 [x] Package must own all directories that it creates.
 [-] Package requires other packages for directories it uses.
 [x] Package does not contain duplicates in %files.
 [x] Permissions on files are set properly.
 [x] Package has a %clean section, which contains rm -rf %{buildroot} (or
$RPM_BUILD_ROOT).
 [x] Package consistently uses macros.
 [x] Package contains code, or permissable content.
 [-] Large documentation files are in a -doc subpackage, if required.
 [x] Package uses nothing in %doc for runtime.
 [-] Header files in -devel subpackage, if present.
 [-] Static libraries in -devel subpackage, if present.
 [-] Package requires pkgconfig, if .pc files are present.
 [-] Development .so files in -devel subpackage, if present.
 [-] Fully versioned dependency in subpackages, if present.
 [x] Package does not contain any libtool archives (.la).
 [-] Package contains a properly installed %{name}.desktop file if it is a GUI
application.
 [x] Package does not own files or directories owned by other packages.

=== SUGGESTED ITEMS ===
 [-] Package does not include license text files separate from upstream.
 [-] Description and summary sections in the package spec file contains
translations for supported Non-English languages, if available.
 [x] Reviewer should test that the package builds in mock.
     Tested on: FC-6 / i386
 [-] Package should compile and build into binary rpms on all supported
architectures.
     Tested on:
 [?] Package functions as described.
 [-] Scriptlets must be sane, if used.
 [-] The placement of pkgconfig(.pc) files are correct.
 [-] File based requires are sane.
 [x] Latest version is packaged.

=== Issues ===
1. Missing BR perl(YAML).
2. There are two licenses that apply to this module.  The first is "GPL or
Artistic" but the second is only "Artistic".  I think you need to change your
license tag to be just "Artistic".

=== Final Notes ===
1.


Give that a clean up and I'll approve the package.

SRPM URL: http://home.comcast.net/~ckweyl/perl-DBIx-POS-0.03-2.fc6.src.rpm
SPEC URL: http://home.comcast.net/~ckweyl/perl-DBIx-POS.spec

(In reply to comment #1)
> === Issues ===
> 1. Missing BR perl(YAML).

Fixed, at above links :)

> 2. There are two licenses that apply to this module.  The first is "GPL or
> Artistic" but the second is only "Artistic".  I think you need to change your
> license tag to be just "Artistic".

Well, this module (as most of the perl world) is indeed dual-licensed.  While
the module itself is a touch misleading when it comes to this, one is the GPL,
the other is Artistic...  Hence the license tag GPL or Artistic.

(In reply to comment #2)
> Well, this module (as most of the perl world) is indeed dual-licensed.  While
> the module itself is a touch misleading when it comes to this, one is the GPL,
> the other is Artistic...  Hence the license tag GPL or Artistic.

I want to make sure we are talking about the same thing.  I'm speaking
specifically of these lines in the README:

The instance routine is from Andy Wardley's <abw.co.uk>
Class::Singleton, and carries the following copyright and license.

Copyright (C) 1998 Canon Research Centre Europe Ltd.  All Rights Reserved.

This module is free software; you can redistribute it and/or modify it under
the term of the Perl Artistic License.


If you set the license tag to "GPL or Artistic" it is misleading in that the
entire package is not "GPL or Artistic", however, it can be entirely licensed as
"Artistic".

But if in your opinion you have the right info in the tag, I'm willing to go
with that.

Point well taken.  That text is also in the source file (lib/DBIx/POS.pm) itself.

The author intends to license this module under perl terms (dual GPL/Artistic)
under the clear text of the licensing statement, and this module includes code
copyrighted under a strictly Artistic license. This is a not derivative work,
however, not a modification of the package Class::Singleton, so this appears to
me to be kosher under the Artistic license.  It is my assessment that this
package (DBIx-POS) is properly licensed by the author under both the GPL and the
Artistic license.

This is just based on my reading of the Artistic license -- that is, that
fragments of code licensed under the Artistic license may be reliscensed under
the GPL (as would be the case if someone opted to use this package under the
terms of the GPL).  Comment is invited :)

(In reply to comment #4)
> that is, that fragments of code licensed under the Artistic license may be 
> reliscensed under the GPL (as would be the case if someone opted to use this
> package under the terms of the GPL). 

This is where I don't quite follow you.  What part of the Artistic license
allows this?  And why would you consider the portion under the Artistic license
a "fragment"?

Note:  I think we both understand that this is not a blocker on the package
itself because mixing these two licenses is certainly compatible.  It's just a
matter of getting the tag to reflect the realistic licensing of the package as a
 whole.

(In reply to comment #5)
> (In reply to comment #4)
> > that is, that fragments of code licensed under the Artistic license may be 
> > reliscensed under the GPL (as would be the case if someone opted to use this
> > package under the terms of the GPL). 
> 
> This is where I don't quite follow you.  What part of the Artistic license
> allows this?  And why would you consider the portion under the Artistic 
> license a "fragment"?

That's a good question.  The Artistic license is very clear about what can and
cannot be done with the package, both as provided ("Standard Version") and
derivative works...  If we treat D::P as a derivative work of C::S, then I think
this usage falls under the scope of clause 3(a):

"       3. You may otherwise modify your copy of this Package in any way, pro-
           vided that you insert a prominent notice in each changed file stat-
           ing how and when you changed that file, and provided that you do at
           least ONE of the following:

           "a) place your modifications in the Public Domain or otherwise make
               them Freely Available, such as by posting said modifications to
               Usenet or an equivalent medium, or placing the modifications on
               a major archive site such as uunet.uu.net, or by allowing the
               Copyright Holder to include your modifications in the Standard
               Version of the Package."

Parts of C::S are aggregated (totally embedded, even) within D::P; and the
author clearly states which parts, where they came from, and the original
copyright.  Furthermore, the author satisfied 3a by making such modifications
freely available, etc.

So, I'm certanly not a copyright lawyer, but that's my reading.

> Note:  I think we both understand that this is not a blocker on the package
> itself because mixing these two licenses is certainly compatible.  It's just a
> matter of getting the tag to reflect the realistic licensing of the package as 
> a whole.

Yep :)  If we decide we can't go with the author's original dual-licensing as
is, we can just term it Artistic and I'll take the matter upstream.

So we have 

a) D::P - Artistic or GPL
b) C::S - Artistic
c) License Tag - Artistic or GPL

If the license tag is Artistic or GPL, doens't it imply that the entire package
can be relicensed under the choice of Artistic or GPL?  Nothing I see in
Artistic license for C::S allows that AFAICS.

(In reply to comment #7)
> So we have 
> 
> a) D::P - Artistic or GPL
> b) C::S - Artistic
> c) License Tag - Artistic or GPL
> 
> If the license tag is Artistic or GPL, doens't it imply that the entire package
> can be relicensed under the choice of Artistic or GPL?  Nothing I see in
> Artistic license for C::S allows that AFAICS.

Ok, sold.  (for some reason I had it in my head it was akin to BSD/MIT, using
snippets is OK with attribution.)  I'll change the license tag to Artistic, and
take the licensing issue upstream for further resolution?

(In reply to comment #8)
> I'll change the license tag to Artistic, and
> take the licensing issue upstream for further resolution?

Sounds good.  Everything else is in order.


================
*** APPROVED ***
================

New Package CVS Request
=======================
Package Name: perl-DBIx-POS
Short Description: Define a dictionary of SQL statements in a POD dialect (POS)
Owners: cweyl.edu
Branches: FC-5, FC-6, devel
InitialCC: fedora-perl-devel-list

Imported and built.  Will follow up with upstream, thanks for the review! :)