Automattic, Brands, Copyright, GPL, Trademarks, WP Engine
Published on October 13, 2024

The ACF>SCF ‘fork’ and legal risk

written by Richard Best

What the…

Just when the community thought things couldn’t get more disruptive – because they’re already mighty disruptive – they have. Automattic’s CEO has forked (or purported to fork) the incredibly popular Advanced Custom Fields plugin on the WordPress.org plugins repository, calling the new version ‘Secure Custom Fields’. Advanced Custom Fields is a WP Engine plugin (WP Engine acquired it from Delicious Brains in 2022), so no surprises as to why he has done this.

Freedom of speech

Before I proceed, let me say something of freedom of speech.

I anticipate (rightly or wrongly) that MM/Automattic’s defence to some of the allegations against it in WP Engine’s court filing will be premised on first amendment / freedom of speech grounds. Fair enough.

By contrast, we are seeing people in the WordPress community, who are exercising their right to freedom of speech to comment on what they’re seeing unfold, being shut out of WordPress.org communities, Slack groups, and Twitter/X feeds, or otherwise being spoken to with hostility, even when they are trying to help. That doesn’t sit well with WordPress.org’s Community Code of Conduct.

I have thought long and hard about whether to publish this post, because I fear I will be shut out too. I hope that won’t happen and I would encourage those who may not like this post to consider the questions I’m raising openly and non-defensively. Until recently, WordPress has been a large village of sorts where people help each other out. That can include pointing things out that perhaps not even lawyers closely enmeshed with client strategy have considered.

In that vein, one might look at the issues I’ve raised as not only being risks, but risks that are capable of being mitigated.

Key facts

Here are what appear to be the key facts:

1. Announcement: On 12 October, MM released a post on WordPress.org stating:

On behalf of the WordPress security team, I am announcing that we are invoking point 18 of the plugin directory guidelines and are forking Advanced Custom Fields (ACF) into a new plugin, Secure Custom Fields. SCF has been updated to remove commercial upsells and fix a security problem.

…

This update is as minimal as possible to fix the security issue. Going forward, Secure Custom Fields is now a non-commercial plugin, and if any developers want to get involved in maintaining and improving it, please get in touch.

Similar situations have happened before, but not at this scale. This is a rare and unusual situation brought on by WP Engine’s legal attacks, we do not anticipate this happening for other plugins.

…

(I understand at least some members of the WordPress security team were unaware of this development.)

2. Minimal changes: It seems clear that minimal changes have been made to ACF. The changelog says this:

Changelog

6.3.6.2

Release Date 12th October 2024

  • Security – Harden fix in 6.3.6.1 to cover $_REQUEST as well.
  • Fork – Change name of plugin to Secure Custom Fields.

3. No new and separate listing or repository:

Ethics

Regardless of what the GPL may allow (more on that below), people are and will be questioning the ethics of this so-called fork, despite what they may feel about WP Engine’s level of contribution to the community. We’re not talking here about a small plugin that was in dire need of updates. We’re talking about one of the most popular plugins in the ecosystem with 2 million+ users, a long and trusted development history behind it, and trusted developers maintaining it.

I’ve been using WordPress since 2005 and, in that time, I’ve felt there’s an unwritten (and non-legal) rule in the WordPress community which can be summarised as: ‘don’t do this sort of shi*, regardless of what the GPL allows’. Indeed, that unwritten rule is one of the reasons people frown on so-called GPL vaults, that take and resell pro/commercial plugins.  Imagine the furore if, say, Rocket Genius were to take Restrict Content Pro and relabel and sell it as something else. It could (assuming RCL is 100% GPL), but Rocket Genius would never do anything like that.

Putting ethics to one side, though, what kinds of objections might the lawyers have? Can it be said this is all kosher because the GPL allows anyone to make a fork? Well, no, in my view it’s not that simple… . I’ve set out some initial thoughts below but I don’t mean to present them as definitive. Instead, I’ve pitched my thoughts as questions for consideration.

Legal risk

So, what might be wrong with this in legal terms?

One can certainly argue that the invocation of guideline 18 of the WordPress Plugin Directory Guidelines is unconvincing but I’m not going to dwell on that because, at the end of the day, MM controls WordPress.org and so, arguably, has the power to remove and replace a plugin if he wants to (subject perhaps to promissory estoppel arguments to the contrary but I’m not sure how strong/weak they’d be under US law). However, that power and how it’s exercised has its limits, because applicable laws still apply.

These are the questions I would be asking if I were the owner of a plugin that suffered this fate:

1. Is this actually a ‘fork’ and, if not, what might the consequences of that be?

If a repository operator takes a third party’s existing codebase which that third party put in the repository and is actively maintaining and developing, and takes control of and changes that actual codebase rather than duplicating it in a separate repository (or sub-repository) and then modifying it, is that a true fork and, if not, is it permitted by the GPL?

