note license: gplv2 vs. the gpl-3.0.txt link trs++

[kevindawson]

diff --git a/META.yml b/META.yml
index cefd6f4..b6129c8 100644
--- a/META.yml
+++ b/META.yml
@@ -8,7 +8,7 @@ configure_requires:
ExtUtils::MakeMaker: 6.36
distribution_type: module
dynamic_config: 1
-generated_by: 'Module::Install version 1.06'
+generated_by: 'Module::Install version 1.10'
license: gplv2
meta-spec:
url: http://module-build.sourceforge.net/META-spec-v1.4.html
@@ -21,5 +21,5 @@ no_index:
requires:
List::MoreUtils: 0
resources:

• license: http://opensource.org/licenses/gpl-license.php
• license: http://www.gnu.org/licenses/gpl-3.0.txt
  version: 0.01

[mohawk2]

Would it be a lot of work to make a pull-request with this?

[kevindawson]

mohawk2

I have just refreshed my memory of this topic, and am going to dump some more info here for discussion

[kevindawson]

the following is taken from M::I v1.08
Module::Install::Metadata

#Stolen from M::B
my %license_urls = (
    perl         => 'http://dev.perl.org/licenses/',
    apache       => 'http://apache.org/licenses/LICENSE-2.0',
    apache_1_1   => 'http://apache.org/licenses/LICENSE-1.1',
    artistic     => 'http://opensource.org/licenses/artistic-license.php',
    artistic_2   => 'http://opensource.org/licenses/artistic-license-2.0.php',
    lgpl         => 'http://opensource.org/licenses/lgpl-license.php',
    lgpl2        => 'http://opensource.org/licenses/lgpl-2.1.php',
    lgpl3        => 'http://opensource.org/licenses/lgpl-3.0.html',
    bsd          => 'http://opensource.org/licenses/bsd-license.php',
    gpl          => 'http://opensource.org/licenses/gpl-license.php',
    gpl2         => 'http://opensource.org/licenses/gpl-2.0.php',
    gpl3         => 'http://opensource.org/licenses/gpl-3.0.html',
    mit          => 'http://opensource.org/licenses/mit-license.php',
    mozilla      => 'http://opensource.org/licenses/mozilla1.1.php',
    open_source  => undef,
    unrestricted => undef,
    restrictive  => undef,
    unknown      => undef,
);

[kevindawson]

