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.

  • 27
    This is pretty much precisely what the GNU GPL is for, it forces forkers to let you merge their changes back in if they release them, giving you the improvements they made plus your own.
    – Vality
    Aug 20, 2014 at 22:50
  • 49
    The MIT license was originally written for the X Window System, and was written to allow companies to fork it and include it in their for-sale proprietary products. Aug 21, 2014 at 0:01
  • 5
    @Vality: It doesn't really matter whether something is under GPL or MIT license as far as back-merging is concerned, and the GPL has its own bunch of stings attached.
    – DevSolar
    Aug 21, 2014 at 7:05
  • 70
    "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." – Umm, actually, that's pretty much exactly what it is for. There is no such thing as "the MIT License". MIT uses a lot of different licenses. The license in question is the MIT X11 License, which was created specifically so that Unix vendors could integrate MIT X11 into their Unices, rebrand it, rewrite it, and take it in whatever direction they please. Aug 21, 2014 at 8:27
  • 10
    The ØMQ guide has an interesting story about pretty much exactly this scenario. The takeaway: "BSD makes most people see us as lunch. Closed source makes most people see us as enemies (do you like paying people for software?) GPL, however, makes most people, with the exception of the Patricks of the world, our allies." Aug 22, 2014 at 1:25

7 Answers 7


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.


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.

  • 38
    A nitpick about confusing language: using the GPL wouldn't restrict commercial use, but proprietary use. It's perfectly okay to sell copies of GPLed software for a profit. You just have to abide by the licence conditions when you do so. Aug 20, 2014 at 22:45
  • 5
    @BerndJendrissek: From a theoretical standpoint, you are right. But since you are required to give the sources to your software to your customer together with the binary, and the customer is free to re-distribute your software free of charge if he wishes (and there are plenty of people out there that would consider it their duty to do so), chances are pretty slim that you'd make many sales.
    – DevSolar
    Aug 21, 2014 at 7:09
  • 8
    @DevSolar - Although the source code is open and free for them to distribute, that does not mean that other non-code assets of the project are. With a game, the media, maps, scripts, etc., may be under a different license and it may not be legal for the customer to distribute them. For examples, see en.wikipedia.org/wiki/List_of_open-source_video_games
    – corvec
    Aug 21, 2014 at 17:56
  • 8
    @DevSolar: RMS himself sold GPL software for many years to finance the FSF. Aug 21, 2014 at 23:21
  • 7
    Lots of people sell GPL and other open source code. The whole Joomla ecosystem is built around that, so is Drupal's (in Joomla it is more for plug and play, for Drupal it is more for custom work but either way it is all GPL for sale). Many customers like having an invoice with the guarantees that come with a financial transaction, or they like the brand; look how many people pay for bottled water.
    – Elin
    Aug 22, 2014 at 0:47

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.

  • 1
    I would add the MPL as a noteworthy entry to the list of other licenses that still allow forks, but keep the code open.
    – mucaho
    Aug 22, 2014 at 1:03
  • Could you touch on how the BSD licenses relate to this?
    – jpmc26
    Aug 24, 2014 at 9:58
  • 2
    @jpmc26 - software licenses are legal documents, and I'm not a lawyer so for a definitive answer you need to consult a lawyer. However, the general consensus is that the BSD and MIT X11 licenses are similar in what they do. They are often referred to as the "academic licenses". Aug 25, 2014 at 11:05

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.

  • 14
    If you want to take the software in a different direction, i.e. if there are changes that would be an improvement for your goals but not accepted by the current maintainer, then making a fork is completely reasonable - that's how it generally happens. Changing the licensing terms afterward is easier said than done - unless you're the sole author or have agreement from everyone (not, say, 99%) who contributed, then you can't really do that.
    – Peteris
    Aug 21, 2014 at 6:54
  • 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.

  • 1
    You state that people are conflating the legal and ethical situation and even say that Ethically it's more complicated, but you don't give any reasons to back up those statements. In other words what do you see as an ethical complication in forking the software?
    – NotMe
    Aug 21, 2014 at 23:00
  • 1
    I think it is more social norms than ethics. It's not about moral/immoral it is about "this is how things are done." Overall @BrendanLong is right that forks are insane amounts of work and that's why most forks fail, many others end up being remerged when cooler heads prevail, and generally people try to avoid them.
    – Elin
    Aug 22, 2014 at 0:53
  • @ChrisLively The situation really is "complicated". What I was trying to do in the answer was point out that it could be unethical to fork a piece of software, but it sounds like Xamarin did the right thing in this case. The reasons it could be unethical to fork software are because being in charge of a significant open source project brings people a certain amount of respect and sometimes money (people tend to like getting support from a project's maintainers). Forking software will generally take some of that away and shouldn't be done just because you want to be the person in charge. Aug 22, 2014 at 14:19
  • 2
    For example, Cocos2D-XNA is likely to lose a lot of developers, since Xamarin's fork is suddenly getting a bunch of corporate backing and Cocos2D-XNA is losing theirs. It's completely logical that the maintainer is angry, since he created an open source project which is likely a dead-end at this point. On the other hand, Xamarin seems to have a good reason for doing it. Aug 22, 2014 at 14:26

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.

  • 3
    This ^ only one to go directly to the source. +1
    – Ryan
    Aug 21, 2014 at 23:34
  • 25
    That change doesn't seem to originate in the forked codebase. More importantly, it was by Jacob Anderson, Cocos2D-XNA team member and the one who objected to the fork. In contrast, Miguel de Icaza is the one who did the forking. Am I missing something? Or have you attributed the removals to the wrong person and project? Aug 22, 2014 at 0:48
  • 3
    That was Sept 2013? I'm confused about timing if that is part of a fork that just happened.
    – Elin
    Aug 22, 2014 at 1:04
  • 9
    @Elin Yeah, I think that diff is a red herring. As far as I can see, it wasn't done by anyone from Xamarin and it happened way before the fork. I don't think any bad faith is involved here, but this post certainly seems like a false accusation of wrongdoing. Aug 22, 2014 at 1:08
  • 5
    -1. That change was made in Cocos2D-XNA, before the fork occurred. Here's the identical change in Cocos2D-XNA. Aug 23, 2014 at 11:00

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.


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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.