31

Long story short, a company used to have an open source and MIT licensed wordpress plugin (a gateway payment processor for woocommerce) published on github.

I have submitted contributions to it, which they incorporated in their code.

They now decided to go back on open source, so they removed all of the code from the repository with a force push, used their permission to modify PR code to do the same on forked repositories and archived it.

And they are now selling this plugin containing code that me and other contributors wrote when it was still under MIT licensing. Do I have any right over my contributions, even if they are a small portion of the code? Is what they did legal, if not highly unethical?

As being left out high and dry like this really left a bitter taste in my mouth as I thought I was contributing to an open source project, instead they just stole our contributions, didn't leave us with a copy of the code and are now selling said code.

In the end the internet never forgets and I was still able to find a fork with the code prior to the rug pull.

Can I ask them to pull my contributions out from their now commercial code and would they have to comply?

9
  • 7
    You cannot force them to remove your contributed MIT-licensed code, but since WordPress is GPL licensed, you might be able to argue that they must open up the source (at least to their customers) due WordPress's GPL license. Note that GPL also allows 'commercial' code (i.e. they can sell it and they don't need to place it on a source hosting platform like github if they don't want to.) Commented Jan 21 at 8:42
  • 9
    "used their permission to modify PR code to do the same on forked repositories" - aside: do you have a link to what exactly happens here on GitHub? I'd have naively though a fork is a fork is a fork? Commented Jan 21 at 13:19
  • 10
    @MartinBa Yes a fork is still a fork and they don't have right over forks. But they do on branches created only for the purpose of opening a PR and nowadays github only forks a single branch instead of the whole repo by default for PRs. Do you know how when you open a PR you have a checkbox that asks "Allow maintainers to modify this pull request". Well this allows them to force push to the branch referenced in the PR, even after it is merged. Effectively giving them almost full control over your branch. Something I'll definitely be careful about in the future Commented Jan 21 at 18:14
  • 4
    Force pushing doesn't erase your version history. It should be straightforward to just revert to before they did that. Commented Jan 22 at 10:41
  • 2
    "Force pushing doesn't erase your version history." Your local one yes, but I had deleted that already, I contribute to hundreds of projects and if I kept every one of them, my poor hard drive would suffer and then finding the projects I'm currently working on becomes harder and harder. So there was only the github branch on the repository available. But I was still able to find a few forks with up to date history Commented Jan 23 at 11:02

4 Answers 4

37

As we've said many times here, the normal community understanding on contribution licensing is inbound=outbound, which is to say that contributors agree for their contributions to be licensed under the project's existing licence.

