FAQ
I know most of you don't want to think about this or don't care at all
but others do.
So I'd like to clean things up a bit in the way CPAN modules are licensed.
Let's think about it as a necessary evil...

While I respect the right of everyone writing whatever they want as license
I would like to make sure that those who don't know or don't care can have
an easy way to say that they distribute their code under license X.
I would like this to be correct for the major values of X:

"the Perl license"
Artistic 2.0
Artistic 1.0
GPL

Others can be added too and that's actually one of my questions here.
Which license should be added?

Thomas and I would like CPANTS to be able to check that modules
declare about their license in a way acceptable by corporations,
lawyers and even Linux distributions.

So here are some items that should be checked.
I am thinking aloud, please comment:

- CPAN distributions should have a LICEN[CS]E file
with the exact text of the license in it
- Each distributed files should have a short version of the license.
Maybe this would only mean the .pm and .pl files, maybe only the .pm files,
I am not sure
- Each distro should have a META.yml and a license field in it for machines to
check the license. (this one is probably not a legal requirement but it will
help the various automated tools)

- Preferably every file in the distro should be under the same license,
The LICEN[CS]E file should hold the text of this license and META.yml
should declare the same license.

When there are portions of the distro under different licenses,
(e.g. I think DBD::SQLite)
there should be a clear indication of this (how? where?)

I think TPF should get legal advice on how and where this
information should be written?
TPF should also get legal advice on what should we do with
our current text on the existing distros?
Changing the license of a module could be an issue as well.

Then TPF should publish some of the recommended options.


BTW There are several tools out there:

Software::LicenseUtils http://search.cpan.org/dist/Software-License/
lists the full text of some of the licenses.
Maybe it is enough to make your distro dependent on Software::License
and say the license is the specific version of that module?

Software::LicenseUtils in the same distro can help recognizing licenses
within the pod.


Case study:
when using Software::LicenseUtils 0.003 to check the license of
Module::CPANTS::Analyse 0.81 - the code of CPANTS - it did not find the license.
I think this happened because SLU is checking some wording and MCA had
a different wording of the same intention.
I don't know if that matters for the legal departments - TPF should
find that out -
and then make sure we are checking the same thing legals will.

comments?

regards
Gabor

