Open to scene, year 2017: With no good guidance on the license field, the ecosystem had at least as many variations for "Artistic 2.0" license as humans had fingers. But there was a hope that robot kind and human kind could work to solve this problem, together.

Most of our ecosystem modules that have licenses are Artistic 2.0. Here are just some of the variations of the license metedata tag we had in the ecosystem for the same license. Some were ambiguous as well:

The Artistic License 2.0

Artistic

artistic

perl

Perl

Artistic 2

Artistic 2.0

https://opensource.org/licenses/Artistic-2.0

www.perlfoundation.org/artistic_license_2_0

The list goes on. Note: the ambiguous license names above (perl and Artistic) were found on modules that were provably Artistic 2.0 as they had a LICENSE file. I make no assertion that all modules using these ambiguous names are Artistic 2.0, and the list above only refers to what was found on actual Artistic 2.0 projects in the ecosystem.

This was by no fault of the module creators, as the docs.perl6.org example didn't even show a license field at all (this has now been updated with guidance on the license field). The original META spec in S22 used to say that the field should contain a URL to the license, and even if this had been consistent between modules in the ecosystem, it still would not have been very useful for computers or people to quickly figure out with certainty what license a project was under, as the URL's were at many different addresses for the same licenses.

It was clear the original spec was not sufficiently useful to computers or package managers, so the spec was changed to more conform to other parts of META. It was decided we would use SPDX standard identifiers in the license field, which are both human and computer readable. Then allowing for an optional URL to the license to go under the support key of the META (where other project URL's already go).

This new effort hopes to make sure the license fields in META are both computer and human useful to look at, so we standardized based on the SPDX identifiers which are the most widely used identifiers in the open source world.

Humans and Robots working together

We had 103 modules that had license fields, but were non-standard values. My robot agreed to make about 50 pull requests, as a show of good will towards us humans :). These automated pull requests were made when it was a full certainty which license the project had, (either by the LICENSE file or because the license field was "The Artistic 2" or something unambiguous but nonstandard).

There is a full list of the modules with non-standard licenses here where we are keeping track of the progress that has been made! The list is planned to expand to also cover modules with no license field at all, but the ones with license fields were much easier for my robot friend to deal with.

If you have a module in that list, or have a module with no license field (don't feel bad, until several days ago none of my modules had license fields either), it is your job to add one!

If you have any modules which me or my robot friend didn't PR, feel free to add those license fields to any other modules you may have. If you see a module and notice it has no license field in the meta file, feel free to submit a PR of your own if they have a LICENSE file showing which license the module is under, or if there is no license field, opening an issue so the author can make the change themself. If possible add it to the list above so we can keep track of it. As mentioned before, make sure to use SPDX identifiers.

For the details of the updated META spec regarding the license field, please see S22 here.

Thank you for doing your part to help make the ecosystem a better place!

P.S. On April 19th only 13% of modules had a license field at all. Now, 4 days later we are up to 20.5%! Keep up the good work everyone!