How to avoid being forked into oblivion by a more powerful contributor?

Question

As recently reported here:

Xamarin has forked Cocos2D-XNA, a 2D/3D game development framework, creating a cross-platform library that can be included in PCL projects.

However the founder of the project that was forked says:

The purpose of the MIT license is to unencumber your fair use. Not to encourage you to take software, rebrand it as your own, and then "take it in a new direction" as you say.

While not illegal, it is unethical.

It seems that the GitHub page of the new project doesn't even indicate that it's a fork in a typical GitHub manner, opting for an easily-removable History section instead (see bottom).

So my questions are:

1. Was Xamarin's action and the way the action was done ethical or not?
2. Is it possible to avoid such a situation if you are a single developer or a small unfunded group of developers?

I am hoping this could be either a wiki question or there will be some objective answers grounded on modern OSS ethics/philosophy.

Answer 1

Was Xamarin's action and the way the action was done ethical or not?

Well, let's ask an expert - The Open Source Initiative's listing of the MIT License itself, with the license quoted in its entirety:

The MIT License (MIT)

Copyright (c)

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

If anyone - individual or company - releases software/source code with an MIT license, it means that anyone else - individual or company can "deal in the Software without restriction". So long as the copyright notice stays intact, they are pretty much able to do as they please.

This is one of those cases when ethics and legality are pretty much exactly the same. If a person or group didn't understand the license or its implications then they failed to do their due diligence. The Open Source Initiative provides lots of other nice resources to help us understand licenses like the MIT variant. Let's look at a few clauses of their Open Source Definition:

1) Free Redistribution - The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.

3) Derived Works - The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.

5) No Discrimination Against Persons or Groups - The license must not discriminate against any person or group of persons.

6) No Discrimination Against Fields of Endeavor - The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

To my reading this seems all abundantly clear: releasing something as open source, especially with the MIT license, allows someone to freely take the software, change it, package it, and sell it to pretty much whoever they like, so long as they don't remove your copyright notice and claim it to be their own sole work.

As the author you are explicitly giving up the right to be picky and choosy. You don't get to decide who or what can benefit from your software or make use of it, and you don't get to decide why they are using it. You explicitly give up that right.

The idea is that you are contributing to the greater good by explicitly renouncing any legal rights you have to control and restrict use and change of what you have made. If Microsoft wants to fork your FluffBall project and sell it for $2k per seat as WindowsSpongeCake, they can. Wasn't letting people do whatever they want the whole point of your project in the first place?

Is it possible to avoid such a situation if you are a single developer or a small unfunded group of developers?

Kind of! First, use a license that's appropriate to you and your organization's goals and desires. If you don't want anyone to use it in a way you don't approve of, you probably shouldn't be releasing it as Open Source - and frankly you maybe shouldn't be releasing it at all! If you don't want anyone to use a derivative work (like a fork) on a commercial project you should probably go for a copyleft version of the GPL. If you want a noncommercial license you should probably get a copyright/license lawyer to advise, because this is often not considered "open source" software at all and there isn't any major pre-written license to support this case.

The issue with the Xamarin and Coco kerfuffle is not a matter of ethics or legality - it's about an internet fight between a few people who have a beef with each other. We're all human, it happens. It seems to be the result of being unable to collaborate/cooperate, likely due to a personality conflict or incompatible visions for how the project should be handled.

So the other way of defense is being open to collaboration and change, but understand that if it doesn't work out and visions diverge...well, that's the reason for the option to fork and have your own separate project.

It's very human and understandable for feelings of ownership and popularity to make software projects very, very complicated. But the goal of open source is to try to transcend that and allow the best software to be available freely to all.

Bottom-line, be clear about your goals when you are deciding a license, and understand its implications for your future control and direction of the project. If you just want to donate to the greater good, open source is the way to go. If you want to control your project more tightly and have ownership and at least a legal case if someone tries to market your project or absorb it into their own (in part or entirely), you'll need a different license and will probably need to sort it out with a lawyer.

Answer 2

Releasing a project under the MIT license is giving people permission to fork the project. Part of the philosophy behind free software is to give users and developers the right to use, modify, and release the software in ways that wouldn't normally be allowed. If you don't want people to do this, then don't use the MIT license. You can't really complain when people use code under the terms of the license that you've given them.

Forks are a fairly normal thing to happen in the free software community. It looks like the fork's developers tried to contribute to the original project, and didn't agree so they contributed to their own project instead. Free software encourages this so that developers are not prevented from modifying software because the owners don't like their changes.

Also, by releasing something under a free software license, you're benefiting from other people's contributions, contributions you might not have received if it was under a different license. If you accept contributions under a license, you should respect the terms of the license yourself.

One way to maintain control over an official version is to rely on things like trademarks. Mozilla Corporation for example has a trademark on Firefox which allows them to dictate what people can do with Firefox even though it's open source (See Iceweasel for the fork of this).

Other licenses like LGPL still allow forks, but keep the code open. This way, you can at least incorporate any changes from the fork into your original project, and benefit from the development on the fork. LGPL code can use any MIT licensed code so if you wanted more control over the project, you could use LGPL instead.

Answer 3

I wouldn't call it unethical. I would call it unsportsmanlike. There's an unwritten expectation that you will give a good faith effort to improve the original version before deciding to fork, and it seems the original author feels that good faith effort wasn't made.

