From: Sam Reis Date: Thu, 08 Oct 2026 13:59:23 GMT Subject: Re: [PATCH 0/4] faster SHA-1 collision detection Message-ID: In-Reply-To: Hi Ben, On Thu, Oct 8, 2026 at 3:25 PM D. Ben Knoble wrote: > > Hi Sam, > > On Thu, Oct 8, 2026 at 7:23 AM Sam Reis wrote: > > > > Hey everyone. Just for the avoidance of doubt, very happy to see > > Scott's patch here land and for git to benefit from faster sha1dc > > hashing. Let me know if I can do anything to support! > > [We bottom-post here] No problem! > > > > On 07.10.26 20:13, Scott Chacon wrote: > > > > Hey, > > > > > > > > On Wed, Oct 7, 2026 at 7:23 PM Junio C Hamano wrote: > > > >>> This series ports the approach of Sam Reis's sha1dc Rust crate [1], > > > >>> which gitoxide recently switched to [2], to C. > > > >> > > > >> Which means license-wise the original is compatible with us, I > > > >> presume, as they are "Apache2 or MIT, your choice". > > Leaving aside the question below about AI policy, I think the > important question for Sam and Sebastien is license compatibility? I can try answering as best as possible from my perspective. I think it's important to note, insofar this wasn't clear before, that the actual code for the ubc checks is fully autogenerated rather than written by hand. The generator for it was written from scratch by me with LLM assistance, and based on the methodology described in the 2017 paper from Marc Stevens and Dan Shumow. Nonetheless I ended up crediting Stevens and Shumow in the copyright notice to be on the safe side. > > The sha1collisiondetection submodule and the sha1dc code (extracted > from that submodule's upstream, if I'm reading 28dc98e343 (sha1dc: add > collision-detecting sha1 implementation, 2017-03-16) correctly?) are > MIT licensed, too, so there is some precedent for Git here. I skimmed > what I could find of the original threads: > > - https://lore.kernel.org/git/20170223195753.ppsat2gwd3jq22by@sigill.intra.peff.net/ > - https://lore.kernel.org/git/?q=sha1dc%3A+add+collision-detecting+sha1+implementation > > but I didn't see a discussion of licensing at that time. Perhaps the > idea is that we are clear that such code carries a different license > from Git? > > Anyway, I suppose the fair thing would then be for Scott's code to be > MIT (and/or Apache2), in which case it would need similar > clarifications? (Or are we prepared to take the stance that de nouveau > code based on existing code can be license-washed, in this case to > GPL-2?) > > Interestingly, Gentoo claims Git's license is only GPL-2, but I think > they compile in the sha1dc code since it's the default in meson. > Should we be claiming the Git package (with sha1dc) is actually GPL-2 > and MIT? Again IANAL, but my understanding was always that MIT is GPL-compatible. From https://en.wikipedia.org/wiki/License_compatibility#GPL_compatibility: "Many of the most common free-software licenses [...] are GPL-compatible. That is, their code can be combined with a program under the GPL without conflict, and the new combination would have the GPL applied to the whole (but the other license would not so apply)." So as long as it's correctly attributed, that might not be an issue? > > (This is complex territory and I'm sure to have gotten it wrong; > pointers to past discussions, esp. those by copyright and licensing > professionals, welcome.) > > > > >> How can you/we be sure, with respect to the current AI policy in > > > >> SubmittingPatches (which by the way was vetted by SFC lawyers), that > > > >> your "AI generated" code did not "borrow" from places that gets > > > >> you/us into trouble? > > > > > > > > It's a good question. I actually just submitted a proposed update to > > > > that policy based on SFC's updated guidelines, but either way, I > > > > learned about this from Sam and have talked to him about the port and > > > > he seemed excited about it. I can triple check, but I'm fairly > > > > confident that he's fine with this and I am fine signing off on it > > > > under the terms of the DCO language. > > > > > > > > Of course, he in turn used AI tooling to produce _his_ library, but > > > > within the guidelines of the updated SFC guidelines. Johannes's > > > > alternative series is the original Rust code of Sam that my agent > > > > looked at to produce this (in addition to his blog post explaining > > > > it), so I'm not sure how that might be materially different. > > [snip] > > > > >>> [1] https://sam.dev/blog/faster-sha1-collision-detection > > > >>> [2] https://github.com/GitoxideLabs/gitoxide/pull/3008 > > > -- > D. Ben Knoble