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! What we're dealing with here is whether a relatively simple META file can/should attempt to deal with the many ways that authors may choose to specify one or more license, whether junctions or unions or whatever, in a file intended for consumption by machines. Right now the "license" field is mandatory and takes a single key from a restricted set of keys. I suspect this is sufficient for 99% of distributions on CPAN. No one has been able to articulate a clear *current* problem that more than one or two people are actually complaining about today. This whole proposal and discussion is bikeshedding how we might possibly solve problems that people haven't really experienced yet. This discussion also should not be about how M::I, M::B or EU::MM guess/flag or otherwise set a license in the META file. It should just be about how we want to *summarize* licensing information in a machine readable format. Every suggestion seems to come down to one of these options: (a) a defined 'keyword' that indicates a particular license (e.g. 'perl', 'gpl', 'gpl2', 'unknown', etc.) Pro: status quo; short Con: arbitrary and we have to revise the spec to add new types; requires users to know how to map those to actual license information (b) a 'name' (e.g. 'The Artistic License 1.0') (c) a 'url' (e.g. http://dev.perl.org/licenses/) [Treating these together as they are similar] Pro: user-defined, thus extensible; meaning is obvious Con: not standardized; machine consumers need heuristics to match a license; URL's can go stale (d) a Software::License class suffix (e.g. 'Artistic_2_0') or full classname (e.g. 'Software::License::BSD') Pro: user-defined, thus extensible; maps to a CPAN API that provides additional information like name and URL Con: awkward, non-obvious meaning (more obvious if full class-name is used); makes META interpretation dependent on a CPAN module (e) free text (whether written by hand or via a helper module) Pro: completely flexible for all types of licenses (including odd combinations) Con: requires heuristics to parse back into machine-useable form Then the remaining issue is whether the license field is a scalar or an array and what meaning is ascribed to an array. Given that one of the design criteria for 2.0 is to be limited in our changes, here's my proposal (not quite in patch format, but hopefully clear enough): 'license' [required]{string or arrayref} One or more licenses that apply in some way to the distribution. If more than one license is listed, distribution documentation should be consulted for details. The list of valid options includes: [incorporate the meta_name() from every existing Software::License subclasss, plus the existing non-license terms in M::B::API like 'open_source' and 'restrictive'] Then we specify that that $meta->{resource}{license} is optional and is either a URL string or a hashref of name/URL pairs (that will probably be autopopulated by M::B or M::I anyway based on what goes into the 'license' field) I think that is as limited as can be and should be sufficient for 99.9% of situations that will arise on CPAN. Reactions please? -- David
