dean

The current state: The Perl interpreter and most of CPAN are provided under the Artistic 1.0 license and the GPL1.0 license. The Artistic 1.0 license was written by Larry Wall and due to its problems Perl is simultaneously licensed under the GPL 1.0 License.

It is the de-facto standard to license software published to CPAN under the same terms as the Perl interpreter.

The Artistic 2.0 license supersedes the Artistic 1.0 license and is designed to overcome its problems. Raku uses this license as it was specifically created for Perl 6. Mojolicious also uses this license.

The Artistic licenses are not widely used outside the Perl & Raku sphere.

What is the "best" license? (Discussion)

The major philosophical axis in (free) Open Source licenses is Copyleft versus Permissive

"Copyleft" licenses require source code to be made available with compiled software that is distributed. "Permissive" licenses don't have that requirement.

For scripting languages this distinction is almost irrelevant unless the code is actually compiled (perlcc for example) or bundled up somehow in firmware or something.

However if someone is running the software and not distributing it (i.e. running a website) then there is almost no difference.

Since Perl's main usage is in websites, system administration, etc. there is very little practical difference between Permissive and Copyleft.

Note: Other licenses like the AGPL exist which require source to be provided by websites etc. Software is also sometimes made available as open source on commercial terms (example Radiator from open.com.au)

Why is the author releasing your code as open source?

As an individual author, is the code released for purely altruistic reasons or as a type of portfolio? Perhaps there is an implied business model that organizations using the software will create commercial opportunities to support it? I think it's unlikely though that an individual author will single handedly write software that goes much beyond this. No doubt there are exceptions but likely they are outliers.

For groups of individual authors which tend to organize into "projects", at one end there are the pure hobbyists (think software that controls model railroads) and the other end is employees of various companies being paid (or not!) to contribute to software these companies use.

Commercial entities (businesses) may release code hoping that through usage there will be opportunities commercial support, training, or hosting opportunities will arise. A "freemium" model is also quite common.

Who is the target audience? What's your business model?

Is the author's intention lean more towards hobbyists to use the software or for businesses to do so?

If for businesses, what function does the software perform for the business? I think this heavily informs license choice.

In all cases let's assume that the author wants people and maybe businesses to find the software useful and to use it, that more users are preferred over less, and that there isn't a desire to make using the software any harder than possible.

My thoughts

Taking an open source software as is then attempting to sell it would require establishing marketing and distribution, then convincing consumers they should pay for something they can get for free. This would be a significant investment which wouldn't provide any investment for future versions. Even for "shrink wrapped"/"one then done" software like games, I suspect the effort would simply send more users to the free version over the long term. To me a Copyleft license makes more sense in this context, however I am not convinced as many open source games are available and this doesn't seem to have happened.

The "freemium" business model is a similar idea to this, where companies attempt to convince users to pay money for features deliberately excluded from the free version.

As a historical example, consider the Wine and TransGaming saga. TransGaming created a proprietary version of Wine (which was at the time under the X11 license) called Cedega. Wine re-licensed to LGPL to attempt to force contribution. Cedega has long since been discontinued, and the authors of Wine themselves now have their own proprietary Wine version called CrossOver office which blends the LGPL with proprietary bits with support (basically the Freemium model). Based on this real world example, I am not convinced that Copyleft helps encourage contributions as intended.

A contrary example is BusyBox which is licensed under the GPL license. Actively prosecuting license violations has resulted in a string of settlements and code dumps. Projects such as OpenWRT and SamyGO exist because of these code drops. At the same time, these legal actions have resulted in companies taking open source license compliance more seriously. The Toybox project aims to provide a BSD licensed replacement for BusyBox and is used in Android.

It's worth noting that GitHub reports the MIT license as the most popular (circa 2015). The Node.js and Lua interpreters use this license.

License Compliance

Litigation has resulted in companies taking license compliance more seriously, including open source licenses. Companies and similar organizations should have a well written policy for which licenses are permitted to use and how license compliance is tracked. Likely the most common licenses have been reviewed by lawyers and the burdens each places on the organization considered, representing a considerable investment by the organization.

The AGPL license places a heavy burden on the organization as code must be published even if no software is distributed. This license is very commonly prohibited.

GPL licenses have the burden of providing source code with products and keeping track of the code that creates each release.

On the other hand, permissive licenses do not require source code to be distributed with products or websites merely attribution (in most cases)

The blending of these licenses in an organizations code base necessitates systems that track and ensure compliance. Which is even more important in companies that ship products and run websites.

If and how these licenses can work together is also a question legal must answer.

Likely the organization has used a consultant who already understands the licenses and how courts have enforced them, rather than reviewing the licenses in house. The policy may be based on a template to cost effectively provide "cookie cutter" policy documents.

Less common or bespoke licenses are almost certainly not included and would need to be reviewed. An activity that specialist lawyers will gladly do, charging in 6 minute increments. So, unless the software is enormously helpful to the organization, the legal department will likely take the cheapest route and simply decline to allow the license.

My Conclusion

For my CPAN modules, I want business to use that software and want to make use of a common license and place as little burden as possible on the business to comply with it. I plan to re-license them, with old releases remaining under the "Perl" license.

Given the common use cases of Perl and its scripted nature, I recommend re-licensing code to the ISC or MIT license.

[edit: some typos and punctuation fixed]