On Sun, Oct 11, 2009 at 8:59 PM, Ricardo Signes
<perl.cpanw...@rjbs.manxome.org> wrote:
> I am also happy to add a meta2_name method to all the Software::License
> classes
> to avoid a direct connection between SL and META, but I don't want to keep
> using the unsatisfactory list from the current spec.
I didn't realize they were ambiguous. What I really would prefer is
to go the other way.
my $obj = Software::License->new('artistic_2');
my $obj = Software::License->new(''bsd');
How's this for a proposed mapping? The keys on the left are what we would
put in the META spec and the mapping would get implemented in Software::License
to make it easy to look up things in the license field. The rule I'm
following is
that the "first" entry for a family has no version number and subsequent ones
are have a version separated by an underscore. This is consistent with
how artistic and artistic_2 appear in Module::Build::API now (which is what
the current spec references). I've put an asterisk to mark currently
documented keys[1]:
agpl => Software::License::AGPL_3
* apache => Software::License::Apache_1_1
apache_2 => Software::License::Apache_2_0
* artistic => Software::License::Artistic_1_0
* artistic_2 => Software::License::Artistic_2_0
* bsd => Software::License::BSD
freebsd => Software::License::FreeBSD
gfdl => Software::License::GFDL_1_2
gfdl_1_3 => [ not yet written ]
* gpl => Software::License::GPL_1
gpl_2 => Software::License::GPL_2
gpl_3 => Software::License::GPL_3
* lgpl => Software::License::LGPL_2_1
lgpl_3_0 => Software::License::LGPL_3_0
* mit => Software::License::MIT
* mozilla => Software::License::Mozilla_1_0
mozilla_1_1 => Software::License::Mozilla_1_1
openssl => Software::License::OpenSSL
* perl => Software::License::Perl_5
qpl => Software::License::QPL_1_0
ssleay => Software::License::SSLeay
sun => Software::License::Sun
zlib => Software::License::Zlib
* open_source (n/a)
* restrictive (n/a)
* unrestricted (n/a)
* unknown (n/a)
[1] M::B has other, undocumented keys it accepts, which I will eliminate
in favor of the keys above if this proposal is accepted. If that breaks things
for some people, well, sucks to be them for using undocumented features.
For backwards compatibility, I propose leaving the old open_source,
etc, keys alone rather than renaming them.
Once a year or so, we can add new Software::License classes to the
Spec list, if we need to. Thankfully, lawyers release new licenses a
lot less often that CPAN authors release new distributions. :-)
-- David
