Re: [PATCH 6/7] xdiff: conditionally use Rust's implementation of xxhash

From: Yee Cheng Chin <ychin.macvim@gmail.com>
Date: Oct 5, 2025, 05:32 UTC
Message-ID: <CAHTeOx84BaAS1tkGdvoj1c6z+We+NobsJsTpfshw-xHn-NXGLw@mail.gmail.com>
In-Reply-To: <dd3a7ab0-947b-4592-a086-8c7028f02ffd@gmail.com>

Hi, I have a different but related question. Xdiff is currently licensed under LGPL, not GPL. With the new Rust code not having any license header in their files, what is the intention for the licensing for them? Given that these are derived from the original Xdiff code, I would have imagined they would use the existing LGPL license for Xdiff, but the lack of licensing header makes it seem like they are just going to inherit the GPL license from Git. Is this a conscious relicensing effort? Or just something that hasn't come up yet? Otherwise if xdiff stops being a standalone codebase (due to it relying on the Rust components), it would essentially mean it ceases to be a library that could be used by other parties.

This is critical for downstream projects that use Xdiff. For example, libgit2 mtaintains an xdiff fork, and Vim (which I contribute to) / Neovim currently use Xdiff as the internal diff engine, which per my understanding is only possible due to the license being LGPL (Vim is licensed under the Vim license and Neovim is under Vim / Apache).

On Sun, Jul 20, 2025 at 3:15 AM Phillip Wood <phillip.wood123@gmail.com> wrote:

Show 59 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?
>
> > 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.
>
> 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.
>
> Thanks
>
> Phillip
>
>