Kernl to Offer Hosted Private Plugin and Theme Updates


Jack Slingerland started hacking on WordPress in 2008, but recently his career has taken him a bit further afield from it than he would like. By day he is a Senior Software Engineer at CA Technologies in Raleigh, working in React/Redux, Node, ElasticSearch, Grails, and Groovy. But at night he is busy building Kernl, a service that provides private plugin and theme updates for WordPress.

Once a plugin has been added to the service, the updates delivered from Kernl will look exactly like updates from

“Kernl’s core feature is providing private plugin and theme updates for WordPress developers. However, our differentiating features are what get me excited,” Slingerland said. “We have purchase code validation (so only authorized users can download updates) and continuous integration (CI) support.

“The CI stuff is really neat, because it allows WP developers to push their code into GitHub or BitBucket and then have it automatically packaged and deployed to their customers. CI has been traditionally hard to do on WordPress because your ‘production’ environment is often something you don’t control,” he said. “Kernl solves that problem.”

The idea for Kernl came to Slingerland after previous years trudging through client work.

“One thing that constantly nagged at me was how hard it was to get any bug fixes or feature updates out to my clients,” he said. “I often didn’t manage their sites, so getting them updates involved lots of emailing and communication overhead.

“I originally had the idea for Kernl back in 2011, but never executed on it until last year,” Slingerland said. “I was hoping that I could help other people solve the same problem I had.”

Kernl launched in private alpha in May 2015 with ~65 alpha users. In November he opened it up for public beta and the service now has approximately 100 beta users. Testers are currently putting Kernl through its paces:

  • Kernl hosts 73 plugins & 43 themes (117 total)
  • The service processed 4.07 million update checks since May
  • Kernl processes around ~2 update status checks / second
  • 14,100 updates have been downloaded from Kernl

How does Kernl compare to WP Pusher?

I asked Slingerland about how Kernl measures up to WP Pusher, which allows developers to deploy WordPress themes and plugins from GitHub and Bitbucket.

“Kernl doesn’t require your end-user to install anything besides your plugin/theme,” Slinglerland said. “If I understand WP Pusher correctly, you first install WP Pusher, then tell WP Pusher to manage updates for a given plugin/theme via it’s version control repository. But this has to happen on every end user installation and might feel complicated to non-technical users.

“Kernl works seamlessly with your plugin/theme, just like those that are installed from the repository. This makes installing and updating feel familiar and blend in seamlessly,” he said.

“We also have purchase code validation, which is going to be getting some love and an API after we go live. Kernl also supports versioning your plugin/theme, so intermediary commits don’t get randomly sent out to your customers.”

The Importance of Continuous Integration

One of the reasons Slingerland built Kernl is because he wants to help more WordPress developers add continuous integration to their workflows. This particular aspect of the app (the “push to build” feature) posed the biggest technical challenge but was one of the most important problems for Kernl to solve.

“There are a lot of edge-cases that I didn’t foresee, especially once I started integrating with both BitBucket and GitHub,” Slingerland said. “In these cases the beta testers were invaluable in helping ferret out bugs.

“Having a solid continuous integration and deployment workflow really changes the way you think about development,” he said. “Instead of having ‘big bang’ once a quarter feature releases, it becomes easier to iterate on your idea. Fail fast, validate your ideas/changes, and iterate again. It’s a big enabler of the Agile development methodology, and I feel that the WordPress plugin/theme community has kind of lacked that. It encourages good testing as well, which is almost required if you are deploying continuously.”

Slingerland is aiming Kernl at developers who create WordPress plugins and themes that are not hosted on A handful of his beta users have even been using the service to distribute updates for their own beta testers before they publish an official release to

Kernl will host any plugin or theme for free as long as it is both open source and freely available. Pricing for commercial plugins and themes will range from $5 – $25/month. The service is free to use during the beta period, which is planned to be wrapped up in mid-February.

Kernl Will Not Police Product Licensing

After further inquiry regarding Kernl’s position on the licensing of products it hosts, Slingerland states that he will not police his customers’ licensing. This means that authors of non-GPL themes and plugins would be welcome to distribute their software via his platform. Since themes and plugins are derivative works of WordPress, they are required to be licensed under the GPL.

Slingerland’s lack of willingness to police non-GPL software has the potential to make Kernl a hive for products that break WordPress’ license. The service makes it easy to distribute non-GPL software that masquerades in the admin as regular compliant plugins/themes when it comes to updates.

