This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 231774 - (perl-DBIx-POS) Review Request: perl-DBIx-POS - Define a dictionary of SQL statements in a POD dialect (POS)
Review Request: perl-DBIx-POS - Define a dictionary of SQL statements in a PO...
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bernard Johnson
Fedora Package Reviews List
http://search.cpan.org/dist/DBIx-POS/
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-11 12:17 EDT by Chris Weyl
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-04-27 23:08:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
bjohnson: fedora‑review+
wtogami: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Chris Weyl 2007-03-11 12:17:26 EDT
SRPM URL: http://home.comcast.net/~ckweyl/perl-DBIx-POS-0.03-1.fc6.src.rpm
SPEC URL: http://home.comcast.net/~ckweyl/perl-DBIx-POS.spec

Description:
DBIx-POS subclasses Pod::Parser to define a POD dialect for writing a SQL
dictionary for an application, and uses code from Class::Singleton to make
the resulting structure easily accessible.
Comment 1 Bernard Johnson 2007-04-17 11:10:21 EDT
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.
Comment 2 Chris Weyl 2007-04-17 23:28:11 EDT
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.
Comment 3 Bernard Johnson 2007-04-17 23:38:50 EDT
(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@cre.canon.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.
Comment 4 Chris Weyl 2007-04-19 11:28:55 EDT
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 :)
Comment 5 Bernard Johnson 2007-04-19 22:58:21 EDT
(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.
Comment 6 Chris Weyl 2007-04-20 00:34:33 EDT
(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.
Comment 7 Bernard Johnson 2007-04-25 11:27:26 EDT
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.

Comment 8 Chris Weyl 2007-04-26 11:53:59 EDT
(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?
Comment 9 Bernard Johnson 2007-04-26 12:18:22 EDT
(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 ***
================


Comment 10 Chris Weyl 2007-04-26 12:27:35 EDT
New Package CVS Request
=======================
Package Name: perl-DBIx-POS
Short Description: Define a dictionary of SQL statements in a POD dialect (POS)
Owners: cweyl@alumni.drew.edu
Branches: FC-5, FC-6, devel
InitialCC: fedora-perl-devel-list@redhat.com
Comment 11 Chris Weyl 2007-04-27 23:08:11 EDT
Imported and built.  Will follow up with upstream, thanks for the review! :)

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