Reminder: Respecting Trademarks Includes Icons and Banners

This is a reminder that one of our guidelines is respecting trademarks and brands.

tl;dr

Using someone else’s trademarked logo in your plugin logo or banner is a trademark violation, and they have the right to have us remove your plugin at any time.

Explanation

Normally trademark situations come up when you submit a plugin like Facerange Messenger, but you don’t happen to work for Facerange. We change your slug from facerange-messenger to messenger-for-facerange (or something to that effect) and ask you to rename the plugin to “Messenger for Facerange”. Another common instance is when we have to explain bobo-facerange-messenger.com is a violation of their trademark use, and you need to rename your domain.

As of late, companies have begun enforcing logo usage as well. Originally they were just picky about the icon or banner being only their logo, but now they’ve moved on to the use at all. What this means to you is simple: Don’t use someone else’s logo in your plugin’s icon or banner. Period.

If you don’t have the legal rights to use it, don’t. If you’re not sure if you do, assume you don’t. If you lose the legal right (like no longer being a part of PayFriend’s trusted developer program), you must immediately remove their logo from your plugin’s public facing pages.

FAQ

What happens if a company complains?

You will receive a warning via email that a complaint has been filed and you are to correct the icon and/or banner immediately.

How long do I have to comply?

0-days. Technically you’re already a violation. They don’t have to let us give you a chance to come correct, so we would appreciate it being done within 48 hours.

Do I have to push a new version of my code to do this?

Nope. Just fix the images in your assets folder.

Addendum by Otto: This includes screenshots. If you have somebody else’s logos in your plugin itself, or displayed on your service, then you might want to consider getting those removed as well.

What do I do if a company asks me to change my icon/banner?

Change it. Seriously, it’s not worth it. Make your own unique and distinct logo for your plugin. It’ll make you more memorable in the long run.

Do I have to change my display name as well?

Yes, you do. Remember: Don’t start your display name with someone else’s trademark/copyright/commonly known name. If it’s not your name, it’s not a good idea.

Isn’t this contrary to the GPL and open source?

No. Licences like GPLv2 are separate entities, and in fact the GNU supports the use of copyright in code. As for open source, it’s not above the law. Check out FOSSMarks for more information and as always, contact a lawyer with your legal questions.

Addendum by Otto: Also note that Trademark and Copyright are two entirely different things. There is no “licensing” for trademarked items. The GPL and any other license will not apply. Basically, if something is trademarked, then you need to get explicit permission to use it, in writing, or you just don’t use it.

I think it’s fair use. Will you let me keep the icon while I fight them?

Alas, no. We have to consider the directory as a whole and it’s over 60k plugins. The risk for us is too high, and we will side with the legal request.

Addendum by Otto: There is no concept of “fair use” in trademark law. Don’t use other people’s trademarks. Period.

What about existing plugins that you let violate trademarks in the slugs?

That’s because we do not have the technical ability to rename a slug without breaking it for all users. They’d be abandoned. And you can’t automatically migrate users from one plugin to another, so because of that limitation, most companies have permitted us to retain plugins that violate their trademark in the slug. Some have not, and we’ve been forced to close those plugins.

Since the logo and display name can be safely changed, it’s a different matter.

Someone else is violating too! Why didn’t you shut them down?

We email people in batches. You’re welcome to report fellow plugin devs who are violating the guideline, but the odds are we’ve already been in contact with them (or will be shortly). You’re not being singled out, we just have a lot of plugins to work through and we take breaks. Keep in mind, if it’s not YOUR trademark, we generally just warn.

Someone’s using my trademark in their icon/banner, how do I get them to stop?

Contact them first and point to this post (and the 17th guideline) and just ask them NICELY to please change it. If they blow you off or don’t respond in a reasonable time (like 2 weeks), you can email us at plugins@wordpress.org and we’ll follow up.

#guidelines #trademarks

Guideline Update: Clarifications to trialware and human readability

Two situations have arisen where we feel it would be best to clarify the guidelines a little.

