On Mon, Mar 31, 2008 at 6:28 PM, David Cantrell <[EMAIL PROTECTED]> wrote: > On Mon, Mar 24, 2008 at 11:54:01PM +0200, Gabor Szabo wrote: > > On Mon, Mar 24, 2008 at 11:30 PM, David Landgren <[EMAIL PROTECTED]> wrote: > > > Gabor Szabo wrote: > > > > As I am usually using Module::Build I did not know that a recent > > > > version of MakeMaker > > > > has started to support the LICENSE parameter and will include it in > > > > the automatically > > > > created META.yml. > > > That has been the case for a couple of years or so. I think it was first > > > introduced in 6.30. > > Now are you telling me... :-) > > and I have been giving the lack of LICENSE support of MakeMaker as the > excuse > > why so many modules have their Lincense set to Unknown on > search.cpan.org.[1] > > In my case it's because I didn't know that it was supported in the > version of MakeMaker that I use (I didn't even know what version I used > until just now when I checked) and also because I don't care much. I > put the licence information in POD. If you care what specific licence I > use for a piece of code, read the documentation. If you only care that > it be free software, then you needn't bother, as that's one of the > pre-requisites for something being on the CPAN.
Besides the point that AFAIK there is no requirement on PAUSE/CPAN that everything must be OSI licensed, there are huge differences between free and free too. On one hand you as the author are free to decide which license to use on the other hand the distributors and the end users are free to decide which license they accept and which not. Their reasons might not make sense to you or me but that's beyond this discussion. The distributors (e.g. Fedora, Debian) have their own rules of what do they distribute. (e.g. Fedora will not package anything that is Artistic 1 only - without the GPL). Both Fedora and Debian wants to make sure the licenses are correctly (to whatever value of correct) are spelled out. AFAIK they care more about the textual license than the META.yml field. The latter is a mere convenience for someone who wants to to easily automate the filtering of modules. When I had to put about 100 modules through the legal department of a company I really wished I had an easy and automatable method of gathering this information. One of the drawback of nature of CPAN is the lack of standardization. I don't want to standardize what license you use, I just wish there was an easy way to know what are you using. Also it does not have cover all the modules but I don't think there are more than 10% that need special treatment. When installing and using module X I have the time reading its docs and license but I am quite sure I won't have time to do so with its 20-40 dependencies. On one hand I don't care how the dependencies work as long as the module I am using works. On the other hand I still need to make sure the licenses of all the dependencies are acceptable by whatever organization I working for. Eg. can I use Moose? There is this nice site you might be familiar with http://cpandeps.cantrell.org.uk/ that shows the dependencies of a module and the likeliness it will be able to install on your system. But should I bother installing it or is one of its dependencies incompatible with the requirements of whatever organization I do it for? > > [1] Among others I have talked to the Debian and Fedora packagers and > > they both said that one of the problematic issues with CPAN modules is > > the lack or incorrect license information. > > How can they possibly determine whether a licence is correct or not? I don't know and I hope to work with them more in order to find out how do they determine that. If we can help them make their work easier without a lot of work on our side then we can make the life of our end users easier. (which in turn will bring more nice bug reports to us :-) regards Gabor
