Merging parts of another, parallel, fork [MIT]

Question

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?

Answer 1

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]

Answer 2

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.