Guideline 4: Human Readability

We strongly feel that one of the strengths of open source is the ability to review, observe, and adapt code. By maintaining a public directory of freely available code, we encourage and welcome future developers to engage with WordPress and push it forward.

However with the advent of larger and larger plugins using more complex libraries, people are making proper use of build tools (such as npm) to generate their distributed production code. In order to balance the need to keep plugin sizes smaller while still encouraging open source development, we will be requiring plugins to make the source code to any compressed files available.

For example, if you’ve made a Gutenberg plugin and used npm and webpack to compress and minify it, you must either include the source code within the published plugin or provide access to a public maintained source that can be reviewed, studied, and yes, forked.

We strongly recommend you include directions on the use of any build tools to encourage future developers.

Guideline 5: Trialware

Historically we’ve not permitted test or trial plugins that arbitrarily limit usage, and then upsell, to be included in the directory. The primary reason we don’t permit this is that locking people down to a specific number of (say) images is foolish and a pointless endeavour. People can, and will, fork your locked plugin and unlock it, as well they should. That said, we’ve always allowed (and will continue to) plugins that offer a free limited service (think Akismet for a good example).

Related to this are ‘sandbox’ plugins, used for testing. For example, if your plugin only accessed the Instagram Sandbox API, and included upsells about a pro version that allowed full access, you would be a trial plugin. Since they are easily abused as turning the directory into a marketplace, we have modified the 5th guideline to address this more clearly.

#guidelines

WP 4.9.6, Privacy, Hooks, and You

WordPress 4.9.6 has been released. This was a focused release, a little different than other minor releases, in that it adds a system for a privacy policy to WordPress. While the only change to plugins has been our requirement that you not claim (or imply) 100% compliance in anything, the changes to privacy awareness are far reaching.

The tl;dr of the whole post is “You’re going to need to consider the impact of data collection in your plugins, even if you don’t collect anything.” So yes, I know it’s long, but please read the whole thing.

NOTE: We are not lawyers. We cannot tell you if what your plugin is doing is going to break a law. Please don’t ask us to try and figure that out for you. The purpose of this post is to make you aware of what’s going on, and give you a place to start with making your plugins better.

Does This Impact You?

Yes. This impacts everyone. Plugins are used internationally which means you actually do have to be aware of the world, Net Neutrality shenanigans aside. Your plugin could, in fact, cause someone to get in legal trouble. While that is technically their responsibility, you should be as aware as possible of the implications of your code and how it’s used.

Ask yourself this: Does your plugin…

  • … write any private data of users (registered or visitors) to the database?
  • … send any data to remote servers (i.e. act as a service or embed content)?
  • … edit the comments form in any way?

If yes, then this absolutely, without a doubt, impacts your plugins.

If no, then this may still impact you, so please keep reading, because people are going to ask you about this.

Privacy Means Disclosure

If you’re a service, like you pull a library from a remote server, then you have to tell people that you pull data remotely. This has always been a policy, so if you’re not disclosing this now, please go fix it right away.  But you also need to tell people the obvious things, like embedding content via your plugin means the site administrator is consenting to the embed terms of that service.

An example for you. Let’s say you have a plugin that embeds YouTube playlists. Your plugin should be clear “This plugin embeds YouTube Playlists.” We also recommend you include a link to YouTube’s privacy doc. It’s alright to say “By using the embed features in this plugin, you will be agreeing to YouTube’s Terms of Use.”

The same holds true now for data stored locally. If your plugin stores browser data of visitors, then yes, you need to document and disclose this. You can’t force site admins to publicize this in turn, but by making sure they know, you’re helping them determine what their own reasonable disclosure should be.

Some Code To Help

WordPress has gone the extra step to make it easier to make a privacy page and hook into it, both for users and developers. The moving parts you need to be aware of are the tool for users to request an export of all the stored data associated with them on the site. There’s also a tool for users to request erasure of that same data. Both tools include admin workflows to fulfill those requests. And there’s one to suggest what kind of text should be on someone’s site.

