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 wrote:
> On Tue, Nov 03, 2009 at 02:12:00PM -050
On Tue, Nov 03, 2009 at 02:12:00PM -0500, Jarkko Hietaniemi wrote:
> On Tue, Nov 3, 2009 at 12:41 PM, David Cantrell wrote:
> > On Mon, Nov 02, 2009 at 12:45:30PM -0500, Jarkko Hietaniemi wrote:
> > > +Inf. "Public domain" doesn't mean what one might think it means. Most
> > > importantly, it doe
Angels, head of a pin, lawyers, three doors down :-)
On Tue, Nov 3, 2009 at 3:02 PM, Zefram 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,
> >licenses
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.
* Jarkko Hietaniemi [2009-11-03T14:12:00]
>
> 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.
>
I think that's the best "against" I have rea
On Mon, Nov 02, 2009 at 12:45:30PM -0500, Jarkko Hietaniemi wrote:
> +Inf. "Public domain" doesn't mean what one might think it means. Most
> importantly, it doesn't mean much outside U. S. jurisdictions.
[citation needed]
But to avoid ambiguity, how about using "copyright-free" instead of
"pu
On Tue, Nov 3, 2009 at 12:41 PM, David Cantrell wrote:
> On Mon, Nov 02, 2009 at 12:45:30PM -0500, Jarkko Hietaniemi wrote:
>
> > +Inf. "Public domain" doesn't mean what one might think it means. Most
> > importantly, it doesn't mean much outside U. S. jurisdictions.
>
> [citation needed]
>
The
On Mon, Nov 02, 2009 at 12:14:05PM -0500, David Golden wrote:
> On Mon, Nov 2, 2009 at 11:04 AM, David Cantrell wrote:
> > On Sat, Oct 31, 2009 at 03:44:14PM -0400, David Golden wrote:
> >> C.f. http://rosenlaw.com/lj16.htm
> > That article looks solely at software. Distributions on the CPAN are
On Mon, Nov 2, 2009 at 3:38 PM, Barbie wrote:
> If I want to include a pre-existing piece of work in a distribution,
> which has already been released as public domain, then I would prefer to
> acknowledge that part of the whole is released that way.
>
> I already have distributions that are lacki
On Mon, Nov 02, 2009 at 12:14:05PM -0500, David Golden wrote:
>
> But everything I've read about "public domain" says "don't do it" --
> just use a permissive license instead. E.g.
> http://wiki.creativecommons.org/CC0_FAQ.
Whether it's a good idea or not is immaterial.
If I want to include a p
+Inf. "Public domain" doesn't mean what one might think it means. Most
importantly, it doesn't mean much outside U. S. jurisdictions.
On Mon, Nov 2, 2009 at 12:14 PM, David Golden wrote:
> On Mon, Nov 2, 2009 at 11:04 AM, David Cantrell
> wrote:
> > On Sat, Oct 31, 2009 at 03:44:14PM -0400, D
On Mon, Nov 2, 2009 at 11:04 AM, David Cantrell wrote:
> On Sat, Oct 31, 2009 at 03:44:14PM -0400, David Golden wrote:
>> On Sat, Oct 31, 2009 at 1:50 PM, Barbie wrote:
>> > Can we also have "public" for Public Domain, or is this what
>> > "open_source" represents?
>> It's not clear that "public
On Sat, Oct 31, 2009 at 03:44:14PM -0400, David Golden wrote:
> On Sat, Oct 31, 2009 at 1:50 PM, Barbie wrote:
> > Can we also have "public" for Public Domain, or is this what
> > "open_source" represents?
> It's not clear that "public domain" is a valid legal status,
> particularly in many countr
On Sat, Oct 31, 2009 at 1:50 PM, Barbie wrote:
> Can we also have "public" for Public Domain, or is this what
> "open_source" represents?
It's not clear that "public domain" is a valid legal status,
particularly in many countries.
C.f. http://rosenlaw.com/lj16.htm
So I would rather not encode a
On Sun, Oct 11, 2009 at 09:49:28PM -0400, David Golden wrote:
> to make it easy to look up things in the license field. The rule I'm
> following is
> that the "first" entry for a family has no version number and subsequent ones
> are have a version separated by an underscore. This is consistent
-=| Chris Weyl, Sun, Oct 11, 2009 at 08:15:12PM -0700 |=-
> On Sun, Oct 11, 2009 at 5:10 PM, David Golden wrote:
> > On Sun, Oct 11, 2009 at 5:33 PM, Chris Weyl wrote:
> >> we ought to
> >> give authors a clear, easy way to unambiguously specify the terms
> >> their software is under...
> >
> > A
On Oct 11, 2009, at 5:59 PM, Ricardo Signes wrote:
I am all for something like this:
license is a required string or arrayref[string] of all the
licenses that are
known to be at play for the dist; the list of valid options includes:
a list of unambiguous identifiers for real licenses
I've put together a branch for my recommendation:
http://github.com/dagolden/cpan-meta-spec/tree/17-license
Per an IRC suggestion from Rick, I've made all relevant strings have a
version number attached. This unfortunately breaks backwards
compatibility, but eliminates the current ambiguity of
On Sun, Oct 11, 2009 at 11:15 PM, Chris Weyl 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 licensing metada
On Sun, Oct 11, 2009 at 5:10 PM, David Golden wrote:
> On Sun, Oct 11, 2009 at 5:33 PM, Chris Weyl 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
>
On Sun, Oct 11, 2009 at 10:02 PM, Ricardo Signes
wrote:
> We'll need to make sure that anything currently ambiguous is not changed in
> meaning. That is, we don't want to worry about interpreting the meaning of a
> license field based on the metafile version if possible.
I believe I'm using the
* David Golden [2009-10-11T21:49:28]
> On Sun, Oct 11, 2009 at 8:59 PM, Ricardo Signes
> 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 keep using the unsatisfactory list from
On Sun, Oct 11, 2009 at 8:59 PM, Ricardo Signes
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 keep
> using the unsatisfactory list from the current spec.
I didn't realize they wer
* David Golden [2009-10-11T20:10:49]
> 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
On Sun, Oct 11, 2009 at 5:33 PM, Chris Weyl 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'
On Sun, Oct 11, 2009 at 10:33 PM, Chris Weyl wrote:
> * Continue the current auto-guessing / flagging that goes on, but add
> a field indicating that the license was auto-determined by a build
> tool.
If you go down this route, then I suggest we either have to make the
requirement of such a fiel
Chris Weyl wrote:
> On Sun, Oct 11, 2009 at 1:40 PM, Ruslan Zakirov
> wrote:
>> On Sun, Oct 11, 2009 at 5:16 PM, David Golden wrote:
>>> On Sun, Oct 11, 2009 at 3:21 AM, Zefram wrote:
> 17.02) Make the license field an arrayref rather than a scalar.
>
Could make the field a string e
On Sun, Oct 11, 2009 at 1:40 PM, Ruslan Zakirov
wrote:
> On Sun, Oct 11, 2009 at 5:16 PM, David Golden wrote:
>> On Sun, Oct 11, 2009 at 3:21 AM, Zefram wrote:
17.02) Make the license field an arrayref rather than a scalar.
>>> Could make the field a string expression, with the defined
On Sun, Oct 11, 2009 at 5:16 PM, David Golden wrote:
> On Sun, Oct 11, 2009 at 3:21 AM, Zefram 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 l
David Golden wrote:
> On Sun, Oct 11, 2009 at 3:21 AM, Zefram 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
On Sun, Oct 11, 2009 at 3:09 AM, Ricardo Signes
wrote:
> * Zefram [2009-10-10T19:05:20]
>> 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
On Oct 11, 2009, at 6:16 AM, David Golden wrote:
As I said in the original comments -- I don't think anyone actually
uses the "license" field in META today. Case examples anyone? Can we
adopt a YAGNI principle on license?
I always use `license => 'perl',` in my `Build.PL` files, unless I'm
On Sun, Oct 11, 2009 at 3:21 AM, Zefram 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 w
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 redist
On Oct 10, 2009, at 6:32 PM, David Golden wrote:
17.01) Enumerate a list of license strings explicitly in the spec,
rather than by reference to Module::Build::API. Currently, the list
is:
+1
17.02) Make the license field an arrayref rather than a scalar.
Change the definition to have the fi
On Fri, Oct 9, 2009 at 7: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)
This discussion is going in circles, I think. I'd like to break it
do
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
Ricardo Signes wrote:
> * Zefram [2009-10-10T19:05:20]
>> 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.
>
> Exampl
* Zefram [2009-10-10T19:05:20]
> 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.
Example:
gpl
The distribut
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 Fri, Oct 9, 2009 at 9:03 PM, Jan Dubois wrote:
> I would prefer to specify the "license" field as authoritative
> for CPAN packages; if the maintainer puts in the license type
> "perl" then that should be trusted. If the licensing is more
> complicated, then the maintainer should not set this
On Fri, 09 Oct 2009, David Golden wrote:
> On Fri, Oct 9, 2009 at 7: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)
>
> I would pref
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
On Fri, Oct 9, 2009 at 7: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)
I would prefer to remove the "license" field entirely.
In the "resour
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 namespace
Hello,
On Fri, Oct 9, 2009 at 3:50 PM, 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)
>
> Comments:
[snip]
>
> * When it comes to extensible and un
David Golden wrote:
17. Better formalization of license field
no vote.
Steffen
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
properti
* David Golden [2009-10-09T07:50:07]
> 17. Better formalization of license field
>
> Proposal:
>
> Replace the list of strings for the "license" field with something
> extensible and unambiguous. (RicardoSignes)
All for it, obviously.
> * There won't need to be a list, apart from perhaps 02pac
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.
*
50 matches
Mail list logo
