Press This: Are Your WordPress Plugins GPL-compatible?

Welcome to Press This, the WordPress community podcast from WMR. Each episode features guests from around the community and discussions of the largest issues facing WordPress developers. The following is a transcription of the original recording.

Doc Pop: You’re listening to Press This, a WordPress community podcast on WMR. Each week we spotlight members of the WordPress community. I’m your host, Doc Pop. I support the WordPress community through my role at WP Engine and my contributions on TorqueMag.io. You can subscribe to Press This on RedCircle, iTunes, Spotify, or your favorite podcasting app, or you can download episodes directly from WMR.fm.

If you’ve ever contributed to an open-source project, you know that it’s all about collaboration and innovation, but there’s a little-known challenge that many developers might face in ensuring their plugins stay on the right side of the GPL, GNU, General Public License. It’s not just a matter of compliance. It’s about preserving the spirit of open source.

So today we have a special guest, Jeff Paul, the director of open source at 10up, who will share a game-changing solution he presented at WordCamp US this year. Imagine having a tool that scans your codebase automatically to guarantee your plugin’s GPL compatibility, even as you add new features and dependencies.

That’s what we’re going to be talking about today. But before we dive into it, Jeff, can you tell us your WordPress origin story?

Jeff Paul: Sure. I don’t know that I have the exact year. It was probably early 2000s. I had a personal site that was on a former CMS, I think it was called Geeklog. And between that and my hosting provider at the time, and who knows how many other factors, there was, you know, a collapse of content in CMS.

And so I was just searching for something to replace that with at the time. I found, WordPress and it worked for what I needed. You know, didn’t go down the path of building a CMS myself, which seems to be a good origin story for a lot of folks. But that was, call it, I don’t know, ‘04 to ‘07, somewhere in that range, but I didn’t, kind of cross the divide to contributing until the WordPress 4.7 release when I joined the release squad there with Helen Hou-Sandí and Aaron Jorbin. So, I spent many years being a consumer of the project, and it wasn’t until quite some time down the road that I became a contributor and have been, you know, continuing on that path since then. Well, you know, dual consumer and contributor at this point.

DP: And you’ve been a very active contributor to WordPress core as well. 10up maintains dozens of plugins in the plugin repository, including ElasticPress, Distributor, ClassifAI. These are all available on the wordpress.org repository, and they’re maintained on GitHub, publicly and using open-source practices.

You are very familiar with the topic we’re going to dive into. Why don’t we just start off with the WordPress repository, like, the WordPress plugin repository? Tell us quickly, what is the WordPress repository and what are the rules to be able to upload anything to it?

JP: Sure. So the WordPress repository is hosted by WordPress.org, the open source project, separate from WordPress.com, separate from any other host in the ecosystem, separate from, third-party plugin companies or distributors. And it is what is directly linked or tied into every WordPress install out there. When somebody is in the WordPress admin, is searching for a plugin or theme, those searches are through that WordPress.org plugin repository, and theme repository, available in the WordPress admin. And similarly on WordPress.org. Effectively the same search, same content, is available there.

In terms of getting something listed there, the wordpress.org plugin review team has a set of, detailed guidelines of do’s and don’ts for plugin developers. And then there is an actual submission workflow to go through to do that initial submission to the wordpress.org plugin repository. Once that is approved, there is an SVN repo that is created for your plugin. And, you know, any updates, releases, etc. are pushed there to SVN. And that’s kind of where everything currently lives and breathes for things that are available for search on WordPress.org or within the WordPress admin.

DP: One of the first rules I believe is that whatever you put into the WordPress repository needs to be compliant with the GPL, including fonts and images, not just the code. Is that correct?

JP: Correct. Right. So quite literally, the first rule of the plugin team is that the plugins in their entirety must be GPL-compatible. That is the same license that WordPress follows, and as you mentioned, code, images, and third-party libraries, all have to be GPL-compatible. It doesn’t have to necessarily be the actual, you know, GPLv2 license, there are others that are GPL compatible, but yeah, fonts, images, third-party libraries, dependencies, all that has to be GPL compatible and not just the code that a plugin developer writes, right? All those other things also need to be GPL-compatible.

DP: And just so we don’t keep listeners waiting, like, we could just jump into it. Your talk was about how to be able to check for GPL compatibility using GitHub actions. Can you walk us through that process?

