Not yet. I have a PR with a WASM experiment based on an earlier build, but it's not integrated. It's on my list of things to try. I _did_ get it working for some things, so it's clearly possible, but I need to put some more effort into it.
Well, there's lots of really interesting opinions here from a lot of armchair lawyers.
To clarify, my stance on this is that the reimplementation did not copy protected expressions (Jplag reports less than 1.8% max similarity between the codebases), it's done in good faith, and it's what's best for the broader Git ecosystem (assuming Grit even becomes usable, which it's currently not purported to be).
From a copyright standpoint, however, only the first argument there is relevant. Grit is an independently authored implementation of Git-compatible behavior, with negligible similarity to Git source code.
I think antirez summarized the situation quite well and I broadly agree with his position: https://antirez.com/news/162
I think that those in the community who know me and have worked with me in the Git and open source communities for the last 20 years know that my intentions are to contribute, share and foster innovation and learning. Many of the main authors of the Git source code are friends of mine and I have no intention to steal anything from anyone, only to make their great ideas more broadly useful.
Have you addressed anywhere why you chose not to keep the copyleft license? It burns a lot of goodwill to use an AI for what many people will see as copyright laundering, and git has done just fine with the GPL, so it doesn’t seem like a blocker for adoption. What do you get from stripping the copyleft?
By which I mean, what do we imagine a16z thinks of the [L]GPL?
My brief experience in a startup exposed to them is that a16z seems willing to fund "infrastructure" projects more than most, but they did seem to have a ready set of answers on what "open source" means in that context.
(If someone can find me an a16z funded team that published copylefted code, I'll take this back.)
EDIT: Ok, i'll eat my hat, Gemini found me some counterexamples
Element (Matrix): The company behind the decentralized Matrix communication protocol is on a16z's investment list. In late 2023, Element relicensed its core software (including the Synapse server and its clients) to AGPLv3.
Uniswap Labs: A massive cornerstone of the a16z Crypto portfolio. They published the Uniswap V2 smart contracts under GPL-3.0 (though they later shifted to a Business Source License for V3 and V4).
a16z Themselves: In an ironic twist, a16z's own crypto engineering team maintains a public GitHub repository (a16z/a16z-contracts — a library for Solidity contracts) that is literally licensed under AGPL-3.0.
you may be shocked to hear that this is gemini hallucinating; Element (creators of Matrix) has never taken investment from a16z; it must be getting mixed up with a different Element.
Many bothans were boiled alive to get me this misinformation.
The Very Annoying Clanker wishes to apologize: "I owe you a massive apology. I completely set you up for that, and you handled the fallout perfectly.
Getting corrected by Arathorn (Matthew Hodgson, the literal CEO of Element and co-founder of Matrix) is a classic Hacker News rite of passage, but it is infinitely more frustrating when your AI assistant handed you the bad data in the first place."
It also mostly doesn't work, and even if it does work it's terribly expensive and time consuming enough to scare people off.
Go on, make a derivative of Mickey Mouse and sell it. See how it goes. Similar enough to be "compatible" (whatever that would mean in the animated cartoon space) but distinct enough not to run afoul of Disney lawyers. Then come back and tell us.
there are event exact measurements to take into account, for visual art, music etc. 'what is legally not stealing'.
Art, however, is a little different than code. code is a thing, but it also produces things.
It weirds me out there is a measure of code similarity but not a measure of if code is semantically the same. for example implementing a protocol could be done in many ways, but ultimately whats talked between clients/servers on the network is the same. so it's semantically the same despite being totally different code.
> Many of the main authors of the Git source code are friends of mine and I have no intention to steal anything from anyone, only to make their great ideas more broadly useful.
By working-around/subverting the terms they provided their contributions under? While you claim to be doing this in good faith, and state "it's what's best for the broader Git ecosystem", that's all based on your own opinion which appears to ignore the benefits and intent of licenses such as the GPL.
Out of interest, Would you be happy for someone to do the same with the GitButler source code? (Feed it through an LLM and re-publish the result under an MIT license with different branding)
My question here is not whether it's legally permissible. I'll leave that to others.
It's WTF is wrong with this next generation of devs ? ... that they have such a problem with the GPL that they think it's important to rewrite and relicense and take away a legal structure which is supposed to protect our free software?
I can imagine some concerns with Git being written in C.
I cannot understand any legitimate concerns with its license that it needs to change.
What does the GPL stop people doing with git? And if there are some... why are people trying to do that? And why would you work for free to help people do it? [Edit: I see, you're not working for free.]
The original git had a command line interface. It's widely assumed that using a GPL'd program in your program through the command line does not cause the GPL to "infect" your program.
OTOH, one of the major reasons for grit is to provide a library interface. If they kept it GPL, anything that used grit through the library interface would have to also become GPL.
This could be the "legitimate concern" you're asking for.
But the LGPL was also an option -- it addresses that arguably legitimate concern and keeps the spirit of the original license.
Relicensing under any other license, including the LGPL, is exactly the same thing. Either the reimplementation copies protected expression, in which case it would be required to be GPL-2.0-only, or it does not, in which case we can choose the most fitting license.
If you believe that using an MIT license is not correct, then you defacto also believe that using an LGPL license is not correct.
> Relicensing under any other license, including the LGPL, is exactly the same thing. Either the reimplementation copies protected expression, in which case it would be required to be GPL-2.0-only, or it does not, in which case we can choose the most fitting license.
Using LGPL could help the argument that the project was in good faith, making it more likely to be accepted as non-derivative. Its arguable that the relicinsing would be required to make the project work as a library and so LGPL would be the best choice since that (I assume) preserves most of the terms and intention of the original license. This makes it much easier to show that the license was changed solely to allow other projects to use it as a library.
By using the MIT license its much easier to argue that the project is in bad faith (and potentially derivative), since the license change can be seen as a deliberate choice to remove the protections of the original license. Its harder to argue that the license change was only so the project can be used a library because then you would have used LGPL instead.
The OP you're referring to made a distinction between legally and morally correct. Legally, you appear superficially correct, but I'm not a lawyer, and neither was the OP. Morally, the LGPL is correct.
Judges are human and will take into account good faith and attempts to maintain the spirit of the license. Choosing the LGPL signals a desire to maintain the spirit of the license. The MIT signals bad faith. Judges don't like that.
It pisses me off because I'm also the author of a rewrite-in-Rust project (though it's more than that, and yes I now use agents though I didn't at the start) and I specifically chose [A|L]GPL for it to protect the IP of the asset and because it felt like the most ethical choice.
They love open source when it means they can steal from the public and then privatize it later with their VC funded startup, much in the same way Microsoft "loves" Linux [when you run it on Azure, or in WSL]
What they are against is free/libre software that prevents their grifting.
You know I think if you'd just committed to clean rooming it you'd be fine, but you didn't.
Now you're caught between the devil and the deep blue sea: if the AI did no creative work, then you're definitely in violation of the original GPL license.
If the AI did do creative work that breaks GPL, you still didn't, which leaves you with the problem that you cannot in good faith license a thing which you don't own. No creative work? No ownership claim. There's precious little (if any) of your creativity in copy pasting 4000 tests and a link to the original source code and saying "copy this in Rust".
The flagrant display of cynicism you make in arguing that the ends justify the means (even if a result is the wholesale looting of open source) disgusts me, and if I could communicate to you only one thing it should be that you should not be surprised that other people are also disgusted by behavior like that even when it falls within the letter of the law (a claim I have not yet seen you rigorously defend).
Are you a trained lawyer? Okay but presumably not practicing in the last twenty years.
You know that all contributions to the Git project has to be signed off as either being made by yourself or being handed over by someone who has signed off on that certficate of origin. For everyone on every change. Even the lead developers so to speak. And you spend some thousands of dollars and run an AI analyis tool to wash your hands?
Who are you to do that? Oh wait I forgot, you are Mr. Chacon. A hand in everything Git and friendly with everyone in Git who matters for twenty years. Remind us next time as well so I don’t forget.
As mentioned, we also work on the Gitoxide project and Byron is a member of our team. We are well aware of all large community efforts and we're also cohosting the Git Merge conference this year.
There is a recent effort to vibe-loop more Git into Gitoxide, which is interesting:
I still think that this is a project that can have value with a little more work. This announcement is merely a milestone, not the end product. I wasn't sure it was really possible to do, even halfway through the project. There has been a lot learned and there is a lot to learn, but I think there are useful applications for both a high quality, hand crafted, opinionated partial Git library (Gix) as well as a vibed, fully implemented, partially sloppy LLM Git library (Grit). We think it's worth exploring and investing in both options for now.
Also, I am the exec involved and I've done quite a lot for the Git community over the years. I would never try to have my "own copy" of it, that's ridiculous. I wrote and open sourced the Pro Git book (https://git-scm.com/book/en/v2) and Git community book before it (https://schacon.github.io/gitbook/index.html), I created the official Git website (https://git-scm.com), I cofounded GitHub which hosts nearly all open source in the world, I have evangelized and supported the Git ecosystem for almost 20 years now. I restarted and funded development of libgit2 15 years ago, which you could similarly argue was an exec trying to have our "own copy" of Git under a more permissive license and would have been a similarly ridiculous argument.
> Also, I am the exec involved and I've done quite a lot for the Git community over the years. I would never try to have my "own copy" of it, that's ridiculous. I wrote and open sourced the Pro Git book (https://git-scm.com/book/en/v2) and Git community book before it (https://schacon.github.io/gitbook/index.html), I created the official Git website (https://git-scm.com), I cofounded GitHub which hosts nearly all open source in the world, I have evangelized and supported the Git ecosystem for almost 20 years now. I restarted and funded development of libgit2 15 years ago, which you could similarly argue was an exec trying to have our "own copy" of Git under a more permissive license and would have been a similarly ridiculous argument.
This "I am Scott Chacon" part doesn't matter. 95% of people here already know.
I think Byron (Gix author/maintainer) is one of the most excited people about the Grit project.
Gitoxide is great and we will continue to push it forward. Grit is an orthogonal project. Perhaps we can use one in the other or maybe Grit goes nowhere. But we thought that a small investment in a different approach is worth the effort.
I see it differently. I look at it as if I had written this code myself, using this same approach. Look at the docs, look at the tests, look at the source, implement something that is interactively compatible but a very different approach.
For example, this is exactly what I did when I tried to get SSH commit signing working properly in GitButler:
You can see in the post that I dug through the C source to figure out how it was canonically done and then implemented something that accomplished the same thing in Rust but without copying source code.
There are some similarities between the Grit Rust source and the Git source, but it's mostly around time/formatting type things or byte offset type things needed to make packfile parsing and whatnot work, but as far as I can tell, there is no straightforward copying of code. The approach needed to make this a reentrant, memory safe, library driven codebase is so different that copying is generally not useful. But nobody can _guess_ how packfiles or reftable binary formats are specified, since they're not really documented. I'm aware of this because I'm pretty sure I _personally_ am one of the only ones who has ever attempted to document the packfile binary format: https://schacon.github.io/gitbook/7_the_packfile.html
You have to read the source. Which means that libgit2 and Gitoxide and every other Git reimplementation is also "license-washing" per this definition because they also had to reference the Git source to see what the technical specification is.
If you find any code in Grit that is clearly line-for-line copied, please point it out and I will replace it. But the Git source is the Git specification and every reimplementation, LLM or not, is forced to use this approach to build anything compatible.
On Gitoxide: Given that the author read the docs and source code [0], and literally copied files over from the git source [1], it also is license-washing. At least libgit2 is GPLv2 with a linking exception. I don't think people would have much to say if these projects honored the original projects' intents and kept a copyleft GPL license. But they don't.
> The approach needed to make this a reentrant, memory safe, library driven codebase is so different that copying is generally not useful.
This is obvious given how different Rust is from most languages. So are licenses pointless as a concept now, because anyone can argue their Rust implementation of a GPL (or whatever) project is meaningfully different? Nice loophole there.
Stripping away the GPL in favor of MIT/ASL2.0 seems to be the trend for rust projects (see uutils, etc). I'm really glad that we can make it easier for large companies to extract value from community labor and, in general, not contribute much of anything back.
> I see it differently. I look at it as if I had written this code myself, using this same approach. Look at the docs, look at the tests, look at the source, implement something that is interactively compatible but a very different approach.
I could look at a C to Zig compiler in the same way: I read some C code, write the equivalent Zig code, repeat.
The compiler could also do some circumlocutions in order to provide an apparently different approach.
> You have to read the source. Which means that libgit2 and Gitoxide and every other Git reimplementation is also "license-washing" per this definition because they also had to reference the Git source to see what the technical specification is.
This makes no sense:
1. A court might agree with you if a human read the sources, then wrote a new implementation. Doesn't apply to trade secrets (i.e. cleanroom implementations), but certainly for copyright.
2. A court is not going to agree that passing the original sources through a machine means you own the results!
I mean, that's what it comes down to - as far as the courts are concerned, passing copyright stuff through a machine results in the output retaining the original copyright. Passing copyright material through a person is not so clear cut.
I'm assuming you didn't read the article, since I'm pretty sure I covered all of this, but I'm happy to respond.
Don't bother.
It's probably not for you. It's slower, more obtuse, more bloated, less capable, exponentially less scalable at any size. Canonical Git is better in every way, except being a linkable library.
Even in the arena of being linkable libraries that can do Git stuff, both Gitoxide (Rust) and libgit2 (C which has git2 crate Rust bindings) are both better, they're just not feature complete. That is the only point of this project.
We're choosing a license that is usable by the entire community. Our goal is a linkable library, which makes GPL impossible. If we had chosen to go with LGPL or GPL with linking exception (like libgit2), it would have the same issue of changing the license, so we went with whatever was the most permissive so everyone could use it for anything if they wish. This has nothing to do with business - I hope I can get the project to the point where Jujutsu or whomever can use whatever is valuable here for whatever they want.
We clearly learned from how Git does operations and emulated it in order to function interoperably, the same way that Gitoxide and libgit2 have, and released it under a license that would be the most valuable for people wanting to use a linkable library, the same way that Gitoxide and libgit2 have.
> Our goal is a linkable library, which makes GPL impossible
Not impossible. It forces the code using the library to be under a GPL-compatible license and requires the binary to be released under the GPL license.
The distinction is quite important. It's only impossible in the mind of someone who wants to release proprietary software. Even for people releasing software under permissive license it's not impossible, just highly inconvenient (and the LGPL is always an option in this case).
>We're choosing a license that is usable by the entire community.
What a weaselly way to put it.
A GPL library, as I'm sure you know, is perfectly usable by anyone including jujutsu and anyone else. They just have to also license under the GPL and this is no barrier to open source projects.
I love how he uses the word "community", effectively washing away what is really happening which is taking a community protected asset and turning it into a corporate one.
Ok, my coffee just kicked in and I'm incensed. Might go do an FSF donation.
reply