Re: CMSP 17. Better formalization of license field
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, 2009 at 02:12:00PM -0500, Jarkko Hietaniemi wrote: On Tue, Nov 3, 2009 at 12:41 PM, David Cantrell da...@cantrell.org.uk 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 core of the problem is this: public domain is a legal term that only is defined within the U.S. (and I admit, other Anglo-Saxon law, like UK and Australia, etc.). Say, a German author saying This is public domain is making no sense. I know for a fact that in Finnish law an author cannot give away his rights, and the same applies in other European countries. Even more importantly, it doesn't work the way most people think. It doesn't e.g. relieve the author of warranties or damage claims. It's much better to choose a minimal license that disclaims warranties, such as the MIT one. But that doesn't relieve the author of damage claims either, no matter what the licence says. At least not in all jurisdictions. So on the basis that public domain can't be used because it is invalid in Germany, MIT can't be used because it is not entirely valid in the UK. Likewise the GPL and the Artistic licence. -- David Cantrell | Reality Engineer, Ministry of Information Your call is important to me. To see if it's important to you I'm going to make you wait on hold for five minutes. All calls are recorded for blackmail and amusement purposes. -- There is this special biologist word we use for 'stable'. It is 'dead'. -- Jack Cohen
Re: CMSP 17. Better formalization of license field
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, licenses attached. It is in the public domain. Null licensing is not the same as not saying anything about licensing. I know for a fact that in Finnish law an author cannot give away his rights, and the same applies in other European countries. So public domain isn't necessarily even a null license. -zefram -- There is this special biologist word we use for 'stable'. It is 'dead'. -- Jack Cohen
Re: CMSP 17. Better formalization of license field
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. I know for a fact that in Finnish law an author cannot give away his rights, and the same applies in other European countries. So public domain isn't necessarily even a null license. -zefram
Re: CMSP 17. Better formalization of license field
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 redistribute under any of the licenses; (b) different parts of the distro are under different licenses, so you can only redistribute if you obey all the licenses at once. More complex license combinations can occur by mixing these two. The nature of the license combinations should be made explicit. 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. -zefram
Re: CMSP 17. Better formalization of license field
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. 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? -- David
Re: CMSP 17. Better formalization of license field
* 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 keep using the unsatisfactory list from the current spec.
I didn't realize they were ambiguous. What I really would prefer is
to go the other way.
my $obj = Software::License-new('artistic_2');
my $obj = Software::License-new(''bsd');
I'm happy to have a list of simple names that map to unambiguous licenses, and
I'll make sure Software::License plays nice.
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.
--
rjbs
Re: CMSP 17. Better formalization of license field
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 to specify the terms there software is under. THEY WRITE IT IN THE SOURCE FILES! Well, yes, but that's not exactly optimal. The same argument could be made that authors have a clear, easy, unambiguous way of specifying their software's dependencies: in the source! And that's not exactly optimal, either, so it gets (re)stated in Makefile.PL/Build.PL/etc and then regurgitated out into META.yml for tool usage. Right now, we're in a situation where even if an author wanted to more precisely state what the licensing scheme is, the current spec doesn't support it. I'd say that's the problem... Expanding to a set of licenses, with a larger base of tags (as others have suggested) would go a long way to addressing this. 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 metadata gives me a good view of the legal/policy requirements. So I end up being one of the two people that worry about it alot :) -Chris -- Chris Weyl Ex astris, scientia
Re: CMSP 17. Better formalization of license field
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 licensing metadata gives me a good view of the legal/policy requirements. So I end up being one of the two people that worry about it alot :) I understand. I think my proposal will achieve what you're looking for. Most things will have a single license key (set manually or via auto-detection by M::I or M::B). That will give you the information you need. Only things with multiple licenses listed will need a human to read and interpret the specifics. Trying to build a general purpose license math mini-language is more than I think we need or should attempt. That's all. -- David
Re: CMSP 17. Better formalization of license field
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 those cases that are adequately described by a widely-used license. In the unusual cases where no defined keyword suffices, machine readability (beyond recognising that this is the case) is a lot less important. -zefram
Re: CMSP 17. Better formalization of license field
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 isn't unambiguous enough for the truly/duly paranoid. They want to know what brand of morning cereal Larry was eating when he wrote a particular Perl. license: Lucky Charms David
Re: CMSP 17. Better formalization of license field
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 break it
down to a number of specific sub-proposals and get people's reactions
to them individually. These sub-proposals are not all mutually
exclusive, so if you want to react to them as clusters, that's fine,
too.
17.01) Enumerate a list of license strings explicitly in the spec,
rather than by reference to Module::Build::API. Currently, the list
is:
perl
apache
artistic
artistic_2
lgpl
lgpl2
lgpl3
bsd
gpl
gpl2
gpl3
mit
mozilla
open_source
unrestricted
restrictive
unknown
Additional strings (e.g. 'mixed' or additional licenses) could be
added if deemed necessary.
17.02) Make the license field an arrayref rather than a scalar.
Change the definition to have the field be a list of all license which
might apply to the distribution, either as alternatives or for
different subcomponents.
17.03) Make the license field optional (defaulting to 'unknown')
17.04) Instead of license being a list of valid strings, define it as
a Software::License subclass name (which implies an API standad that
can be used to get information about the license like display name and
URL)
17.05) Make the $meta-{resources}-{license} field an optional
hashref with name/URL pairs for providing short names and URLs for use
by indexers. (These might get populated by Software::License, of
course.) N.B. This option is probably redundant if 17.02 and 17.04
are adopted.
-- David
Re: CMSP 17. Better formalization of license field
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 properties 1) a name 2) a URL. perhaps for a list of specified names the URL could be omitted but I do not think we should restrict what should be in the license field * When it comes to extensible and unambiguous identifiers, all roads eventually lead to URLs... (AdamKennedy); yes * 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]] +1 * 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]] maybe some way of indicating that the distribution is of mixed licenses and then listing all the licenses it is a mixture of. Graham.
Re: CMSP 17. Better formalization of license field
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 namespaced and indexed; if it can't be found, treat as Other rjbs 15:21, 28 August 2009 (BST) [snip] URL reference to a site is not that good as you can not be sure that in long term that URL describes license you want. I'm not talking about special cpan:// URLs, but about regular http://... Real life example is GPL. http://www.gnu.org/licenses/gpl.html is the only way to reference the current GPL license at this moment, but when GPL4 come out that page will be describing GPL4 and you would be able to find GPL3 on http://www.gnu.org/licenses/old-licenses/old-licenses.html#GPL. I'm pretty sure in this as it happened once with GPL2. So you can not describe GPL3 only with an URL to GNU's site. Well for sites like search.cpan.org having a link is very useful. We can only encourage people to use links to pages they know will not change. for a lot of the common licenses we can have a list of standard identifiers which will have links to http://www.opensource.org/licenses Graham.
Re: CMSP 17. Better formalization of license field
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 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 artistic/gpl) Licensing is not something that is so simple that it can expressed with confidence in a single field for an entire distribution. By listing it in resources instead, we make it easy for search.cpan.org to provide useful information but ultimately, knowing the exact license details will require people to read the source, not the META file. -- David
Re: CMSP 17. Better formalization of license field
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 artistic/gpl) +1 David
