Cleaned up based on other Maypole fixes:

New SPEC:
http://www.auroralinux.org/people/spot/review/Maypole/perl-Class-DBI-Loader-Relationship.spec

New SRPM:
http://www.auroralinux.org/people/spot/review/Maypole/perl-Class-DBI-Loader-Relationship-1.2-3.src.rpm

I can't find any trace of licensing terms in the upstream tarball for this
package...

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?

I sent an email to the upstream maintainer, but have yet to receive a response.

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

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

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.

FYI: Larry Wall has a comment about this in

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

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

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

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.