The handbooks have been updated to help you out here:

Also, while this is a little more aimed at theme developers, if your plugin happens to mess around with comments, please read the changes that affect themes, as there is going to be a new checkbox for comments.

Update Your Plugins

The tl;dr of all this is that plugins should…

  • … disclose what user/visitor information it saves in the readme;
  • … hook into the privacy page creator to inform people there too;
  • … provide a way to export said information;

We aren’t (currently) changing any policy to require all this. At the same time, I strongly recommend at the bare minimum everyone put a privacy policy in your readme. Even if you don’t save any data and you don’t send anything, make a Privacy Policy anyway and tell people that.

Why? At the very least, it may stop people from asking you “Is this plugin collecting any data?” which saves you time. But more importantly, this is to protect yourself. After all, if people come through with a 1-star review that you caused them to become non-compliant because you didn’t disclose local data collection, well, that would be a very justified review.

#core, #guidelines, #privacy

Legal Compliance Added to Guidelines

Guideline 9 (Developers and their plugins must not do anything illegal, dishonest, or morally offensive.) has been amended to include the following new prohibition:

  • implying that a plugin can create, provide, automate, or guarantee legal compliance

While the vast majority of plugins will never run into this issue, we want to explain why this change is necessary.

Over the years, by accident or intent, some developers have claimed their plugins can provide legal compliance, sometimes automatically, across various aspects of site administration. These areas have included security (e.g. FIOS, PCI/DSS), cookies and tracking (i.e. the “EU Cookie Law”), online shopping (VAT), privacy (GDPR), accessibility (ADA), copyright, and more.

Sadly, no plugin in and of itself can provide legal compliance. While a plugin can certainly assist in automating the steps on a compliance journey, or allow you to develop a workflow to solve the situation, they cannot protect a site administrator from mistakes or lack of compliance, nor can they protect site users from incorrect or incomplete legal compliance on the part of the web site.

In short, plugins are helpful tools along the legal compliance journey, but should never be presented as a solution, nor should they give users a false sense of security.

Because of that, going forward we will be attempting to prevent these types of claims in all plugins. These issues will be handled in the same way we try to make sure that people don’t use ‘official plugin’ without actually being official.

Plugins that are are currently at odds with this change, either by accident or intent, will be notified shortly and required to change their titles, descriptions, and/or readmes.

ETA: I made the FAQ public early to hopefully help you with any questions!

#guidelines, #notice

Keyword Stuffing is Spamming

In January 2017 we clarified what was meant by not spamming in the directory.

Since then, the language has been tweaked slightly, but the crux of the matter remains as follows: Public facing pages on WordPress.org (readmes) must not spam

To whit:

Public facing pages, including readmes and translation files, may not be used to spam. Spammy behavior includes (but is not limited to) unnecessary affiliate links, tags to competitors plugins, use of over 12 tags total, blackhat SEO, and keyword stuffing.

If you have a keyword or phrase repeated over 30 times in your plugin, you’re probably spamming. There are exceptions, especially when a term is a common word or you’re listing your shortcodes. However please be reasonable. If we see you using the same word 50 or more times in the readme, you’ll likely be receiving a warning.

Please take these warnings seriously. If you get asked to fix one plugin, we expect you (and ask you) to take care of any plugins we didn’t list as well. Be mature humans.

#guidelines

Guideline Update

The previously proposed changes have been merged into the plugin guidelines.

It’s important to note that I do not think this is a ‘complete’ or ‘finished’ project. The guidelines are imperfect, in part because it’s impossible to create a rule for every single possible variant of a possible conflict, but also because we cannot predict the future.

There are people who are unhappy we didn’t go far enough with certain guidelines — like not saying “you may have 3 links to your own products on your plugin admin pages.” Others are unhappy we’ve gone as far as we did in certain situations — such as the 9th guideline’s prohibition against harassment.

