Nothing has foregrounded the fundamental bargain of open source like the past couple months of WordPress drama. I’m not here to talk about that in particular, but it has really gotten people thinking about what’s legal, what’s ethical, what you can charge for, what you can give away, and how a business will or won’t work within the ecosystem based on how you answer these questions.
Matt Mullenweg recently took over the WordPress.org repository copy of Advanced Custom Fields, for which he received a great deal of criticism. Just a couple of days ago, he included advanced features (the one’s you’d ordinarily have paid for) as part of this free (renamed) version of the plugin.
GPL is a free pass
As nearly as I can tell, this is completely within the letter of the GPL (General Public License, a baseline agreement created by GNU). If you use GPL’d software to make your thing, the anyone else can use your thing for whatever they like.
At the same time, there’s been something of an understanding in the WordPress world that you can charge for plugins and themes if you want to, and there’s a genuinely large business ecosystem built around this.
But this business ecosystem is in some respects built on faulty assumptions, and Matt’s release of “premium features” from Advanced Custom Fields is solid proof of this, barring some significant turn of events in a legal action that hasn’t happened yet (ACF’s parent company WP Engine is suing Matt and others but not over this particular matter).
New models
I am convinced that there needs to be a model for code that is examinable and extendible, but that requires a low-cost license to use (or to use in a business resale context, but I prefer the simpler idea of just charging a small amount for any use). I think a blockchain model of project governance is the way to accomplish this, but that’s a post for another day.
Meanwhile, though, those of us trying to run businesses in the WordPress space are pretty concerned by the idea that their features can be distributed for free on the primary distribution site for the ecosystem at WordPress.org.
SaaS, API or Bust
My take is that you have to offer your business as a SaaS, or a SaaS with a connector plugin, if you want to operate in a way that you can legally protect. If I sell you a service, all you see and use is the service. To date, anyway, what I build the service with is my choice and the code I did it with isn’t necessarily anyone else’s concern.
So if what I’m selling you is essentially access to a WordPress site, you’re using the site, not running the code, and you aren’t necessarily entitled to see the code. I’m probably obligated to make the code available to you if I build it within a GPL context, but this seems effectively unenforceable.
For one thing, anything that I want to keep outside of GPL provisions I can implement as a separate service that’s used via REST calls. The code that processes the REST requests isn’t GPL and you’re not entitled to take it and resell it.
I can even make the source code available to you, but not under a GPL license. I can let you see it but not use it yourself, let you see it but only use it if licensed for a fee, and so on.
Business behind the curtain
In the current environment, what I suspect will happen is that developers will cordon off some portion of what they do behind a REST API and not let you see the inner workings. That’s not really the way I want PeakZebra to do business, but I want there to be a revenue stream that Matt can’t gut at a whim.
The good thing about this sort of workaround, where it is feasible, is that it makes it possible to continue to do business in the WordPress space without undue risk to the business owner. And there are all sorts of great reasons to keep WordPress (and it’s ecosystem) thriving and moving forward.