Please relicense from "Perl 5" to MIT or Apache 2.0 license
Following from my previous post, I am now actively encouraging everyone to switch licenses to MIT/ISC license or Apache 2.0.
My reasoning is that in the vast majority of cases the author and contributors want the software to be used by as many businesses and hobbyists as possible.
Previously I described how the burden of understanding and complying with licenses, including open source licenses, can be an unintended barrier to them using the software.
Perl modules tend to use "Perl 5" combination as the default license i.e. "Licensed under the same terms as Perl itself". And the "Perl 5" license is actually a dual licensing of the problematic Artistic 1.0 license and the dated GPL1.0 license which also has problems. Both are rarely used outside of Perl and in my view present a barrier to adoption.
Recall I described how permissive ("BSD") and copyleft ("GPL") licenses are functionally identical if no binary is distributed (websites) or for scripted languages that remain in source form.
For these reasons I recommend the widely used and permissive MIT license - or the trimmed down ISC license.
Indeed I have been actively working to swap the license on my CPAN modules.
You may consider the longer Apache 2.0 license attempts to ensure that users do not have to worry about infringing patents by using the software. You may want to make this assurance to users of your software that you won't pursue them for patent royalties - something businesses will be thankful for. Recall that Fedora intends to remove CC0 licensed software as patent licensing is becoming of more concern.
(I will mention that it does blur contract and copyright clauses, and that in my opinion the MIT license granting "without limitation the rights to use" the software seems to include patents)
How to go about relicensing?
If you are the only author of your code and you authored it on your own computers in your own time, then you can just change the license and upload it to CPAN.
If you wrote the code using a company computer then depending on your employment agreement it may be the property of your employer. Similarly if you wrote it while being paid by an employer, chances are they own that software. In both cases your company should have a process for open sourcing their software including which licenses are permitted. You will have to pursue that process and select a different license. (The good news is that other contributors in the organization don't need to be consulted)
If there are contributors and you own your contributions then you will have to get permission from them. I used git to extract all the committers. Then checked that their contributions where still in the most recent version.
Once you have approval then if you're using Dist::Zilla then simply edit the dist.ini file to set license = MIT, then release to CPAN.
In my efforts so far, I created a github issue explaining the change and tagged all the relevant contributors. Just from this I found about 30% of people responded quickly - the rest I had to chase via email. For changes that predate source control history, I had to chase them via details Contributors files and CPAN release history.
(When contacting contributors, you might also ask them to assign copyrights to you via a Contributor License Agreement)
I blog about Perl. I am now in California
I know a lot of people will hold the Artistic and GPL 1.0 in great sentimental regard but we shouldn't let that stop of from seeing the obvious, especially with the Artistic license which I've personally had trouble with on the job. Using a license that company lawyers already understand and sign off on is something long overdue.
What problems have company lawyers had with the Artistic license?
I've never run into this before, even at a previous employer where lawyers had the developers document every open source library or package used (including every CPAN module).
In order for someone to use a perl module, they have to run it with a perl interpreter, which requires that they already comply with the perl5 license. I think this is why most module authors default to that.
Is there really any benefit to changing module licenses to something different from the interpreter that runs them?
I was going to ask the same thing. Is the perl interpreter itself going to relicense?
“Same terms as Perl 5” is both the default and the best practice, and for obvious good reason. Distributing a module under a different license than the interpreter should be a considered choice at best and one that should be avoided if possible.
If there is a problem with the licensing terms of Perl 5 then that’s also where the issue should be addressed.
Is any work being done there?
I would like to see the perl interpreter modernize it's license. I think the legal committee should embark upon that herculean task.
Regarding company policies though.
It is common for companies to have a list of permitted licenses whilst also listing a whole distribution as permitted which has in it software with other licenses.
The result would be that whilst your Perl interpreter is approved as part of your distribution, any modules that you want to pull from the CPAN would need approval. Or you might find that perl modules from the distribution are approved as packaged, but pulling a new version from the CPAN would require a review.
Given that both Artistic 1 and Artistic 2 are clearly OSI-approved licenses, I don't see what the benefit is to relicense anything. Can someone explain this to me in simple terms?
Artistic 2 has already had thorough legal review. Has something happened in copyright law to require a new review?
I concede. Y'all have made good points. I withdraw any objection to the effort.
This is a problem with the company's procedures, not with Perl's or modules' licenses.
It is not worth the (mostly unpaid) time of a CPAN author to contact contributors and change the licenses on what may be dozens of modules, because a potential user suffers from bureaucracy.
The assertion that "It isn't worth the (mostly unpaid) time" ignores the reasoning for an author writing and releasing the software in the first place.
If the author releases the software hoping that supporting it will generate business (consulting, supporting, or even just reputational) then lowering adoption friction is a good thing making the effort worthwhile.
IMO this is the scenario that most suits the rationale for a permissive license.
If the software is more oriented to hobby users and not intended for businesses to sell it, then it is more up to the author. A well known copyleft license is probably more suited to this scenario as the author can more easily defend the license in court compared to an obscure license.
This is my hypothetical "model train controller software" scenario I described in an earlier post, where the project contibutors celebrate more model train enthusiasts using the software but want want to avoid companies selling binary only proprietary versions.