JP: Yeah, so this stems a bit from my role as the director of open source at 10Up. It’s perhaps not something that an everyday plugin author of, you know, a single plugin or even multiple ones might be aware of, or, bother them. But I think at some point I had almost quite literally that wake up in the middle of the night thinking, “I don’t know if I know for certain that you know, all the images, all the third party dependencies, all the fonts, et cetera, are GPL-compatible and trying to figure out a way at scale for us at 10up where we’ve got, like you mentioned, dozens of plugins that are available on the wordpress.org repository or on GitHub as well. The source there.

I didn’t want to have to go through all of that with a fine-toothed comb and have to check any upstream dependencies that we were using for the plugins and figure out, you know, how are these licensed. That could be a pain in the butt for a single plugin, let alone multiple. And through some, searching online, I identified that there were some tools, some GitHub actions that could be used to help effectively automate that process so that, you know, not just a single one-time scan of a repository to say, yes, you’re compatible or no, you’re not, but continued scans so that any future bug fixes, enhancements, et cetera, that might either add a new dependency or perhaps bump a dependency in your plugin that perhaps happened to change how something was licensed, being able to check that ongoing, and do that kind of first-time pass through was something I was trying to figure out so that it wouldn’t become just a manual, intensive process and kind of like an ongoing nightmare to ensure that, that compatibility.

So yeah, I mean, I think the initial concern that I had was, I didn’t know that—I had no way to know that some feature we add, if we’re including a new dependency, that that was GPL-compatible, and then realized there could have been an even worse scenario where we had plugins that had been released, iterated upon that already had incompatibilities within their software.

And so that was kind of the first problem I wanted to try and solve. That first initial scan, right? Are our, you know, individual plugins, and are all the ones that 10up supports, truly compatible with the license we declared? And hopefully, cross our fingers they were. And then, you know, from there, that continued check of making sure that future PRs, be they from my team and the open source practice at 10up, broadly with other 10upers contributing to the projects, or just really anybody in the community, ensuring that those maintained the licensing that we stated in the plugins themselves.

DP: And just to clarify here, if you didn’t, if you found through this, that there was, uh, some existing dependency or something in there that, that was not compliant, is the ramification just sort of, shaming from the community or is there possibly punitive damage that you could suffer for not following the rules?

JP: So I’m not a lawyer, right? So, you know, I do not have a lawyer hat on giving this comment, so, you know, not valid legal advice, but the approach that I took as I was running these scans on our plugins, because again, I didn’t know, I was actually quite nervous running all of these, what the results were going to be.

My plan was if I found that there was a plugin that was using something that wasn’t GPL-compatible, that the best approach would be to either remove that dependency, swap it out for something else, effectively clear through that, whatever the issue was and quickly release a new version, right?

There wasn’t much that I felt could be done for what had already been published and released. From my perspective, none of it would have been done in a manner of purposely trying to circumvent licensing. it would have just been, you know, at some point along the line, human error, somewhat akin to a security issue that gets reported to a plugin author. Like, the best approach there is to work on a remediation and quickly get a release out so that folks that are staying current on plugins are in that safer state, be it a security issue or in this case, a licensing concern. Certainly, if there happened to be a plugin that was significantly revenue generating, and if there perhaps could be, reasons to show that it was a known mistake to have something off-licensed, aside, I don’t believe that anybody in the space is doing that on purpose, but I think the only ones that would potentially be at legal risk would be ones that are significantly revenue generating, that would be a target for licensing.

So yeah, I think long story short, if somebody runs a scan and finds an issue in their existing code base, I think the best approach is really that issue a release, an updated version, you know, call out in the change log, call out in the release notes what was changed and why, be transparent about that. But at that point, that’s really, I think the best that a plugin author can do in that case. Fortunately for 10up’s plugins, we didn’t run into that scenario. Everything was, fortunately, compatible, and I would hope that the large majority of folks going down this path, setting up some automation to give them that level of comfort, would have a similar experience.

It may be a little bit of a nervous, anxious wait for a couple of seconds or a minute for the GitHub actions to run. But, you know, once it shows that everything passes, I think most people would probably end up in that state.

DP: Speaking of getting comfortable, we’re going to take a short break. So sit back and relax, and we’ll be back after the short commercial break with more of our interview with Jeff Paul, the director of open-source initiatives at 10up about keeping your plugins GPL-compliant. Stay tuned for more after this short break.

DP: Welcome back to Press This, a WordPress Community Podcast. I’m Doc. I’m talking to Jeff Paul about, using GitHub actions to make sure that your code, your plugins are GPL-compliant. Before the break, we kind of dived into this a little bit and we talked about the ramifications if you aren’t fully compliant. And I guess I wanted to get back to this specific thing. There are GitHub actions that anyone can create. But Jeff, you mentioned in your WordCamp talk that you use the official GitHub action, I think, with, some small changes. Can you tell us what is the name of the action that people should be looking for to be able to do this?

