Skip Menu |
 

This queue is for tickets about the Module-Build CPAN distribution.

Report information
The Basics
Id: 79587
Status: open
Priority: 0/
Queue: Module-Build

People
Owner: Nobody in particular
Requestors: victor [...] vsespb.ru
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: gpl3 license not recognized
Date: Wed, 12 Sep 2012 13:44:52 +0400
To: bug-Module-Build [...] rt.cpan.org
From: Victor Efimov <victor [...] vsespb.ru>
Download (untitled) / with headers
text/plain 672b
Module::Build v0.4003 reports unknown license, however I specified it as Software::License::GPL_3, also does not work with "gpl3" it works almost fine with "GPL_3", but generates wrong MYMETA.json ( "license: gpl" ), no bug in MYMETA.yml example of META.yml --- abstract: 'Amazon Glacier TreeHash algorithm' author: - 'Victor Efimov' configure_requires: Module::Build: 0.4003 generated_by: 'Module::Build' license: gpl3 meta-spec: url: http://module-build.sourceforge.net/META-spec-v1.4.html version: 1.4 name: Net-Amazon-TreeHash provides: Net::Amazon::TreeHash: file: lib/Net/Amazon/TreeHash.pm version: 0.71 requires: Digest::SHA: 0 version: 0.71
Download (untitled) / with headers
text/plain 923b
Victor, the M::B license parameter must be a subclass name, i.e. C<GPL_3>, see L<http://p3rl.org/Module::Build::API#license> and F<lib/Module/Build/Base.pm> +4481. diff --git a/Build.PL b/Build.PL index 1cdf914..7d5af64 100644 --- a/Build.PL +++ b/Build.PL @@ -12,7 +12,7 @@ my $build = Module::Build->new( recursive_test_files=>1, dist_abstract=>'Amazon Glacier TreeHash algorithm', - license => 'Software::License::GPL_3', + license => 'GPL_3', requires => { 'Digest::SHA' => 0, } Maintainers, however, that still fails. S::L::GPL_3 returns the M::B::API string C<gpl>, which CPAN::Meta::Converter then upgrades to C<open_source>. AFAICT this is all working as designed, and the real solution is to change M::B to natively handle meta spec v2 compliant structs so that the legacy licence handling can be removed.
Download (untitled) / with headers
text/plain 1.1k
On Mon Apr 29 07:54:03 2013, DAXIM wrote: Show quoted text
> Victor, the M::B license parameter must be a subclass name, i.e. > C<GPL_3>, see L<http://p3rl.org/Module::Build::API#license> and > F<lib/Module/Build/Base.pm> +4481. > > diff --git a/Build.PL b/Build.PL > index 1cdf914..7d5af64 100644 > --- a/Build.PL > +++ b/Build.PL > @@ -12,7 +12,7 @@ my $build = Module::Build->new( > > recursive_test_files=>1, > dist_abstract=>'Amazon Glacier TreeHash algorithm', > - license => 'Software::License::GPL_3', > + license => 'GPL_3', > requires => { > 'Digest::SHA' => 0, > } > > > Maintainers, however, that still fails. S::L::GPL_3 returns the > M::B::API string C<gpl>, which CPAN::Meta::Converter then upgrades > to C<open_source>. AFAICT this is all working as designed, and the > real solution is to change M::B to natively handle meta spec v2 > compliant structs so that the legacy licence handling can be > removed.
Yeah, rewriting the meta support from scratch would fix an awful lot of issues. It's fairly inevitable, but non-trivial and tricky to do without breaking too much backwards-compatibility. Leon
From: victor [...] vsespb.ru
Download (untitled) / with headers
text/plain 1.4k
Nope, seems 'GPL_3' recognized as 'open_source' license, example http://search.cpan.org/~vsespb/App-MtAws-0.957/ On Mon Apr 29 21:39:08 2013, LEONT wrote: Show quoted text
> On Mon Apr 29 07:54:03 2013, DAXIM wrote:
> > Victor, the M::B license parameter must be a subclass name, i.e. > > C<GPL_3>, see L<http://p3rl.org/Module::Build::API#license> and > > F<lib/Module/Build/Base.pm> +4481. > > > > diff --git a/Build.PL b/Build.PL > > index 1cdf914..7d5af64 100644 > > --- a/Build.PL > > +++ b/Build.PL > > @@ -12,7 +12,7 @@ my $build = Module::Build->new( > > > > recursive_test_files=>1, > > dist_abstract=>'Amazon Glacier TreeHash algorithm', > > - license => 'Software::License::GPL_3', > > + license => 'GPL_3', > > requires => { > > 'Digest::SHA' => 0, > > } > > > > > > Maintainers, however, that still fails. S::L::GPL_3 returns the > > M::B::API string C<gpl>, which CPAN::Meta::Converter then
> upgrades
> > to C<open_source>. AFAICT this is all working as designed, and
> the
> > real solution is to change M::B to natively handle meta spec v2 > > compliant structs so that the legacy licence handling can be > > removed.
> > Yeah, rewriting the meta support from scratch would fix an awful lot > of issues. It's fairly inevitable, but non-trivial and tricky to do > without breaking too much backwards-compatibility. > > Leon
From: victor [...] vsespb.ru
Download (untitled) / with headers
text/plain 1.8k
Yes, actually I did not find a way to correctly list module as GPLv3 (even with meta_merge). And I did not find Module::Build+GPLv3 modules on CPAN with correct metadata (another example http://search.cpan.org/~gsb/App-SourcePlot-1.19/ ). Also, when license listed as 'open_source', it does however have correct licenses URL to GPLv3 text. On Tue May 28 03:05:02 2013, vsespb wrote: Show quoted text
> Nope, seems 'GPL_3' recognized as 'open_source' license, example > http://search.cpan.org/~vsespb/App-MtAws-0.957/ > > On Mon Apr 29 21:39:08 2013, LEONT wrote:
> > On Mon Apr 29 07:54:03 2013, DAXIM wrote:
> > > Victor, the M::B license parameter must be a subclass name, i.e. > > > C<GPL_3>, see L<http://p3rl.org/Module::Build::API#license> and > > > F<lib/Module/Build/Base.pm> +4481. > > > > > > diff --git a/Build.PL b/Build.PL > > > index 1cdf914..7d5af64 100644 > > > --- a/Build.PL > > > +++ b/Build.PL > > > @@ -12,7 +12,7 @@ my $build = Module::Build->new( > > > > > > recursive_test_files=>1, > > > dist_abstract=>'Amazon Glacier TreeHash algorithm', > > > - license => 'Software::License::GPL_3', > > > + license => 'GPL_3', > > > requires => { > > > 'Digest::SHA' => 0, > > > } > > > > > > > > > Maintainers, however, that still fails. S::L::GPL_3 returns the > > > M::B::API string C<gpl>, which CPAN::Meta::Converter then
> > upgrades
> > > to C<open_source>. AFAICT this is all working as designed, and
> > the
> > > real solution is to change M::B to natively handle meta spec v2 > > > compliant structs so that the legacy licence handling can be > > > removed.
> > > > Yeah, rewriting the meta support from scratch would fix an awful lot > > of issues. It's fairly inevitable, but non-trivial and tricky to do > > without breaking too much backwards-compatibility. > > > > Leon
> >
From: victor [...] vsespb.ru
Download (untitled) / with headers
text/plain 2.3k
Ok, seems Meta Spec 1.4 does not have GPL 3 at all, so it maps to 'GPL' and then GPL maps to open_source: http://cpansearch.perl.org/src/DAGOLDEN/CPAN-Meta-2.131560/Changes The 1.x spec "gpl" and "lgpl" and "mozilla" license values now up-convert to "open_source" because they indicate too non-specific a license. On Sun Jun 02 12:05:37 2013, vsespb wrote: Show quoted text
> Yes, actually I did not find a way to correctly list module as GPLv3 > (even with meta_merge). And I did not find Module::Build+GPLv3 > modules on CPAN with correct metadata (another example > http://search.cpan.org/~gsb/App-SourcePlot-1.19/ ). > > Also, when license listed as 'open_source', it does however have > correct licenses URL to GPLv3 text. > > On Tue May 28 03:05:02 2013, vsespb wrote:
> > Nope, seems 'GPL_3' recognized as 'open_source' license, example > > http://search.cpan.org/~vsespb/App-MtAws-0.957/ > > > > On Mon Apr 29 21:39:08 2013, LEONT wrote:
> > > On Mon Apr 29 07:54:03 2013, DAXIM wrote:
> > > > Victor, the M::B license parameter must be a subclass name, i.e. > > > > C<GPL_3>, see L<http://p3rl.org/Module::Build::API#license>
> and
> > > > F<lib/Module/Build/Base.pm> +4481. > > > > > > > > diff --git a/Build.PL b/Build.PL > > > > index 1cdf914..7d5af64 100644 > > > > --- a/Build.PL > > > > +++ b/Build.PL > > > > @@ -12,7 +12,7 @@ my $build = Module::Build->new( > > > > > > > > recursive_test_files=>1, > > > > dist_abstract=>'Amazon Glacier TreeHash algorithm', > > > > - license => 'Software::License::GPL_3', > > > > + license => 'GPL_3', > > > > requires => { > > > > 'Digest::SHA' => 0, > > > > } > > > > > > > > > > > > Maintainers, however, that still fails. S::L::GPL_3 returns the > > > > M::B::API string C<gpl>, which CPAN::Meta::Converter then
> > > upgrades
> > > > to C<open_source>. AFAICT this is all working as designed,
> and
> > > the
> > > > real solution is to change M::B to natively handle meta spec
> v2
> > > > compliant structs so that the legacy licence handling can be > > > > removed.
> > > > > > Yeah, rewriting the meta support from scratch would fix an awful
> lot
> > > of issues. It's fairly inevitable, but non-trivial and tricky to
> do
> > > without breaking too much backwards-compatibility. > > > > > > Leon
> > > >
> >
From: victor [...] vsespb.ru
Download (untitled) / with headers
text/plain 2.7k
I suddenly found that M:B supports Meta-Spec v2, so license should be open_source in meta.yml (meta-spec v1.4) and 'gpl_3' in meta.json (meta-spec v2). While currently both are "open_source". On Thu Jun 06 13:59:56 2013, vsespb wrote: Show quoted text
> Ok, seems Meta Spec 1.4 does not have GPL 3 at all, so it maps to > 'GPL' and then GPL maps to open_source: > > http://cpansearch.perl.org/src/DAGOLDEN/CPAN-Meta-2.131560/Changes > > The 1.x spec "gpl" and "lgpl" and "mozilla" license values now up- > convert > to "open_source" because they indicate too non-specific a license. > > > On Sun Jun 02 12:05:37 2013, vsespb wrote:
> > Yes, actually I did not find a way to correctly list module as GPLv3 > > (even with meta_merge). And I did not find Module::Build+GPLv3 > > modules on CPAN with correct metadata (another example > > http://search.cpan.org/~gsb/App-SourcePlot-1.19/ ). > > > > Also, when license listed as 'open_source', it does however have > > correct licenses URL to GPLv3 text. > > > > On Tue May 28 03:05:02 2013, vsespb wrote:
> > > Nope, seems 'GPL_3' recognized as 'open_source' license, example > > > http://search.cpan.org/~vsespb/App-MtAws-0.957/ > > > > > > On Mon Apr 29 21:39:08 2013, LEONT wrote:
> > > > On Mon Apr 29 07:54:03 2013, DAXIM wrote:
> > > > > Victor, the M::B license parameter must be a subclass name,
> i.e.
> > and
> > > > > F<lib/Module/Build/Base.pm> +4481. > > > > > > > > > > diff --git a/Build.PL b/Build.PL > > > > > index 1cdf914..7d5af64 100644 > > > > > --- a/Build.PL > > > > > +++ b/Build.PL > > > > > @@ -12,7 +12,7 @@ my $build = Module::Build->new( > > > > > > > > > > recursive_test_files=>1, > > > > > dist_abstract=>'Amazon Glacier TreeHash algorithm', > > > > > - license => 'Software::License::GPL_3', > > > > > + license => 'GPL_3', > > > > > requires => { > > > > > 'Digest::SHA' => 0, > > > > > } > > > > > > > > > > > > > > > Maintainers, however, that still fails. S::L::GPL_3 returns
> the
> > > > > M::B::API string C<gpl>, which CPAN::Meta::Converter then
> > > > upgrades
> > > > > to C<open_source>. AFAICT this is all working as designed,
> > and
> > > > the
> > > > > real solution is to change M::B to natively handle meta
> spec
> > v2
> > > > > compliant structs so that the legacy licence handling can
> be
> > > > > removed.
> > > > > > > > Yeah, rewriting the meta support from scratch would fix an awful
> > lot
> > > > of issues. It's fairly inevitable, but non-trivial and tricky to
> > do
> > > > without breaking too much backwards-compatibility. > > > > > > > > Leon
> > > > > >
> > > >
> >
Subject: Re: [rt.cpan.org #79587] gpl3 license not recognized
Date: Thu, 6 Jun 2013 20:50:41 +0200
To: bug-Module-Build [...] rt.cpan.org
From: Leon Timmermans <fawaka [...] gmail.com>
Download (untitled) / with headers
text/plain 461b
On Thu, Jun 6, 2013 at 8:41 PM, Victor Efimov via RT <bug-Module-Build@rt.cpan.org> wrote: Show quoted text
> I suddenly found that M:B supports Meta-Spec v2, so > license should be open_source in meta.yml (meta-spec v1.4) and 'gpl_3' in meta.json (meta-spec v2). > > While currently both are "open_source".
The current meta systems takes 1.4 as input, upconverts it to the 2.0 model. The META.yml output is actually downconverted from that, which explains your results. Leon


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.