I have to say that I really don't care going down this particular rabbit
hole. We can argue this to hell and back, but in the end if it comes to
that, the court will decide, for each particular case.
On Wed, Nov 4, 2009 at 12:57 PM, David Cantrell da...@cantrell.org.ukwrote:
On Tue, Nov 03,
Angels, head of a pin, lawyers, three doors down :-)
On Tue, Nov 3, 2009 at 3:02 PM, Zefram zef...@fysh.org wrote:
Jarkko Hietaniemi wrote:
If your need is to list the licenses a package contains, in a way there is
no need to list the public domain bits because there are no strings,
err,
Jarkko Hietaniemi wrote:
If your need is to list the licenses a package contains, in a way there is
no need to list the public domain bits because there are no strings, err,
licenses attached. It is in the public domain.
Null licensing is not the same as not saying anything about licensing.
David Golden wrote:
17.01) Enumerate a list of license strings explicitly in the spec,
Yes, that's good.
17.02) Make the license field an arrayref rather than a scalar.
Bad idea as it stands. There are at least two ways that different
licenses can be combined in one distro: (a) you may
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
* David Golden xda...@gmail.com [2009-10-11T21:49:28]
On Sun, Oct 11, 2009 at 8:59 PM, Ricardo Signes
perl.cpanw...@rjbs.manxome.org wrote:
I am also happy to add a meta2_name method to all the Software::License
classes to avoid a direct connection between SL and META, but I don't want
to
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
On Sun, Oct 11, 2009 at 11:15 PM, Chris Weyl chris.w...@gmail.com wrote:
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
David Golden wrote:
Replace the list of strings for the license field with something
extensible and unambiguous. (RicardoSignes)
The existing strings *are* unambiguous, and extensible to new
widely-used licenses. It seems convenient for this information to be
fully machine-understandable, in
On Oct 10, 2009, at 5:21 PM, Jarkko Hietaniemi wrote:
gpl
The distribution is licensed under the terms of the GNU
General Public
License (http://www.opensource.org/licenses/gpl-license.php).
What version?
There are numerous other ambiguous cases.
Likewise, (the same as) perl
On Fri, Oct 9, 2009 at 7:50 AM, David Golden xda...@gmail.com wrote:
17. Better formalization of license field
Proposal:
Replace the list of strings for the license field with something
extensible and unambiguous. (RicardoSignes)
This discussion is going in circles, I think. I'd like to
On Oct 9, 2009, at 6:50 AM, David Golden wrote:
17. Better formalization of license field
Proposal:
Replace the list of strings for the license field with something
extensible and unambiguous. (RicardoSignes)
+1
From the perspective of search.cpan I would like to see it have two
On Oct 9, 2009, at 11:53 AM, Ruslan Zakirov wrote:
* 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
On Fri, Oct 9, 2009 at 7:50 AM, David Golden xda...@gmail.com wrote:
17. Better formalization of license field
Proposal:
Replace the list of strings for the license field with something
extensible and unambiguous. (RicardoSignes)
I would prefer to remove the license field entirely.
In the
On Oct 9, 2009, at 1:16 PM, David Golden wrote:
In the resources section, there is a license key. Let's make that
a hash, instead, with name/URL pairs. Any licenses which may apply to
any part of the distribution should be listed. (I.e. multiple entries
do *not* mean license options like
15 matches
Mail list logo