I recently discovered the Github repository page hosting the forked version of WP Migrate DB Pro is offline due to a DMCA Takedown request. According to the request, the offending plugin contained a README.md file that used copyrighted content from Delicious Brains Inc. without their permission.

The Github user slang800 has forked our repository found at https://github.com/bradt/wp-migrate-db. This action alone would have been fine, but he has also added a new file named README.md containing content copied from our website that we did not give him permission to use.

I confirmed with Touesnard that the DMCA Takedown notice had nothing to do with the code hosted on the repository. Although several commercial themes and plugins are licensed under the GPL, it doesn’t mean you can violate a company’s trademark or infringe on their copyrights. If you’re going to fork a commercial WordPress product and redistribute it, here are a few tips to avoid trouble.

Rename it. Keeping the same product name confuses users

Maintain the copyright of the original author

Do not use trademarked images, logos, etc.

Create your own set of documentation and support system

Before forking, try working with the developer to have your features or fixes integrated into the product. Most of the time, they’ll gladly work with you to have a specific feature added, especially if there’s already a patch. If your WordPress products are GPL licensed, I’d like to know how you’ve handled trademark and copyright infringement in the comments. What advice do you have for other business owners?

Would you like to write for WP Tavern? We are always accepting guest posts from the community and are looking for new contributors. Get in touch with us and let's discuss your ideas.

Like this:

Related

35 Comments

Sorry, a bit confused:
Headline speaks of “WP Migrate DB Pro”, but mentioned repository seems to be from the free version “only”. As I read from the post, the DMCA takedown was “only” regarding a readme.md, not the whole plugin itself — forking a free plugin (which is GPL v2, plus from .org) seems fully ok – or not?

Forking the plugin is ok, no issue there, even if it’s a fork of a commercial version. The issue is violating the copyright of the original author by having content in the readme file they didn’t have permission to use. So, the moral of the story here is that forking is ok but follow a few simple steps to avoid legal trouble, especially copyright and trademark infringement.

…And now that that’s cleaned up, we’re back: https://github.com/slang800/wp-sync-db! I had to rename the plugin because Delicious Brains trademarked the name “WP Migrate DB” on May 2nd 2014. But the new name isn’t that bad, and the old url will redirect to the new repo properly. I’m probably going to have to take some time this week to comb through the repo and remove any lingering uses of the old name, but I think I got the vast majority with a find/replace.

Oh, also: the Bitbucket repo is removed because that had the old name on it and Bitbucket just isn’t fun to use.

Since they redacted the section about what specific infringements are present, you can’t adequately counter-claim, I believe. I would ask GitHub how that redaction works, where the redaction came from, and what the redacted information was.

Actually, today Brad sent me an email asking me to do exactly that: ‘remove all instances of “WP Migrate DB” in the code and in any other files in your public releases on Github, Bitbucket, or elsewhere’. However, I’m not totally sure if I need to do that because the code is covered under GPLv2 so I should be able to redistribute it as-is.

Anyway, I’m waiting for a reply from the FSF… Hopefully they can help me figure this out.

You are mixing two entirely different issues. The GPL and Trademarks. They aren’t one and the same. The GPL does not give you the right to utilize someone else’s trademark as you see fit. PERIOD.

Let’s use a real world GPL example that has already set a precedence but it certainly isn’t the only one. Red Hat.

The best and easiest example of this to understand an be found on the Wikipedia page that discussed Red Hat Enterprise Linux Derivatives and discusses exactly this. Redistribution of a GPL product and the Trademark implications.

“To avoid misrepresentation of Red Hat’s trademark, material in the original distribution covered by the trademark must be stripped off or removed from the redistribution.”

GPL != Trademark

I’ll give you a good example of the reverse. Misrepresentation of a FREE GPL product that would trigger having the Trademark holder seeking a cease and desist in order to have it taken down: WordPress

If someone setup a site to sell WordPress, simply sell the free WordPress distribution as a download, and it gained traction through adword links, etc. Do you not think the WordPress Foundation would do something about it to avoid causing confusion in the marketplace and hurting users by someone selling the WordPress distribution and using the WordPress trademark to do so? If they didn’t, they’d risk losing their trademark because enforcing your trademark is extremely important to maintaing legal rights to the trademark.

You should take a look at the WordPress Foundations page specifically on it’s trademark which can be found here:

Pay close attention to the part about use “WordPress” in the product name which i’m quoting from here:

“Similarly, a business related to WordPress themes can describe itself as “XYZ Themes, the world’s best WordPress themes,” but cannot call itself “The WordPress Theme Portal.””

The same applies to using the trademark in code. It’s no different.

The GPL gives you the right to use the code how you see fit. It doesn’t give you the right to use another individuals Trademark how you see fit.

All you had to do is remove some text from the README file as requested and Brad would have granted you the approval to do what you were doing. You chose not to do so and instead kicked and screamed “GPL!”. What you should do is instead read up on Trademark law.

