Front page | perl.module-authors |
Postings from March 2008
Re: license in META.yml
From: Gabor Szabo
March 31, 2008 20:01
Re: license in META.yml
Message ID: firstname.lastname@example.org
On Mon, Mar 31, 2008 at 6:28 PM, David Cantrell <email@example.com> wrote:
> On Mon, Mar 24, 2008 at 11:54:01PM +0200, Gabor Szabo wrote:
> > On Mon, Mar 24, 2008 at 11:30 PM, David Landgren <firstname.lastname@example.org> wrote:
> > > Gabor Szabo wrote:
> > > > As I am usually using Module::Build I did not know that a recent
> > > > version of MakeMaker
> > > > has started to support the LICENSE parameter and will include it in
> > > > the automatically
> > > > created META.yml.
> > > That has been the case for a couple of years or so. I think it was first
> > > introduced in 6.30.
> > Now are you telling me... :-)
> > and I have been giving the lack of LICENSE support of MakeMaker as the excuse
> > why so many modules have their Lincense set to Unknown on search.cpan.org.
> In my case it's because I didn't know that it was supported in the
> version of MakeMaker that I use (I didn't even know what version I used
> until just now when I checked) and also because I don't care much. I
> put the licence information in POD. If you care what specific licence I
> use for a piece of code, read the documentation. If you only care that
> it be free software, then you needn't bother, as that's one of the
> pre-requisites for something being on the CPAN.
Besides the point that AFAIK there is no requirement on PAUSE/CPAN that
everything must be OSI licensed, there are huge differences between
free and free too.
On one hand you as the author are free to decide which license to use
on the other hand the distributors and the end users are free to decide which
license they accept and which not.
Their reasons might not make sense to you or me but that's beyond this
The distributors (e.g. Fedora, Debian) have their own rules of what do
(e.g. Fedora will not package anything that is Artistic 1 only -
without the GPL).
Both Fedora and Debian wants to make sure the licenses are correctly
(to whatever value of correct) are spelled out. AFAIK they care more
about the textual license
than the META.yml field. The latter is a mere convenience for someone
who wants to
to easily automate the filtering of modules.
When I had to put about 100 modules through the legal department of a company
I really wished I had an easy and automatable method of gathering this
One of the drawback of nature of CPAN is the lack of standardization.
I don't want to standardize what license you use, I just wish there
was an easy way to know
what are you using.
Also it does not have cover all the modules but I don't think there
are more than 10%
that need special treatment.
When installing and using module X I have the time reading its docs
and license but
I am quite sure I won't have time to do so with its 20-40 dependencies.
On one hand I don't care how the dependencies work as long as the
module I am using works.
On the other hand I still need to make sure the licenses of all the
dependencies are acceptable
by whatever organization I working for.
Eg. can I use Moose?
There is this nice site you might be familiar with
that shows the dependencies of a module and the likeliness it will be able to
install on your system.
But should I bother installing it or is one of its dependencies
the requirements of whatever organization I do it for?
> >  Among others I have talked to the Debian and Fedora packagers and
> > they both said that one of the problematic issues with CPAN modules is
> > the lack or incorrect license information.
> How can they possibly determine whether a licence is correct or not?
I don't know and I hope to work with them more in order to find out how do
they determine that. If we can help them make their work easier
without a lot of work on our side then we can make the life of our end users
easier. (which in turn will bring more nice bug reports to us :-)