Preventing people from forking and profiting over minor changes

Question

Twinone App Locker is an Android app. It used to be open-source, released under an Apache 2 License. It was ad-supported.

People forked it. If I understand correctly, they tended not to make any real improvements to their forks. All they had to do was change the name, change the icon, and the AdMob publisher ID. Then they could put their fork up on the Google Play store and make money.

Frustrated, Twinone moved the app locker to a source-viewable-only model and eventually to a closed-source model.

1. Is there a way that we can prevent lazy opportunists from doing the same scummy trick to us that they did to Twinone?

2. (Optional:) In practice, if you email the Google Play store support desk, and you ask them to take the fork down — will they?

Answer 1

When you release software as open source, it's your intention that others can take it and do whatever they want with it — either as copyleft (where they must do so under the same license) or as permissive software (where they can choose a different license if they want to).

Taking the software, changing it (for example, by taking out ads) and sharing it further is the thing you want to happen; otherwise, why are you making it open source?

If you believe that taking software, changing it so that more people want to use it, and re-distributing it is scummy, then it makes me wonder why you want to do open source in the first place. It's working as intended. If you don't want that happening, the solution is not to publish open source (and there is nothing inherently wrong with that).

It seems doubtful Google will take action against people doing things you chose to give them express permission for in the first place.

Answer 2

"Ad supported" is a business model which simply doesn't work for Open Source because anyone can just disable the ads and redistribute the work. If you want to monetize open source software, you need to look for a different approach.

For more details, I recommend the question "How can large open source projects be monetized?".

However, most of these business models do not fit well into the app-store ecosystem. What you can try, however, is a pay-what-you-want business model. Offer your app gratis, but ask people to pay you if they want to support your work. Either through in-app purchases (which don't actually do anything) or by offering differently priced versions which are all functionally identical. Pay-what-you-want does work on the consumer market, as can be seen with the very successful Humble Bundle game bundles (although it is not "purely" pay-what-you-want with their "pay more than average to also get X" and "pay more than $n.nn to also get Y" gimmicks).

Should someone try to copy that model and funnel these donations to themselves while claiming that it supports the original developers (which it does not), you might want to consult a lawyer if you can press fraud charges.

Answer 3

1. If it's open source, no. Even if it were closed source you couldn't do anything about people re-implementing a clone assuming they did it cleanly.

2. A company I worked for contacted Google and had an app taken down though the circumstances were a bit different. In this case the other app was just a wrapped version of the website.

I would think that if the branding were changed then there's no basis for the claim.

On a side note, I used to do tech support for Google Play stuff. It's just a bunch of kids in a call center. You'd need to find the contact info for the legal department.

Answer 4

The other answers here are great, but just to more directly answer your questions:

Is there a way that we can prevent lazy opportunists from doing the same scummy trick to us that they did to Twinone?

You mentioned that they used the Apache 2.0 license. In this case, not much you can do. But what might help is to use the GNU GPLv3 instead, so you're still opening up your code, but you're forcing everyone who takes your code to do the same thing as well. Adding this requirement might be a deterrent, or at least aid in helping the general public become aware that it's a cheap knock-off of something else.

(Optional:) In practice, if you email the Google Play store support desk, and you ask them to take the fork down — will they?

I think you'd need to contact their legal department. But, to directly answer your question, as long as the knock-off folks complied with your license requirements, then there's nothing you can do. However, by using the GPL, due to the strong copyleft requirements, you're more likely to create a legal case for you to pursue them because there are more requirements to the license, and the odds of them missing one or getting one wrong and thus placing themselves in non-compliance are increased.

I'm not promoting the GPL as a non-commercial license by the way. I'm simply saying that the strong requirements might aide in giving a degree of control in special circumstances. I believe this business model was flawed regardless of license, but others have already touched on this.

At the end of the day, you need to understand that people are going to take your stuff and run with it, especially if you've created something very useful. That's kind of the whole point. Will some people be ungrateful? Of course they will be, but unfortunately I don't know of any legal case where a "you must have good manners" clause was ever enforceable. :)

Answer 5

You can't prevent it while remaining open-source. In general this can be seen as beneficial - it means popular projects can be maintained when the original authors are no longer active (loose interest, get hit by a buss... etc) - or if its poorly maintained, others can take over.

However re-releasing with insubstantial modifications to take users away from the original authors is a real concern too. Our project experienced this, here are some suggestion.

• Strong branding
  (logo, documentation that refers to the project by name)
  They can re-brand of course, but you retain your trademark.
• Periodic releases
  This depends on your own pace of development and on how involved your software is - of course don't do releases for the sake of it. However rolling all improvements into a release periodically means your version will be the best one, and others who are releasing your work will have to play catch-up, with some delay before theirs is up to date (depending on how dedicated they are...).
• Include Value Added Data/Assets (if appropriate)
  Again this depends a lot on the kind of project, but including assets (documentation, tutorials, sample data...) adds value to your distribution, giving users a reason to choose your version over others - where someone else isn't allowed to simply re-purpose your version without removing these assets.
  (this has some potential to be mis-used too since it moves in the direction of devaluing the all open-version, so wary of recommending this. The application should remain usable without the added content at least).
• Make public statements that their version is a re-release without any real improvements, not helping original developers continue with further work, ideally so on-line searches for their name links to such statements.

---

All that said, its understandable that a small application on an app-store may be difficult to make users care they're using the version released by the original author (depends on how invested they are in the application).