Public Domain - License Text?
Hi all: I'm working on a module that will be released into the Public Domain. It contains some code that is, itself, in the public domain by another author. There has been a lot of discussion on the implications of Public Domain software in places that do not have the notion of Public Domain, particularly on the Debian list about copyright law in Germany. What I did to get around this is provide a clause in the module like so: # All rights to this package are hereby disclaimed and its contents released # into the public domain by the author. Where this is not possible, you may # use this file under the same terms as Perl itself. So it's released into the public domain, but also the Perl license (Artistic + GPL) to get around this problem. I have chosen thus far to reflect this in the Build.PL as: license = 'unrestricted' (ie, unrestricted distribution). What I am wondering is- is this the most appropriate license clause to use? Should I link to the Perl licensing terms for the META.yml (ie, http://dev.perl.org/licenses/) OR should I keep my current link of a paper studying public domain software (http://edwardsamuels.com/copyright/beyond/articles/public.html) Thanks in advance for your guidance :-) Cheers, Jonathan Yu (PAUSE: FREQUENCY)
Re: Public Domain - License Text?
Scott: Posting this back to the list. Hope you don't mind; I think the others on this list could benefit from your reply. On Thu, Mar 19, 2009 at 12:01 PM, Scott Elcomb pse...@gmail.com wrote: On Thu, Mar 19, 2009 at 11:46 AM, Jonathan Yu jonathan.i...@gmail.com wrote: Hi all: I'm working on a module that will be released into the Public Domain. It contains some code that is, itself, in the public domain by another author. There has been a lot of discussion on the implications of Public Domain software in places that do not have the notion of Public Domain, particularly on the Debian list about copyright law in Germany. What I did to get around this is provide a clause in the module like so: # All rights to this package are hereby disclaimed and its contents released # into the public domain by the author. Where this is not possible, you may # use this file under the same terms as Perl itself. So it's released into the public domain, but also the Perl license (Artistic + GPL) to get around this problem. I have chosen thus far to reflect this in the Build.PL as: license = 'unrestricted' (ie, unrestricted distribution). Hi Jonathan, I can't provide any suggestions to this, but it seems (to me anyway) that releasing under the Public Domain would automatically preclude any other licensing terms. Is that not the heart (if not point) of Public Domain? The idea is that the module is public domain (do whatever you want with it, no terms, no copyright), however, in certain jurisdictions that don't allow public domain, or where an author chooses to do so, the module may be used under the terms of Artistic/GPL. Basically this is no different from *just* public domain in countries that support the idea of it, since, if something is public domain, you can do whatever you want with it, including putting it under a different license. That's my understanding of public domain, anyway, but I'm not a lawyer. Anyway, I'm not sure if it's of any value to you however the folks behind the Creative Commons licenses recently released a new Public Domain Certification called CC0 (CC-Zero). You can find more information here: http://creativecommons.org/about/cc0 I will look into this, but the problem with CC licenses is that they are not Perl-approved - that is, they do not have fields in Module::Build's license field, though public domain isn't really a license, it's an explicit statement that there need be no licensing because there is no ownership of copyright. The implications of this are particularly important for Debian packaging. By saying that the code is licensed under (one of) Public Domain (no license), Perl Artistic or GNU GPL, it gets around the restrictions of jurisdictions that do not allow authors to place their work into the public domain. The Perl license itself is either Perl Artistic or GNU GPL. The GPL is incompatible with the Perl Artistic license, but nonetheless, because of the or clause, Perl's licensing is not contradictory. You can pick one or the other. If someone decides to fork the Perl code into something else, they can license it as EITHER Perl Artistic OR GPL, or continue to license it as both. I look forward to reading the paper you linked-to in your original post. Take care and thanks for the though provoking question! - Scott. -- Scott Elcomb http://www.psema4.com/
Re: Public Domain - License Text?
Hi Jonathan! On Thursday 19 March 2009 17:46:39 Jonathan Yu wrote: Hi all: I'm working on a module that will be released into the Public Domain. It contains some code that is, itself, in the public domain by another author. There has been a lot of discussion on the implications of Public Domain software in places that do not have the notion of Public Domain, particularly on the Debian list about copyright law in Germany. What I did to get around this is provide a clause in the module like so: # All rights to this package are hereby disclaimed and its contents released # into the public domain by the author. Where this is not possible, you may # use this file under the same terms as Perl itself. Well, if you're keen on being faithful to the public-domain nature of the code, you may wish to instead say Where this is not possible, you may use this file under the terms of the MIT X11 Licence ( http://www.opensource.org/licenses/mit-license.php ), which is the closes licence you can get to PD. (Except for the http://en.wikipedia.org/wiki/WTFPL , but it's kinda a joke). I had written about why saying This program can be used under the same terms as Perl itself is problematic here: http://use.perl.org/~Shlomi+Fish/journal/36050 (also read the comments). If you still want to licence it under the same terms as Perl, make sure you also include the 2.0 version (and later - very important) of the Artistic Licence, which is all of GPL-compatible, allows use by proprietary software, and phrased much more sanely and less ambiguously than the original Artistic licence. The default Same terms as Perl includes only the GPLv2 and above and only the original Artistic Licence - neither of which are very useful. Regards, Shlomi Fish So it's released into the public domain, but also the Perl license (Artistic + GPL) to get around this problem. I have chosen thus far to reflect this in the Build.PL as: license = 'unrestricted' (ie, unrestricted distribution). What I am wondering is- is this the most appropriate license clause to use? Should I link to the Perl licensing terms for the META.yml (ie, http://dev.perl.org/licenses/) OR should I keep my current link of a paper studying public domain software (http://edwardsamuels.com/copyright/beyond/articles/public.html) Thanks in advance for your guidance :-) Cheers, Jonathan Yu (PAUSE: FREQUENCY) -- - Shlomi Fish http://www.shlomifish.org/ Understand what Open Source is - http://xrl.us/bjn82 God gave us two eyes and ten fingers so we will type five times as much as we read.
Re: Public Domain - License Text?
On Thu, Mar 19, 2009 at 4:46 PM, Jonathan Yu jonathan.i...@gmail.com wrote: # All rights to this package are hereby disclaimed and its contents released # into the public domain by the author. Where this is not possible, you may # use this file under the same terms as Perl itself. You could draw inspiration from this: http://en.wikipedia.org/wiki/Template:PD-self -- Dominique Quatravaux +41 79 609 40 72
Re: Perl Critic and (honest) hash references
On Mon, Mar 02, 2009 at 11:15:53PM -0800, Joshua ben Jore wrote:
On Mon, Mar 2, 2009 at 12:22 PM, Nicholas Clark n...@ccl4.org wrote:
On Mon, Mar 02, 2009 at 10:23:38AM -0800, Bill Ward wrote:
Personally I always use hashes for objects. Hashes are pretty fast in
Perl,
especially when there aren't many keys, so I don't think the benefits of
using arrays are worth it. The risk of typos is pretty small, and the
Hash lookup should be O(1), independent of number of keys. Of course, a hash
with more keys uses more memory, but so does an array with more elements.
I once found some very fast code varying in something I'm guessing was
O(n) on the length of the keys. I've occasionally wished I could get
static lookups to compile with the hashed I32 already stashed.
There is code to do this in the peephole optimiser. For those who don't know,
shared hash key scalars store the precomputed U32 hash value. For
illustration, I'm going to use pre 5.10, as 5.8.x and earlier store them in
PVIVs, which makes them visibly distinct from regular PVs in dump output.
The code (in blead) to convert constant method names to shared hash keys is
in Perl_ck_method: http://perl5.git.perl.org/perl.git/blob/HEAD:/op.c#l7455
The code to convert hash lookups (or at least some of them) is
in Perl_peep: http://perl5.git.perl.org/perl.git/blob/HEAD:/op.c#l8568
However, something in ithreads, I know not what, undoes this one. So, for
an unthreaded 5.8.8, notice that rules is a PVIV, so shared:
$ ./perl -Ilib -MO=Concise -e '$perl-{rules}'
8 @ leave[1 ref] vKP/REFC -(end)
1 0 enter -2
2 ; nextstate(main 1 -e:1) v -3
7 2 helem vK/2 -8
51 rv2hv[t1] sKR/1 -6
4 1 rv2sv sKM/DREFHV,1 -5
3 $ gv(*perl) s -4
6$ const(PVIV rules) s/BARE -7
-e syntax OK
Whereas the threaded 5.8.8 loses this optimisation at some point later:
$ perl -MO=Concise -e '$perl-{rules}'
8 @ leave[1 ref] vKP/REFC -(end)
1 0 enter -2
2 ; nextstate(main 1 -e:1) v -3
7 2 helem vK/2 -8
51 rv2hv[t2] sKR/1 -6
4 1 rv2sv sKM/DREFHV,1 -5
3 # gv[*perl] s -4
6$ const[PV rules] s/BARE -7
-e syntax OK
If you have time to identify and fix that, that would be great. Method names
don't seem to suffer from this:
$ ./perl -Ilib -MO=Concise -e '$perl-rules()'
7 @ leave[1 ref] vKP/REFC -(end)
1 0 enter -2
2 ; nextstate(main 1 -e:1) v -3
6 1 entersub[t1] vKS/TARG -7
30 pushmark s -4
-1 ex-rv2sv sKM/1 -5
4 $ gvsv(*perl) s -5
5$ method_named(PVIV rules) -6
-e syntax OK
$ perl -MO=Concise -e '$perl-rules()'
7 @ leave[1 ref] vKP/REFC -(end)
1 0 enter -2
2 ; nextstate(main 1 -e:1) v -3
6 1 entersub[t2] vKS/TARG -7
30 pushmark s -4
-1 ex-rv2sv sKM/1 -5
4 # gvsv[*perl] s -5
5$ method_named[PVIV rules] -6
-e syntax OK
However, longer term, I'm wondering why we even do this in the peephole
optimiser, given that, worst case, we could allocate *all* bare words are
shared, straight out. (And possibly even allocate all strings from the
tokeniser as shared, given that they can now be copied as COW, and my hunch
is that strings in the tokeniser more likely than not occur more than once).
Nicholas Clark
Re: Public Domain - License Text?
Hi Shlomi, I've looked into the CC0 license that Scott mentioned, and it looks promising. I wonder if it is legally permissible to provide use of the code under several licenses, ie: 1. GPL (should it be GPL 2+ only?) 2. Artistic 2.0+ 3. Public Domain 4. CC0 5. MIT 6. BSD Basically I want this code to be as free as possible, and I don't much care what people do with it. Dominique's reference to Wikipedia's Public Domain text might be useful, too. Is it easier to do that? And this all still leaves the question, what do I do for META.yml's license field, and Build.PL's license part? Jonathan On Thu, Mar 19, 2009 at 12:13 PM, Shlomi Fish shlo...@iglu.org.il wrote: Hi Jonathan! On Thursday 19 March 2009 17:46:39 Jonathan Yu wrote: Hi all: I'm working on a module that will be released into the Public Domain. It contains some code that is, itself, in the public domain by another author. There has been a lot of discussion on the implications of Public Domain software in places that do not have the notion of Public Domain, particularly on the Debian list about copyright law in Germany. What I did to get around this is provide a clause in the module like so: # All rights to this package are hereby disclaimed and its contents released # into the public domain by the author. Where this is not possible, you may # use this file under the same terms as Perl itself. Well, if you're keen on being faithful to the public-domain nature of the code, you may wish to instead say Where this is not possible, you may use this file under the terms of the MIT X11 Licence ( http://www.opensource.org/licenses/mit-license.php ), which is the closes licence you can get to PD. (Except for the http://en.wikipedia.org/wiki/WTFPL , but it's kinda a joke). I had written about why saying This program can be used under the same terms as Perl itself is problematic here: http://use.perl.org/~Shlomi+Fish/journal/36050 (also read the comments). If you still want to licence it under the same terms as Perl, make sure you also include the 2.0 version (and later - very important) of the Artistic Licence, which is all of GPL-compatible, allows use by proprietary software, and phrased much more sanely and less ambiguously than the original Artistic licence. The default Same terms as Perl includes only the GPLv2 and above and only the original Artistic Licence - neither of which are very useful. Regards, Shlomi Fish So it's released into the public domain, but also the Perl license (Artistic + GPL) to get around this problem. I have chosen thus far to reflect this in the Build.PL as: license = 'unrestricted' (ie, unrestricted distribution). What I am wondering is- is this the most appropriate license clause to use? Should I link to the Perl licensing terms for the META.yml (ie, http://dev.perl.org/licenses/) OR should I keep my current link of a paper studying public domain software (http://edwardsamuels.com/copyright/beyond/articles/public.html) Thanks in advance for your guidance :-) Cheers, Jonathan Yu (PAUSE: FREQUENCY) -- - Shlomi Fish http://www.shlomifish.org/ Understand what Open Source is - http://xrl.us/bjn82 God gave us two eyes and ten fingers so we will type five times as much as we read.
Re: Public Domain - License Text?
On Thu, Mar 19, 2009 at 12:09:50PM -0400, Jonathan Yu wrote: On Thu, Mar 19, 2009 at 12:01 PM, Scott Elcomb pse...@gmail.com wrote: Anyway, I'm not sure if it's of any value to you however the folks behind the Creative Commons licenses recently released a new Public Domain Certification called CC0 (CC-Zero). You can find more information here: http://creativecommons.org/about/cc0 I will look into this, but the problem with CC licenses is that they are not Perl-approved - that is, they do not have fields in Module::Build's license field You mean not Module::Build-approved. Module::Build is obviously buggy in this area. -- David Cantrell | Minister for Arbitrary Justice Cynical is a word used by the naive to describe the experienced. George Hills, in uknot
Re: Public Domain - License Text?
Good point David. Anyway, for the rest of the list, I've come up with the following text; hopefully it is legally possible: Copyleft (C) 2009 by Jonathan Yu freque...@cpan.org. All rights reversed. ABSTRACT I, the copyright holder of this package, hereby release the entire contents therein into the public domain. This applies worldwide, to the extent that it is permissible by law. In case this is not legally possible, I grant any entity the right to use this work for any purpose, without any conditions, unless such conditions are required by law. RATIONALE As the author / copyright holder / intellectual property owner, I want this codebase to be as free (both as in freedom and free beer) as possible in your legal jurisdiction. This software and the code contained herein is (to the best of my knowledge) completely unencumbered by patents, copyright, licensing restrictions, etc. Some legal departments of commercial entities may be uncomfortable with the using software without first obtaining a license from the author directly. If this is the case, then I encourage a representative of your legal department to contact me directly to discuss a token fee being paid in exchange for a license to unrestricted use of the code. DISCLAIMER OF WARRANTIES The software is provided AS IS, without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose and noninfringement. In no event shall the authors or copyright holders be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or the use or other dealings in the software. LICENSING If you are legally required to do so, then you may use this file under, at your option: 1. The MIT/X11 License; or, 2. The BSD License; or, 3. The Perl Artistic License, version 2.0 or later; or, 4. The GNU General Public License, version 2.0 or later; or, 5. The Creative Commons CC0 (CC-Zero) License, version 1.0 or later Note that points (3) and (4) roughly coincide with the distribution terms of Perl itself; so if you have considered and accepted the licensing restrictions posed by Perl 5.10, you have accepted suitable terms to use this software. The full texts of all these licenses follow. -- I'm not sure how well this would actually hold up in court, because I don't think many distributions are multi-licensed to this extent :-) I just want to make sure anyone that wants to, can use my software if they so choose, totally unencumbered by legal restrictions. On Thu, Mar 19, 2009 at 1:31 PM, David Cantrell da...@cantrell.org.uk wrote: On Thu, Mar 19, 2009 at 12:09:50PM -0400, Jonathan Yu wrote: On Thu, Mar 19, 2009 at 12:01 PM, Scott Elcomb pse...@gmail.com wrote: Anyway, I'm not sure if it's of any value to you however the folks behind the Creative Commons licenses recently released a new Public Domain Certification called CC0 (CC-Zero). You can find more information here: http://creativecommons.org/about/cc0 I will look into this, but the problem with CC licenses is that they are not Perl-approved - that is, they do not have fields in Module::Build's license field You mean not Module::Build-approved. Module::Build is obviously buggy in this area. -- David Cantrell | Minister for Arbitrary Justice Cynical is a word used by the naive to describe the experienced. George Hills, in uknot
Re: Public Domain - License Text?
On Thu, Mar 19, 2009 at 2:03 PM, Jonathan Yu jonathan.i...@gmail.com wrote: If you are legally required to do so, then you may use this file under, at your option: 1. The MIT/X11 License; or, 2. The BSD License; or, 3. The Perl Artistic License, version 2.0 or later; or, 4. The GNU General Public License, version 2.0 or later; or, 5. The Creative Commons CC0 (CC-Zero) License, version 1.0 or later If you're going this way, you could even go so far as to say any OSI approved license or the CC0 is allowed. And reference this URL: http://www.opensource.org/licenses/category -- David
Re: Public Domain - License Text?
On Thu, Mar 19, 2009 at 1:31 PM, David Cantrell da...@cantrell.org.uk wrote: On Thu, Mar 19, 2009 at 12:09:50PM -0400, Jonathan Yu wrote: On Thu, Mar 19, 2009 at 12:01 PM, Scott Elcomb pse...@gmail.com wrote: Anyway, I'm not sure if it's of any value to you however the folks behind the Creative Commons licenses recently released a new Public Domain Certification called CC0 (CC-Zero). You can find more information here: http://creativecommons.org/about/cc0 I will look into this, but the problem with CC licenses is that they are not Perl-approved - that is, they do not have fields in Module::Build's license field You mean not Module::Build-approved. Module::Build is obviously buggy in this area. The Module::Build::API doc suggests that unrestricted is a valid license type. I would just use that if you really need to put something. Though I think that the latest Module::Build relies upon Software::License, so someone could probably send some CC licenses to RJBS and lobby him to include them. Then they would be Perl-approved -- at least to the extent they are encoded into the toolchain. -- David
Re: Public Domain - License Text?
Shlomi: My reasoning for including all the other ones is that companies' legal teams may have decided that they can use GPL-licensed code, but have not investigated the other licenses. This way, they'd be able to say that the original copyright holder provided a provision licensing the code under the GPL, so they're already covered by their prior research. What are your thoughts there? I thought publishing with license = 'unrestricted' would be most appropriate, since I don't want people to think that they are bound by the restrictions of the MIT License, when in reality, they are not. They can do whatever they want with it, it's public domain :-) I briefly skimmed over your article on the Perl Monks site (I think?) and it was my understanding that Artistic 2.0+ is the preferred license, which is considered compatible with GPL? Your idea is probably safer, though. Jonathan On Thu, Mar 19, 2009 at 2:30 PM, Shlomi Fish shlo...@iglu.org.il wrote: On Thursday 19 March 2009 18:23:23 Jonathan Yu wrote: Hi Shlomi, I've looked into the CC0 license that Scott mentioned, and it looks promising. I wonder if it is legally permissible to provide use of the code under several licenses, ie: 1. GPL (should it be GPL 2+ only?) 2. Artistic 2.0+ That should probably be Artistic 1.0 and then Artistic 2.0+. But see below. 3. Public Domain 4. CC0 5. MIT 6. BSD Basically I want this code to be as free as possible, and I don't much care what people do with it. You can license your code under as many licenses as you please. For example, jQuery ( http://jquery.com/ ) is dually licensed MITL and GPL, and cURL ( http://en.wikipedia.org/wiki/CURL ) used to be dually licensed MITL and MPL (= Mozilla Public Licence). However, if you already decided to license under the MIT/X11 Licence it is completely unnecessary to license it under any other licence (except perhaps the Public Domain) because the MITL specifically allows sub-licensing. Sub-licensing allows anyone to take your MITL work and convert their copy into code of a different licence, free or non-free. So my suggestion is to licence your code under Public Domain, CC0 and MIT, and avoid the rest of the options, which will only be confusing. Dominique's reference to Wikipedia's Public Domain text might be useful, too. Is it easier to do that? And this all still leaves the question, what do I do for META.yml's license field, and Build.PL's license part? Just say 'mit'. It's supported by later M::B's. Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ My Aphorisms - http://www.shlomifish.org/humour.html God gave us two eyes and ten fingers so we will type five times as much as we read.
Re: Public Domain - License Text?
On Thu, Mar 19, 2009 at 2:29 PM, Jonathan Yu jonathan.i...@gmail.com wrote: David: Interesting idea. I'll add that in as option 6. I don't want to replace the others though in case the web site disappears at some point in the future, making the license pretty ambiguous. More formally, you could say any Open Source Initiative approved license and just link to the main page: http://www.opensource.org/ I suspect that's not going away anytime soon. I just wonder if a package can really be licensed under 5-6 different licenses... To be clear -- you are *offering* a choice of licenses to end-users. They (implicitly or otherwise) choose one of those licenses to govern their use of your code. -- David
Re: Public Domain - License Text?
David: Interesting idea. I'll add that in as option 6. I don't want to replace the others though in case the web site disappears at some point in the future, making the license pretty ambiguous. I just wonder if a package can really be licensed under 5-6 different licenses... Cheers, Jonathan On Thu, Mar 19, 2009 at 2:27 PM, David Golden da...@hyperbolic.net wrote: On Thu, Mar 19, 2009 at 2:03 PM, Jonathan Yu jonathan.i...@gmail.com wrote: If you are legally required to do so, then you may use this file under, at your option: 1. The MIT/X11 License; or, 2. The BSD License; or, 3. The Perl Artistic License, version 2.0 or later; or, 4. The GNU General Public License, version 2.0 or later; or, 5. The Creative Commons CC0 (CC-Zero) License, version 1.0 or later If you're going this way, you could even go so far as to say any OSI approved license or the CC0 is allowed. And reference this URL: http://www.opensource.org/licenses/category -- David
Re: Public Domain - License Text?
# from David Golden # on Thursday 19 March 2009 11:32: I will look into this, but the problem with CC licenses is that they are not Perl-approved - that is, they do not have fields in Module::Build's license field You mean not Module::Build-approved. Module::Build is obviously buggy in this area. ... I think that the latest Module::Build relies upon Software::License Indeed, it does. , so someone could probably send some CC licenses to RJBS and lobby him to include them. Then they would be Perl-approved -- at least to the extent they are encoded into the toolchain. As far as rjbs and I know, Module::Build is the only build tool using Software::License. Module::Install seems to have its own shortlist, and ExtUtils::MakeMaker says you should see Module::Build::API ;-) (I guess that would mean it copied and pasted a list from there at one point -- but I'll let someone else look for an answer there.) Note though that you don't really need toolchain support for the license -- just support in your authoring tool (because this is all static data by the time it gets to the target machine.) --Eric -- Don't worry about what anybody else is going to do. The best way to predict the future is to invent it. --Alan Kay --- http://scratchcomputing.com ---
Re: Public Domain - License Text?
Eric- On Thu, Mar 19, 2009 at 2:48 PM, Eric Wilhelm enoba...@gmail.com wrote: # from David Golden # on Thursday 19 March 2009 11:32: I will look into this, but the problem with CC licenses is that they are not Perl-approved - that is, they do not have fields in Module::Build's license field You mean not Module::Build-approved. Module::Build is obviously buggy in this area. ... I think that the latest Module::Build relies upon Software::License Indeed, it does. , so someone could probably send some CC licenses to RJBS and lobby him to include them. Then they would be Perl-approved -- at least to the extent they are encoded into the toolchain. As far as rjbs and I know, Module::Build is the only build tool using Software::License. Module::Install seems to have its own shortlist, and ExtUtils::MakeMaker says you should see Module::Build::API ;-) (I guess that would mean it copied and pasted a list from there at one point -- but I'll let someone else look for an answer there.) Note though that you don't really need toolchain support for the license -- just support in your authoring tool (because this is all static data by the time it gets to the target machine.) The problem is that the META-spec is based on the licenses in Module::Build - so you can't just put anything you want in META.yml, or your META file will no longer match the specification. --Eric -- Don't worry about what anybody else is going to do. The best way to predict the future is to invent it. --Alan Kay --- http://scratchcomputing.com ---