Search Discussions

  • Geoffrey Leach at Jun 4, 2008 at 7:36 pm

    On 06/04/2008 01:50:51 AM, Gabor Szabo wrote:
    I know most of you don't want to think about this or don't care at
    all
    but others do.
    So I'd like to clean things up a bit in the way CPAN modules are
    licensed.
    Let's think about it as a necessary evil...

    While I respect the right of everyone writing whatever they want as
    license
    I would like to make sure that those who don't know or don't care can
    have
    an easy way to say that they distribute their code under license X.
    I would like this to be correct for the major values of X:

    "the Perl license"
    Artistic 2.0
    Artistic 1.0
    GPL

    Others can be added too and that's actually one of my questions here.
    Which license should be added?

    Thomas and I would like CPANTS to be able to check that modules
    declare about their license in a way acceptable by corporations,
    lawyers and even Linux distributions.

    So here are some items that should be checked.
    I am thinking aloud, please comment:

    - CPAN distributions should have a LICEN[CS]E file
    with the exact text of the license in it
    - Each distributed files should have a short version of the license.
    Maybe this would only mean the .pm and .pl files, maybe only
    the .pm
    files,
    I am not sure
    - Each distro should have a META.yml and a license field in it for
    machines to
    check the license. (this one is probably not a legal requirement
    but
    it will
    help the various automated tools)

    - Preferably every file in the distro should be under the same
    license,
    The LICEN[CS]E file should hold the text of this license and
    META.yml
    should declare the same license.

    When there are portions of the distro under different licenses,
    (e.g. I think DBD::SQLite)
    there should be a clear indication of this (how? where?)

    I think TPF should get legal advice on how and where this
    information should be written?
    TPF should also get legal advice on what should we do with
    our current text on the existing distros?
    Changing the license of a module could be an issue as well.

    Then TPF should publish some of the recommended options.


    BTW There are several tools out there:

    Software::LicenseUtils http://search.cpan.org/dist/Software-License/
    lists the full text of some of the licenses.
    Maybe it is enough to make your distro dependent on
    Software::License
    and say the license is the specific version of that module?

    Software::LicenseUtils in the same distro can help recognizing
    licenses
    within the pod.


    Case study:
    when using Software::LicenseUtils 0.003 to check the license of
    Module::CPANTS::Analyse 0.81 - the code of CPANTS - it did not find
    the license.
    I think this happened because SLU is checking some wording and MCA
    had
    a different wording of the same intention.
    I don't know if that matters for the legal departments - TPF should
    find that out -
    and then make sure we are checking the same thing legals will.

    comments?
    My main module says:

    This program is free software; you can redistribute it and/or
    modify it under the same terms as Perl itself.

    which I think is fairly common. Is this one of the ones that you
    reference?

    One thing that really bugs me is a module that has POD that ends with a
    page of legalese -- in caps, yet.

    A suggestion, should what I'm using -- or something equally brief --
    should not be acceptable. Have the module reference a file in the
    distribution that contains the lisence for all files in the
    distribution. Oh, and *please* don't require lisence POD in modules
    that would not otherwise have POD.
  • Eric Wilhelm at Jun 4, 2008 at 10:03 pm
    # from Gabor Szabo
    # on Wednesday 04 June 2008 01:50:
    - Each distro should have a META.yml and a license field in it for
    machines to check the license. (this one is probably not a legal
    requirement but it will help the various automated tools)
    This (alone) might be legally sufficient, as it clearly indicates the
    author's intent. If it helps, I would happily upload a formal
    statement of intent which officially refers to the license field in my
    distributions' META.yml files.

    Certainly, it wins the laziness criteria. Should some additional
    (redundant) information be deemed legally requisite, I would want to
    have some way to automatically generate that from the META.yml field.

    --Eric
    --
    software: a hypothetical exercise which happens to compile.
    ---------------------------------------------------
    http://scratchcomputing.com
    ---------------------------------------------------
  • Ricardo SIGNES at Jun 5, 2008 at 12:08 pm
    * Gabor Szabo [2008-06-04T04:50:51]
    - Each distro should have a META.yml and a license field in it for machines to
    check the license. (this one is probably not a legal requirement but it will
    help the various automated tools)
    The license field in the META.yml is insufficiently specific. It has no way of
    declaring what version of a license is in use.
    Software::LicenseUtils http://search.cpan.org/dist/Software-License/
    lists the full text of some of the licenses.
    Maybe it is enough to make your distro dependent on Software::License
    and say the license is the specific version of that module?
    Your distro doesn't even need to require it. It would be enough if some tool
    knew how to resolve "license: Software::License::GPL_3"

    when using Software::LicenseUtils 0.003 to check the license of
    Module::CPANTS::Analyse 0.81 - the code of CPANTS - it did not find the
    license. I think this happened because SLU is checking some wording and MCA
    had a different wording of the same intention.
    Yeah, it's a real hack.

    --
    rjbs
  • Barbie at Jun 6, 2008 at 9:33 am

    On Thu, Jun 05, 2008 at 08:08:29AM -0400, Ricardo SIGNES wrote:
    * Gabor Szabo [2008-06-04T04:50:51]
    - Each distro should have a META.yml and a license field in it for
    machines to check the license. (this one is probably not a legal
    requirement but it will help the various automated tools)
    The license field in the META.yml is insufficiently specific. It has
    no way of declaring what version of a license is in use.
    Had a think about this, and it occurred to me that the current field was
    scoped in a way that seemed appropriate at the time, but as we've better
    defined what license means, perhaps it's time to redefine it in the
    spec.

    As a suggestion, or starting point how about something like below:


    Current:
    ========

    license

    Example:

    license: perl

    (Spec 1.0) [required] {string} The license under which this distribution may be used and redistributed. See the Module::Build manpage for the list of valid options.



    Proposed:
    =========

    license

    Example:

    license:
    - Artistic License:
    version: 1.0
    file: Artistic.txt
    url: http://search.cpan.org/src/RJBS/Software-License-0.005/lib/Software/License/Artistic_1_0.pm
    - GPL:
    version: 3
    file: COPYING
    url: http://search.cpan.org/src/RJBS/Software-License-0.005/lib/Software/License/GPL_3.pm

    (Spec 1.4) [required] {map} The license(s) under which this distribution may be used and redistributed, using a YAML mapping to describe the version and the file or url containing the full text of the license. For a full list of acknowledged licenses please see the Software::License distribution - http://search.cpan.org/dist/Software-License.

    version

    (Spec 1.4) [required] Explicit version number of the license under which the distribution is being distributed.

    file

    (Spec 1.4) [optional] Local file containing full text of license.

    url

    (Spec 1.4) [optional] URL to a file containing full text of license.


    [Note: although file and url are optional, at least one must exist.]


    It would make it easier for tools to verify that the file or URL exist,
    we could cite the Software::License as the recommend source for license
    text and licenses, and it better allows for dual licensed modules to
    explicity cite which licenses and versions they meant.

    Existing META.yml files listing the license as a string, could still be
    honoured, but for things like CPANTS, and ultimately Debian & RedHat
    (where Gabor is heading) newer distributions would be able to make it
    much clearer to packagers what license a distribution was meant to be
    released under.

    Cheers,
    Barbie.
    --
    Birmingham Perl Mongers <http://birmingham.pm.org>
    Memoirs Of A Roadie <http://barbie.missbarbell.co.uk>
  • Aristotle Pagaltzis at Jun 6, 2008 at 9:58 am

    * Barbie [2008-06-06 11:35]:
    (Spec 1.4) [required] {map} The license(s) under which this
    distribution may be used and redistributed, using a YAML
    mapping to describe the version and the file or url containing
    the full text of the license. For a full list of acknowledged
    licenses please see the Software::License distribution -
    http://search.cpan.org/dist/Software-License.

    version

    (Spec 1.4) [required] Explicit version number of the license
    under which the distribution is being distributed.
    I disagree with this. Version numbers on licences are just a
    naming sleight of hand. GPLv3 differs drastically from GPLv2,
    and while Artistic 2.0 is the spiritual successor to the Artistic
    Licence, in legal terms at least it is a completely new beast.

    The “version number” is part of the name. There is no GPL; there
    are GPL1, GPL2 and GPL3, and you must specify which you mean. In
    case of the Artistic Licence, there is no 1.0 version as it was
    never called Artistic 1.0 prior to the work on Artistic 2.0.

    Using a version number in the name is purely a marketing device.

    Regards,
    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>
  • Chris Dolan at Jun 7, 2008 at 1:34 am

    On Jun 6, 2008, at 4:58 AM, Aristotle Pagaltzis wrote:

    * Barbie [2008-06-06 11:35]:
    (Spec 1.4) [required] {map} The license(s) under which this
    distribution may be used and redistributed, using a YAML
    mapping to describe the version and the file or url containing
    the full text of the license. For a full list of acknowledged
    licenses please see the Software::License distribution -
    http://search.cpan.org/dist/Software-License.

    version

    (Spec 1.4) [required] Explicit version number of the license
    under which the distribution is being distributed.
    I disagree with this. Version numbers on licences are just a
    naming sleight of hand. GPLv3 differs drastically from GPLv2,
    and while Artistic 2.0 is the spiritual successor to the Artistic
    Licence, in legal terms at least it is a completely new beast.

    The “version number” is part of the name. There is no GPL; there
    are GPL1, GPL2 and GPL3, and you must specify which you mean. In
    case of the Artistic Licence, there is no 1.0 version as it was
    never called Artistic 1.0 prior to the work on Artistic 2.0.

    Using a version number in the name is purely a marketing device.

    Regards,
    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>
    Agreed. "GPLv2 or later" is a common license which is not
    represented by the version number. We really don't want the full
    Module::Build version syntax:

    license:
    - GPL:
    version: '>=2, !=3'

    :-)

    Seriously, though, I like the idea of pointing at a file and an URL.
    I would switch the URL to opensource.org, though, since it's easier
    to imagine that staying up-to-date (no offense, RJBS). And I would
    use the file as the key since it's more definitive than the human-
    readable name. Or perhaps the URL should be the key?

    license:
    - 'Artistic.txt':
    title: 'Artistic License v1'
    url: 'http://www.opensource.org/licenses/artistic-license-1.0.php'
    - 'COPYING':
    title: 'GPL v3'
    url: 'http://www.opensource.org/licenses/gpl-3.0.html'

    Chris
  • Aristotle Pagaltzis at Jun 7, 2008 at 6:17 am

    * Chris Dolan [2008-06-07 03:35]:
    Or perhaps the URL should be the key?
    That sounds like the best idea to me, in fact. Pick a bunch of
    stable URIs and tell people that those are the known ones. (But
    allow any URI so people can use any weird crud they want. Not
    because proliferation is a good idea, but sometimes their code
    is coupled to someone else’s and they have no choice.)

    Regards,
    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>
  • Gabor Szabo at Jun 7, 2008 at 10:10 am
    While I am glad there is some convergence in technology,
    before solving the technology problem first I think we should
    get the legal advice.

    For us it might be enough to have a URL but for the legal team
    of a company or a lawyer might not. I think if we are going to give
    some overall solution, it should satisfy them too.

    I think TPF should be the body that verifies what is the correct
    way in declaring licenses in CPAN modules.

    So is someone from TPF listening in?
    Would someone volunteer to find out how to get the legal advice?


    Gabor
  • Aristotle Pagaltzis at Jun 7, 2008 at 1:11 pm

    * Gabor Szabo [2008-06-07 12:15]:
    For us it might be enough to have a URL but for the legal team
    of a company or a lawyer might not.
    Wait wait. I didn’t say that the URL should be the *only* piece
    of information. All I said is that using URLs as the canonical
    machine-processable identifiers for the different licences is a
    good idea. *Of course* distributions should continue to include
    the text of their licence(s), and having their human-readable
    name on file in the META would still be good.
    I think TPF should be the body that verifies what is the
    correct way in declaring licenses in CPAN modules.
    That is also a good idea, of course.

    Regards,
    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>
  • Joshua ben Jore at Jun 5, 2008 at 9:59 pm

    On Wed, Jun 4, 2008 at 1:50 AM, Gabor Szabo wrote:
    - CPAN distributions should have a LICEN[CS]E file
    with the exact text of the license in it
    Dual licensed modules are not accommodated for by a single file. The
    GPL and Artistic license seem to have normative filenames like
    Artistic, Artistic.txt, Copying and Copying.txt, etc. I would not want
    to lose that. To be specific WRT to license, I'm about to post
    something to CPAN with the files Artistic-v1.txt and gpl-v3.0.txt
    where I was specifically asked by a release lawyer to use filenames
    like that. That may not have been a hard requirement but I didn't go
    back to negotiate for wiggle room or to find out the reason.

    Josh

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmodule-authors @
categoriesperl
postedJun 4, '08 at 8:51a
activeJun 7, '08 at 1:11p
posts11
users8
websitecpan.org...

People

Translate

site design / logo © 2021 Grokbase