The GPL allows you to “modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work” as long as certain conditions are met. Whilst MM/WordPress.org permitted WP Engine and earlier owners of ACF to have ACF hosted on WordPress.org, arguably that did not make the version on WordPress.org ‘MM’s copy’ or ‘WordPress.org’s copy’. Arguably it was the official third party source. If that is right, has MM/WordPress.org ‘modified their own copy’? I cannot answer this decisively as there are some technical details I’m unaware of and arguments can be made both ways, but you see the point right? If MM/WordPress.org have not modified their own copy, then questions of copyright infringement may arise. I emphasise, though, that I cannot express a decisive view on this issue and, if there is a risk here, there’s probably a way for MM/WordPress.org to mitigate it.

2. Is trademark infringement occurring?

‘Advanced Custom Fields’ and ‘ACF’ are clearly trademarks. They don’t have to be registered to be protected by law. WP Engine has registrations pending but the marks still have legal protection in the interim. Whilst MM has changed the plugin name to SCF (certainly a required move), ‘ACF’ and ‘advanced-custom-fields’ are still being used throughout the SCF listing and in the downloaded source code. Whether this would be enough to constitute trademark infringement would likely depend on whether the use of the marks is occurring ‘in commerce’ (taking all the context into account, arguably it is despite the fact that SCF is a free plugin ) and is (to summarise) ‘likely to cause confusion, or to cause mistake …’. I don’t have enough information to comment further on that.

One might note in this context, though, that guideline 17 in the Detailed Plugin Guidelines states:

17. Plugins must respect trademarks, copyrights, and project names.

The use of trademarks or other projects as the sole or initial term of a plugin slug is prohibited unless proof of legal ownership/representation can be confirmed. For example, the WordPress Foundation has trademarked the term “WordPress” and it is a violation to use “wordpress” in a domain name. This policy extends to plugin slugs, and we will not permit a slug to begin with another product’s term.

For example only employees of Super Sandbox should use the slug “super-sandbox,” or their brand in a context such as “Super Sandbox Dancing Sloths.” Non-employees should use a format such as “Dancing Sloths for Superbox” instead to avoid potentially misleading users into believing the plugin was developed by Super Sandbox. Similarly, if you don’t represent the “MellowYellowSandbox.js” project, it’s inappropriate to use that as the name of your plugin.

Original branding is recommended as it not only helps to avoid confusion, but is more memorable to the user.

At the moment, SCF is using the ACF slug: 


3. Has there been a breach of copyright in the ACF plugin listing?

If, as it appears, the SCF plugin listing is the same as the prior ACF listing but with names and acronyms switched, there is an argument (how strong I’m not sure) that WP Engine’s copyright in the listing (itself an original copyright literary work) has been infringed. There are no terms of use on WordPress.org that permit this to occur. A plugin owner clearly grants an implied licence to the operators of WordPress.org to use its listing content for the purposes of describing the plugin in the listing, but it is not clear that the operators can copy that listing content and use it more or less verbatim when making a purported ‘fork’.

The counter-argument is that the bulk of the plugin listing comes from the readme.txt file bundled with the plugin and that, the argument runs, is captured by the plugin’s GPL licensing and so can be reproduced.

I won’t seek to resolve those competing arguments here but I do note that the readme file content is only a subset of the content in the WordPress.org plugin listing and associated support forum. For example, none of the answers to the support requests over the years by the owners of ACF are covered by the GPL licence and there’s an argument that the implied licence to WordPress.org to publish them is limited to the support provided in connection with the ACF plugin itself and not a fork.

4. Misleading conduct in commerce?

The name given to the ‘fork’ (Secure Custom Fields), together with the first paragraph of the release post and a later statement in the post that the “update is as minimal as possible to fix the security issue”, might be considered by some as misleading. Automattic had (publicly)-notified a security issue with ACF which WP Engine promptly fixed. That fix was implemented before any announcement of the SCF ‘fork’, and the SCF changelog simply says “harden fix in 6.3.6.1 to cover $_REQUEST as well”. This, as I understand it, can only be described as minimal, and certainly not of any magnitude to warrant a fork.

Any argument that this has nothing to do with commerce would probably be weak, because the announcement post on WordPress.org states:

“Similar situations have happened before, but not at this scale. This is a rare and unusual situation brought on by WP Engine’s legal attacks, we do not anticipate this happening for other plugins.”

That paragraph seems to betray the real reason for what’s happening here. Security does not seem to be the driving reason. Rather, the fork stems from the fight with WP Engine which, in my view, is undeniably occurring in a commercial context.

Whether the security-related implication (assuming other sees that) would fall foul of applicable fair tradings laws is something for local lawyers to assess.

Chess anyone?

My final thought for now is that, to some extent, this feel likes the next move in a somewhat intense game of chess. As we know, chess is a game in which one looks many steps ahead to predict one’s opponent’s next moves. Litigation lawyers will know full well what one such next move might be, but MM/Automattic’s lawyers will already have predicted that… .