Integrating license related things of CPAN
I am trying to push forward simplifying and clarifying the licensing issues on CPAN. Here are a couple of issues I identified. I'd like to get your input on these issues hoping that we can have an agreement and then the people with the commit bits can implement them. 1) META.yml license field is required. http://module-build.sourceforge.net/META-spec.html#license says the license field is required but FAIK when calling make dist or ./Build dist both EUMM and MB will happily create META.yml files without a license field. If there is an agreement on the field being required then I think the tools should not create a distribution without a valid license key. Obviously they should keep installing modules without a license in META.yml. 2) The list of valid values should be in http://module-build.sourceforge.net/META-spec.html#license instead of its current place, which is http://search.cpan.org/dist/Module-Build/lib/Module/Build/API.pod 3) Software::License http://search.cpan.org/dist/Software-License/ has a growing list of licenses with full text in it. The list of licenses is not the same as the values in META.yml and even in the cases where the license seem to be the same their short name is not identical. IMHO these lists should be unified. If we can accept http://www.opensource.org/licenses as the official list of open source licenses the short names should be coordinated with them. 4) Module::Starter and similar tools should use the same list (maybe taken directly from Software::License) to guide the users when they create a new module. 5) search.cpan.org is using the META.yml to display the license name. Once we have a better list it will probably reflect that. 6) In this mail I have not yet dealt with how exactly the license is spelled out in the distribution (eg. LICENSE file) and in the individual files (the blurb we have in the =LICENSE entries of the modules). There is also an optional resources/license field in the META.yml spec: http://module-build.sourceforge.net/META-spec-current.html#resources which can be a URL to the full text of the license. TPF, more specifically Allison took upon herself to check this with real lawyers so we'll have a clear recommendation on *how* to declare our license in the distributions. I hope the recommendation will also include specific instructions on how to say we are using the perl license as that is what the majority is using now. Anyway this 6th issue will be dealt with later when we have the recommendation. For now, please let me know if you have any opinion on 1-4 ? regards Gabor http://szabgab.com/blog.html
Re: Integrating license related things of CPAN
On Wed, Oct 22, 2008 at 01:09:16PM +0200, Gabor Szabo wrote: 1) META.yml license field is required. http://module-build.sourceforge.net/META-spec.html#license says the license field is required but FAIK when calling make dist or ./Build dist both EUMM and MB will happily create META.yml files without a license field. If there is an agreement on the field being required then I think the tools should not create a distribution without a valid license key. Obviously they should keep installing modules without a license in META.yml. I think an outright failure for what is ultimately a non-technical reason, is not a good behaviour. It could warn loudly, but I don't think it should completely fail to build. That would get annoying in sitautions when you want to Just Do It. 2) The list of valid values should be in http://module-build.sourceforge.net/META-spec.html#license instead of its current place, which is http://search.cpan.org/dist/Module-Build/lib/Module/Build/API.pod Specs are good. 3) Software::License http://search.cpan.org/dist/Software-License/ has a growing list of licenses with full text in it. The list of licenses is not the same as the values in META.yml and even in the cases where the license seem to be the same their short name is not identical. IMHO these lists should be unified. If we can accept http://www.opensource.org/licenses as the official list of open source licenses the short names should be coordinated with them. Unified agreement with the wider community is good. -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature
Re: Integrating license related things of CPAN
On Wednesday 22 October 2008, Gabor Szabo wrote:
I am trying to push forward simplifying and clarifying the
licensing issues on CPAN.
[Snip]
4) Module::Starter and similar tools should use the same list
(maybe taken directly from Software::License) to guide the users
when they create a new module.
Well, I tried to contribute to Module-Starter and indeed had fixing its
licence-handling in the future as a priority. The first thing I did was add
some comprehensive tests, which M-S was almost completely absent of. I
submitted a patch for this here:
http://code.google.com/p/module-starter/issues/detail?id=2
While working on the patch, I found some bugs, which I wrote a subset patch
for here:
http://code.google.com/p/module-starter/issues/detail?id=3
Both of these happened over two months ago.
The patches were not applied yet, and if I am to fix the licence-handling in
M-S, then it is a pre-requisite that they will be.
Andy Lester (M-S' maintainer) blogged about Module-Starter here:
http://perlbuzz.com/2008/10/creating-a-module-distribution-with-modulestarter.html
And said that:
{{{
Now, Perl Training Australia has done just that with one of its Perl
Tips, Starting a module with Module::Starter. I've already absorbed it into
the Module::Starter distribution.
}}}
Now, RJBS who is a M-S co-maintainer now has his own private
distribution-creation magic (which is not released yet), and there was also a
distribution like that released by a certain Japanese developer who announced
it on use.perl.org. Its documentation is full of Engrish.
In short - we live in interesting times.
Regards,
Shlomi Fish
-
Shlomi Fish http://www.shlomifish.org/
My Aphorisms - http://www.shlomifish.org/humour.html
Shlomi, so what are you working on? Working on a new wiki about unit testing
fortunes in freecell? -- Ran Eilam
New Version of File-Find-Object - 0.1.1 With a Security Fix (and Many Enhancements)
Hi all!
I released File-Find-Object version 0.1.1 today with a security fix to a
potential printf-format vulnerability. The offending code in F-F-O-0.1.0 was
this:
if ($rc) {
printf(STDERR Avoid loop . $self-_father($ptr)-dir() .
= %s\n,
$self-_current_path($current));
return 0;
}
As one can see $self-_father($ptr)-dir() is included directly in the
printf-format, which may cause a lot of unexpected behaviour. There was a
Perl-sprintf vulnerability a while ago, in which the Perl interpreter
mis-handled some badly formatted sprintf-values, and in general letting the
user input stuff directly into the printf-format field is not such a good
idea.
-dir() is encountered in the directory tree that File-Find-Object traverses.
Otherwise, there are many other enhancements:
0.1.1 - Wed Oct 22 12:30:56 IST 2008
- Potential Security Fix!!! No longer passing a filename directly to
the format in printf (STDERR) when warning on a loop.
- Bug fix - the check for a loop was broken.
- New Feature - Added the -next_obj() and -item_obj() methods
to return a File::Find::Object::Result object instead of a plain
path.
- Refactoring:
- No longer passing $current explicitly from one method to another
(hello EEK!). Instead, we reference $self-_current()
- Remmed out the DESTROY method as it was empty.
- Revamped the _action handling - an array instead of a hash.
- Created _top and _non_top methods delegated by _is_top using
_top_it()
- _current_idx() was eliminated - now it's just $#dir_stack.
- Created a _copy methods to create flat copies of array references.
- Extracted many methods.
- Switched Build.PL to inc/Test/Run/Builder.pm - that gives us:
- ./Build runtest
- ./Build distruntest
- ./Build tags
Regards,
Shlomi Fish
-
Shlomi Fish http://www.shlomifish.org/
Humanity - Parody of Modern Life - http://xrl.us/bkeut
Shlomi, so what are you working on? Working on a new wiki about unit testing
fortunes in freecell? -- Ran Eilam
Re: Integrating license related things of CPAN
* Gabor Szabo [EMAIL PROTECTED] [2008-10-22T07:09:16] 1) META.yml license field is required. http://module-build.sourceforge.net/META-spec.html#license says the license field is required but FAIK when calling make dist or ./Build dist both EUMM and MB will happily create META.yml files without a license field. If there is an agreement on the field being required then I think the tools should not create a distribution without a valid license key. Obviously they should keep installing modules without a license in META.yml. If nothing else, it should warn. I am all for failure, though. I will tell you why. Some time ago, I picked up maintenance of Data::UUID to apply some patches. I made some releases before someone pointed out that there was no explicit license. I tried to contact the author and was unable to reach him. Nearly everyone agrees that the author meant for this to be freely redistributable and modifiable software -- it just seems too likely. That doesn't help much, though. He didn't make an explicit statement. If he'd initially make dist and gotten no license specified! do x, y, z then he would've done so, and I would have never had to bother thinking about this problem. 2) The list of valid values should be in http://module-build.sourceforge.net/META-spec.html#license instead of its current place, which is http://search.cpan.org/dist/Module-Build/lib/Module/Build/API.pod I would be really happy if we had CPAN::METAyml::Spec or something on the CPAN. 3) Software::License http://search.cpan.org/dist/Software-License/ has a growing list of licenses with full text in it. The list of licenses is not the same as the values in META.yml and even in the cases where the license seem to be the same their short name is not identical. IMHO these lists should be unified. I don't care where we get the list from so much, but we need things to be *clear*. Having license: gpl in the META.yml is not clear, because there are many versions of the GPL, and the META.yml field does not specify which is meant. The same goes for some other values. Software::License tries to be explicit. 4) Module::Starter and similar tools should use the same list (maybe taken directly from Software::License) to guide the users when they create a new module. Software::License is not entirely unrelated to some similar code in an alternative to Module::Starter, ExtUtils::ModuleMaker. Module::Starter is sort of free-form in how it allows stuff. Dist::Zilla uses Software::License directly, although I'm sure it's not well tested for things other than 'perl' license. I think all these things will be easier if we have a clearer, more explicit specification for what means what. 5) search.cpan.org is using the META.yml to display the license name. Once we have a better list it will probably reflect that. Sounds good. -- rjbs
Re: Integrating license related things of CPAN
# from Paul LeoNerd Evans # on Wednesday 22 October 2008: I think the tools should not create a distribution without a valid license key. Obviously they should keep installing modules without a license in META.yml. I think an outright failure for what is ultimately a non-technical reason, is not a good behaviour. It could warn loudly, but I don't think it should completely fail to build. That would get annoying in sitautions when you want to Just Do It. If the field is required in META.yml, then ACTION_distmeta should croak if it is not defined. This is not a 'build' failure. This is throwing an error during 'build dist'. While that might be annoying (once -- for the author), the tool can't get around that if it is a required field -- because any other behavior wouldn't comply with the META.yml spec. --Eric -- ...the bourgeoisie were hated from both ends: by the proles, because they had all the money, and by the intelligentsia, because of their tendency to spend it on lawn ornaments. --Neal Stephenson --- http://scratchcomputing.com ---
Re: Integrating license related things of CPAN
On Wed, Oct 22, 2008 at 11:52:27AM -0700, Eric Wilhelm wrote: While that might be annoying (once -- for the author), the tool can't get around that if it is a required field -- because any other behavior wouldn't comply with the META.yml spec. I suppose that's a fair point. I'm just thinking of the case where someone will just put anything in the field to shut up the tool because they just want to get on with it. -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature
Re: RFC: Attribute::Storage
On Mon, Oct 20, 2008 at 11:49:58PM +0100, Paul LeoNerd Evans wrote: Thoughts, anyone? On the name, the implementation, the idea,.. anything else that comes to mind? Nothing; anybody? In that case perhaps I'll shove it up on CPAN then. -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature
Re: RFC: Attribute::Storage
On Wednesday 22 October 2008, Paul LeoNerd Evans wrote: On Mon, Oct 20, 2008 at 11:49:58PM +0100, Paul LeoNerd Evans wrote: Thoughts, anyone? On the name, the implementation, the idea,.. anything else that comes to mind? Nothing; anybody? In that case perhaps I'll shove it up on CPAN then. Looks pretty good after reading it - sorry for not tending to it earlier. Regards, Shlomi Fish - Shlomi Fish http://www.shlomifish.org/ Star Trek: We, the Living Dead - http://xrl.us/omqz4 Shlomi, so what are you working on? Working on a new wiki about unit testing fortunes in freecell? -- Ran Eilam
Re: Integrating license related things of CPAN
On Wed, Oct 22, 2008 at 6:09 AM, Gabor Szabo [EMAIL PROTECTED] wrote: 6) In this mail I have not yet dealt with how exactly the license is spelled out in the distribution (eg. LICENSE file) and in the individual files (the blurb we have in the =LICENSE entries of the modules). Lately I've been thinking that the 'dist' phase should automatically write out a LICENSE or COPYING file with the full text of the license. That way the author could declare the license once, in the Build.PL, and not have to mention it in (or keep it in sync with) the POD in the .pm files. -Ken
Re: Integrating license related things of CPAN
On Thu, Oct 23, 2008 at 4:51 AM, Ken Williams [EMAIL PROTECTED] wrote: On Wed, Oct 22, 2008 at 6:09 AM, Gabor Szabo [EMAIL PROTECTED] wrote: 6) In this mail I have not yet dealt with how exactly the license is spelled out in the distribution (eg. LICENSE file) and in the individual files (the blurb we have in the =LICENSE entries of the modules). Lately I've been thinking that the 'dist' phase should automatically write out a LICENSE or COPYING file with the full text of the license. That way the author could declare the license once, in the Build.PL, and not have to mention it in (or keep it in sync with) the POD in the .pm files. Automatically writing a LICENSE file (probably using Software::License) might be good legally but I am not sure, the plain multiplication of those texts is necessary. Not keeping =LICENSE and =COPYRIGHT entries in the POD in .pm files - if that's what you were suggesting - seems to me like a step backwards in the strength of the license. At least if I am not mistaken the Debian people would prefer if we had the copyright and license in *every* file. Anyway I am not a lawyer so I'd wait with this till Allison can get a real legal advice of what *should* be the form of the license and copyright. I hope she will be able to get this information soon and then we can move forward with the implementation of the various parts of it. regards Gabor
Re: Integrating license related things of CPAN
On Wed, Oct 22, 2008 at 11:21 PM, Eric Wilhelm [EMAIL PROTECTED] wrote: # from Paul LeoNerd Evans # on Wednesday 22 October 2008: On Wed, Oct 22, 2008 at 11:52:27AM -0700, Eric Wilhelm wrote: While that might be annoying (once -- for the author), the tool can't get around that if it is a required field -- because any other behavior wouldn't comply with the META.yml spec. I suppose that's a fair point. I'm just thinking of the case where someone will just put anything in the field to shut up the tool because they just want to get on with it. Well, I think Module::Build will give you a nice error about that telling you what options are valid. If it doesn't, that would be a neat patch. As Gabor pointed out (I think only on IRC), the META.yml spec and the Module::Build docs are a bit too intertwined on this point. Also a good thing to patch. As discussed also in IRC it might be probably better if the META.yml spec was moved to a separate repository so it will be disassociated from Module::Build as META.yml is more, err meta than MB. It was also suggested that we discuss this on the cpan-metadata list. We could move the discussion there but I think the module-authors list is a better place as the module-authors should be involved in the evolving specification. If I am not mistaken Ken is the owner of the MB repository So Ken, would you be ready to move the META.yml spec to another repository? Would you first prefer to move whatever has to be moved from the docs of MB to META.yml and move it then? I know of the list of licenses that should be moved but there might be others. I'd be glad to put some (little) time in helping out in this. regards Gabor
