What are the consequences of pushing a git repository that has an open-source license violation in its history, but not the current head?

Consider this scenario:

  • I have a git repository with some open source software I am writing.
  • I copy in a block of code from another MIT licensed software project, neglecting to include the copyright notice or MIT license text.
  • I commit my changes, creating change ab78e7e.
  • I realize my mistake, and add in the relevant copyright notice and license text for the snippet I copied.
  • I create a new commit, b80c081, and push my changes to a public git repository.

Is it a problem that this ab78e7e commit exists in the history of my git repository? After all, someone could clone the repository and run git checkout ab78e7e to obtain a copy of code that is in violation of the MIT license.

Do I have an obligation to squash these commits or otherwise modify the history of the repository such that there is no infringement at any point in history, regardless of the state of any published branches or tags?

I have seen GitHub issues and pull-requests that address cases where the author neglected to properly attribute code snippets. It seems like pushing a new commit to fix such a problem is not really a full solution. But it could also be disastrous to modify the history of a widely used repository.

  • Isn't this equivalent to downloading a compliant repo and then deleting the license file from your computer, making your local copy non-compliant?
    – endolith
    Apr 12, 2019 at 15:47

3 Answers 3


Whilst IANAL/IANYL, and no developer, it seems to me that the question boils down to "is it a licence violation to offer a repository from which someone could, with some effort, extract a non-licence-compliant subset of the code"?

I would argue that it isn't. With enough care, it's possible to extract a non-compliant version of code from most repositories. For example, given an FTP repo of GPLv3 code, I could choose to extract everything bar the Makefiles. That gives me code that won't build, which is non-GPL-compliant according to GPLv3 s1 (fails to meet the definition of "corresponding source"). Given a similar git repo, I could choose to extract a commit that happened to contain code errors which, though fixed later, prevented the code from compiling; this again fails to meet the same GPL provision.

To my mind, as long as you're offering a repo from which the default pull option is a properly licence-compliant codebase, you are satisfying the conditions of the licence. To require that all repos can only ever provide a fully licence-compliant codebase is to impose too high a burden on developers, and I've never heard any call for such an imposition.

  • What if in README is have link to commit that violate the license? I have MIT repo on GitHub. I've committed GPLv3 file but after realizing my mistake I've deleted that file by adding commit, but it's stil in history, I use this file on the server (so I don't copy it) but I wanted to show what was my changes to that file, so I've created link to commit from README. When someone clone the repo and pull latest changes the file is not there, but he can grab the file from commit.
    – jcubic
    Sep 19, 2019 at 19:56
  • 1
    @jcubic I stand by my last paragraph.
    – MadHatter
    Sep 19, 2019 at 20:01

This might be technically be a case of copyright infringement, however:

  • you acted in good faith
  • you already corrected the license violation
  • you never pushed a HEAD that was in violation

Personally, I would have squashed or rebased the commits before pushing, but that is a minor point.

It could be argued that your fixed Git repository does contain the proper notices and attributions, and that a user would have to explicitly extract a subset that would be in violation. But there are many ways to do that, e.g. by making a copy of the code but leaving out the license file. The possibility of extracting an infringing version is not in itself copyright infringement.

Scenarios like this are a good argument why every file should contain a license notice!

The one exception to this analysis is the GPLv2. Under the GPLv2, the license terminates automatically as soon as the license is violated. You would need to get consent from the copyright holders to reinstate the license (though some projects provide this consent in advance). Other licenses like the GPLv3 have a compliance window that gives you enough time to fix the violation before the license is permanently terminated. The MIT license has no permanent license termination mechanism, instead the license is only conditional on compliance.


The git repository as all information, so also the correct one.

IANAL, and more practical: I would make sure that all tags and publish branches will have the correct license. I would amend the source archives (tar.gz and similar) so that they have correct license (but probably I will keep the original file in a new place, with a README which tell about the error).

I happen to violate the license (and to publish such work). Unpublishing is very difficult (especially on pre-digital era). So you should correct it and not take advantage of the wrong license: this last point is checked on copyright violation: not only the violation, but damages to real author and your gain. With the above point, you have minimized the risk (personally I would say you are safe).

But there is also the technical solution: you remove the wrong file from git. Git documentation (on advanced topic) will explain you how to do it. In practice, you remove the "blob", when checking out the relative version, git will not find the file and it will give an error. But no need to rewrite history or have new commit numbers.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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