-=| Chris Weyl, Sun, Oct 11, 2009 at 08:15:12PM -0700 |=- > On Sun, Oct 11, 2009 at 5:10 PM, David Golden <xda...@gmail.com> wrote: > > On Sun, Oct 11, 2009 at 5:33 PM, Chris Weyl <chris.w...@gmail.com> wrote: > >> we ought to > >> give authors a clear, easy way to unambiguously specify the terms > >> their software is under... > > > > Authors have a clear, easy, unambiguous way to specify the terms there > > software is under. > > > > THEY WRITE IT IN THE SOURCE FILES!
Indeed. > Well, yes, but that's not exactly optimal. The same argument could > be > made that authors have a clear, easy, unambiguous way of specifying > their software's dependencies: in the source! And that's not exactly > optimal, either, so it gets (re)stated in Makefile.PL/Build.PL/etc and > then regurgitated out into META.yml for tool usage. This analogy is not valid. The consequences of mis-stating the information in META is quite different for license and dependencies. If one mis-states dependencies, you get build failures that are easily fixable (install missing dependencies). If you rely on a particular license and the truth is something else, you can get in legal trouble. Licensing is very important for downstream distribution. Having properly and clearly licensed code, in the source files, is of crucual value. Having a complicated license key in META may leave authors with the impression that they don't need to write license statements in their source. Therefore, I'd lean towards a license key with simple meaning. Perhaps renaming it to "used_licenses" and making it an array, meaning to contain all licenses (keywords like "perl5" or "gpl2" that are used in the sources. This way index services will get their data and authors won't be encouraged (hopefuly) to abandon maintaining proper licensing statements in their code. > Right now, we're > in a situation where even if an author wanted to more precisely state > what the licensing scheme is, the current spec doesn't support it. > I'd say that's the problem... Expanding to a set of licenses, with a > larger base of tags (as others have suggested) would go a long way to > addressing this. As an example of a "language" for describing licenses in detail, see http://dep.debian.net/deps/dep5/ . It is about Debian's "copyright" files. Its goal is to let the maintainer describe the copyright holder, the years of copyright and the license of each and every file in the package. The target usage is both human and machines. I doubt META wants any such thing. > As a packager outside of the CPAN I want to have a good idea if we can > redistribute the software -- legally and within project policy. Just > as dependency metadata gives me a good view into the software's > requirements, so licensing metadata gives me a good view of the > legal/policy requirements. So I end up being one of the two people > that worry about it alot :) Hm, I'd say that such a preliminary (and limited) view is not of much use when downstream distribution is concerned as it is of no legal value. You always have to check the actual source anyway. -- dam
signature.asc
Description: Digital signature
