Re: Integrating license related things of CPAN
* On Thu, Oct 23 2008, Bill Ward wrote: Perhaps when you upload to PAUSE without a license in META.yml it could actually replace the META.yml with one that has a license, based in input from an HTML form? Would that be too weird? I think it's technically feasible. So if the user doesn't provide information, PAUSE should just make it up? That doesn't sound very valuable. Now someone reading the license field will have to wonder whether they are looking at the real license or just the license that was randomly selected by PAUSE. This negates the entire usefulness of the field. Also, altering the contents of a distribution will break the signature generated by Module::Signature. Some other thoughts... is the license specified in the META.yml legally binding in any way? If not, anyone using the module will have to look at the rest of the distribution to determine its license, again negating the usefulness of this field. Then again, I, as the author, don't really know what license my distributions are distributed under. I could pick one, but can I really be sure that it applies? If I use Term::ReadLine and it picks the Term::ReadLine::Gnu, is my module GPL now? I don't know and I don't care. Does anyone else? Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: Integrating license related things of CPAN
On Sat, Oct 25, 2008 at 11:08 PM, Jonathan Rockway [EMAIL PROTECTED] wrote: * On Thu, Oct 23 2008, Bill Ward wrote: Perhaps when you upload to PAUSE without a license in META.yml it could actually replace the META.yml with one that has a license, based in input from an HTML form? Would that be too weird? I think it's technically feasible. So if the user doesn't provide information, PAUSE should just make it up? That doesn't sound very valuable. Now someone reading the license field will have to wonder whether they are looking at the real license or just the license that was randomly selected by PAUSE. This negates the entire usefulness of the field. Of course not, don't be absurd. But when the user is uploading the module, the PAUSE web interface could prompt them to select the license. Also, altering the contents of a distribution will break the signature generated by Module::Signature. That's a good point though. Some other thoughts... is the license specified in the META.yml legally binding in any way? If not, anyone using the module will have to look at the rest of the distribution to determine its license, again negating the usefulness of this field. Another good point. One could put GPL in the META.yml but have a LICENSE section in the POD that says same terms as Perl itself -- which one wins? Then again, I, as the author, don't really know what license my distributions are distributed under. I could pick one, but can I really be sure that it applies? If I use Term::ReadLine and it picks the Term::ReadLine::Gnu, is my module GPL now? I don't know and I don't care. Does anyone else? Some people care a lot; to others it doesn't matter so long as it's available. There are some major differences between the licenses, mainly around what can be done with derivative works, but that's a lot less likely to be an issue with a Perl module.
Re: Integrating license related things of CPAN
On Sun, Oct 26, 2008 at 8:38 AM, Bill Ward [EMAIL PROTECTED] wrote: On Sat, Oct 25, 2008 at 11:08 PM, Jonathan Rockway [EMAIL PROTECTED] wrote: Some other thoughts... is the license specified in the META.yml legally binding in any way? If not, anyone using the module will have to look at the rest of the distribution to determine its license, again negating the usefulness of this field. Another good point. One could put GPL in the META.yml but have a LICENSE section in the POD that says same terms as Perl itself -- which one wins? Once we have a clear definition of what should be the text in the POD section CPANTS will check if the licenses are the same. Actually I am sure we'll be able to upload a stand alone module that will check it and I think if you use Dist::Zilla you won't have to care as it will insert the right thing everywhere base on the license keyword you give it. Then again, I, as the author, don't really know what license my distributions are distributed under. I could pick one, but can I really be sure that it applies? If I use Term::ReadLine and it picks the Term::ReadLine::Gnu, is my module GPL now? I don't know and I don't care. Does anyone else? Some people care a lot; to others it doesn't matter so long as it's available. There are some major differences between the licenses, mainly around what can be done with derivative works, but that's a lot less likely to be an issue with a Perl module. I know, at some of my clients the license issue is critical. Some of the downstream distributors (Debian, Fedora ) are also very picky about the licensing terms. They might be extreme but I prefer these over the other extreme that says: oh its free software, we can do whatever want with it and then go on and redistribute a GPL software in their proprietary application. So I'd rather make it easy to check the license. Gabor Szabo http://szabgab.com/blog.html
Re: Integrating license related things of CPAN
* Jonathan Rockway [EMAIL PROTECTED] [2008-10-26 07:10]: I don't know and I don't care. Does anyone else? I do, because it matters. I would love to be able not to care, much as I would love to be able not to care about politics, or about money, because I find all of these topics utterly boring and insubstantial in their essence. But I can only ignore them at my (variously terrible) peril, and so for better of for worse, I know and care. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Integrating license related things of CPAN
Gabor Szabo schreef:
I am trying to push forward simplifying and clarifying the
licensing issues on CPAN.
It would be nice to have a license pragma.
use license Perl;
use license AL/GPL;
use license qw{
Artistic_2 (and_up)
GPL_3 (and_up)
};
We already have
http://search.cpan.org/search?query=Software%3A%3ALicensemode=module
--
Affijn, Ruud
Gewoon is een tijger.
Re: Integrating license related things of CPAN
* Dr.Ruud [EMAIL PROTECTED] [2008-10-26T06:28:44] Gabor Szabo schreef: I am trying to push forward simplifying and clarifying the licensing issues on CPAN. It would be nice to have a license pragma. use license Perl; What would this do? -- rjbs
Re: Integrating license related things of CPAN
# from Ricardo SIGNES # on Sunday 26 October 2008: It would be nice to have a license pragma. use license Perl; What would this do? Skip calls to any code which didn't conform to that license ;-) --Eric -- Moving pianos is dangerous. Moving pianos are dangerous. Buffalo buffalo buffalo buffalo buffalo buffalo buffalo. --- http://scratchcomputing.com ---
Re: Integrating license related things of CPAN
Eric Wilhelm wrote: # from Ricardo SIGNES # on Sunday 26 October 2008: It would be nice to have a license pragma. use license Perl; What would this do? Skip calls to any code which didn't conform to that license ;-) Oh good. Nothing that could possibly go wrong then. -john
Re: Integrating license related things of CPAN
Ricardo SIGNES schreef: Dr.Ruud: Gabor Szabo: I am trying to push forward simplifying and clarifying the licensing issues on CPAN. It would be nice to have a license pragma. use license Perl; What would this do? That's up to the creator of the license pragma, but it would most probably be defined as standing for: This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. See http://www.perl.com/perl/misc/Artistic.html;. -- Affijn, Ruud Gewoon is een tijger.
Re: Integrating license related things of CPAN
In article [EMAIL PROTECTED], Bill Ward [EMAIL PROTECTED] wrote: Of course not, don't be absurd. But when the user is uploading the module, the PAUSE web interface could prompt them to select the license. That fails for a couple of reasons: 1. PAUSE is not the arbiter of licences and doesn't handle license managment. 2. Not everyone uses the web interface.
Re: Integrating license related things of CPAN
In article [EMAIL PROTECTED], Jonathan Rockway [EMAIL PROTECTED] wrote: Then again, I, as the author, don't really know what license my distributions are distributed under. I don't know and I don't care. Does anyone else? I care only to the extent that a user needs something in particular so they can use my code. Almost all of my stuff in Artistic License, but I inherited a couple of GPL packages. Those are the headaches because I have to deal with other people's religion and the constraints that puts on users. I should modify my Distribution::Cooker templates to put license information in every file though.
Re: Integrating license related things of CPAN
* Dr.Ruud [EMAIL PROTECTED] [2008-10-26T14:39:23] That's up to the creator of the license pragma, but it would most probably be defined as standing for: This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. See http://www.perl.com/perl/misc/Artistic.html;. It just seems less than useful to require the loading of more code at execution time to stand in for a comment. Further, given that various packagers (Debian, etc) really really would like to see an explicit copyright in each file, it actually seems counterproductive, since authors may think that adding a 'use license' statement is sufficient. -- rjbs
Re: Integrating license related things of CPAN
On Sun, Oct 26, 2008 at 1:38 AM, Bill Ward [EMAIL PROTECTED] wrote: Another good point. One could put GPL in the META.yml but have a LICENSE section in the POD that says same terms as Perl itself -- which one wins? That's the very reason I want to get the license text out of the POD and into an auto-written LICENSE file. Right now it's all well and good to compile statistics about license declarations in META.yml files, but if there are separate LICENSE sections in the POD then people ( robots) have to look at that manually and we've really gained very little. -Ken
Re: Integrating license related things of CPAN
On Sun, Oct 26, 2008 at 7:00 PM, Ken Williams [EMAIL PROTECTED] wrote: On Sun, Oct 26, 2008 at 1:38 AM, Bill Ward [EMAIL PROTECTED] wrote: Another good point. One could put GPL in the META.yml but have a LICENSE section in the POD that says same terms as Perl itself -- which one wins? That's the very reason I want to get the license text out of the POD and into an auto-written LICENSE file. Right now it's all well and good to compile statistics about license declarations in META.yml files, but if there are separate LICENSE sections in the POD then people ( robots) have to look at that manually and we've really gained very little. The problem is people may add it to META.yml but not remove it from the POD. For one thing, it would be nice to be able to see what the license is when viewing the POD. Once the module is installed META.yml is no longer present, and there's no way for someone using the module to determine the license from perldoc/man. Also, some modules may include a separate LICENSE or COPYRIGHT file in the tarball.
ithread on FreeBSD 7.1
Dear all, I found that ithread seems to be not working on FreeBSD 7.1. Is it so? Will ithread work on FreeBSD 7.0? Or does ithread not work on FreeBSD at all? Or is there any way to make ithread work on FreeBSD 7.x? -- imacat ^_*' [EMAIL PROTECTED] PGP Key: http://www.imacat.idv.tw/me/pgpkey.asc Tavern IMACAT's http://www.imacat.idv.tw/ Woman's Voice http://www.wov.idv.tw/ TLUG List Manager http://www.linux.org.tw/mailman/listinfo/tlug pgpq93NC7Y0VG.pgp Description: PGP signature
Re: Integrating license related things of CPAN
On Oct 26, 2008, at 10:24 PM, Bill Ward wrote: The problem is people may add it to META.yml but not remove it from the POD. For one thing, it would be nice to be able to see what the license is when viewing the POD. Once the module is installed META.yml is no longer present, and there's no way for someone using the module to determine the license from perldoc/man. Also, some modules may include a separate LICENSE or COPYRIGHT file in the tarball. (joining this discussion late...) Isn't that just an authoring problem that already exists today? The LICENSE file is not kept after installation either. This is a human problem, so I think a human solution is appropriate, like a Perl::Critic policy or a Kwalitee rule or a distcheck action to ensure the META.yml matches the POD copyright. The definition of matches is the hard part...
