Re: Documentation: "How to get a CPAN module into debian"
> On Wed, 06 Aug 2008 21:14:18 +0300, Gabor Szabo wrote:
>
> > > Also, "write clean copyright and licensing statements".
> > We have been in this discussion already. The above request is
> > too vague. I don't understand what that means to you.
>
> I'm no expert in copyright/license stuff but IMO we need:
> * An explict copyright statement in the form
> "Copyright YYYY (- YYYY) $copyrightholder(s)"
> * and an explicit license
I am no expert either but an explicit copyright assignment with a
name and email address would go a long way to solving this problem I
feel, there are modules that do not do this, or there used to be.
> What I see every now and then is that a module has "AUTHOR(S)" and
> "LICENSE" but no COPYRIGHT, or a COPYRIGHT header but then a license,
> or some other similar stuff.
>
> Also helpful are consistent informations -- i.e. not having various
> different years (of course year can differ for different files but if
> there is just one .pm file and it has different informations then the
> README, that's confusing).
Can CPANTS maybe have a test for a LICENSE and COPYRIGHT file gabor?
It seems likely that the debian perl group will be moving to a
machine parseable copyright file format so perhaps there is an
opportunity here to extend that format upstream into CPAN for
simplicity's sake? Both groups (debian and perl) would benefit from a
clear, simple copyright file format - it makes the license stronger.
> > Jim Brandt from TPF promised me on YAPC::NA to check how
> > and where one should declare "the same license as perl"
> > to make it strong enough to be defendable.
> > I am expecting an exact phrasing of the sentence or sentences.
> > Once we get that you too will be able to point CPAN authors
> > to that statement and I hope we can add this check to CPANTS.
It sure would be great if some of the "Free Software" distros like
OpenBSD, debian, and fedora could give input on this since it affects
them the most - perl developers sometimes seem oblivious to licensing
issues.
> > There is a chicken and egg problem here.
> > In short: because many modules are missing people use alternative ways
> > and then don't ask for modules to be included. So you don't see the requests.
This is actually a problem that debian and perl share; the DARKPAN
and mystery debs.
Perl gets blamed for bad code written by people who don't follow
community best practices. Debian gets blamed for buggy software
created by people who do not get their debs uploaded into debian but
build them locally and make them available via a local repo. It is
difficult for the CPAN and debian mechanisms to provide security and
support for this type of software.
I think perl developers need to know how to get a module of theirs
into debian and debian should judge whether or not they want to
package it - there is no point in packaging all of CPAN or thirty
"small web servers" or the latest perl interface to social web site
#1499583.
I think the release of lenny will go a long way to solving this
problem. Debian will now have a significant number of highly useful
perl modules along with perl 5.10 and the benefits of the debian-perl
group will become more obvious to users, or at least those who write
perl software on debian, which I imagine is quite a few users. Once
people realize that you can get a perl module with operating system
dependency checking, security and bug tracking support, along with
debian's reputation for stability, that will be a winning combination
and I think you will see more people requesting debian to do the work
instead of people rolling their own solutions.
Hopefully debian-perl is the egg, and people will soon realize it has
grown into a lovely chicken.
Jeremiah
Reply to: