* Ken Williams <[EMAIL PROTECTED]> [2008-11-03T09:49:01] > I noticed that, so I actually just provided explicit mappings for the > licenses M::B already knew about:
Cool. You might want to have a look at Software::LicenseUtils, which does a reverse mapping sort of like your forward mapping: http://search.cpan.org/src/RJBS/Software-License-0.008/lib/Software/LicenseUtils.pm my %yaml_keys = ( perl => 'Perl_5', apache => [ map { "Apache_$_" } qw(1_1 2_0) ], artistic => 'Artistic_1_0', artistic_2 => 'Artistic_2_0', lgpl => [ map { "LGPL_$_" } qw(2_1 3_0) ], bsd => 'BSD', gpl => [ map { "GPL_$_" } qw(1 2 3) ], mit => 'MIT', mozilla => [ map { "Mozilla_$_" } qw(1_0 1_1) ], ); That's supposed to cope with the ambiguity of things like 'gpl'. I'll post to the cpan-metadata list about that sometime, although it looks like the problem might be going away soon, effectively > What I would like to do next is make it more of a pure pass-through, > so that anything S::L knows about can be fed to M::B. That might > depend on having a registry in S::L, or it might mean an author could > specify a class name directly, possibly omitting the > "Software::License::" prefix. What I do in Dist::Zilla's license bit is rewrite '=Foo::Bar' to 'Foo::Bar' and 'Foo::Bar' to 'Software::License::Foo::Bar' That allows people to specify a license class in the normal namespace or, if they must, =MyCorp::License::MCPL. I'd love to avoid having a registry, because it will allow people to specify their own internal license and have all the code generate the right files. They don't even need to bundle the library -- heck they don't even NEED to release it to CPAN, because M::B will create the right LICENSE file. (...and if they do release it, that's great too!) -- rjbs