the above hash has been in M::I for over 4 years with little modification :(

[kevindawson]

from CPAN::Meta::Spec

meta-2 license info

    One or more licenses that apply to some or all of the files in the
    distribution. If multiple licenses are listed, the distribution
    documentation should be consulted to clarify the interpretation of
    multiple licenses.

    The following list of license strings are valid:

     string          description
     -------------   -----------------------------------------------
     agpl_3          GNU Affero General Public License, Version 3
     apache_1_1      Apache Software License, Version 1.1
     apache_2_0      Apache License, Version 2.0
     artistic_1      Artistic License, (Version 1)
     artistic_2      Artistic License, Version 2.0
     bsd             BSD License (three-clause)
     freebsd         FreeBSD License (two-clause)
     gfdl_1_2        GNU Free Documentation License, Version 1.2
     gfdl_1_3        GNU Free Documentation License, Version 1.3
     gpl_1           GNU General Public License, Version 1
     gpl_2           GNU General Public License, Version 2
     gpl_3           GNU General Public License, Version 3
     lgpl_2_1        GNU Lesser General Public License, Version 2.1
     lgpl_3_0        GNU Lesser General Public License, Version 3.0
     mit             MIT (aka X11) License
     mozilla_1_0     Mozilla Public License, Version 1.0
     mozilla_1_1     Mozilla Public License, Version 1.1
     openssl         OpenSSL License
     perl_5          The Perl 5 License (Artistic 1 & GPL 1 or later)
     qpl_1_0         Q Public License, Version 1.0
     ssleay          Original SSLeay License
     sun             Sun Internet Standards Source License (SISSL)
     zlib            zlib License

    The following license strings are also valid and indicate other licensing
    not described above:

     string          description
     -------------   -----------------------------------------------
     open_source     Other Open Source Initiative (OSI) approved license
     restricted      Requires special permission from copyright holder
     unrestricted    Not an OSI approved license, but not restricted
     unknown         License not provided in metadata

    All other strings are invalid in the license field.

[kevindawson]

extracted from Software::License
meta 1.x names

apache => 'http://www.apache.org/licenses/LICENSE-1.1',
apache => 'http://www.apache.org/licenses/LICENSE-2.0.txt',
artistic => 'http://www.perlfoundation.org/artistic_license_1_0',
artistic_2 => 'http://www.perlfoundation.org/artistic_license_2_0',
bsd => 'http://opensource.org/licenses/BSD-3-Clause',
gpl => 'http://www.gnu.org/licenses/gpl-3.0.txt',
gpl => 'http://www.gnu.org/licenses/old-licenses/gpl-1.0.txt',
gpl => 'http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt',
lgpl => 'http://www.gnu.org/licenses/lgpl-3.0.txt',
lgpl => 'http://www.gnu.org/licenses/old-licenses/lgpl-2.1.txt',
mit => 'http://www.opensource.org/licenses/mit-license.php',
mozilla => 'http://www.mozilla.org/MPL/MPL-1.0.txt',
mozilla => 'http://www.mozilla.org/MPL/MPL-1.1.txt',
open_source => 'http://trolltech.com/products/qt/licenses/licensing/qpl',
open_source => 'http://www.freebsd.org/copyright/freebsd-license.html',
open_source => 'http://www.gnu.org/licenses/agpl-3.0.txt',
open_source => 'http://www.gnu.org/licenses/fdl-1.2.txt',
open_source => 'http://www.gnu.org/licenses/fdl-1.3.txt',
open_source => 'http://www.openoffice.org/licenses/sissl_license.html',
open_source => 'http://www.openssl.org/source/license.html',
open_source => 'http://www.zlib.net/zlib_license.html',
perl => 'http://dev.perl.org/licenses/',
unrestricted => 'http://h71000.www7.hp.com/doc/83final/BA554_90007/apcs02.html',

[mohawk2]

That seems like the tests aren't catching what the meta spec says is/isn't valid.

[kevindawson]

thus if we only allow meta 1.x names that are checkable via Software::License
consolidate the two lists
remove the duplicates in favour of the latest

we get the following

apache       => 'http://www.apache.org/licenses/LICENSE-2.0.txt',
artistic     => 'http://www.perlfoundation.org/artistic_license_1_0',
artistic_2   => 'http://www.perlfoundation.org/artistic_license_2_0',
bsd          => 'http://opensource.org/licenses/BSD-3-Clause',
gpl          => 'http://www.gnu.org/licenses/gpl-3.0.txt',
lgpl         => 'http://www.gnu.org/licenses/lgpl-3.0.txt',
mit          => 'http://www.opensource.org/licenses/mit-license.php',
mozilla      => 'http://www.mozilla.org/MPL/MPL-1.1.txt',
open_source  => undef,
perl         => 'http://dev.perl.org/licenses/',
unrestricted => undef,
restrictive  => undef,
unknown      => undef,

[kevindawson]

hence
if we go back to the beginning

license: gplv2

M::I should have barfed - unknown license name

[kevindawson]

comments please :)

[mohawk2]

How authoritative is the CPAN::Meta::Spec you're citing?

[kevindawson]

mohawk2

as far as I can tell, the current tool-chain uses it as it's reference.

Software::License uses it as it's reference

so i just followed suit

I think the main issues here is that the info in pre M:I v1.10 is over 4 years old ( might be out of date now )

[mohawk2]

Does anyone disagree that the code should follow the spec, and should be tested that it is doing so?

[kevindawson]

no I have not received any comments either way

I made an assumption, to move forward
not add any more dependences to M::I and try to follow the spec

I think we are at a point were a con-censors is required as to the way forward
or just roll back and be backward compatible with updated URLs

thoughts ?

[tsibley]

At the very least, the breaking changes (d965d3e, 1f9655b, c9446dd) need to be reverted and a new release made until the desired, backward compatible behaviour is sorted out.

[tsibley]

A PR reverting those commits is #30.

[kevindawson]

from M::I pod

license
      license 'perl';

    The "license" command specifies the license for the distribution.

    Most often this value will be 'perl', meaning "the same as for Perl
    itself". Other allowed values include 'gpl', 'lgpl', 'bsd', 'MIT', and
    'artistic'.

    This value is always considered a summary, and it is normal for authors to
    include a LICENSE file in the distribution, containing the full license
    for the distribution.

    You are also reminded that if the distribution is intended to be uploaded
    to the CPAN, it must be an OSI-approved open source license. Commercial
    software is not permitted on the CPAN.

[kevindawson]

my current thought is to implement the following

apache       => undef
artistic     => 'http://www.perlfoundation.org/artistic_license_1_0',
artistic_2   => 'http://www.perlfoundation.org/artistic_license_2_0',
bsd          => 'http://opensource.org/licenses/BSD-3-Clause',
gpl          => undef,
lgpl         => undef,
mit          => 'http://www.opensource.org/licenses/mit-license.php',
mozilla      => undef,
open_source  => undef,
perl         => 'http://dev.perl.org/licenses/',
unrestricted => undef,
restrictive  => undef,
unknown      => undef,

[kevindawson]

