132

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.

Den
  • 4,827
  • 2
  • 32
  • 48
  • http://meta.programmers.stackexchange.com/questions/6483/why-was-my-question-closed-or-down-voted/6491#6491 – gnat Aug 20 '14 at 20:43
  • 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 '14 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. – Alan Shutko Aug 21 '14 at 00: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 '14 at 07:05
  • @Vality you're thinking of the Qt licence, that says you can take code and what you like as long as you send changes to the original. The GPL just makes you show what you've done, that you could take - gut if they 'take it in a new direction' then it probably won't be much help to you. – gbjbaanb Aug 21 '14 at 07:54
  • 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. – Jörg W Mittag Aug 21 '14 at 08:27
  • 4
    @DevSolar It does matter, as the MIT does not require them to license you back the source code, the forker can only allow you to have binaries so you cannot use the changes they made. – Vality Aug 21 '14 at 09:04
  • @gbjbaanb I agree that the GPL does not stop someone completely reusing the code for a new purpose but it does mean that the forker cannot refuse to release the source code back to you and prevent you from implementing their patches. The Qt license has its use but it a little excessive for my tastes. However, fair point about Qt, that may help the OP, you might want to make that an answer as it does fix the OPs issue. – Vality Aug 21 '14 at 09:07
  • 4
    @Vality: Which didn't happen in this case, the source *is* there, so he can re-merge. -- If you don't get to **see** the source, it becomes bloody difficult to prove that a given project actually *is* a fork of your GPL'ed code. Certainly difficult enough to make the resulting "devteam vs. bigcorp" lawsuit beyond the reach of "devteam". But yes, you are right, the GPL forbids to *legally* fork-and-proprietary, while the MIT doesn't. – DevSolar Aug 21 '14 at 09:29
  • The GPL does not force anyone to release their source code to anyone to whom they have not directly distributed. It als does not require you to send back changes. If the code is public than anyone can take the changes with proper attribution but if you take changes without the author agreeing to any contributor agreement you are potentially in for a world of pain. – Elin Aug 22 '14 at 00:40
  • 10
    The ØMQ guide has an [interesting story](http://zguide.zeromq.org/page:all#header-136) 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." – Michael Hampton Aug 22 '14 at 01:25
  • Maybe they asked GitHub staff to turn it into a source repository rather than a fork (or they didn't even use the fork button in the first place). That's understandable if it's a significantly different version; for one, code search doesn't work in forks (yet). – alexia Aug 22 '14 at 11:57
  • @nyuszika7h code search works perfectly fine in forks. – congusbongus Aug 22 '14 at 14:38
  • 1
    @congusbongus [No, it does not.](https://github.com/nyuszika7h/Limnoria/search?q=test&type=Code&utf8=%E2%9C%93) *Sorry, forked repositories are not currently searchable. You could try searching the parent repository.* – alexia Aug 22 '14 at 14:39
  • 1
    @nyuszika7h [**repository forks will not be searchable unless the fork has more stars than the parent repository**](https://help.github.com/articles/searching-github) – congusbongus Aug 22 '14 at 14:44
  • 1
    Whilst, as a programmer, I feel that this behaviour is somewhat unethical, I think your questions are missing the point - the original dev _chose_ to use that licence _because_ he wanted people to do this. He was quite entitled to us any licence he liked - he chose this one, because he wanted people to be able to do this. If he didn't, then the question is: why do people misunderstand the MIT licence? – stripybadger Aug 22 '14 at 15:07
  • Is the concern because Xamarin is bigger and more powerful? Are their resources going to push the project forward? – Joshua Dance Aug 22 '14 at 15:40
  • What github calls a "fork" is not a fork in the open source sense of the word because the forked repository remains part of the derived network from the original source (and you can send a pull request direct from the fork to the original source). A real fork means that someone create a new unconnected repository. In the Github sense it can't send a direct pull request to the original project It is not part of the project graph. – Elin Aug 22 '14 at 22:06
  • @Elin: Actually, considering that Git will happily (try to) merge from whatever SHA1 you throw at it, even if that commit isn't part of the same network (See Linus's "Coolest merge ever" for an awesome example), there really cannot even be "forks" in that sense when you are using Git. "Fork" becomes a purely social concept now, from a technical perspective, you can *always* share changes back and forth. This is different from, say, Subversion: once you fork, there's no way of merging changes anymore, you're back to emailing patch files. – Jörg W Mittag Aug 23 '14 at 21:47
  • That's what makes Linux work so well. The philosophical differences between some of the kernels are probably as big or even bigger than the philosophical differences between, say, NetBSD and FreeBSD. However, the community is much more cohesive, because with Git, forking a repository is essentially a non-issue. – Jörg W Mittag Aug 23 '14 at 21:50
  • 1
    True and I've read (and used) that post so many times with my on and other people's messy branches. But that is git not Github and we know what Linus says about Github :). Github uses fork in a specific way in its web application. To to the coolest merge ever you need to be on the command line. So what I'm saying is that Fork in Guthub doesn't mean what fork means in the open source world usually, which is an intent to develop independently, it actually is a way of allowing direct pull requests in a web ui. – Elin Aug 24 '14 at 01:32
  • 2
    The GitHub fork feature is very unfriendly when the intention *is* to take a project in a new direction. A few months ago I forked a Py2 project to make it Py3, I've done orders of magnitude more numerous commits since and expanded the scope vastly. Now my commits don't count as contributions unless I submit a pull request, which is something I really don't intend to do, and I would reject if I was in the original maintainer's place. – Liz Av Jun 10 '15 at 23:45

7 Answers7

124

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.

fgb
  • 1,200
  • 2
  • 6
  • 10
  • 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 '14 at 01:03
  • Could you touch on how the [BSD licenses](http://en.wikipedia.org/wiki/BSD_licenses) relate to this? – jpmc26 Aug 24 '14 at 09: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](http://oreilly.com/openbook/osfreesoft/book/ch02.pdf)". – Scott Whitlock Aug 25 '14 at 11:05
78

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.

mts knn
  • 103
  • 4
BrianH
  • 6,092
  • 1
  • 21
  • 23
  • 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. – Bernd Jendrissek Aug 20 '14 at 22:45
  • @BerndJendrissek The GPL only allows you to sell a copy for profit once, because after you did it your customer can underbid you. – Philipp Aug 20 '14 at 23:33
  • @BerndJendrissek You are, strictly speaking, allowed to sell as-in charge for distribution of the software, so that's true - but a derivative work (modification or expansion) cannot be given that is not itself open-source and GPL. Thats what I was trying to get at with the copyleft thing...I agree though, that could be confusing about the nature of the GPL without an appropriate link/explanation. – BrianH Aug 20 '14 at 23:45
  • @BerndJendrissek There, changes made to hopefully clarify that section and add a bit of extra clarity. – BrianH Aug 20 '14 at 23:57
  • 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 '14 at 07: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 http://en.wikipedia.org/wiki/List_of_open-source_video_games – corvec Aug 21 '14 at 17:56
  • @corvec Case in point, I play Doom on Linux using a free-as-in-beer port of the game code, but I had to buy the game to legally obtain a copy of everything that wasn't the code. – Doval Aug 21 '14 at 19:38
  • 1
    @Philipp the first question is whether the customer is interested in selling cheaper - might not be their business. And even if they try you know the software better and continue to develop new features and most likely have better support. If you don't serve your customers you have bad luck though. Then you should use another license which makes customers dependent on you. – johannes Aug 21 '14 at 20:37
  • 8
    @DevSolar: RMS himself _sold_ GPL software for many years to finance the FSF. – Martin Schröder Aug 21 '14 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 '14 at 00:47
  • @DevSolar "chances are pretty slim that you'd make many sales" And yet somehow, RedHat. – jpmc26 Aug 24 '14 at 10:05
  • 2
    @jpmc26: What RedHat sells is not the software, but the support and "being licensed" (a.k.a., Oracle et al.). Guys, I accept that the GPL has its pro's, but please stop the gospel-preaching. – DevSolar Aug 25 '14 at 06:52
  • @DevSolar - What you also get with RedHat is a company actually developing the code to keep it up to date. That's the same thing your yearly license fee covers for most large proprietary products like AutoCAD, Photoshop, etc. You're paying now to make sure there will be an improved version later. Otherwise you're stuck with a dead-end product, which would make the alternatives a lot more attractive. – Scott Whitlock Aug 25 '14 at 11:11
  • @DevSolar It's my understanding that RedHat requires a subscription to download the OS. Whether you call that selling their software is minutia/legal trickery, in my opinion; you have to pay to get it (or maybe mooch off someone else or build from source or something else far less than ideal). The result of that was CentOS, of course. On a side note, by no means do I consider the GPL some kind of gift from heaven. I was just making an observation. (Honestly, I don't even like RedHat or derivatives. It doesn't keep its packages very up to date.) – jpmc26 Aug 25 '14 at 15:59
  • there is still an etiquette to these things and social graces which encourages more people to give to the greater good. part of the reason we give to greater good is a general belief in the inherent goodness of mankind. rude, selfish actors need to be called out as they undermine that belief. it's tragedy of the commons but with no legal recourse, just a social one. – Blaze Jan 11 '21 at 14:18
21

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.

Karl Bielefeldt
  • 146,727
  • 38
  • 279
  • 479
  • 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 '14 at 06:54
12
  • 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.

Community
  • 1
Brendan Long
  • 806
  • 8
  • 12
  • 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 '14 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 '14 at 00: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. – Brendan Long Aug 22 '14 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. – Brendan Long Aug 22 '14 at 14:26
11

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.

Athari
  • 371
  • 1
  • 12
  • 3
    This ^ only one to go directly to the source. +1 – Ryan Aug 21 '14 at 23:34
  • 25
    [That change](https://github.com/mono/CocosSharp/commit/7b3092032a07986b5b11c66ea64945a07ef2647a) doesn't seem to originate in the *forked* codebase. More importantly, it was by [Jacob Anderson](https://github.com/totallyeviljake), Cocos2D-XNA team member and the one who [*objected to the fork*](http://forums.xamarin.com/discussion/comment/70163/#Comment_70163). In contrast, [Miguel de Icaza is the one who did the forking](http://forums.xamarin.com/discussion/22129/welcome-to-cocossharp-forum). **Am I missing something?** Or have you attributed the removals to the wrong person and project? – Eliah Kagan Aug 22 '14 at 00:48
  • 3
    That was Sept 2013? I'm confused about timing if that is part of a fork that just happened. – Elin Aug 22 '14 at 01: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. – Eliah Kagan Aug 22 '14 at 01:08
  • 5
    -1. That change was made in Cocos2D-XNA, before the fork occurred. Here's [the identical change](https://github.com/Cocos2DXNA/cocos2d-xna/commit/7b3092032a07986b5b11c66ea64945a07ef2647a) in Cocos2D-XNA. – David Hammen Aug 23 '14 at 11:00
4

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.

Steve Jessop
  • 5,051
  • 20
  • 23
2

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.

bmargulies
  • 1,698
  • 1
  • 13
  • 20