WP Tavern › Forums › Create Topic
George Stephanis Okay, so here’s the guidelines, just as a refresher for anyone unfamiliar with them: https://wordpress.org/plugins/about/guidelines/ The plugin itself must be all GPL-friendly code. Which those are. It says nothing about the external API that it interfaces with needing to be public GPL code — otherwise any plugin that connects to Twitter, Facebook, Google, or others would be allowed. Kinda silly. But when you’re talking about plugins that connect to external services but don’t do anything apart from that, I think you mean serviceware plugins, which are addressed by point 6 — which for convenience, I’ll copypasta here: 6. “Serviceware” plugins are defined as plugins that merely act as an interface to some external third party service (eg. a video hosting site). Serviceware plugins ARE allowed in the repository, as long as the code in the plugin meets all other conditions. These are allowed even for pay services, as long as the service itself is doing something of substance. Creation of a “service” which does nothing but to provide keys or licenses or anything similar for the plugin, while the plugin does all the actual work, is prohibited. Moving arbitrary code into the service so that it can appear to do some work is also prohibited. This will be handled on a case by case basis and our judgment on any given case is final. Basically, if you’re moving some functionality to cloud services, you should have a reason for it being on cloud services — not just to collect user data by making them authenticate. In the case of Jetpack, there’s absolutely tons of reasons, and we don’t do anything in the cloud that could be done just as easily on client sites. It basically comes with the philosophical distinction of not putting arbitrary restrictions on code. That kinda violates the spirit of the GPL. Does that make sense? I’d be happy to try explaining again if you can clarify what points are confusing.
George Stephanis
Okay, so here’s the guidelines, just as a refresher for anyone unfamiliar with them:
https://wordpress.org/plugins/about/guidelines/
The plugin itself must be all GPL-friendly code. Which those are. It says nothing about the external API that it interfaces with needing to be public GPL code — otherwise any plugin that connects to Twitter, Facebook, Google, or others would be allowed. Kinda silly.
But when you’re talking about plugins that connect to external services but don’t do anything apart from that, I think you mean serviceware plugins, which are addressed by point 6 — which for convenience, I’ll copypasta here:
6. “Serviceware” plugins are defined as plugins that merely act as an interface to some external third party service (eg. a video hosting site). Serviceware plugins ARE allowed in the repository, as long as the code in the plugin meets all other conditions. These are allowed even for pay services, as long as the service itself is doing something of substance. Creation of a “service” which does nothing but to provide keys or licenses or anything similar for the plugin, while the plugin does all the actual work, is prohibited. Moving arbitrary code into the service so that it can appear to do some work is also prohibited. This will be handled on a case by case basis and our judgment on any given case is final.
Basically, if you’re moving some functionality to cloud services, you should have a reason for it being on cloud services — not just to collect user data by making them authenticate. In the case of Jetpack, there’s absolutely tons of reasons, and we don’t do anything in the cloud that could be done just as easily on client sites.
It basically comes with the philosophical distinction of not putting arbitrary restrictions on code. That kinda violates the spirit of the GPL.
Does that make sense? I’d be happy to try explaining again if you can clarify what points are confusing.
Name *
Email *
Website:
Topic Title (Maximum Length: 80):
Forum: — No forum —AI and WordPress Articles Blocks Showcase Discussions Events Introductions Jobs and Working in WordPress Podcast Episodes Site and Block Editor
Enter your email address to subscribe to this blog and receive notifications of new posts by email.
Email Address
Submit
Enter the destination URL
Or link to existing content
