Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 166189 - Review Request: perl-Class-DBI-Loader-Relationship : Easier relationship specification in CDBI::L
Summary: Review Request: perl-Class-DBI-Loader-Relationship : Easier relationship spec...
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Paul Howarth
QA Contact: David Lawrence
URL: http://search.cpan.org/dist/Class-DBI...
Whiteboard:
Depends On: 166188
Blocks: FE-ACCEPT 166203
TreeView+ depends on / blocked
 
Reported: 2005-08-17 20:32 UTC by Tom "spot" Callaway
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-09-14 18:45:37 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Tom "spot" Callaway 2005-08-17 20:32:21 UTC
Spec Name or Url: 
http://www.auroralinux.org/people/spot/review/Maypole/perl-Class-DBI-Loader-Relationship.spec

SRPM Name or Url:
http://www.auroralinux.org/people/spot/review/Maypole/perl-Class-DBI-Loader-Relationship-1.2-2.src.rpm

Description: 

Easier relationship specification in CDBI::L

(NOTE: This package is one of the Maypole dependencies)

Comment 2 Paul Howarth 2005-09-09 15:14:02 UTC
I can't find any trace of licensing terms in the upstream tarball for this
package...

Comment 3 Paul Howarth 2005-09-12 10:09:10 UTC
Review:

- rpmlint clean
- package and spec naming OK
- package meets guidelines
- spec file written in English and is legible
- sources match upstream
- package builds OK in mock for FC4 (i396)
- BR's OK
- no locales, libraries, subpackages or pkgconfigs to worry about
- not relocatable
- no duplicate files
- no directory ownership or permissions issues
- %clean section present and correct
- macro usage is consistent
- no large docs
- docs don't affect runtime
- no scriptlets
- no .desktop file needed
- code, not content

Needswork:

- I can't find any trace of licensing terms for this package. Where did you
  find the "same terms as perl" license info?


Comment 4 Tom "spot" Callaway 2005-09-12 14:38:24 UTC
I sent an email to the upstream maintainer, but have yet to receive a response.

I'll change this to "Distributable" before I commit.

Comment 5 Paul Howarth 2005-09-12 14:48:07 UTC
(In reply to comment #4)
> I sent an email to the upstream maintainer, but have yet to receive a response.
> 
> I'll change this to "Distributable" before I commit.

I guess that's OK since everything on CPAN is required to be free (as in beer)
software. However, doesn't this cause problems for other modules that depend on
it? For example, if a dependent module has the standard "GPL or Artistic"
license, wouldn't the GPL part of that require that this module be available
under the GPL?


Comment 6 Tom "spot" Callaway 2005-09-12 14:51:21 UTC
Only if it actually links to that code. Use does not trigger the "viral" effect
of the GPL. And actually, in the case of a dual license link, it would really
mean that the linking code would default over to Artistic.

I suspect that this code is under the same license as perl, and that the
upstream maintainer is just really lazy.

Comment 7 Jose Pedro Oliveira 2005-09-12 14:54:59 UTC
FYI: Larry Wall has a comment about this in

  http://dev.perl.org/licenses/


Comment 8 Paul Howarth 2005-09-12 15:20:26 UTC
(In reply to comment #6)
> Only if it actually links to that code. Use does not trigger the "viral" effect
> of the GPL. And actually, in the case of a dual license link, it would really
> mean that the linking code would default over to Artistic.

Consider Maypole, which is licensed GPL or Artistic and uses this module. If I
wanted to build and distribute something based on that under the GPL, surely my
package and its non-OS dependencies need to be available under a GPL-compatible
license? I would have thought a perl module (without which Maypole would not
work) would be counted as one of those dependencies?

If it's not, what would be the point of releasing this module under a specific
license such as GPL or Artistic if anyone can use that code under whatever terms
they liked (e.g. proprietary)?

> I suspect that this code is under the same license as perl, and that the
> upstream maintainer is just really lazy.

So do I.

(In reply to comment #7)
> FYI: Larry Wall has a comment about this in
>
>   http://dev.perl.org/licenses/

Hmm, OK, that *seems* to suggest that using a perl module is an act of
aggregation rather than linking. I can go with that in this case, but supposing
the module hadn't been noarch; if it was XS code that had to be compiled, that
would count as linking, wouldn't it?


Comment 9 Tom "spot" Callaway 2005-09-12 15:25:47 UTC
(In reply to comment #8)

> Consider Maypole, which is licensed GPL or Artistic and uses this module. If I
> wanted to build and distribute something based on that under the GPL, surely my
> package and its non-OS dependencies need to be available under a GPL-compatible
> license? I would have thought a perl module (without which Maypole would not
> work) would be counted as one of those dependencies?

I can make a GPL application which does nothing but calls out and runs a
proprietary application with specific flags. Merely running non-GPL-compatible
bits is ok, its only linking at compile time. Larry Wall thinks that perl
modules are not being "linked to", rather only being run.

> If it's not, what would be the point of releasing this module under a specific
> license such as GPL or Artistic if anyone can use that code under whatever terms
> they liked (e.g. proprietary)?

You make a valid point. :) Perl's licensing is really weak.

> Hmm, OK, that *seems* to suggest that using a perl module is an act of
> aggregation rather than linking. I can go with that in this case, but supposing
> the module hadn't been noarch; if it was XS code that had to be compiled, that
> would count as linking, wouldn't it?

I'd say yes. Larry seems to say no.

Comment 10 Paul Howarth 2005-09-12 15:37:46 UTC
OK, since IANAL, it's Approved.

After changing the License: tag to "Distributable", you'll also need to remove
the GPL and Artistic license texts from the package of course, at least until
upstream clarifies the position.


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