The situation is following: There is a project (lets call it A), standard MIT licensed but long abandoned. I created a rebranded fork, fully MIT compliant, called B. Another person, lets call him Jack, created one of his own forks, called C, also MIT.

I have made, and will make substantial changes to B, but one of the changes I want to do was also implemented by Jack in his C repo. instead of reinventing hot water, I want to include his specific feature into my repo, and of course give credit. I tried contacting Jack out of curtesy, but there was no response (though I think this shouldn't really matter).

Potential ways I am thinking about are:

  1. Add his repo as additional remote
  2. Create a branch of my master and cherry pick commits from his repo
  3. Since this will create conflicts and unbuildable state, harmonize his code with another commit of my own
  4. Add Jack to AUTHORS file which I added and now maintain for all other contributors, past, present and future

This will leave his commits as they are and part of B's git chain, but it is more work for me to resolve everything since API surface no longer matches that of project A (which C inherited and just expanded).

Another option I am considering is:

  1. Just copy/paste changes from his repo I need, avoiding conflicts and modifying to fit
  2. When committing, change commit message and add Jack as Co-authored-by:
  3. Add Jack to AUTHORS

This would be faster for me, but would remove him as a direct commit author.

In both ways I believe he would be attributed. But I guess primary question is: Am I even allowed to do that? As in merge outside up/down/stream without Jack's explicit permission?

And if allowed, which way would be allowed/best?


You are thinking very much about Git, and not at all about the existing MIT license.

  • You can just copy Jack's code.
  • You do have explicit permission – the MIT license under which you received Jack's code.
  • This license only has a single condition: that you keep Jack's copyright + license notice.

If you want to preserve Jack's Git history you'll have to do some complicated merging, but you're not required to do that. It is perfectly acceptable that Jack is not the commit-author of some commits that involves Jack's code. The MIT license is not about some abstract notion of “attribution”, but very specifically about Jack's copyright and license notice.

I would just copy the relevant pieces of code from Jack's project. If they are a somewhat self-contained (e.g. an individual function or file) then I'd add a comment near them to explain their origin. In any case, I would update your existing license file to also include Jack's copyright + license notice. For example:

libfoo-fork is a library for doing foo and bar

Copyright 2021 mmix

[MIT license text]

libfoo-fork is based on libfoo-original:

Copyright 2012 Original Author

[MIT license text]

The routines foo_fantastic() and bar_better() in foobar.c are based on libfoo-jack:

Copyright 2018 Jack

[MIT license text]

  • is this chaining necessary if MIT license text is the same? I have also added AUTHORS file in the project and made Copyright notice in LICENCE to "me and various contributors (see AUTHORS), also made a change that both LICENCE and AUTHORS need to be distributed with derivative works. Would it be enough to just list Jack in AUTHORS? – mmix Mar 18 at 23:09
  • 1
    @mmix The condition in the MIT license is that “The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.” I think this is easiest to do when you just reproduce the notices verbatim, without deduplicating anything. I think the Python license is a great example of doing this properly. Trying to be too clever has the risk of accidentally violating the licenses. It sounds like you have removed the original copyright notices, and are thus in violation of the licenses. – amon Mar 19 at 10:56
  • I have note removed the license, I just expanded it and listed all git contributors in AUTHORS file, because old author did not do that (and referenced that file in LICENSE with obligation to ship that file as well). The MIT license text part is verbatim copy. – mmix Mar 24 at 9:47

You are certainly allowed to merge MIT/X11/Expat-licensed code into other code under the same license. (You are allowed to merge such permissively licensed code into virtually anything, including copyleft or proprietary code as well.) As long as you keep the copyright notices and license text, you may do just about anything you like. You could eschew git altogether and distribute some of B's code and C's code together as tarball of files with no history whatsoever.

From a git-workflow perspective, there may (or may not) be some benefit to keeping C's development history. If you are very skilled at using git, it may be helpful to be able to rollback to specific commits in C's history for testing or debugging purposes. However, this is a fairly niche need, and the additional complexity of a git merge in your history may outweigh the flexibility you gain by keeping the full history.

Another benefit could be if you anticipate ongoing independent development from C, which could require repeated future merges with C's remote code. In that case, using git to manage the frequent merges in their own branch could be quite helpful, to save you the trouble of making the same compatibility fixes each time you pull C's code into B. However, since C appears to abandoned, this need is not particularly important.

Personally, as someone with midling git skills, I'd directly perform the modifications on my local copy and push up C's changes as a single commit, but either way is a valid option, from both a legal perspective and a project-management perspective.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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