gitoxide-compatible licensing of Git's Rust code, was Re: [PATCH 6/7] xdiff: conditionally use Rust's implementation of xxhash

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Sep 23, 2025, 09:57 UTC
Message-ID: <9818dc92-3569-3e6f-0252-245c2bf0bf84@gmx.de>
In-Reply-To: <dd3a7ab0-947b-4592-a086-8c7028f02ffd@gmail.com>

Hi Phillip,

On Sun, 20 Jul 2025, Phillip Wood wrote:

Show 31 quoted lines

> Hi Johannes
> 
> On 19/07/2025 22:53, Johannes Schindelin wrote:
> > Hi Ezekiel,
> > 
> > On Thu, 17 Jul 2025, Ezekiel Newren via GitGitGadget wrote:
> > 
> > > diff --git a/rust/xdiff/src/lib.rs b/rust/xdiff/src/lib.rs
> > > index e69de29bb2d1..96975975a1ba 100644
> > > --- a/rust/xdiff/src/lib.rs
> > > +++ b/rust/xdiff/src/lib.rs
> > > @@ -0,0 +1,7 @@
> > > +
> > > +
> > > +#[no_mangle]
> > > +unsafe extern "C" fn xxh3_64(ptr: *const u8, size: usize) -> u64 {
> > > +    let slice = std::slice::from_raw_parts(ptr, size);
> > > +    xxhash_rust::xxh3::xxh3_64(slice)
> > > +}
> > 
> > I know that this is a pretty small file, but I do notice that it does not
> > have a license header.
> > 
> > This reminds me of the unfortunate oversight to be careful about making
> > (and keeping) libgit.a's source files compatible with libgit2's license to
> > nurture a fruitful exchange between those two projects.
> 
> I'm not sure I follow your reasoning here. libgit2 was started after git and
> chose to use an incompatible license. I wasn't around at the time but isn't
> there a list of git contributors who are happy to re-license their
> contributions with the linking exception used by libgit2?

Let me provide some historical context that might clarify the licensing concern.

When libgit2 was created, the goal was to demonstrate that Git functionality could be packaged as a reusable library, inviting innovation via 3rd-party products. The project took existing Git code (with permission) and wrapped it with a proper API. The hope was that this would eventually become the foundation for Git itself.

What we learned from that experience is instructive: license incompatibility became an insurmountable barrier to code sharing between the projects.

Lack of functionality prevented commercial products using libgit2 to provide powerful user interfaces that outshine Git's own user experience, unless they accepted the limited functionality.

Even when volunteers wanted to port new Git features to libgit2, the licensing prevented it.

This fragmentation weakened both projects - libgit2 couldn't benefit from Git's innovations, and Git couldn't leverage libgit2's API improvements nor corporate contributions that would have been more likely to target libgit2 than Git.

You can see this in full action: merge ORT, partial clone, sparse index, etc. All of those features are missing from libgit2, with little hope to end up otherwise.

Innovations such as geographically-distributed, redundant data stores, or Xet-like big-file storage to replace e.g. Git LFS with a fully native solution, haven't happened, despite libgit2's architecture offering the extensibility and proper delineation to make such improvements cleaner and much more straight-forward than Git's own source code would allow.

Show 15 quoted lines

> > With Rust, we still have a really good chance to learn from history and
> > avoid that mistake: Gitoxide is a very exciting project with clear overlap
> > in its mission to implement Git functionality in Rust. Gitoxide is
> > dual-licensed under the Apache License v2 and the MIT license (see
> > https://github.com/GitoxideLabs/gitoxide?tab=readme-ov-file#license).
> > 
> > Would you mind adding a license header to that file that explicitly allows
> > the contents of the file to be used in Gitoxide, to get the Rust effort
> > started on a good foot?
> 
> I wary of that for two reasons. Firstly over time it is de-facto re-licensing
> git as the amount of rust code grows and the amount of C code shrinks which
> deserves a wider discussion. Secondly it makes it harder to convert our C code
> which is licensed under GPL2 (or in the case of xdiff LGPL) to rust if the
> rust code uses a different license.

The industry adopted libgit2 widely precisely because it provided what Git didn't: a clean API for building tools. But the licensing barrier meant that innovation had to happen in isolation.

Due to the feature disparity, we saw "libgit2 evacuation" efforts, starting with Visual Studio, later GitHub and GitLab followed, where work was duplicated by moving away from libgit2 towards a distinctly non-API way to invoke Git functionality: by spawning full-blown `git` processes and communicating by parsing `stdout`, risking regressions due to typo fixes such as the infamous "up-to-date -> up to date" patches. Such a lot of extra work, away from proper API calls, just because of that fragmentation!

With Rust and Gitoxide, we have a rare opportunity to avoid this fragmentation from the start. Gitoxide's permissive dual licensing means code can flow both ways. This isn't about "slipping in" a license change - it's about learning from what happened before.

By the way, you made it sound as if I asked to re-license existing code, which is not the case. I specifically asked for new code to be licensed in a way that avoids to straight up prevent collaboration with the Gitoxide project from the get-go.

It would not even take more than something as simple as GPLv2+exception. We do have prior art for that: The Git project itself suggests in its very own `COPYING` file to use the following license in new files:

        This file is licensed under the GPL v2, or a later version
        at the discretion of Linus.

Note the exception? For new Rust code (and of course excluding code that has been ported verbatim from GPLv2-licensed code), GPL v2 could be used with an exception along these lines: This file is licensed under the GPL v2, with the exception that it can be freely used in the Gitoxide project.

I am not a lawyer (which everybody but laywers are nowadays required to say), therefore this likely needs some tweaking.

> If someone wants to start a discussion about re-licensing git (and is
> prepared to do all of the associated admin in the event that it happens)
> then by all means do so but I don't think it we want to slip such a
> change into this series.

The "wider discussion" you mention is exactly what we need; Starting with compatible licensing makes that discussion possible rather than purely theoretical and moot.

Ciao, Johannes