They are not one and the same. Unfortunately this is a common misconception within the WordPress community due to the fact people see “GPL” and assume they can do whatever the hell they want. And they can. They just can’t do whatever they hell they want with someone else’s brand and trademark.

Now the easy removal of text from the README file just became much more painful for you. Now you have to strip the trademark from the code entirely.

In regards to the source code instances, how does CentOS (before it was bought by RedHat) handle it? To me, that would be a better vector than Firefox/Ice Weasle since RHES is GPL v2 and Firefox has its own license.

I can see removing references to the comments, branding and other information, but I’m unsure if there is any established case-law on trademark for a name in a call or function. In that case, I’d also have to assume that there was a trademark for all parts of the name (all capitalizations and spacings). Moreover, if the function call is something like wp_migrate and not wp_migrate_pro_db, I’d argue that the trademark wouldn’t even apply unless there was a separate trademark for wp_migrate (which frankly, I’d hope wouldn’t be granted because that is incredibly vague, plenty of people could “infringe” without even knowing it).

My guess is that it’s not really the content of the readme they are upset about. It’s just an excuse to have the plugin taken down. Having an easily available and free version of their pro plugin available has the potential to affect their sales.

Yep – I was originally going to go through the whole counter-notification process, but I missed the 14 day deadline because I’ve been busy moving to NYC. So, I’m just going to remove the part of the readme that I think they are complaining about and put the repo back up.

Jeff, the statement “Before forking, try working with the developer to have your features or fixes integrated into the product” is incorrect. Forking a repository on GitHub is the FIRST STEP towards having your feature or fix integrated into a product. A developer forks a repository, makes changes, and submits a “pull request” to the original owner to have those changes incorporated into the original repository.

In all cases, you need to properly determine what is GPL code, and what is non-GPL assets, before you fork anything. Look at Debian’s version of Firefox, IceWeasel, because while the Firefox code is GPL — the Firefox name, logo, and trade dress are most certainly not.

Your fork should remove sample content if its unique, it should remove all art assets that you don’t have a license to use and put placeholders or GPL/CC/PD images in their place, and it should have the documentation rewritten (preferably in a clean room environment without tainting from original copyrighted works) so that if someone DMCAs you, you can respond to the complaint with your assertion on why your project does not infringe in their IP and they can pound sand.

Nathan, you lead me to think of an interesting question. When a user presses the “Fork” button on GitHub, a complete clone of the repository is created, including both open-source and non-open-source files. An ethical user would immediately remove copyrighted material and commit. However, the copyrighted material would still be present in the original version of fork (Git saves all previous versions). Would the copyright holder be able to enforce a DMCA notice based on the presence of copyrighted material in an older commit?

This is a good question, and unfortunately one I don’t have the answer to. However, in my mind, if I saw my intellectual property still available by simply looking at previous commits, then it would still be published and a violation.

I had a good conversation with both Joost DeValk and Carl Hancock last night on Twitter about GPL, Trademarks, and how they go about enforcing them. Joost says he has a lawyer that sends about 20+ DMCA/Cease and Decist notices a month to infringes.

Although I’m sympathetic to the original developer, I think it is worth calling a spade a spade: this was a passive aggressive way to get the plugin removed. Rather than hiding behind the Readme, he should have just done what Joost does.

That said, I also think that this situation is an important reminder that the GPL works both ways. Removing/replacing all references to WP Migrate Pro — even at the code level (and see above comment, I’m not actually sure that’s required, if follow whatever CentOS and Scientific Linux do), is a simple regular expression or two. A DMCA can’t change that.

Part of releasing under the GPL means having to deal with stuff like this. For good and for bad. I’m sympathetic to a point, but if you choose to base your business on something that is licensed on the GPL, you better be prepared for this to happen.

The only real way to pseudo-avoid stuff like this is to make part of the plugin a server-side component — and I don’t just mean a validation check, I mean some of the code that is required for the plugin to run would have to exist on a server. That wouldn’t really work well in this case – since local databases are part of the target audience. More to the point, if you spend so much time obfuscating your code so that others can’t “steal” it, you might want to question why you’re building a GPL plugin anyway. But that’s just me.

I just get annoyed when I see some members of the community (not talking about Carl or Joost in this case) become GPL zealots until it makes things commercially uncomfortable. All licenses have positive and negative consequences. If a person can’t accept that, maybe they shouldn’t be trying to sell something that is GPL.

Thanks for the thoughtful insights. I’m wondering which do you think is better — and for whom? — 1) putting trademarked names throughout your code so trademark law supersedes the GPL and essentially makes the code more proprietary or 2) creating software that won’t work full, or for long, or at all without a connection to a remote, server-side application? Plus, neither of these methods is immune to being defeated.

Actually, they’ve always been public (there’s a link in the article to the takedown notice). Today GitHub made a ton of other improvements to its DMCA process, like giving a warning before the takedown, and not taking down forks.