In the case of copyleft licences, as the linked question says, this is actually a requirement of the licence. In the case of the permissive licences like MIT, however, it's just a community understanding. Unless the project required a CLA from you, you could make an argument that you never licensed your contributions to the project at all, but I'd expect it to be a hard, uphill business to convince a judge of that (indeed, as Bart points out (thank you, Bart!), given GitHub's embedding of in=out in their TOS, it will likely be next to impossible).

But the project is completely entitled to change to a proprietary licence, and unless you can convince a judge that you never agreed to licence your contributions, you have no right to demand they stop using your contribution. One of the many advantages of copyleft licensing is that, once contributions have been accepted, the project can no longer unilaterally relicense. The permissive licences don't give the same protection, and this is generally understood, so what they've done, though not nice, is neither unlawful nor unethical.

One thing you can do is to take the copy of the MIT-licensed source you've found, and make sure it's available from your website (or at least, not solely from your github account). You have every right to do that, and as the search engines pick it up, you may hope that their proprietary-licensed version is supplanted by the free version.

10
  • 6
    Why "not your github account"? Commented Jan 20 at 14:33
  • 12
    If I understood the question correctly, multiple copies of this source have already been removed from GitHub. The mechanism might not extend to the OP's copy, but any hosting service that's not under the OP's direct control can still be pressured with eg DMCA takedown notices. If it's on your own paid-for site, preferably on your own server and running on your own hardware, it's an awful lot harder for some third-party to get it removed. Commented Jan 20 at 14:35
  • 4
    Convincing a judge that the contributions (made through GitHub) were not licensed will be next to impossible, given that the inbound=outbound is also part of the GitHub ToS as the default (docs.github.com/en/site-policy/github-terms/…) Commented Jan 20 at 14:52
  • 2
    Why not both? (i.e., both on your web-site and on GitHub.) Commented Jan 21 at 8:13
  • 12
    Yes, but when someone serves you with a takedown notice, you can decide what to do about it: engage a legal expert, do some research, ignore it on the basis that you're not in the US and it's either invalid or unenforceable, something else. How much time, energy, and money you will devote to dealing with it is your choice. When service is provided by some third-party US company that you're not even a customer of, you have very little input into, or control over, how the notice is handled. Commented Jan 21 at 16:12
24

As the project was under license e.g. XYZ when you contributed, you licensed your code to them under the XYZ, just as much as they licensed their code to you under XYZ.

You can't demand they stop using your code, as you gave them a license to do so. The license you licensed to them under (MIT) clearly states you licensed your code in a way that allows them "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,"

This means they can use your MIT-licensed contributions, and bundle it in their larger plugin, and sell/license the plugin under a different license.

Technically, your contributions in their codebase is still under MIT, but since you gave them permission to commercially use it (as MIT grants), all they are legally required to do is put the MIT license at the top of the (php or whatever) code file, if the majority of that file was written by you. They aren't required to host or distribute it publicly, nor to sublicense their code under the same license. And if your code contributions were minor, they may not even have to label your code under the license, as MIT says, "The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.", and a few function additions might not be "substantial" enough to merit the requirement of demarking several lines or several functions from the greater body of work (and even if it was, merely putting them in a separate code file and importing it into their codebase would satisfy that requirement).

HOWEVER, because they also had their own code licensed under MIT, it means that any copy of the old code that they licensed under MIT is still licensed under MIT, even if they deleted the repository. You can fork the last-known MIT-licensed version (i.e. that you may have downloaded or someone else may have downloaded), and host it yourself on Github to keep it publicly available to everyone else under MIT, and there's nothing they can do about it, as long as you rename it. If it was previously called McDuffin, you could call it "McScruffin - a Free fork of McDuffin".

They'll probably shoot you a legal takedown notice to scare you, and you can then give their scare-tactic lawyers the middle-finger, replying, "I have a lawful license to distribute this code, and to sublicense it, because it was licensed to me, by your company, 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'"

You could even sell your fork and compete with them commercially.

TLDR:

  • You licensed your code under MIT, so they get to use it, sublicense it to others, redistribute it, and sell it.
  • They licensed their code under MIT, so you get to use it, sublicense it to others, redistribute it, and sell it.
  • Neither of you are obligated to host the code or make it available for free.
  • Neither of you are able to prevent the others from hosting the code or making it available for free.
  • Any new code you or them write on your two diverging copies, doesn't have to be licensed under MIT.

This only applied to MIT license - other licenses vary! Some opensource licenses (GPL and LGPL if I remember right) do require users to provide copies i.e. distribute/host/"make accessible", usually just by ensuring someone somewhere in the world is hosting the code you can link to, or by emailing a copy of the code upon request.

3
  • "As the project was under MIT when you contributed, you licensed your code to them under the MIT, just as much as they licensed their code to you under MIT." I'm sorry, but MIT isn't a copyleft licence; the argument simply doesn't hold water. As I think I've been clear, in=out is at best a community understanding when permissive licences are involved. Commented Jan 21 at 19:39
  • 4
    Ah, I just read your answer, and I think I see what you are saying, but I don't see our two answers are substantially differing. You're saying, "It's not explicitly licensed, but would be hard to convince a judge otherwise", whereas I am treating the implicit licensing as a foregone reality. Apart from that, we both came to the same conclusion, unless I am misunderstanding? Commented Jan 21 at 19:58
  • 5
    That is what I'm saying, but it's not because the MIT licence has any special powers. It's because the OP knew his/her contribution was being redistributed as part of the larger project, under an MIT licence, for some period of time, did not object during that period, and thus could reasonably be said to have accepted the situation. Also, as Bart points out, in=out is an explicit feature of the GitHub ToS. I think it's quite important that people understand the shortcomings of permissive licences, as well as their strengths. Commented Jan 21 at 20:17
9

The other two (as of this writing) answers are thorough, but they may not do much to address the underlying confusion that a lot of people have, that seems to have been behind how the first part of question was worded: "Is it legal to delete an MIT-licensed github repository (...)?"

So in this answer, I'd like to focus on clearing up that confusion: "open source" is not the same thing as what you might call "open development".

There is nothing in the MIT license (or in fact any open-source license that I'm aware of) that obligates that anyone to maintain a public repository of the source code on a code host site such as GitHub.

The obligations, when they do appear (in licenses such as the GPL), are phrased in terms of how you cannot be denied a copy of the source code if you request one.

So the answer to "Can they take the open source repositories that they're hosting, down? Is that allowed?" should always be: yes, they can, and if that possibility worries you, you should maintain your own mirror (by some technical means that they can't take down).

2
  • 4
    Agree with the main point here, however "are phrased in terms of how you cannot be denied a copy of the source code if you request one." is a little misleading. Copyleft can only apply if you're a recipient or (in case of AGPL, networked) user of an application. If you did not receive or communicate with an application then you do not have the right to receive sources upon request. This right is dependent on the copyleft clauses being applicable. Commented Jan 22 at 13:02
  • 1
    GPL requires that if you distribute binaries you also distribute source; you can fullfill this by providing link to a public repo of the source that is valid for a period of time. If they have distributed executables of a GPL and used the link provisions, then yes they are responsible to ensure the repo stays up (for a period of time). Commented Jan 23 at 16:51
1

They have the right to do so under the MIT license, but you also have the right to publish that version of the source code that was still open source. Just create your own repository.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.