On Sun, Oct 11, 2009 at 1:40 PM, Ruslan Zakirov
<ruslan.zaki...@gmail.com> wrote:
> On Sun, Oct 11, 2009 at 5:16 PM, David Golden <xda...@gmail.com> wrote:
>> On Sun, Oct 11, 2009 at 3:21 AM, Zefram <zef...@fysh.org> wrote:
>>>>17.02) Make the license field an arrayref rather than a scalar.
>>>>
>>> Could make the field a string expression, with the defined keywords as
>>> atomic expressions, "|" and "&" operators for license combination, and
>>> parens for precedence. A distro with some files Perl-licensed and some
>>> pure-GPLed could then be expressed as "gpl & perl". "perl" itself is
>>> defined as "gpl | artistic".
>>
>> -1
>>
>> License can never really be determined without actually reading the
>> source. I don't want to see us create a mini-language to describe
>> license combinations.
>
> Agree with this.
I strongly disagree. Software licensing is one of the most important
things to consider when packaging software for distribution (or,
frankly, using it as part of another bit of software); we ought to
give authors a clear, easy way to unambiguously specify the terms
their software is under... IMHO, we don't give this nearly enough
thought when it comes to software we release on the CPAN. Right now,
we're at a point that we can do this without significant additional
pain down the road.
Suggestion:
* Allow a null value, but only as "the author has specifically chosen
to not designate a licensing scheme."
I'm hoping this will be fairly rare :)
* Allow an "unspecified" value, but only as "the author has not
indicated a licensing scheme and any auto-determination that may have
been applied has failed."
* Continue the current auto-guessing / flagging that goes on, but add
a field indicating that the license was auto-determined by a build
tool.
* Create a specific set of names that should be used with the most
common licenses and allow, but not mandate, their use.
We already do this to a certain extent -- e.g. Module::Install's
"license 'perl'", "license 'lgpl'" and the like. This could be
retained, while also extending to be more granular. (e.g. 'lgpl2+' to
specifically indicate "LGPL v2 or later" rather than only 'lgpl',
which is a less precise.)
Just because an automated tool can't 100% determine what license the
software is under doesn't mean that we shouldn't allow authors who
choose to do so to specify clearly and unambiguously how they are
licensing their code. While this won't work in 100% of all licensing
systems (e.g. someone makes up a license on the fly), we can enable
this to a very high degree just by hitting the most common licenses.
-Chris
--
Chris Weyl
Ex astris, scientia
