A look into the most popular packages on Packagist and their licences.

A recent conversation got me curious about licences in the PHP world. Licensing is important (and often overlooked), though is harder than it seems. Licencing is important as it tells the users of your software, the ways in which they are allowed to use your package and any attribution back, it also shows who is responsible should the software not work, along with other details such as how the end user can redistribute your code.

If you are unsure about licence differences tldrlegal is a great reference point.

I have had discussions with top solicitors in the past about software licencing as some parts of licences are more technical than they appear to be.

I'm not sure how much developers in general audit their dependencies apart from the occasional `composer licenses` run, and from my experience licensing seems to be an afterthought if the code is "open source" i.e you can see the code. This is especially so for web use, as most open source licences focus on the redistribution of code, which is not as much of a concern for most end users who are running a website, for example.

I was wanting a more in depth view of things.

I'm using a modified version of the script Nikita Popov wrote to analyse top packages. I look at the top 5,000 packages as ranked by Packagist in May 2021, and their chosen licenses.

A few things to note here, firstly the amount of packages which suggest they don't have a licence. If this is true these packages should be avoided (more reading on that here), these packages have no explicit permission to use them.

The difference in the number of packages with a proprietary licence, and the number of downloads is striking, that suggests that licences are being looked at more than I thought, or that the proprietary packages are less popular (i.e. in the lower end of the 5k packages).

There are lots of not easily analysable licences as they are marked as proprietary. While some are truly reflective of this, it's hard as each one will have to be manually checked.

This is not entirely accurate though, as packagist only knows the licence indicated in the composer.json, this may or may not be the same licence as in the package.

There are four ways in which this could go wrong:

1. A licence in composer.json, but nothing in the source repo
2. Nothing in composer.json, but a valid licence in the source repo
3. A licence in composer.json, and a valid licence in the source repo, but a conflict
4. A licence in composer.json, and a valid licence in the source repo, but something else conflicts, e.g. the README

All of these cases occur in the following popular repositories:

• elastic/elasticsearch-php is duel licenced, but the composer.json suggests only one of the licences
• openlss/lib-array2xml composer suggests Apache-2.0, licence suggests GPL-3
• paypal/PayPal-PHP-SDK composer suggests Apache, licence suggests Paypal SDK Licence
• Laravel-Backpack/Settings composer and licence match, but readme suggests something different

Even Nexmo who have some of the best documentation, with a team who really know what they are doing make these mistakes, see Nexmo/vonage-php-nexmo-bridge: composer.json says MIT, Licence says BSD-3, so even industry leading developers working on well known and used packages make mistakes in licencing.

Other common things to do are:

• Changing the licence a small amount, this makes Github not pick on on the real licence. I have classed this as malformed, while some of these match the original licence has changed
• Subtle differences, such as licence under GPL-2.0 in composer.json but using the GPL2.0-or-later licence.

A basic analysis is shown below

It's worth noting that some of the "Missing Licence" ones are actually against their own terms, as MIT for example says:

"The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software."

So not including the licence text in their own package is against their own terms.

How can we improve this ?

Ideally before releasing a package as open source, people should consider what licence they want, each person will have their own reasons for wanting to do open source, so there's not a single licence which fits all needs. Github is getting better at asking you to include a licence when making a new repo, and can even import one on your behalf. This needs to match the distribution method, for PHP code this will almost certainly be Composer.

Composer could check that the licence matches, all of the data I have provided here has been downloaded from Packagist and Github, but it's not really Composer's/Packagist's job to do this. A reminder system could be useful, similar to how you get emails about invalid json files.

Education could also help, but licencing is a dry subject, which is hard to get right. I've been to conference talks about licensing, but they tend to be a bit preachy about the speaker's preferred licence.

A useful product would be something like Dependabot, which can check in bulk and open an issue on the repo. From my experience, once licence issues are pointed out, they are fixed quickly, although the code I have written to do this analysis could be extended on, it took 7 hours to get the information for only 5,000 packages. I'm not sure how to get a higher API limit, but suggestions would be welcome! I would be interested in writing a bot to validate this.

What can you do today? Check your open source packages, check the package on Github matches your packagist profile both extract this information.

If your package is using a known open source licence and you are unsure how to check, get in touch through twitter and I will gladly look at your licence set up.

Thanks

Thanks to Greg Bowler, Rory and Phil Walker for the editing help and helpful suggestions