develooper Front page | perl.module-authors | Postings from June 2008

Licenses of CPAN modules

Thread Next
Gabor Szabo
June 4, 2008 01:51
Licenses of CPAN modules
Message ID:
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

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:

  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.



Gabor Szabo
Test Automation Tips

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About