Plugin Guideline changes

I realise this is slightly jumping the gun on the Trialware in the directory vote although no changes will go-live before the vote finishes, but as it looks like the voting is coming down against trialware being permitted, a new rule would be needed:

  1. Trialware is not permitted in the directory; any plugin submitted to the directory must be functional when installed and not stop working; plugins using SaaS which stops functioning when a subscription ends is not included in the definition of trialware as they are regarded and classified as premium.

Based on some discussions around licencing (on which I would like @timkaye’s opinion) do we also need to change current rule 6, which currently states the below, by removing the highlighted word?

  1. All Free Plugins must be compatible with the GNU General Public License; using the same license as ClassicPress (GPLv2 or later) is strongly recommended, but any GPL-compatible license is acceptable.
1 Like

I think this is inaccurate. The plugin could be free, and the service it interfaces with is premium.

Yes, remove the word Free since all plugins must be GPL compatible. (There is an edge case of a plugin that doesn’t actually use any WP functions being considered not derived from WP, but that is a separate issue from the cost of the plugin.)

1 Like

Rule 5 states: Software-as-a-Service must be categorized as a Premium plugin.

Ah, my mistake. I think everyone else will make that mistake also, though. To me, a premium plugin label means that you have to give money to get the plugin. I take issue with the word premium, because it can have two meanings (quality or money).
Since the directory is where the label is, and the plugin is not necessarily for sale, I think this is false advertising.

This was discussed to death a while ago and the consensus was that free/freemium/premium was known and understood terminology.

If I recall correctly, requiring plugins to be premium when they depend on SaaS was because the plugin is not functional without the service.

3 Likes

Matt says he obtained a legal opinion on that some years ago, and that’s what it said. Maybe he did, but he’s never published it (so far as I am aware) and I don’t know any lawyers who think it’s correct. (Maybe it might have been years ago, but the WP eco-system has grown exponentially since then.)

The point is that, while it’s true that all work that is “derivative” of or “based on” WP must be licensed as GPL, what counts as "derivative"or “based on” is a question of fact that, in a trial in the US, would be determined by a jury. I have come across several plugins that essentially treat WP merely as a thin wrapper, while the substantive code has almost nothing to do with WP at all. I doubt they would be considered either “derivative” of or “based on” WP. Lots of plugins that just attach some JavaScript to a WP hook are probably in the same boat. So I don’t think there’s any legal obligation on us to take any particular stance.

Nevertheless, I think it makes most practical sense to require that all plugins obtainable via a CP channel be licensed as GPL. That’s because, if they are not, the code may be obfuscated and could contain all sorts of stuff. There would then be no way to audit it at all, even if we received complaints about privacy or security problems. It’s true that some other open source licence would also achieve that, but requiring an alternative open source licence would just add confusion, so I’d suggest sticking with GPL.

2 Likes

The closest thing I’ve seen is the Oracle v. Google case, which did end up with the Supreme Court earlier this year.

Indeed.

OK, I have amended guidelines to remove “free” from the current rule and once the vote ends will dd the new rules against trialware.

1 Like

Following the end of the voting, I’ve added the trialware rule into the guidelines.

2 Likes