Accepting the imperfection of English, as well as the flaws built in to creating guidelines for such a large audience, many of whom do not speak English natively, has led to situations where we have to settle. These guidelines are not perfect. They are not complete. They will be constantly evolving and adapting as we try to please and protect the majority of developers and users.

I encourage all of you to help us write them better. You can email us at plugins@wordpress.org or make pull requests on the GitHub repository. While we may not accept all requests, I promise we do listen to and read every last one.

#guidelines

Reviewing the Guidelines – 2017

I do this regularly, but recently I received a comment that the guidelines were still too vague.

I need to stress that this is by intent. If we make guidelines like “You can only have 3 external links” then people will find ways to exploit that. However I do not think that guidelines are perfect. Which is why I’m proposing a minor update to them to address the following concerns:

  • Overall tense of guidelines made consistent
  • Update introduction for readability and unpack what we mean by keeping email updated
  • Explain the converse of 3
  • Put the important part of 5 on top
  • Add link to forum guidelines to 9
  • Add prohibition against harassment to anyone in WP
  • Clarify self-dismissible alerts are acceptable in 11
  • Changed tense of 12 and 13 to emphasize their importance
  • Grammar fix for title of 15
  • Fix reference to zips in 16 (upload now vs link to)
  • Reword title of 17 to explain that PLUGINS must honor…
  • Guideline 18 has received a full rewrite to clarify what rights we reserve and reiterate our promise to do this as fairly as possible.

You can see all the changes proposed here on GitHub

Please read the guidelines and leave comments or pull requests on Github. The plan is to make these live in January 2018 so please jump in and help! Thanks.

#announcement, #guidelines

Clarification of Guideline 8 – Executable Code and Installs

Since Jetpack announced it installs themes, a number of people have asked if this is a violation of the 8th guideline:

The plugin may not send executable code via third-party systems.

And in specific, these two items:

  • Serving updates or otherwise installing plugins, themes, or add-ons from servers other than WordPress.org’s
  • Installing premium versions of the same plugin

The short answer is no, it’s not, and yes, you could do this too.

The longer answer involves understanding the intent of this guideline, which initially was to prevent nefarious developers from using your installs as a botnet. In addition, it’s used to disallow plugins that exist only to install products from other locations, without actually being of use themselves (ie. marketplace only plugins). Finally it’s there to prevent someone silly from making a plugin that installs a collection of ‘cool plugins’ they found from GitHub and want to make easier to install. Which actually did happen once.

Plugins are expected to do ‘something’ to your site. A plugin that exists only to check a license and install a product, while incredibly useful, is not something we currently allow as a standalone product. This is why we allow plugins to have the in-situ code for updates that is used by their add-on plugins. The plugin we host has to use WordPress.org to update itself.

In addition, we do permit valid services to perform actions of installations onto sites, and have for a very long time. ManageWP, for example, has had this ability for quite a while. It provides a valid service, letting you manage multiple sites from their dashboard, and yes, install and update plugins. Going back to the example of a plugin that hosts the update code for it’s addons, the ‘service’ is the license you bought for the add-on plugin.

The trick here, and this is what is about to sound like hair splitting, is that it’s not the plugin UI on your site that does the install. In order for Manage WP and Jetpack to work, you have to go to your panel on their sites and install the items. If you wanted to make, say, my.servicename.com and let people log in, authenticate their sites, and from that interface use a JSON API to trigger an install, you absolutely, 100%, totally can.

To hit the major talking points:

  • Is Jetpack allowed to do this? Yes.
  • Are you allowed to do this? Yes.
  • Can you have your plugin install things? No.
  • Can your service install things onto a connected site? Yes.
  • Are you allowed to have a marketplace plugin? Not at this time.

I know this is frustrating to a lot of people. The reason it never came up before is no one asked us, and it isn’t our place to run your business or invent all the cool things. The guidelines are guidelines, and not laws or rules, to allow people to interpret them, and you’re always welcome to ask us if something’s okay or not. Or warn us if you’re about to do something you think might get the masses up in a dander.

#guidelines

Plugin Guideline Change

