On Tue, Dec 6, 2011 at 10:45 AM, Sean M. Burke <sbu...@cpan.org> wrote: > I seek advice on software licenses!
Run and hide? > In many cases, my modules' current documentation says, as copyright/license, > simply "This library is free software; you can redistribute it and/or modify > it under the same terms as Perl itself." > But I'm told that modern practice involves explicitly making clearer (in > docs and probably metadata) the choice between perlartistic and perlgpl,... > or what are the other well-known options that I can use? I haven't seen real shift. Plenty of code still says "same terms as Perl" as vague as that is. Best place for license information is OSI: http://www.opensource.org/licenses/category Look at the popular category for options and ignore the rest. > I'm not up on these things-- and I've recently been emailing with someone > who wants me to have Unidecode be under GNU *Lesser* General Public License > (the existence of which I was unaware of), because he wants it as part of a > project that's MIT licensed, and that's a problem somehow-- so now I'm > feeling like I should put actual thought into this now. MIT license is one of the least restrictive. Generally GPL/LGPL tend to be some of the more restrictive licenses. (Perl's Artistic license is fairly liberal) > Suggestions? I personally favor the Apache 2.0 license. I find it the clearest to read, with the best defined terms, and includes clauses covering contributions back to the original in whatever form (i.e. if someone sends you a patch, it's licensed to you; if someone tells you verbally about how to fix your code, it's licensed to you.) I haven't seen any other open source license that is so explicit about how contributions are handled. The license also specifies you can include a NOTICE file that must be included or displayed in anything using your code, which I think accomplishes your goal. (I personally don't bother, but that's me.) I don't know if that's sufficient for your MIT license using person, but it's as permissive as I'd be willing to go with my own code (except for things that are dual-life on CPAN and in the Perl core, for which I license under the terms of Perl itself for simplicity). -- David