JP: Sure. That’s it’s a dependency review action. So GitHub.com, slash actions, slash dependency, hyphen review, hyphen action. Hopefully, the transcript gets that correctly. If there’s any problem finding that I do have notes about this up on my site, on a post that covers the talk. So, there are links available, but if you search for dependency review action in the GitHub action marketplace, you will hopefully find the official one that I used, and it does more than just check plugin dependencies. It will check more than just the licenses. It can also check for vulnerabilities and other things in your plugin dependencies. But the only thing that I use it for, the core thing I use it for, is checking for invalid licenses in the dependencies within our plugins.

DP: And this is an action that you can set up what type of GPL you want to be following. You can include a license and it checks against that. And there’s also the possibility if you maintain, let’s say, dozens of plugins, that you can still source to that same thing. You can have all of those, plugins that you maintain still coming to that one directory, so you don’t have to go and, and update that each time, right?

JP: Correct. Yeah. I see you sat through my talk at WordCamp US, kudos to you for being in the audience and awake and listening, or you caught it on YouTube or WordPress.tv, but yes, there are kind of two standard flows that I would expect folks to follow here.

One, a plugin author that is responsible for one or a very small number of plugins, or somebody who has more on the one-to-n scale, they have that many plugins they are supporting. So for folks that just have a single one, the GitHub action, as you have it defined, can effectively within that workflow file where you effectively are calling that dependency review action, and having it scan through your repository, there are two, environmental variables or parameters that you can provide. That action one is allow licenses and, the corollary to that is deny licenses. You can’t do both at the same time. and the approach that I took was to go with the allow licenses as opposed to the deny licenses. The thinking there was… I would rather have a case where I forgot to include a GPL-compatible license in the allow license list and get effectively a false positive, right? Like get a dependency flagged as not compatible with my licenses because its license was just something I forgot to add in the list, versus if I use the deny licenses list and I forgot to deny a license that I don’t want, then that could have meant a dependency would get through, would not be caught by this check.

So, my extremely strong recommendation is to go with that allow licenses list. And in the case where somebody is maintaining a single plugin, is to just use that parameter and that list of licenses in your workflow files. So, for 10up, for our plugins, that’s the dot GitHub directory, and then the workflows subdirectory there. And then we have the dependency review workflow that calls that dependency review action, has the allow licenses list, you can pull up my presentation either on my site or find the talk online and see the list of licenses that we have. You can also explore any of 10up’s repositories on GitHub and see the licenses we explore.

Our workflow files are fairly well documented and kind of explain how we got to identifying what we felt were compatible licenses with our plugins. So folks would be welcome to use the list that we have, would be welcome to use a subset of that list, would be welcome to do their own research, perhaps to feel that level of comfort. But we did do fairly lengthy research to make sure that what we were using in our allow licenses list actually is compatible with what we declare. And pretty much by default for 10up, we use, GPLv2 or later, and so all of the licenses that we list are GPLv2-compatible, specifically.

So that’s the case for, again, the plugin author with a single plugin they’re maintaining. As you mentioned, for the case where somebody has more than one, multiple ones, you can have a separate license policy file that effectively has all of those licenses declared in it. And then you reference that config file, that license policy file, in the workflow in your plugins, so that, as you mentioned, you really at that point only have one place you need to maintain the list of compatible licenses. If there happens to be, you know, a new open-source, initiative-approved license that happens to be GPLv2-compatible for us, right? If a new one comes on the scene, then that could be added to the list, or perhaps if one needs to be removed for whatever reasons, you don’t have to do that in dozens of locations. You do it in one location, and then all of your workflow files that are referencing that config are updated immediately, using that new list of licenses.

DP: This is all automated, so if someone does a pull request, it does that just for you. Right?

JP: Correct, correct. So, as we create our workflow files in our repositories, we do have a trigger on a pull request. So, you could also perhaps have it set up to run on a CRON schedule, you could have it run weekly or monthly, but really, once you do that first run, you scan the entire code base of the dependencies, and it’s really going forward, you really only need to check those pull requests that are coming in, You could probably also check individual commits if you’re not using a fairly strict system of requiring PRs on whatever your default or stable branches are for your plugins.