With the advent of the new directory being on the horizon, which allows us to easily hard-limit the number of plugin tags displayed, we have taken the time to change the guidelines.

While minor updates to the guidelines (with regard to spelling, grammar, etc) are common, major changes are rare and we are striving to be more transparent about them. Hence this post 🙂

Guideline 12 (readme links) clarified to cover spam and tags.

The guideline now reads as follows:

12. Public facing pages on WordPress.org (readmes) may not spam.

Public facing pages, including readmes and translation files, may not be used to spam. Spammy behavior includes (but is not limited to) unnecessary affiliate links, tags to competitors plugins, use of over 12 tags total, blackhat SEO, and keyword stuffing.

Links to directly required products, such as themes or other plugins required for the plugin’s use, are permitted within moderation. Similarly, related products may be used in tags but not competitors. If a plugin is a WooCommerce extension, it may use the tag ‘woocommerce.’ However if the plugin is an alternative to Akismet, it may not use that term as a tag. Repetitive use of a tag or specific term is considered to be keyword stuffing, and is not permitted.

Write your readmes for people, not bots.

In all cases, affiliate links must be disclosed and must directly link to the affiliate service, not a redirect or cloaked URL.

The previous version had the title of “… may not contain “sponsored” or “affiliate” links or third party advertisements” which was too specific and yet not direct enough as to what the intent was. We sincerely mean “Do not use your readme to spam.” Tag abuse, keyword stuffing, and blackhat SEO practices are all spamming.

While we still ask you to use no more than 12 tags, once we move to the new directory, we will simply not display the overage. You should clean that up now. The code is such that there will not be a way to grant exceptions. This is by intent. You don’t need 30 tags, folks.

Guideline 13 (formerly number of tags) now references using included libraries

Since we no longer needed a separate guideline for tags, we have completely changed this guideline to address an issue of security.

13. The plugin should make use of WordPress’ default libraries.

WordPress includes a number of useful libraries, such as jQuery, Atom Lib, SimplePie, PHPMailer, PHPass, and more. For security and stability reasons, plugins may not include those libraries in their own code, but instead must use the versions of those libraries packaged with WordPress.

For a list of all javascript libraries included in WordPress, please review Default Scripts Included and Registered by WordPress.

This issue has become incredibly important when you consider that roughly 90 plugins had to be contacted and closed regarding the use of PHPMailer. They had included the entire library and not kept it updated. I’m aware that we use a forked version of that specific library and I have raised core trac ticket #39714 to address this issue.

While we do not (yet) have a public page to list all 3rd party libraries, I’ve raised meta trac ticket #2431 to hopefully get this sanely documented.

#guidelines

Revised Guidelines Are Live

We soft-launched them on the 20th, just to make sure we didn’t mess anything up. Those last few spelling and grammar edits are killer. However yes, the guidelines, reviewed and revised by the community are now the official Plugin Developer Guidelines.

While I can hope they’re easily understood by all, I know that’s a fond wish. I’m leaving the repository on Github open for the time being, in order to allow people who spot late breaking issues to report them. If you do spot problems, please open an issue on the GitHub Repo or email plugins@wordpress.org and let us know.

In addition to just rewriting the guidelines, we took the time to codify the expectations of developers and cost of not abiding by the guidelines, as well as a reminder that we do remove plugins for security issues. We are doing our best to be transparent of what we expect from you and, in return, what you can expect from us.

Finally, THANK YOU. Everyone who helped write this, edit it, and who was patient understanding I was chasing down people to get their sign-off on what might be construed as massive changes, I greatly appreciate the time you spent on this project. It’s a massive undertaking to re-write guidelines in the public eye, in a way that won’t pull the rug out from anyone. Our goal was to clarify, not totally change, but also to address the needs of an ever changing technology.

Our goal, as always, remains to provide a safe place for all WordPress users – from the non-technical to the developer – to download plugins that are consistent with the goals of the WordPress project.

Please take the time to read the Detailed Plugin Guidelines.

#guidelines