if we follow CPAN::META::Spec

   resources
    Example:

      resources => {
        license     => [ 'http://dev.perl.org/licenses/' ],
        homepage    => 'http://sourceforge.net/projects/module-build',
        bugtracker  => {
          web    => 'http://rt.cpan.org/Public/Dist/Display.html?Name=CPAN-Meta',
          mailto => '[email protected]',
        },
        repository  => {
          url  => 'git://github.com/dagolden/cpan-meta.git',
          web  => 'http://github.com/dagolden/cpan-meta',
          type => 'git',
        },
        x_twitter   => 'http://twitter.com/cpan_linked/',
      }

    (Spec 2) [optional] {Map}

resources.license: [optional]

so there should be no way M::I would right an incorrect - resources.license

plus a barf when an Author uses an unapproved license as per pod.

[tsibley]

@kevindawson While not writing a resources.license is indeed an option, it seems like a crappy one since it's a feature loss.

Also, your statement that "plus a barf when an Author uses an unapproved license as per pod." concerns me because M::I should have no place in deciding an "approved" license. Note that the M::I pod you quote says, "Other allowed values include" (emphasis mine). It doesn't say, "Other allowed values are".

Can you tell me what's wrong with simply reverting your commits, as PR #30 does, and then only updating the few license urls that have changed rather than completely changing behaviour in a stable release?

I see no reason why we can't preserve backwards compat and update license information where it's out of date.

[haarg]

A more relevant place to look for the meta v1 names would be the v1.4 spec which references Module::Build::API.

[kevindawson]

haarg, thanks for the link

the following is from Module::Build::API.

        license
            [version 0.07]

            Specifies the licensing terms of your distribution.

            As of Module::Build version 0.36_14, you may use a
            Software::License subclass name (e.g. 'Apache_2_0') instead of one
            of the keys below.

            The legacy list of valid license values include:

            apache
                The distribution is licensed under the Apache License, Version
                2.0 (<http://apache.org/licenses/LICENSE-2.0>).

            apache_1_1
                The distribution is licensed under the Apache Software
                License, Version 1.1
                (<http://apache.org/licenses/LICENSE-1.1>).

            artistic
                The distribution is licensed under the Artistic License, as
                specified by the Artistic file in the standard Perl
                distribution.

            artistic_2
                The distribution is licensed under the Artistic 2.0 License
                (<http://opensource.org/licenses/artistic-license-2.0.php>.)

            bsd The distribution is licensed under the BSD License
                (<http://www.opensource.org/licenses/bsd-license.php>).

            gpl The distribution is licensed under the terms of the GNU
                General Public License
                (<http://www.opensource.org/licenses/gpl-license.php>).

            lgpl
                The distribution is licensed under the terms of the GNU Lesser
                General Public License
                (<http://www.opensource.org/licenses/lgpl-license.php>).

            mit The distribution is licensed under the MIT License
                (<http://opensource.org/licenses/mit-license.php>).

            mozilla
                The distribution is licensed under the Mozilla Public License.
                (<http://opensource.org/licenses/mozilla1.0.php> or
                <http://opensource.org/licenses/mozilla1.1.php>)

            open_source
                The distribution is licensed under some other Open Source
                Initiative-approved license listed at
                <http://www.opensource.org/licenses/>.

            perl
                The distribution may be copied and redistributed under the
                same terms as Perl itself (this is by far the most common
                licensing option for modules on CPAN). This is a dual license,
                in which the user may choose between either the GPL or the
                Artistic license.

            restrictive
                The distribution may not be redistributed without special
                permission from the author and/or copyright holder.

            unrestricted
                The distribution is licensed under a license that is not
                approved by www.opensource.org but that allows distribution
                without restrictions.

            Note that you must still include the terms of your license in your
            code and documentation - this field only sets the information that
            is included in distribution metadata to let automated tools figure
            out your licensing restrictions. Humans still need something to
            read. If you choose to provide this field, you should make sure
            that you keep it in sync with your written documentation if you
            ever change your licensing terms.

            You may also use a license type of "unknown" if you don't wish to
            specify your terms in the metadata.

            Also see the "create_license" parameter.

[kevindawson]

the only issue here is with: apache_1_1

from Software::License

meta_name: apache
meta2_name: apache_1_1

[haarg]

The version of Module::Build::API I linked to is the version that was current when the 1.4 spec was published. In that version, the 'apache' license linked to http://opensource.org/licenses/apachepl.php, which at the time was the 1.1 license.

[kevindawson]

haarg, thanks for the correction,

so just
meta_name: apache
that is ok, then :)

as there is more than one meta_name: apache from Software::License
this means that M::I will not write the resources.license:

and it will be up to the author to append the correct LICENSE file to there distribution

[kevindawson]

haarg, your link is APR 28, 2007

were there any changes to supported meta list, re Oslo