Regarding the circular dependencies between this module, Log::Log4perl, and
Log::Dispatch, have you considered bundling them all together in one package, as
was done with DateTime, DateTime::Locale, and DateTime::TimeZone (Bug 167376)?

Paul,

I don't feel confortable creating a bundle of Log::Dispatch,
Log::Dispatch::FileRotate, and Log::Log4perl because:

 i) these three perl distros are maintained by different people (the three
DateTime modules that have been bundled are all maintained by Dave Rolsky)

  ii) the circular dependencies are only caused by the test suite
as this module only extends Log::Dispatch but uses Log::Log4perl as it
main log infrastructure in the test suite (most likely, the test suite
should be redone using only Log::Dispatch or, at least, conditional
require Log::Log4perl).

iii) The author of Log::Dispatch::FileRotate doesn't appear to be very
responsive, at leasat judging from the rt tickets
(http://rt.cpan.org/NoAuth/Bugs.html?Dist=Log-Dispatch-FileRotate); at least I
haven't got any answer for #14563.

/jpo

PS - I will start submitting Log::Log4perl and its building requiments in the
next hours/days: I need to review one more time the ones I have at
http://gsd.di.uminho.pt/jpo/software/fedora/

(In reply to comment #2)
> Paul,
> 
> I don't feel confortable creating a bundle of Log::Dispatch,
> Log::Dispatch::FileRotate, and Log::Log4perl because:
> 
>  i) these three perl distros are maintained by different people (the three
> DateTime modules that have been bundled are all maintained by Dave Rolsky)
> 
>   ii) the circular dependencies are only caused by the test suite
> as this module only extends Log::Dispatch but uses Log::Log4perl as it
> main log infrastructure in the test suite (most likely, the test suite
> should be redone using only Log::Dispatch or, at least, conditional
> require Log::Log4perl).
> 
> iii) The author of Log::Dispatch::FileRotate doesn't appear to be very
> responsive, at leasat judging from the rt tickets
> (http://rt.cpan.org/NoAuth/Bugs.html?Dist=Log-Dispatch-FileRotate); at least I
> haven't got any answer for #14563.

OK, that's fair enough.

Is there a precedent in Extras for calling perl modules (or anything else for
that matter) "distributable" in the absence of any specific licensing terms
being included upstream?

Looking at rt for this module, the author appears to be completely unresponsive
to rt tickets. Perhaps it's worth trying to contact him directly?

(In reply to comment #3)
> (In reply to comment #2)

> Is there a precedent in Extras for calling perl modules (or anything else for
> that matter) "distributable" in the absence of any specific licensing terms
> being included upstream?
Absence of copyright and licensing always means "legally questionable/use at
your own risk",
c.f. http://www.debian.org/doc/debian-policy/ch-archive.html#s-pkgcopyright

=> This package probably qualifies as non-distributable.

Another indication for the same, is this package seemingly missing from Debian
(at least I could not find it).

(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> 
> > Is there a precedent in Extras for calling perl modules (or anything else for
> > that matter) "distributable" in the absence of any specific licensing terms
> > being included upstream?
> Absence of copyright and licensing always means "legally questionable/use at
> your own risk",
> c.f. http://www.debian.org/doc/debian-policy/ch-archive.html#s-pkgcopyright
> 
> => This package probably qualifies as non-distributable.
> 
> Another indication for the same, is this package seemingly missing from Debian
> (at least I could not find it).

Isn't CPAN an exception?
Every author that opens an account in PAUSE and submits files to it knows that
they will be heavely mirrored (right now CPAN has more than 260 official mirrors).

Fedora Core perl packages with "Distributable" license
------------------------------------------------------
distributable perl-Compress-Zlib
Distributable perl-File-MMagic
distributable perl-Net-Telnet
Distributable perl-TermReadKey
Distributable perl-URI
distributable perl-XML-Grove

Fedora Extras perl packages with "Distributable" license
--------------------------------------------------------
Distributable perl-Class-DBI-Loader-Relationship
Distributable perl-Crypt-Blowfish
Distributable perl-Lingua-EN-Inflect-Number
Distributable perl-Mail-Sender
Distributable perl-Mail-Sendmail
Distributable perl-Time-modules
Distributable perl-UNIVERSAL-exports

PS - Haven't checked their licenses but I remembered one or two Maypole
requirements being approved with a Distributable license due to lack of
license information.

(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > (In reply to comment #2)
> > 
> > > Is there a precedent in Extras for calling perl modules (or anything else for
> > > that matter) "distributable" in the absence of any specific licensing terms
> > > being included upstream?
> > Absence of copyright and licensing always means "legally questionable/use at
> > your own risk",
> > c.f. http://www.debian.org/doc/debian-policy/ch-archive.html#s-pkgcopyright
> > 
> > => This package probably qualifies as non-distributable.
> > 
> > Another indication for the same, is this package seemingly missing from Debian
> > (at least I could not find it).
> 
> Isn't CPAN an exception?
Well, may-be ... CPAN modules/dists definitely are well known to be widely used
on various platforms, which might qualify all submissions as "implicitly
licenced Perl, unless otherwise stated", but I would not bet on this.
Courts probably would have to decide "in case", but I even doubt there is a
precedence for such cases.

All I can say, to be on the safe side as a packager, each package must be
covered by _both_ a Copyright and a License notice. However, as only copyright
holders are legitmated to sue you, it probably would have to be this
perl-module's author to do so ;)

I.e. I think, the risk of being sued for shipping/packaging this package is very
low, however I don't think this package fulfills Fedora's narrow licensing
contraints.

May-be somebody from "Legal" will have give a statement on "if distribution
perl-modules through CPAN implies licensed Perl unless otherwise stated"
(I am inclined to think so.)

(In reply to comment #6)

> May-be somebody from "Legal" will have give a statement on "if distribution
> perl-modules through CPAN implies licensed Perl unless otherwise stated"
> (I am inclined to think so.)
My inclination seems to be wrong. 
c.f. http://www.cpan.org/misc/cpan-faq.html#How_is_Perl_licensed

Ralf,
Thanks for the above link. 
I have just "pinged" the author.

I haven't receive any answer until now. I used the email listed
in the author's CPAN page (http://search.cpan.org/~markpf/).

Perhaps a contributor in Australia could be persuaded to give them a call? 
Their phone number can be found via their CPAN page.

I managed to contact the author through the email (eds.com) I found in this post
http://www.nntp.perl.org/group/perl.cpan.testers/69402.

The answer was that the license was the same as perl. He also replied and closed
the RT ticket I had on the subject:
http://rt.cpan.org/Public/Bug/Display.html?id=14563.

jpo

http://gsd.di.uminho.pt/jpo/software/fedora/perl-Log-Dispatch-FileRotate-1.13-2.src.rpm

Changelog:
* Mon Apr 24 2006 Jose Pedro Oliveira <jpo at di.uminho.pt> - 1.13-2
- The license is: GPL or Artistic.
  License information: http://rt.cpan.org/Public/Bug/Display.html?id=14563.

http://gsd.di.uminho.pt/jpo/software/fedora/perl-Log-Dispatch-FileRotate-1.14-1.src.rpm

Log-Dispatch-FileRotate 1.14 released a couple of hours ago.
The copyright section in the main pod page only mentions the Artistic license.

Is anyone reviewing this package?  I don't think so, but it's not assigned to
the usual "unassigned" address.

I'll pick it up later today unless someone chimes in.

(In reply to comment #14)
> Is anyone reviewing this package?  I don't think so, but it's not assigned to
> the usual "unassigned" address.
> 
> I'll pick it up later today unless someone chimes in.

It's on my to-do list but I'm a bit busy today. Feel free to take it.

I have a few minutes free and this is a simple package, so:

* package meets naming and packaging guidelines.
* specfile is properly named, is cleanly written and uses macros consistently
and follows the Perl specfile template.
* license field matches the actual license.
* license is open source-compatible. It's not included separately in the
package, but this is not necessary as the upstream tarball does not include it.
* source files match upstream:
   b7cc69172d5c8b1a34c429d738bc3fa5  Log-Dispatch-FileRotate-1.14.tar.gz
   b7cc69172d5c8b1a34c429d738bc3fa5  Log-Dispatch-FileRotate-1.14.tar.gz-srpm
* BuildRequires are proper.
* package builds in mock (development, x86_64).
* rpmlint is silent.
* final provides and requires are sane.
* no shared libraries are present.
* package is not relocatable.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* %clean is present.
O %check is present but necessarily disabled.
* code, not content.
* documentation is small, so no -docs subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* no headers.
* no pkgconfig files.
* no libtool .la droppings.
* not a GUI app.

APPROVED

Thanks for the review.

Imported and built for FC-4, FC-5, and devel.

License update
--------------
After having contacted the author about the license mismatch, he released a new
version of Log-Dispatch-FileRotate: the license in version 1.15 is now "GPL or
Artistic".

Package Change Request
======================
Package Name: perl-Log-Dispatch-FileRotate
New Branches: EL-4 EL-5
Owners: steve

cvs done.