Re: Integrating license related things of CPAN
* Ken Williams [EMAIL PROTECTED] [2008-11-02T22:55:46] Announcement: I've just committed change 12024 to Module::Build for creating a LICENSE file during the dist phase using Software::License. To get such behavior the author sets the create_license parameter to new(). In celebration of this change, I will be accepting patches or demands for new licenses to be added. Ken: is it possible to specify a S:L class directly as a license, now? I ask because the existing license keys are ambiguous. -- rjbs
Re: Integrating license related things of CPAN
On Mon, Nov 3, 2008 at 7:19 AM, Ricardo SIGNES
[EMAIL PROTECTED] wrote:
Ken: is it possible to specify a S:L class directly as a license, now? I ask
because the existing license keys are ambiguous.
I noticed that, so I actually just provided explicit mappings for the
licenses M::B already knew about:
{
my %licenses = (
perl = 'Perl_5',
apache = 'Apache_2_0',
artistic = 'Artistic_1_0',
artistic_2 = 'Artistic_2_0',
lgpl = 'LGPL_2_1',
bsd = 'BSD',
gpl = 'GPL_1',
gpl2 = 'GPL_2',
gpl3 = 'GPL_3',
mit = 'MIT',
mozilla = 'Mozilla_1_1',
open_source = undef,
unrestricted = undef,
restrictive = undef,
unknown = undef,
);
sub valid_licenses {
return \%licenses;
}
}
On the right side, those are S::L subclass names. On the left side,
they don't correspond exactly to S::L's meta_yml names.
What I would like to do next is make it more of a pure pass-through,
so that anything S::L knows about can be fed to M::B. That might
depend on having a registry in S::L, or it might mean an author could
specify a class name directly, possibly omitting the
Software::License:: prefix.
-Ken
Re: Integrating license related things of CPAN
* Ken Williams [EMAIL PROTECTED] [2008-11-03T09:49:01]
I noticed that, so I actually just provided explicit mappings for the
licenses M::B already knew about:
Cool. You might want to have a look at Software::LicenseUtils, which does a
reverse mapping sort of like your forward mapping:
http://search.cpan.org/src/RJBS/Software-License-0.008/lib/Software/LicenseUtils.pm
my %yaml_keys = (
perl = 'Perl_5',
apache = [ map { Apache_$_ } qw(1_1 2_0) ],
artistic = 'Artistic_1_0',
artistic_2 = 'Artistic_2_0',
lgpl = [ map { LGPL_$_ } qw(2_1 3_0) ],
bsd = 'BSD',
gpl = [ map { GPL_$_ } qw(1 2 3) ],
mit = 'MIT',
mozilla = [ map { Mozilla_$_ } qw(1_0 1_1) ],
);
That's supposed to cope with the ambiguity of things like 'gpl'. I'll post to
the cpan-metadata list about that sometime, although it looks like the problem
might be going away soon, effectively
What I would like to do next is make it more of a pure pass-through,
so that anything S::L knows about can be fed to M::B. That might
depend on having a registry in S::L, or it might mean an author could
specify a class name directly, possibly omitting the
Software::License:: prefix.
What I do in Dist::Zilla's license bit is rewrite '=Foo::Bar' to 'Foo::Bar' and
'Foo::Bar' to 'Software::License::Foo::Bar'
That allows people to specify a license class in the normal namespace or, if
they must, =MyCorp::License::MCPL.
I'd love to avoid having a registry, because it will allow people to specify
their own internal license and have all the code generate the right files.
They don't even need to bundle the library -- heck they don't even NEED to
release it to CPAN, because M::B will create the right LICENSE file. (...and
if they do release it, that's great too!)
--
rjbs
Re: Integrating license related things of CPAN
Ricardo SIGNES schreef:
* Ken Williams [EMAIL PROTECTED] [2008-11-03T09:49:01]
What I would like to do next is make it more of a pure pass-through,
so that anything S::L knows about can be fed to M::B. That might
depend on having a registry in S::L, or it might mean an author could
specify a class name directly, possibly omitting the
Software::License:: prefix.
What I do in Dist::Zilla's license bit is rewrite '=Foo::Bar' to
'Foo::Bar' and 'Foo::Bar' to 'Software::License::Foo::Bar'
That allows people to specify a license class in the normal namespace
or, if they must, =MyCorp::License::MCPL.
I'd love to avoid having a registry, because it will allow people to
specify
their own internal license and have all the code generate the right
files.
They don't even need to bundle the library -- heck they don't even
NEED to
release it to CPAN, because M::B will create the right LICENSE file.
(...and
if they do release it, that's great too!)
Suggestion for a core license.pm:
package license;
$LICENSE = perl;
1;
sub import {
eval sprintf q/*%s::LICENSE=\\%s/,
scalar caller,
@_ == 2 ? $_[1] : join ,, @_[1..$#_];
1;
}
__END__
(and Cuse license ... ; should be compiled away unless at
distribution-time)
--
Affijn, Ruud
Gewoon is een tijger.
Re: Integrating license related things of CPAN
On Mon, Nov 3, 2008 at 2:05 PM, Dr.Ruud [EMAIL PROTECTED] wrote:
Suggestion for a core license.pm:
package license;
$LICENSE = perl;
1;
sub import {
eval sprintf q/*%s::LICENSE=\\%s/,
scalar caller,
@_ == 2 ? $_[1] : join ,, @_[1..$#_];
1;
}
__END__
(and Cuse license ... ; should be compiled away unless at
distribution-time)
What itch is this animal intended to scratch?
-Ken
Re: Integrating license related things of CPAN
Announcement: I've just committed change 12024 to Module::Build for creating a LICENSE file during the dist phase using Software::License. To get such behavior the author sets the create_license parameter to new(). I haven't written the docs or tests for it yet though. -Ken
Re: Integrating license related things of CPAN
On Thursday 30 October 2008, David Cantrell wrote: On Wed, Oct 29, 2008 at 11:13:24PM -0500, Ken Williams wrote: On Mon, Oct 27, 2008 at 11:17 AM, David Cantrell [EMAIL PROTECTED] wrote: So, in summary, here's my objections to the current 'license' field in META.yml: * poorly documented; * limited range of options for licences; * only one licence per distribution The first is fixable so I'm not too bothered by it. The second and third are fundamental design flaws which make it unfit for purpose. Your proposal doesn't seem to address the second point in any way. That's the bit where I suggest instead of saying, eg, frobnitz to mean the Frobnitz licence you say frobnitz to mean the licence whose text is in the 'frobnitz' file. That would allow the author to use any licence he wants. This seems like the road to chaos. Imagine I put mit there and mit.txt contains the text of the GPLv3. I think we should have unique identifiers for every licence, and expand them to encompass more licences if necessary, then allow such inconsistent behaviour. Regards, Shlomi Fish - Shlomi Fish http://www.shlomifish.org/ Parody on The Fountainhead - http://xrl.us/bjria 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 Fri, Oct 31, 2008 at 11:36:08AM +0200, Shlomi Fish wrote: On Thursday 30 October 2008, David Cantrell wrote: That's the bit where I suggest instead of saying, eg, frobnitz to mean the Frobnitz licence you say frobnitz to mean the licence whose text is in the 'frobnitz' file. That would allow the author to use any licence he wants. This seems like the road to chaos. Imagine I put mit there and mit.txt contains the text of the GPLv3. I think we should have unique identifiers for every licence, and expand them to encompass more licences if necessary, then allow such inconsistent behaviour. If you say 'mit' and don't have a 'mit' file that should be an error in my scheme. mit.txt != mit. If you're silly enough to put the text of the GPL3 in a file called 'mit.txt' then that's your problem. No such scheme can protect against user error. Your hypothetical is no different from you putting 'mit' in the current 'license' field while saying in the POD blah blah blah GPL3 blah blah. -- David Cantrell | Minister for Arbitrary Justice There is no one true indentation style, But if there were KR would be Its Prophets. Peace be upon Their Holy Beards.
Re: Integrating license related things of CPAN
Quoth [EMAIL PROTECTED] (Shlomi Fish): On Thursday 30 October 2008, David Cantrell wrote: On Wed, Oct 29, 2008 at 11:13:24PM -0500, Ken Williams wrote: On Mon, Oct 27, 2008 at 11:17 AM, David Cantrell [EMAIL PROTECTED] wrote: So, in summary, here's my objections to the current 'license' field in META.yml: * poorly documented; * limited range of options for licences; * only one licence per distribution The first is fixable so I'm not too bothered by it. The second and third are fundamental design flaws which make it unfit for purpose. Your proposal doesn't seem to address the second point in any way. That's the bit where I suggest instead of saying, eg, frobnitz to mean the Frobnitz licence you say frobnitz to mean the licence whose text is in the 'frobnitz' file. That would allow the author to use any licence he wants. This seems like the road to chaos. Imagine I put mit there and mit.txt contains the text of the GPLv3. I think we should have unique identifiers for every licence, and expand them to encompass more licences if necessary, then allow such inconsistent behaviour. Having the full text of the licences available in the distribution seems like a good idea, though. How about making it so that 'make dist'/'Build dist' creates the files with appropriate contents if they don't exist, and throws an error if they do but with the wrong contents? Then a version of Software::Licence with the correct licence in is only needed on the developer machine. Ben
Re: Integrating license related things of CPAN
On Fri, Oct 31, 2008 at 10:36 AM, Ben Morrow [EMAIL PROTECTED] wrote: Having the full text of the licences available in the distribution seems like a good idea, though. How about making it so that 'make dist'/'Build dist' creates the files with appropriate contents if they don't exist, and throws an error if they do but with the wrong contents? Then a version of Software::Licence with the correct licence in is only needed on the developer machine. Right, that's what I was proposing earlier in this thread too. -Ken
Re: Integrating license related things of CPAN
On Fri, Oct 31, 2008 at 03:36:15PM +, Ben Morrow wrote: Having the full text of the licences available in the distribution seems like a good idea, though. How about making it so that 'make dist'/'Build dist' creates the files with appropriate contents if they don't exist, and throws an error if they do but with the wrong contents? Wrong being measured how? What if my version of GPL2.txt has an extra CRLF at the end because of how I cut n pasted it from the GNU website? How about following the Perl Way of providing great tools that people *can* use if they want, but not trying to hold their hands too much if they really want to follow one of the other ways of doing things? -- David Cantrell | Cake Smuggler Extraordinaire Wow, my first sigquoting! I feel so special now! -- Dan Sugalski
Re: Integrating license related things of CPAN
On Fri, Oct 31, 2008 at 08:03:10PM +, David Cantrell wrote: What if my version of GPL2.txt has an extra CRLF at the end because of how I cut n pasted it from the GNU website? Or has the address changed, as they are wont to do. Nicholas Clark
Re: Integrating license related things of CPAN
On Fri, Oct 31, 2008 at 5:23 AM, David Cantrell [EMAIL PROTECTED] wrote: On Fri, Oct 31, 2008 at 11:36:08AM +0200, Shlomi Fish wrote: On Thursday 30 October 2008, David Cantrell wrote: That's the bit where I suggest instead of saying, eg, frobnitz to mean the Frobnitz licence you say frobnitz to mean the licence whose text is in the 'frobnitz' file. That would allow the author to use any licence he wants. This seems like the road to chaos. Imagine I put mit there and mit.txt contains the text of the GPLv3. I think we should have unique identifiers for every licence, and expand them to encompass more licences if necessary, then allow such inconsistent behaviour. If you say 'mit' and don't have a 'mit' file that should be an error in my scheme. mit.txt != mit. If you're silly enough to put the text of the GPL3 in a file called 'mit.txt' then that's your problem. No such scheme can protect against user error. Your hypothetical is no different from you putting 'mit' in the current 'license' field while saying in the POD blah blah blah GPL3 blah blah. Instead of including a COPY of the license in every distro, how about putting the URL into the META.yml file? (Or is it URI? I always get that mixed up.) This seems like the sort of thing that URL or URI or whichever it is would be perfect for.
Re: Integrating license related things of CPAN
* Bill Ward [EMAIL PROTECTED] [2008-10-31T16:12:01] Instead of including a COPY of the license in every distro, how about putting the URL into the META.yml file? (Or is it URI? I always get that mixed up.) This seems like the sort of thing that URL or URI or whichever it is would be perfect for. To save what? A few bytes? Then the file will move or the server will go away, or whatever. What we really need are URNs, which don't exist and never will. It's better to put the actual text in there. I believe it's what nearly everyone prefers, anyway: packages, the authors of the license. If the cost is 1 kilobyte and that a few people add a little code to generate this file as needed, it's well worth it. -- rjbs
Re: Integrating license related things of CPAN
On Thu, Oct 30, 2008 at 7:18 AM, Bill Ward [EMAIL PROTECTED] wrote: I think supporting options like other or mixed should resolve most of these cases. Sure, automatic tools that use this field will be out of luck, but that should be a fairly small minority. This is exactly what I mean. I think setting 'other' as the license should indicate that the developer is aware of this field and cares but that the available options don't fit. This is IMHO much better then nothing or 'unknown'. Gabor
Re: Integrating license related things of CPAN
On Wed, Oct 29, 2008 at 11:13:24PM -0500, Ken Williams wrote: On Mon, Oct 27, 2008 at 11:17 AM, David Cantrell [EMAIL PROTECTED] wrote: So, in summary, here's my objections to the current 'license' field in META.yml: * poorly documented; * limited range of options for licences; * only one licence per distribution The first is fixable so I'm not too bothered by it. The second and third are fundamental design flaws which make it unfit for purpose. Your proposal doesn't seem to address the second point in any way. That's the bit where I suggest instead of saying, eg, frobnitz to mean the Frobnitz licence you say frobnitz to mean the licence whose text is in the 'frobnitz' file. That would allow the author to use any licence he wants. I agree that the second point is a problem. I'd like to solve it by delegating to Software::License. Anything it knows about should be a valid choice. All that does it make it Someone Elses Problem while still not solving the problem. As an example, Software::License doesn't appear to know about the Microsoft or Python licences. PS - sorry you're getting this twice Ken. It's because you CCed me on your post to the mailing list, so the copy sent directly to me arrived first, so the copy from the list got thrown away. And it's the copy I get from the list which goes through a procmail recipe to insert a Reply-To header. Please don't CC me on mailing list messages in the future. -- David Cantrell | Official London Perl Mongers Bad Influence Good advice is always certain to be ignored, but that's no reason not to give it-- Agatha Christie
Re: Integrating license related things of CPAN
* David Cantrell [EMAIL PROTECTED] [2008-10-30T12:53:58] I agree that the second point is a problem. I'd like to solve it by delegating to Software::License. Anything it knows about should be a valid choice. All that does it make it Someone Elses Problem while still not solving the problem. As an example, Software::License doesn't appear to know about the Microsoft or Python licences. license: =inc::Software::License::Microsoft -- rjbs
Re: Integrating license related things of CPAN
On Mon, Oct 27, 2008 at 11:17 AM, David Cantrell [EMAIL PROTECTED] wrote: So, in summary, here's my objections to the current 'license' field in META.yml: * poorly documented; * limited range of options for licences; * only one licence per distribution The first is fixable so I'm not too bothered by it. The second and third are fundamental design flaws which make it unfit for purpose. Your proposal doesn't seem to address the second point in any way. I'm also not thrilled with how it addresses the third, since it seems to me that any distribution with such complex licensing terms probably can't be covered by such a mechanism anyway. For instance, if I have A.pm under GPL and B.pm under BSD, what happens when they call each other? Does that constitute encapsulation and/or usage as a library? Such matters generally have to be spelled out explicitly. I agree that the second point is a problem. I'd like to solve it by delegating to Software::License. Anything it knows about should be a valid choice. -Ken
Re: Integrating license related things of CPAN
On Wed, Oct 29, 2008 at 9:13 PM, Ken Williams [EMAIL PROTECTED] wrote: On Mon, Oct 27, 2008 at 11:17 AM, David Cantrell [EMAIL PROTECTED] wrote: So, in summary, here's my objections to the current 'license' field in META.yml: * poorly documented; * limited range of options for licences; * only one licence per distribution The first is fixable so I'm not too bothered by it. The second and third are fundamental design flaws which make it unfit for purpose. Your proposal doesn't seem to address the second point in any way. I'm also not thrilled with how it addresses the third, since it seems to me that any distribution with such complex licensing terms probably can't be covered by such a mechanism anyway. For instance, if I have A.pm under GPL and B.pm under BSD, what happens when they call each other? Does that constitute encapsulation and/or usage as a library? Such matters generally have to be spelled out explicitly. I agree that the second point is a problem. I'd like to solve it by delegating to Software::License. Anything it knows about should be a valid choice. I think supporting options like other or mixed should resolve most of these cases. Sure, automatic tools that use this field will be out of luck, but that should be a fairly small minority.
Re: Integrating license related things of CPAN
I was wondering why no-one appeared to have read anything I said in this 'ere thread - and it seems my procmail rule to fix reply-to brokenness was, errm, broken. Oops. So, in summary, here's my objections to the current 'license' field in META.yml: * poorly documented; * limited range of options for licences; * only one licence per distribution The first is fixable so I'm not too bothered by it. The second and third are fundamental design flaws which make it unfit for purpose. In one of my messages that went missing, I proposed replacing it with this (and please excuse my bad YAML!): to mean everything's covered by the licence in GPL2.txt licence: GPL2.txt to mean this file's GPL2 or Artistic, that file's under the Apache licence, and everything else is in the public domain: licences: lib/Foo/Bar.pm: GPL2.txt or Artistic.txt lib/Apache/Foo/Bar.pm: Apache.txt *: public-domain and then say that *either* 'licence' *or* 'licences' must be present, as must the files they reference. The exact spelling of the word or in the second example I leave to you :-) -- David Cantrell | Godless Liberal Elitist When a man is tired of London, he is tired of life -- Samuel Johnson
Re: Integrating license related things of CPAN
On Sun, Oct 26, 2008 at 1:08 AM, Jonathan Rockway [EMAIL PROTECTED] wrote: If I use Term::ReadLine and it picks the Term::ReadLine::Gnu, is my module GPL now? JR may neither know nor care, but I think I know and I'd like to hear about it if I've got it wrong. No. You haven't distributed Term::ReadLine::Gnu. Making you a party to the goings-on in someone else's domain because you set up the possibility for that someone else to do something that they did is absurd. -- DN
Re: Integrating license related things of CPAN
* On Thu, Oct 23 2008, Bill Ward wrote: Perhaps when you upload to PAUSE without a license in META.yml it could actually replace the META.yml with one that has a license, based in input from an HTML form? Would that be too weird? I think it's technically feasible. So if the user doesn't provide information, PAUSE should just make it up? That doesn't sound very valuable. Now someone reading the license field will have to wonder whether they are looking at the real license or just the license that was randomly selected by PAUSE. This negates the entire usefulness of the field. Also, altering the contents of a distribution will break the signature generated by Module::Signature. Some other thoughts... is the license specified in the META.yml legally binding in any way? If not, anyone using the module will have to look at the rest of the distribution to determine its license, again negating the usefulness of this field. Then again, I, as the author, don't really know what license my distributions are distributed under. I could pick one, but can I really be sure that it applies? If I use Term::ReadLine and it picks the Term::ReadLine::Gnu, is my module GPL now? I don't know and I don't care. Does anyone else? Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: Integrating license related things of CPAN
On Sat, Oct 25, 2008 at 11:08 PM, Jonathan Rockway [EMAIL PROTECTED] wrote: * On Thu, Oct 23 2008, Bill Ward wrote: Perhaps when you upload to PAUSE without a license in META.yml it could actually replace the META.yml with one that has a license, based in input from an HTML form? Would that be too weird? I think it's technically feasible. So if the user doesn't provide information, PAUSE should just make it up? That doesn't sound very valuable. Now someone reading the license field will have to wonder whether they are looking at the real license or just the license that was randomly selected by PAUSE. This negates the entire usefulness of the field. Of course not, don't be absurd. But when the user is uploading the module, the PAUSE web interface could prompt them to select the license. Also, altering the contents of a distribution will break the signature generated by Module::Signature. That's a good point though. Some other thoughts... is the license specified in the META.yml legally binding in any way? If not, anyone using the module will have to look at the rest of the distribution to determine its license, again negating the usefulness of this field. Another good point. One could put GPL in the META.yml but have a LICENSE section in the POD that says same terms as Perl itself -- which one wins? Then again, I, as the author, don't really know what license my distributions are distributed under. I could pick one, but can I really be sure that it applies? If I use Term::ReadLine and it picks the Term::ReadLine::Gnu, is my module GPL now? I don't know and I don't care. Does anyone else? Some people care a lot; to others it doesn't matter so long as it's available. There are some major differences between the licenses, mainly around what can be done with derivative works, but that's a lot less likely to be an issue with a Perl module.
Re: Integrating license related things of CPAN
On Sun, Oct 26, 2008 at 8:38 AM, Bill Ward [EMAIL PROTECTED] wrote: On Sat, Oct 25, 2008 at 11:08 PM, Jonathan Rockway [EMAIL PROTECTED] wrote: Some other thoughts... is the license specified in the META.yml legally binding in any way? If not, anyone using the module will have to look at the rest of the distribution to determine its license, again negating the usefulness of this field. Another good point. One could put GPL in the META.yml but have a LICENSE section in the POD that says same terms as Perl itself -- which one wins? Once we have a clear definition of what should be the text in the POD section CPANTS will check if the licenses are the same. Actually I am sure we'll be able to upload a stand alone module that will check it and I think if you use Dist::Zilla you won't have to care as it will insert the right thing everywhere base on the license keyword you give it. Then again, I, as the author, don't really know what license my distributions are distributed under. I could pick one, but can I really be sure that it applies? If I use Term::ReadLine and it picks the Term::ReadLine::Gnu, is my module GPL now? I don't know and I don't care. Does anyone else? Some people care a lot; to others it doesn't matter so long as it's available. There are some major differences between the licenses, mainly around what can be done with derivative works, but that's a lot less likely to be an issue with a Perl module. I know, at some of my clients the license issue is critical. Some of the downstream distributors (Debian, Fedora ) are also very picky about the licensing terms. They might be extreme but I prefer these over the other extreme that says: oh its free software, we can do whatever want with it and then go on and redistribute a GPL software in their proprietary application. So I'd rather make it easy to check the license. Gabor Szabo http://szabgab.com/blog.html
Re: Integrating license related things of CPAN
* Jonathan Rockway [EMAIL PROTECTED] [2008-10-26 07:10]: I don't know and I don't care. Does anyone else? I do, because it matters. I would love to be able not to care, much as I would love to be able not to care about politics, or about money, because I find all of these topics utterly boring and insubstantial in their essence. But I can only ignore them at my (variously terrible) peril, and so for better of for worse, I know and care. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Integrating license related things of CPAN
Gabor Szabo schreef:
I am trying to push forward simplifying and clarifying the
licensing issues on CPAN.
It would be nice to have a license pragma.
use license Perl;
use license AL/GPL;
use license qw{
Artistic_2 (and_up)
GPL_3 (and_up)
};
We already have
http://search.cpan.org/search?query=Software%3A%3ALicensemode=module
--
Affijn, Ruud
Gewoon is een tijger.
Re: Integrating license related things of CPAN
* Dr.Ruud [EMAIL PROTECTED] [2008-10-26T06:28:44] Gabor Szabo schreef: I am trying to push forward simplifying and clarifying the licensing issues on CPAN. It would be nice to have a license pragma. use license Perl; What would this do? -- rjbs
Re: Integrating license related things of CPAN
# from Ricardo SIGNES # on Sunday 26 October 2008: It would be nice to have a license pragma. use license Perl; What would this do? Skip calls to any code which didn't conform to that license ;-) --Eric -- Moving pianos is dangerous. Moving pianos are dangerous. Buffalo buffalo buffalo buffalo buffalo buffalo buffalo. --- http://scratchcomputing.com ---
Re: Integrating license related things of CPAN
Eric Wilhelm wrote: # from Ricardo SIGNES # on Sunday 26 October 2008: It would be nice to have a license pragma. use license Perl; What would this do? Skip calls to any code which didn't conform to that license ;-) Oh good. Nothing that could possibly go wrong then. -john
Re: Integrating license related things of CPAN
Ricardo SIGNES schreef: Dr.Ruud: Gabor Szabo: I am trying to push forward simplifying and clarifying the licensing issues on CPAN. It would be nice to have a license pragma. use license Perl; What would this do? That's up to the creator of the license pragma, but it would most probably be defined as standing for: This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. See http://www.perl.com/perl/misc/Artistic.html;. -- Affijn, Ruud Gewoon is een tijger.
Re: Integrating license related things of CPAN
In article [EMAIL PROTECTED], Bill Ward [EMAIL PROTECTED] wrote: Of course not, don't be absurd. But when the user is uploading the module, the PAUSE web interface could prompt them to select the license. That fails for a couple of reasons: 1. PAUSE is not the arbiter of licences and doesn't handle license managment. 2. Not everyone uses the web interface.
Re: Integrating license related things of CPAN
In article [EMAIL PROTECTED], Jonathan Rockway [EMAIL PROTECTED] wrote: Then again, I, as the author, don't really know what license my distributions are distributed under. I don't know and I don't care. Does anyone else? I care only to the extent that a user needs something in particular so they can use my code. Almost all of my stuff in Artistic License, but I inherited a couple of GPL packages. Those are the headaches because I have to deal with other people's religion and the constraints that puts on users. I should modify my Distribution::Cooker templates to put license information in every file though.
Re: Integrating license related things of CPAN
* Dr.Ruud [EMAIL PROTECTED] [2008-10-26T14:39:23] That's up to the creator of the license pragma, but it would most probably be defined as standing for: This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. See http://www.perl.com/perl/misc/Artistic.html;. It just seems less than useful to require the loading of more code at execution time to stand in for a comment. Further, given that various packagers (Debian, etc) really really would like to see an explicit copyright in each file, it actually seems counterproductive, since authors may think that adding a 'use license' statement is sufficient. -- rjbs
Re: Integrating license related things of CPAN
On Sun, Oct 26, 2008 at 1:38 AM, Bill Ward [EMAIL PROTECTED] wrote: Another good point. One could put GPL in the META.yml but have a LICENSE section in the POD that says same terms as Perl itself -- which one wins? That's the very reason I want to get the license text out of the POD and into an auto-written LICENSE file. Right now it's all well and good to compile statistics about license declarations in META.yml files, but if there are separate LICENSE sections in the POD then people ( robots) have to look at that manually and we've really gained very little. -Ken
Re: Integrating license related things of CPAN
On Sun, Oct 26, 2008 at 7:00 PM, Ken Williams [EMAIL PROTECTED] wrote: On Sun, Oct 26, 2008 at 1:38 AM, Bill Ward [EMAIL PROTECTED] wrote: Another good point. One could put GPL in the META.yml but have a LICENSE section in the POD that says same terms as Perl itself -- which one wins? That's the very reason I want to get the license text out of the POD and into an auto-written LICENSE file. Right now it's all well and good to compile statistics about license declarations in META.yml files, but if there are separate LICENSE sections in the POD then people ( robots) have to look at that manually and we've really gained very little. The problem is people may add it to META.yml but not remove it from the POD. For one thing, it would be nice to be able to see what the license is when viewing the POD. Once the module is installed META.yml is no longer present, and there's no way for someone using the module to determine the license from perldoc/man. Also, some modules may include a separate LICENSE or COPYRIGHT file in the tarball.
Re: Integrating license related things of CPAN
On Oct 26, 2008, at 10:24 PM, Bill Ward wrote: The problem is people may add it to META.yml but not remove it from the POD. For one thing, it would be nice to be able to see what the license is when viewing the POD. Once the module is installed META.yml is no longer present, and there's no way for someone using the module to determine the license from perldoc/man. Also, some modules may include a separate LICENSE or COPYRIGHT file in the tarball. (joining this discussion late...) Isn't that just an authoring problem that already exists today? The LICENSE file is not kept after installation either. This is a human problem, so I think a human solution is appropriate, like a Perl::Critic policy or a Kwalitee rule or a distcheck action to ensure the META.yml matches the POD copyright. The definition of matches is the hard part...
Re: Integrating license related things of CPAN
Hello. Bill Ward wrote: The META.yml thing is nice but you can't make it required yet. The recommended version of Perl for production use is 5.8.8. It is 5.10 now (for a half year or so). http://5.8.8. The version of ExtUtils::MakeMaker included in 5.8.8 distributions does not support the license field. And they would not see error (as we have no means to modify EU::MM at their computers). Only when they upgrade to EU::MM that has mandatory license or to 5.10.1 (maybe 5.8.9), they would see this error. -- Alexandr Ciornii, http://chorny.net
Re: Integrating license related things of CPAN
On Fri, Oct 24, 2008 at 4:01 AM, Alexandr Ciornii [EMAIL PROTECTED]wrote: Bill Ward wrote: The META.yml thing is nice but you can't make it required yet. The recommended version of Perl for production use is 5.8.8. It is 5.10 now (for a half year or so). Not according to perl.com (http://www.perl.com/download.csp): The maintenance version of Perl is *5.8.8*. This is a stable, tested release that you should use in production environments. It was based on this that we (at my day job) recently decided to move from 5.8.6 to 5.8.8 and not 5.10.0. Also, .0 releases (of any software) are notorious for having stability issues. http://5.8.8. The version of ExtUtils::MakeMaker included in 5.8.8 distributions does not support the license field. And they would not see error (as we have no means to modify EU::MM at their computers). Only when they upgrade to EU::MM that has mandatory license or to 5.10.1 (maybe 5.8.9), they would see this error. Yeah I misunderstood at first, I thought the error would occur at the time of uploading to CPAN rather than at make dist time. --Bill.
Re: Integrating license related things of CPAN
On Fri, Oct 24, 2008 at 10:11 PM, Bill Ward [EMAIL PROTECTED] wrote: On Fri, Oct 24, 2008 at 4:01 AM, Alexandr Ciornii [EMAIL PROTECTED] wrote: Bill Ward wrote: The META.yml thing is nice but you can't make it required yet. The recommended version of Perl for production use is 5.8.8. It is 5.10 now (for a half year or so). Not according to perl.com (http://www.perl.com/download.csp): Please. if anyone wants to discuss which version of perl is stable or why isnt 5.10.0 marked as such, please open a separate thread. This is irrelevant to the license issue. http://5.8.8. The version of ExtUtils::MakeMaker included in 5.8.8 distributions does not support the license field. And they would not see error (as we have no means to modify EU::MM at their computers). Only when they upgrade to EU::MM that has mandatory license or to 5.10.1 (maybe 5.8.9), they would see this error. Yeah I misunderstood at first, I thought the error would occur at the time of uploading to CPAN rather than at make dist time. There was such a suggestion on the thread but I don't think we should go that far in enforcing it. Anyway, even without any enforcing we should at least make the possible values clear and easy to use. What we need now is 1) moving the list of licenses from the MB::API to the META.yml spec 2) Adding the missing licenses to Software::License (the licenses that are in the API/spec already but not in SL) 3) Changing the META.yml spec to include more Open source licenses. (All the licenses from SL ?) 4) IMHO we need a way to indicate that none of the defined licenses fit your module. There is an option to call it unknown but IMHO some other word would describe the situation better. Maybe other? 5) There are modules that have parts with different licenses. e.g. DBD::SQlite includes third party code with different license. No matter what the relationship between the two (or more) licenses, we should somehow indicated in the META.yml what is the license. In general IMHO this is something we can never define well for all the possible cases so maybe all such modules should set license field to other saying that I am aware of the filed but cannot use it to describe the license exactly. Gabor
Re: Integrating license related things of CPAN
On Fri, Oct 24, 2008 at 10:11 PM, Bill Ward [EMAIL PROTECTED] wrote: On Fri, Oct 24, 2008 at 4:01 AM, Alexandr Ciornii [EMAIL PROTECTED] wrote: Bill Ward wrote: The META.yml thing is nice but you can't make it required yet. The recommended version of Perl for production use is 5.8.8. It is 5.10 now (for a half year or so). Not according to perl.com (http://www.perl.com/download.csp): Please. if anyone wants to discuss which version of perl is stable or why isnt 5.10.0 marked as such, please open a separate thread. This is irrelevant to the license issue. http://5.8.8. The version of ExtUtils::MakeMaker included in 5.8.8 distributions does not support the license field. And they would not see error (as we have no means to modify EU::MM at their computers). Only when they upgrade to EU::MM that has mandatory license or to 5.10.1 (maybe 5.8.9), they would see this error. Yeah I misunderstood at first, I thought the error would occur at the time of uploading to CPAN rather than at make dist time. There was such a suggestion on the thread but I don't think we should go that far in enforcing it. Anyway, even without any enforcing we should at least make the possible values clear and easy to use. What we need now is 1) moving the list of licenses from the MB::API to the META.yml spec 2) Adding the missing licenses to Software::License (the licenses that are in the API/spec already but not in SL) 3) Changing the META.yml spec to include more Open source licenses. (All the licenses from SL ?) 4) IMHO we need a way to indicate that none of the defined licenses fit your module. There is an option to call it unknown but IMHO some other word would describe the situation better. Maybe other? 5) There are modules that have parts with different licenses. e.g. DBD::SQlite includes third party code with different license. No matter what the relationship between the two (or more) licenses, we should somehow indicated in the META.yml what is the license. In general IMHO this is something we can never define well for all the possible cases so maybe all such modules should set license field to other saying that I am aware of the filed but cannot use it to describe the license exactly. Gabor
Re: Integrating license related things of CPAN
The META.yml thing is nice but you can't make it required yet. The recommended version of Perl for production use is 5.8.8. The version of ExtUtils::MakeMaker included in 5.8.8 distributions does not support the license field. Supporting it is nice, but you'll have to wait until 5.10 is more widely in use before you can make it be required. What you could do, however, is modify PAUSE to require the user to specify the license there (as an HTML form thingy) when it isn't found in the META.yml in the tarball. On Wed, Oct 22, 2008 at 4:09 AM, Gabor Szabo [EMAIL PROTECTED] wrote: 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
* Bill Ward [EMAIL PROTECTED] [2008-10-23T15:20:00] The META.yml thing is nice but you can't make it required yet. The recommended version of Perl for production use is 5.8.8. The version of ExtUtils::MakeMaker included in 5.8.8 distributions does not support the license field. Gabor is not suggesting that it be required to upload to PAUSE, but that it be required to 'make dist.' This change would, perforce, require yet another new version of EU::MakeMaker et al. -- rjbs
Re: Integrating license related things of CPAN
On Thu, Oct 23, 2008 at 1:49 PM, Ricardo SIGNES [EMAIL PROTECTED] wrote: * Bill Ward [EMAIL PROTECTED] [2008-10-23T15:20:00] The META.yml thing is nice but you can't make it required yet. The recommended version of Perl for production use is 5.8.8. The version of ExtUtils::MakeMaker included in 5.8.8 distributions does not support the license field. Gabor is not suggesting that it be required to upload to PAUSE, but that it be required to 'make dist.' This change would, perforce, require yet another new version of EU::MakeMaker et al. Well I have no problem with that. But how about changing PAUSE? Perhaps when you upload to PAUSE without a license in META.yml it could actually replace the META.yml with one that has a license, based in input from an HTML form? Would that be too weird? I think it's technically feasible.
Re: Integrating license related things of CPAN
* Bill Ward [EMAIL PROTECTED] [2008-10-23T17:11:09] On Thu, Oct 23, 2008 at 1:49 PM, Ricardo SIGNES Gabor is not suggesting that it be required to upload to PAUSE, but that it be required to 'make dist.' This change would, perforce, require yet another new version of EU::MakeMaker et al. Well I have no problem with that. But how about changing PAUSE? Perhaps when you upload to PAUSE without a license in META.yml it could actually replace the META.yml with one that has a license, based in input from an HTML form? Would that be too weird? I think it's technically feasible. Too many authors use one of the various cpan-upload scripts, all of which would now break. I think it's likely to be a big pain. What if the user puts a 'license X' declaration all over all the files, but forgets to include a license in META.yml. Then PAUSE puts in a default, from the user's profile? Now there is a conflict. Also, if this was set in some thing while uploading, the user would have to specify it every time? I mean, if he wanted to specify the license once and be done with it, he'd make sure he got a META.yml. The best solution will be, eventually, to reject dists without a valid META.yml. I don't think META.yml or its producers are ready for that, yet. -- rjbs
Re: Integrating license related things of CPAN
On Thu, Oct 23, 2008 at 4:18 PM, Ricardo SIGNES [EMAIL PROTECTED] wrote: * Bill Ward [EMAIL PROTECTED] [2008-10-23T17:11:09] On Thu, Oct 23, 2008 at 1:49 PM, Ricardo SIGNES Gabor is not suggesting that it be required to upload to PAUSE, but that it be required to 'make dist.' This change would, perforce, require yet another new version of EU::MakeMaker et al. Well I have no problem with that. But how about changing PAUSE? Perhaps when you upload to PAUSE without a license in META.yml it could actually replace the META.yml with one that has a license, based in input from an HTML form? Would that be too weird? I think it's technically feasible. Too many authors use one of the various cpan-upload scripts, all of which would now break. I've never seen these upload scripts but I suppose it's a nobrainer that they should exist. If no license is in META.yml, and none is specified through the upload process, then it would be rejected. That's the behavior that was proposed anyway. And if the uploader scripts want to play ball with the new rules we could easily allow them to specify license=gpl2 or something in the URL they are uploading to or whatever API they're using. Under the proposed plan, uploader scripts would fail unless there was a license in META.yml anyway, so this is a red herring. I think it's likely to be a big pain. What if the user puts a 'license X' declaration all over all the files, but forgets to include a license in META.yml. Then PAUSE puts in a default, from the user's profile? Now there is a conflict. Also, if this was set in some thing while uploading, the user would have to specify it every time? I mean, if he wanted to specify the license once and be done with it, he'd make sure he got a META.yml. All problems that could be solved through good usability design. The ability to set a default per-user would help, as would the ability to recycle the license used the last time. The best solution will be, eventually, to reject dists without a valid META.yml. I don't think META.yml or its producers are ready for that, yet. I agree. My idea of adding this feature in PAUSE would provide a stopgap solution, though.
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
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: 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