Distributing non-GPL software can be a deal breaker for WordPress developers who feel strongly about the GPL. The GPL protects users’ freedom to use and modify the software for any purpose, and many developers have built their businesses and reputations on upholding that freedom.

Software hosted by Kernl may or may not comply with GPL licensing, and the user may never know. This leaves the user vulnerable in a way that official updates from does not. Developers who don’t want to be parcel to supporting a platform that has the potential to distribute non-GPL software may want to look for an alternative.


23 responses to “Kernl to Offer Hosted Private Plugin and Theme Updates”

    • Will have to take a look at your code at some point, but the first question that came into my mind is why not to use EDD and its licensing extension which seems to be both somewhat cheaper and requires only 2 plugins (EDD+licensing) instead of 3 (WC+simba updates+connector)?

      • I wrote a licensing manager that was e-commerce-plugin agnostic, because I didn’t know at that time what bit of e-commerce software I would be wanting to use a few years down the line. Moduralisation is good.

        As it is, I’ve never used EDD. I have no opinions on it either way. For me, the answer to lots of “why not use X instead?” questions is “because what I’m using works, without any known side-effects”.

        How many plugins you have installed on a site matters very little – much less than whether those plugins are well or badly written that makes a difference. Of course, fewer plugins means fewer plugin updates; but, on the other hand, functions that aren’t modularised sufficiently cause bigger fall-out when you hit a problem with them.

  1. @sara

    The GPL protects users’ freedom to use and modify the software for any purpose

    That is simply not true, the GPL is a restrictive license. If a plugin is under GPLv3 you are not allowed to use it for any site which has code protected by patent and IIRC you have to share your modifications in some cases. The only way in which GPL gives you freedom is re-distribution and that is it.

  2. Can this be clarified? “Since themes and plugins are derivative works of WordPress, they are required to be licensed under the GPL.” … if I write a plugin from scratch it’s not a derivative work, even if it implements a API of a GPL program. If someone reused GPL code and sold it without code access then that would be a derivative work against the GPL, but a fresh code would not be.

        • The current court ruling on the google vs oracle case relating to copyrights of the java API is that API is not copyrightable, therefor by defining an API you do not get to claim any right on a code that use it.

          This was always kind of obvious as otherwise everything PHP will need to comply with the PHP license and everything on linux will have to be GPLv2. This was always thrown as a FUD against the use of GPL software “if you have even one small GPL component your product will have to be fully GPLed”. I never heard of a case relating to this kind of thing and therefor I assume that even EFF do not believe that by just interfacing with GPL code you become GPL if after so many years of popular GPL software being used all over the place, no one was sued for such it.

          The other issue that might “inflict” GPL on plugins and themes is the inclusion of of snippets from core or from theme distributed with core. This is trickier but for almost every plugin and theme those snippets will fall under fair use because they are small and without any creativity, or under “obvious” as there is only one recommended way to do things in wordpress therefor you can not claim creativity and therefor copyrights on its usage (think of a main loop, or widget class, there is really by design only one way to write them).

          Even the foundation do not show any sign it fully believes in the GPL claim as it preferred a pitiful shaming campaign or accuse of trademark violation against people that do not comply with the GPL. Never they actually sued for copyright violation.

          Legal splitting hairs sidenote: It is not obvious at all that the foundation can even release wordpress under GPL as it do not require the contributors to declare that they are the owners of the code that they are contributing. It is possible that someone by mistake contributed a code that he developed for a client and therefor the copyrights for it belong to the client and not to the developer.

          This is why I always say that whenever a developer needs a license advice he should go to a lawyer and not take anything posted on the net as a gospel. Copyrights is a complex thing and the law can even be different enough to make a difference in different countries.

        • Sorry, @mark k., but you are completely wrong about the Google vs Oracle case. I think you must be talking about the original trial verdict and not the subsequent appeal.

          In fact, the Court of Appeals for the Federal Circuit has held that APIs can be subject to copyright. You can read the full law report here:

          Google did petition the Supreme Court, but the latter declined to take the case, so the appeals court’s holding is what currently states US law.

          Google might still succeed in a trial on the facts, if it can establish fair use. But, as Google itself recognizes, a win on those terms would be very different from winning on the basis that an API cannot be subject to copyright at all.

          • Just shows how correct is my main point, developers should not have opinions about law and leave it to lawyers which they hire :)

            Still while the initial ruling was about the copyrightability of API, google lost a court case which is about re-implementing an API, and not about the usage (invocation) of API. Btw it is too early over here and not enough coffee but it seems like there are very nuanced reasons that contributed to google losing the case (they copied 7000 lines as they were, oracle developers testified about the creative process of the API), which might be relevant for other similar cases, and again if it was simple MS might have sued the wine or samba projects which re-implement win32 API without its blessing (they did give the blessing to the .net reimplementation)

            What you can learn from that case and rulings is that this kind of things are far from being obvious. Now the re-implementation of API at least has some guidance from the court – reinplementation of a full stack of API might get you in trouble, but the jury is out about usage of API as there was no specific case about that. Matt can find a new lawyer that will say again the same things he was told before and I can find a different one that will say otherwise (and they both might belong to the EFF as the EFF do not like the copyrightable API idea and both can present a good arguments, but it would be just legal masturbation. If Matt and the foundation think they are right, there are more then enough non GPL plugins and themes around they can sue to create a legal guideline, until then all this “all your plugins are GPL” claim is no more then FUD.

      • Thanks for chiming in with the comments. I remember a company I developed a theme and other glue code for was bought by a larger (and ultimately incompetent) corporation. Their attorneys were all in a tizzy over the GPL and I had to address the exact issue at hand you describe, implementations of APIs that were never sold as code products, just used to run the site.

      • @mark k,

        It’s a pity you cloudied the issue by mentioning the Google v Oracle case. As I explain below, you’ve got that decision completely wrong.

        However, on the more general point you make here, you are right. Just because some people like to repeat the peculiar mantra that themes and plugins are derivatives of WordPress does not make it true.

        Whether a particular theme or plugin is or is not derivative will be strongly fact-dependent. For example, a plugin that just exposes functions within core will clearly be derivative. But a fully-fledged e-commerce or membership plugin is certainly not derivative.

        That leaves a large gray area in between, where the answer would become clear only after protracted litigation. Unfortunately, some people behave as if scaring developers is an acceptable alternative.

  3. It is possible that someone by mistake contributed a code that he developed for a client and therefor the copyrights for it belong to the client and not to the developer.

    If I build you a house and devise new methods, custom tools, savvy workflows and creative strategies to deliver you the best house your money can buy—you don’t own copyrights to my IP. You get a kick-ass final product. You can R.E. your OSS deliverables, but I’ll license every-other byte. That’s it. You pay, we play. You steal, no deal ;)

    • This falls under “work for hire” anything you generate, unless you have an agreement that explicitly says otherwise, belongs by law to the person which hired you. So yes, the implication is that when you use the same code for different projects one of them might end up being sued for copyright infringement.

      You can retain the knowledge and reuse it, but not the code.

      • unless you have an agreement that explicitly says otherwise, belongs by law to the person which hired you.

        Simply not true that “work for hire” is automagically owned by the client. Also, independents are not employees. People reading this who don’t know Copyright Law or have never read 17/101 should brush up and not listen to people spreading AssumedLaw™ online.

  4. The copyright issues are quite big here, considering that they also imply both ownership and control. It would imply that copyleft could come into play, and creators of commercial plug ins could find themselves with no recourse against people who take their code and redistribute it for free, as the plugin should, to meet wordpress standards, be licensed under GPL.

    This seems to be a pretty big legal hurdle.

    • creators of commercial plug ins could find themselves with no recourse against people who take their code and redistribute it for free, as the plugin should, to meet wordpress standards, be licensed under GPL

      I heard of enough people having to pay damages for redistributing things they thought they are allowed to.

      If you can not afford a lawyer on your pay roll it is better that you do not distribute anything you have not created or have explicit license for distribution. “but Matt said so….” type of defense will at most serve as a mitigation factor, but really just the cost of going into court is so high, that unless you are 100% sure in what you do, you should not take any risk that might lead you there. If a plugin is not explicitly GPL then just don’t redistribute it or any part of its code.

  5. Being listed alongside non-GPL plugins & themes is a deal breaker for me. I stopped reading when I saw that. I hope the people running this service might reconsider on this issue.

    If not I hope that their service sees only limited success. I personally don’t want to see another major operation in the WordPress ecosphere which ( like Envato ) does not clearly embrace the GPL.


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: