17. Better formalization of license field

Proposal:

Replace the list of strings for the "license" field with something
extensible and unambiguous. (RicardoSignes)

Comments:

* I believe Module::Build already allows the use of Software::License
  classes here.  That would be a simple solution.

* I wouldn't want to depend on an external module for a list.  I'd be OK
  giving an explicit list in the spec drawn from there and saying that
  lower case names are reserved and anything else must start with a capital
  letter.  Consumers can try to lower case the field and see if
  Software::License supports it. (Dagolden)

* When it comes to extensible and unambiguous identifiers, all roads
  eventually lead to URLs... (AdamKennedy);

* There won't need to be a list, apart from perhaps 02packages.  also,
  cpan:///package/Software::License::Perl_5 works; it makes it easy to
  re-use your own license in a machine-readable way by publishing it as a
  package, and is namespaced and indexed; if it can't be found, treat as
  Other rjbs 15:21, 28 August 2009 (BST)

* Right now, the only dual license you can specify is "perl".  What if
  someone wants a dual Artistic 2/GPL 3 license? The current spec says this
  can only be a string; why not an array? [[User:elliot|Elliot Shank]]

* Licences can differ per-file - eg, code might be covered by
  Artistic1/GPL2, and doco by something CCish.  Or some code might be
  Artistic1/GPL2 but one file borrowed from another project might be GPL2+.
  For plenty of distributions, a single entry (whether it be a string or an
  array) is misleading. [[User:DrHyde|David Cantrell]]

* ...so we can have Mixed, which is a subset of Other. rjbs 15:21, 28
  August 2009 (BST)

* Devil's advocate position: Does anyone really care about license in
  META.yml?  I mean -- consume it?  Any packager or company needs to read
  the individual files to check for copyright/license statements anyway.
  How does having an assertion in META.yml help anyone? (Dagolden)

* Seconded. Perhaps a list of URLs to licences that apply to all or part of
  the distribution would be more applicable. (Barbie)

* Terse and automatically encoded forms of the license could be handy for
  recursive license traversal (for example, to spot clashes in licensing).
  It also makes life easier for things like search.cpan.org and other
  websites --Adam K

Reply via email to