That being said, the best way to avoid your software being forked is to be responsive to customer requests in such a way that your software has as broad an appeal as possible. No one is going to give support to a fork if they know the original is superior. Aside from that, your only protection is to change the licensing terms.

Answer 4

• Was Xamarin's action and the way the action was done ethical or not?

A lot of people are conflating the legal and ethical situation. The X11 license allows anyone to "use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so", so this is definitely legal.

Ethically though, it's more complicated. In open source communities, it's generally considered preferable to improve the original software rather than create a fork. In the link you gave, Miguel de Icaza says:

As you know, we contributed extensively to Cocos2D-XNA and we just could not continue to work together.

Once we reached a point where we could not collaborate together, I decided to take the project in the direction that I desired at the expense of backwards compatibility.

It's not clear why they "could not collaborate together", but it sounds like Xamarin made a reasonable effort to work on the original project before deciding to fork it.

• Is it possible to avoid such a situation if you are a single developer or a small unfunded group of developers?

Legally, you could choose to use a license that doesn't allow forking by disallowing redistribution of the source code (at this point, it wouldn't be "free software"). Another option is to leave the code unencumbered but don't allow redistribution of static assets like images or non-code text (some games have licenses like this).

Socially, you can prevent forking by:

• Making it easy for people to contribute changes to your project.
• Reviewing patches quickly.
• Allowing changes that don't directly benefit you.
• Being polite. A surprising number of forks are due to contributors not being willing to work with each other anymore.

Forking software is a lot of work, and most sane people won't do that if they have an easier option. If they have no other choice, then preventing them from forking your code will just force them to either fork someone else's code or rewrite your software from scratch. It might slow them down, but it won't really help you much.

Also, using a more restrictive license will make some people less likely to contribute. Xamarin apparently "contributed extensively to Cocos2D-XNA", and I doubt they would have done that if the license didn't allow them to redistribute it.

Answer 5

What Xamarin did is legal and ethical... almost.

Let's have a look at the commit fixup of the license and misc typo fixes in the readme:

LicenseAndCredit.txt (diff)

-Copyright (c) 2010-2012 cocos2d-x.org
-
-Copyright (c) 2008-2010 Ricardo Quesada
-Copyright (c) 2011      Zynga Inc.
-Copyright (c) 2011-2012 openxlive.com
-Copyright (c) 2012      Totally Evil Entertainment, LLC
-Copyright (c) 2012      Gena Minchuk
-Copyright 2012 Xamarin Inc
+Copyright (c) The Cocos2D-XNA Team

There's only one requirement in the whole MIT License:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

And Xamarin did exactly the forbidden thing. Xamarin may think that it makes the license "prettier" to have less copyright notices at the top, but they don't have permission (legal or ethical) to remove the "redundancy".

Of course, if they fix the license file, they will again be in the legal area. The original library's author may not agree, but he made the choice of the license and he can't blame anyone that they did what the license explicitly permits.

Answer 6

It would be shady to allow people to draw incorrect conclusions about the authorship of whatever code the fork ships, even if the legalities are covered by providing the necessary notices and revision history for anyone who chooses to look closely. So maybe Xamarin's presentation is unethical, maybe it isn't, but I think that's the basis on which to judge it: does it mislead?

The license lays down permission to use the code and a requirement to include relevant copyright notices with copies of the code. That's all at quite a low level. It doesn't discuss how you should publicly summarize who contributed what, but just because that's outside the scope of the license and not part of the legal agreement doesn't mean anything goes ethically. Ethics vary, but giving honest credit where due is quite a widely-held principle so it's easy to see why failing to do so will give offence.

Like everyone says there's no intention in the MIT license to prevent forks, so that's not unethical of itself. If "rebrand it as your own" is code for "make public claims of credit you don't deserve", then sure that would be unethical if true.

As for preventing it happening to you: if you want to avoid the situation of someone else insinuating that your code is theirs, then you need a loud voice when claiming credit. If you want to avoid the situation of someone creating a fork of your code that might eventually prove more popular than your original (either due to their greater resources or just their focussing on the "right" user needs) then I think you're out of luck in OSS. You can't just decide to be right if another group wants different features in the software from what you want, and if (in the view of users) you're wrong then you should lose regardless of being there first. This is a consequence of the primary open source principle (or properly, free software principle) that the author doesn't control the software, the people who run it do.

Answer 7

An expansion of the trademark topic:

At the Apache Software Foundation, all the code is AL. And, as with the BSD license under discussion here, it's perfectly clear that the AL permits forks. Period. End of discussion. In fact, as discussed in other answers, all true open source licenses permit forks. All they control is the license / usage of the forked code.

The Apache foundation has chosen to register and defend trademarks. If some entity other than a foundation project forks, oh, 'Apache Tomcat', they are fine ... but they cannot call it Apache Tomcat, and, when we can defend the mark, they cannot call it Tomcat.

The problem here is that trademarks are not for the faint of heart. If you are a small group of people, with no legal structure and no funding, you cannot, practically, use trademark law to protect your name.

In the end, this sort of thing is one of the reasons for the various foundations out there.

From an ethical standpoint, well, if there's an internal fission between contributors, who is to say who 'deserves' to keep the name? If, on the other hand, an outsider forks, it's probably not the most ethical thing in the world to leave the name unchanged. It's not a heinous act, either.

Github is full of forks. Sometimes people do change the name, or the Java package, or whatever -- particularly if they want to publish to Maven central. Often they don't, and users are left navigating a maze of confusion. It's not ideal, but that's the breaks with anarchy.