So, there could be additional triggers that people might want to use. For 10up, we tend to fairly strictly require PRs to develop and trunk branches so that we can use this action reliably and know that any changes to dependencies that introduce a new one or bump a version that happens to change the license will get caught by this. So yeah, we use, we pivot or trigger off of pull requests, but depending on how strict folks are, you might, perhaps have that check individual commits to a specific branch, or even run on a schedule daily, weekly, monthly, just to have that comfort knowing that your code is still passing, that there aren’t any licenses that are incompatible with, in this case, GPLv2 for 10up.

DP: We’re going to take another short break here. When we come back, we’ll wrap up our conversation with Jeff Paul about GPL licenses and maybe pick up on anything we didn’t touch upon earlier. So stay tuned for more after this short break.

DP: Welcome back to Press This, a WordPress Community Podcast. We are wrapping up the show and we’re going to switch gears up a little bit. There has been some talk lately about the review process on the plugin repository and, just basically stating this fact that it’s, it’s a little slower than it’s been in the past.

Some people are saying they know that it’s taking, you know, months to get something reviewed where I think I’ve seen it peak at maybe four weeks in most of my years in WordPress. So, Jeff, I know that they’ve talked about maybe some changes they’re going to make to that. Can you tell us what the team is working on now?

JP: Sure. Yeah. And I’ve, you know, I amplify what you said. I think historically, I’ve seen all the things that I’ve submitted have been under two weeks and have been much faster than what is usually reported. And it’s up at around 88 days or something unfortunate for everybody involved.

I think there’s been some turnover on that team. Some very experienced senior knowledge was lost. And the folks that have graciously stepped in to help fill that void, I think are still getting to the point where they can have that same sort of throughput on processing plugins and reviewing those initial submissions. And there is work they’re doing to try and automate some of that. So some of the things that, you know, computers are better at that humans perhaps aren’t, perhaps like running WordPress coding standards and honing in where there are really critical errors reported, right? Instead of a human having to go through and process those things, having a plugin checker that runs and checks for things that can be automated and helping that plugin review team just get a quick initial pause of like, are things that are automated passing? If so, then, okay, dive into your human review and speed things along. If things have been reported, being automated in nature that are not passing, then it’s, I think, a quicker response to that plugin developer of, hey, we’ve identified these initial things in our scan, you know, please, resolve those and then submit an updated zip file, to get things back on course.

So I know that they are working to add some automation in, I think the more they can do to help them on that path, the better, just because at this point, well up over a thousand plugins, the backlog is lengthy, and again, not helping anybody there. So yes, they are working on automations. I know they want to do more, and I think if that’s an area where somebody is particularly gifted at automations and wants to contribute, I think the plugin review team would love to have some help on that front. So certainly reach out in Slack if that’s the case.

DP: And speaking of reaching out, if folks have questions, about your talk that you gave at WordCampUS, or just some of the projects that 10uP is working on in the open source space, what’s the best way for people to reach out to you?

JP: Sure. So my website is jeffpaul.com. I’ve got my presentation up there, if you just search for GPL, it’s probably going to be one of the first posts in any case. Otherwise, my email is [email protected], my work email, um, and then pretty much every social network. WordPress.org, GitHub, Twitter, slash X, and I am @Jeff Paul, and y’all can find me on the social networks that way.

DP: Similarly, if listeners want to find examples of maybe the 10uP work on GitHub, I’m assuming that’s just 10up on GitHub?

JP: Correct, yeah, github.com/10up. All of the repositories for our plugins are up there in public. Our team tracks new issues and PRs closely. Those all get piped into our Slack channel, so anything, any questions folks have, any discussions, they open there. Our team should be fairly responsive to those, but if not, you know, hitting me up on, on WordPress Slack, on Twitter via email, any of those work. I’m always happy to chat open source with folks in the community.

DP: Well, thank you so much for joining us today, Jeff, it has been really great talking to you and I learned a lot about the actions that GitHub has for pull requests and automating that experience. That’s very helpful.

If you missed it last week’s episode of Press This, we talked to Carmen Johnson about steps that you can take to prepare your site for the end of life of MySQL 5.7 and how to get ready for MySQL 8. So that’s a really good episode you can check out, and we have plenty more. You can find those on TorqueMag.io if you want to find transcribed versions. Thanks for listening to Press This, a WordPress community podcast on WMR. You can follow our adventures on Twitter, at the Torque Mag.

You can subscribe to Press This on RedCircle, iTunes, Spotify, or your favorite podcasting app, or you can download episodes directly from WMR.fm. I’m your host, Dr. Popular. I support the WordPress community through my role at WP Engine, and I love spotlighting members of that community each and every week on PressThis.