> In looking at the code that the LLMs have produced for the project, especially given the pretty massive and widespread architectural changes needed to make the implementation libified and memory safe, we decided that the codebase is not a derivative work that would require carrying forward the GPL license and have decided to release the code under the MIT instead.
A translation of a book to a different language is a derivative work. So a translation of a computer program to a different programming language is also. But if in the translation of the book you start altering the plot and the personalities of that characters, does it at some point become not a derivative work? What point? IANAL, and I have no real idea, but I imagine that point has been probed significantly in case-law with respect to creative works. Given the current climate of ever-expanding scope of "intellectual property", if they admit that the LLM had access to git source code then I would say their case is weak at best.
It's not technically a translation, it's a re-implementation, with test suites acting as the destination. If it was a file by file translation your argument would have been valid.
Git is part of the LLM's training set though, so simply asking it to recreate git in another language is pretty equivalent. Like, you can almost certainly get these LLMs to output gits full source code with some prompting, so there's not that much difference (as much as we like to pretend that AI generated code has no copyright implications)
As mentioned in another comment, it's even more clear cut in this case. They actually put the original git sources in their project repo and instructed the agent to use it as the "source of truth".
Simple thought experiment. If you handed this same agents.md file (https://github.com/gitbutlerapp/grit/blob/main/AGENTS.md#sou...) to a human software developer and let them work on exactly the same goal, would their output be considered a derivative work?
That's something I have been wondering. If I as a human want to make a clean room reimplementation of some API or application, I must not have read the source code of the original implementation. I don't see why this shouldn't apply to LLMs as well. If an LLM might have been trained on the original source code, it should be considered "tainted".
Yes, and realistically any code that LLMs produce is a derivative work of its training data. There's going to be a huge disaster licensing wise
I have absolutely no idea how LLMs got through anyone's legal departments, I guess the hope is that if everyone breaks the law enough, it'll just be fine
> the hope is that if everyone breaks the law enough, it'll just be fine
Ever since the early 2010s when companies were started with the business idea "unlicensed hotels" and "unlicensed taxis" and made the owners really, really rich, this is said pretty much out loud. Look for words like "regulatory risks" and similar.
Maybe it started with the unlicensed gambling fad before that? That also made a lot of people filthy rich. Every time you have something under special license, or insuance requirements, then of course there is a margin for you if you can skimp on the license and hire gig workers instead.
The LLM situation with copyright and derived works in the 2020s is similar. Someone is likely to be rich, but there is a clear regulatory risk to it.
> if everyone breaks the law enough, it'll just be fine
That's pretty much what happened, isn't it? These concerns were all discussed in the beginning back in 2022, and I recall answers from many here on HN along the lines of "oh well, we can't stop it now or we'll risk falling behind China in AI development"
So yeah, the laws went out the window a long time ago the moment our government and the people decided to just look the other way willingly in the name of "progress."
Problem is there's a lot more than a single repo in training data, the corpus is massive... Should the author of a blog post on cats also be compensated for simply being in the same training data as the git repo?
Honestly? Yes. This is why its such a problem that most of the training data was not used with permission, and without the correct copyright status or license associated with it
There's a lot of arguments about humans doing the same thing, but the reality is that humans and robots don't enjoy the same legal protection. Its clearly a derivative work of all of its training data
Then it works both ways. Say I manage to generate essentially a ripoff of your copyrighted song, release it and make a ton of money, you now have to split that royalty with keyboard cat. And Joe bloggs. You'd end up fractions of pennies
> If I as a human want to make a clean room reimplementation of some API or application, I must not have read the source code of the original implementation.
That is the difference between necessary and sufficient. Clean-room is sufficient to guarantee avoiding copyright, but it is not necessary. The line legally is south of there, but that position was chosen because they didn’t want to crossing and it was easier to argue for legally in court.
tl;dr: clean room is overkill for avoiding copyright infringement
> Like, you can almost certainly get these LLMs to output gits full source code with some prompting, so there's not that much difference (as much as we like to pretend that AI generated code has no copyright implications)
Are you sure? LLMs are in some way a compressed version of their input but it's a pretty lossy compression (arguably this makes them more like a compression algorithm than a compressed version of the data). I'm not sure you can prompt a full, accurate, copy of a nontrivial codebase out of them. Even with zero temperature their accuracy is just not that high.
> I'm not sure you can prompt a full, accurate, copy of a nontrivial codebase out of them. Even with zero temperature their accuracy is just not that high.
> For Claude 3.7 Sonnet, we were able to extract four whole books near-verbatim, including two books under copyright in the U.S.: Harry Potter and the Sorcerer’s Stone and 1984 (Section 4).
That paper is basically using the LLM as a compression algorithm: it's prompting with some section of the book and it's reprompting if it doesn't give the right output. Notably this only works if you already have a copy of the book in question!
You misunderstand my point: the LLM is not a losslessly compressed version of the text: you need to supply additional information from the original in order to 'extract' it from the LLM (and from that point of view, the extra information would be the compressed form).
Yes, but as soon as copyright became a problem for very rich people parts of it were cancelled.
1) re-implementation for compatibility (which was quickly "reestablished" through use of copyright-protecting encryption. In other words: do you get to write software that connects to MS/Apple/Google/Facebook servers without authorization from those companies? Yes. Do you get to copy an encryption key from their software to make it possible? No)
and, more recently,
2) violating copyright for LLM training
and, currently mostly attempted:
3) "uncopyrighting" run software through an LLM, and some people "believe" it comes out with your copyright on it! Because very rich people want to sell uncopyrighting.
Ie. the jury's still out what will happen when it's billionnaire vs billionnaire.
Of course, the question is what happens the second someone does this with a disney movie, or a big microsoft application ...
> Yes, but as soon as copyright became a problem for very rich people parts of it were cancelled.
When copyright law was established, not many poor people owned printing presses. That is to say, copyright law is a PROTECTION to the very rich, not an inconvenience
true but as the exception for model training (which can only be done by very, very rich people and organizations) shows, there's some new rich and they want new rules.
Against the will of the people, as evidenced by the court cases and protests online ...
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.
I don't think it's that clear cut. The functional parts probably aren't copyrightable, only the stylistic ones. It's going to be a mix of courts applying laws in new ways that hasn't been done before and fact specific questions about what actually persisted through the LLM if it goes to court.
I'd be fascinated to see what happens if it does. Both in the analyses that we'd get of what the LLM did to the codebase and on the legal decisions on what the copyrightable creative elements in code actually are.
If I was the author though... there would be no way that I would be volunteering to be a test case like this. Also seems just rude for no reason.
It probably would have been less bad if he had chosen MPL-2.0 or LGPL-2.1-or-later. But he chose MIT, which cuts at the core of the intent of licensing the project with a share-alike license.
Tell me, can I create a copyrighted video that's not GPL licensed using ffmpeg?
Now tell me how creating a rust library using the git test suite is different?
But for the sake of argument: The test suite itself is copyrighted. To the extent the resulting work is a derivative of the test suite it is possibly infringing. For example you might example that the agent would derive variable names, function names, structure sequence and organization of the code from the test suite. It might even copy comments wholesale. Those are copyrightable things. (Which is of course just the first step in analyzing if it is infringement, there would be interesting fair use, de-minimis copying, etc arguments following a conclusion that any of those were copyrighted. A product produced this way definitely could be infringing given the right facts though).
yeah fair - the "The canonical Git source code we're targeting to replicate the functionality of is in the git/ subdirectory." part makes this hard to argue against.
> To the extent the resulting work is a derivative of the test suite it is possibly infringing
It's this bit that I have a problem with. If I run the test, it fails and reports a failure. Now I write code and run the test again. What is the theory there that code that I wrote infringes.
Doesn't infringe upon copyright period, because there's no creative element in that work.
Imagine a more substantial example though. Perhaps you have a test that checks that some file written in a binary format is correct, and gives names (creative elements) to each field of the format that it prints when you mess up the field, and has comments describing why the bytes are laid out like they are (the comments being copyrightable even if the facts they describe aren't), and the LLM copies those field names and comments verbatim... Now it's quite likely that the LLMs work is a derivative of the test suite.
For that assertion in particular I believe I'm practically parroting a ruling by the district court in Oracle vs Google about some extremely simple Java functions that Oracle claimed Google copied. Though I can't say I checked to make sure I'm remembering right.
You're recalling it right, but there's a nice quote from Judge Alsup in that case that talks about this exact situation:
> “So long as the specific code used to implement a method is different, anyone is free under the Copyright Act to write his or her own code to carry out exactly the same function or specification...”
Here given that this is rust and the original expression is C, the implementations cannot be the same by definition.
I'd challenge you here to think about this in terms of the legal aspects rather than reaching specifically for similarities as similar is often meaningless in the law or contracts when specific acts are codified rather than generalized ones.
I'd say what we're talking about here is probably a fair bit different to modding a game in most aspects.
I haven't followed any relevant cases but I would be surprised if there's any serious dispute that the common methods of modding games generally create derivative works. I think the dispute would be downstream of that as to whether or not the mods are covered by fair use.
If you did it in a loop until the test passed, maybe?
Your result is essentially impossible without the original. With ffmpeg, your result does not depend on ffmpeg specifically - you can use any video creation tool.
Repetition isn't really a factor in deciding whether something is infringing or not - check the copyright law in your jurisdiction. Here if you look specifically at what an LLM's sampling stage is doing, it's choosing non infringing tokens (i.e. rust source code) over infringing ones (i.e. C source code). So it's making an intentional choice to do something similar rather than creating something that has the same expression. That doesn't seem like it's copyright infringement to me.
A GPL tool that processes data doesn't virally transfer the license to its output. Copyrighted ffmpeg code isn't incorporated into the video output. The LLM didn't just conjure up equivalent behavior to git without ingesting the code and transforming it as new output. There is no other behavioral description that would reproduce all needed functionality.
It would be reasonable to point an LLM at these and use them with a basic knowledge of git to produce a rust version of git in a non-infringing manner.
If you did this manually it would take a long time.
Substitutibility probably doesn't apply here in the way you're implying and if it did it would likely be hampered by the 9th circuits findings about transformation in sony v connectix. Arguments here likely would look at rust not having a stable ABI, and hence not being inherently substitutable as a libray (grit-lib), less clear as an executable (grit-cli) on that side
basics of copyright law - the fundamental thing being protected is the expression... is a rust program's expression the same expression as a c program? I'd say generally not.
The test suite could test aspects of the architecture/design of the codebase that are not necessary for interoperability and constitute novel expression of a piece of software in a way that is not at all language specific.
By definition a test suite is about testing interoperability with the test suite. An HTTP test suite should likely test for whether response code 418 is implemented a particular way and while humorous it would still be an interop test no?
Because compilers and LLMs do different things, and what is done matters, so you can't reason by stepping from one to the other.
Compilers don't axiomatically yield derivative works, they simply in practice do because for non-trivial programs they preserve copyrightable elements of the work in the output.
Well compilers are a mechanical transformation and if that were sufficient to free you of IP law then IP law wouldn't work.
An LLM is also a computer program which takes input and produces output related in some way to that input. However I don't think most people would view it as a "mere" mechanical transformation. One could tautologically argue that an LLM blends the user input with the training inputs which is a sort of transformation and further that the LLM itself is a computer program thus it is mechanical in nature. However it should be immediately obvious that such an overly literal interpretation is in danger of subsuming human work as well. Where the boundary lies is an unanswered question.
Related, compilers can pose a problem depending on what the output includes. For example common lisp compilers that aren't under a permissive license are a minefield because regardless of what anyone might say the image that gets output includes (approximately) the full language implementation verbatim in addition to the user's program.
functional parts not being copyrightable means that you can't claim a program is a copyright violation based on the fact it does the exact same thing based on compatibility reasons (you can copy what the program does). E.g. git stores refs in .git/refs, so does grit, that's not a violation. You still can't copy the program.
Yes... and now we get to the fact specific question of "did they copy the program". Or actually the answer to that is plainly "no" - they made something similar from it - and didn't run ctrl-c ctrl-v in an unlicensed manner, but "did they copy the relevant facets of the program into the new similar thing".
No. You're allowed to make a similar tool, the functional elements are not copyrightable. There's a long history, predating LLMs by many decades, of doing this in the software industry.
My use of the word "similar" does not imply here that I think it's obvious that they are "similar" in any copyrightable elements - whether they are or not is one of the interesting questions I think this case would have to resolve.
Incidentally you're also allowed to make similar creative elements so long as they aren't copies and you did so independently... which could actually come up in a case like this (imagine the LLM produced a similar function to some function in the original... but the original wasn't in the context window at the time. Not at all unlikely with code where there often is only one or two natural ways to write something).
I suspect that the issue is more likely that the LLM code doesn't have an author and hence some parts of it can't be licenses, it's less likely that it's infringing on git's copyright for various reasons. (I am not a lawyer, but I do read copyright law for funsies).
> It concludes that the outputs of generative AI can be protected by copyright only where a human author has determined sufficient expressive elements. This can include situations where a human-authored work is perceptible in an AI output, or a human makes creative arrangements or modifications of the output, but not the mere provision of prompts.
What makes you think that's what the article says that it did? There's a lot of specific nuance and it doesn't say that anywhere. In fact it speaks of making a test suite pass only. This is the classic cleanroom bios from specs approach but no need to extract it as the test is available to run and there's nothing in the GPL that suggests that running a test suite infects software that you run it on.
You've read books and they are in your brains corpus. You only infringe copyright if you reproduce the same actual words from the books in your memory (and then do infringing acts defined by copyright laws with that output).
Here that's not happening. The code being produced by the LLM is Rust, not C.
Knowing what you don't know is such an important skill in life and your career. And I 100% agree with you that the author is, well, off their rocker.
Let me give an example: I could take Goldeneye from the N64, extract the binary and then run it through an LLM to disassemble it and possibly rewrite it in a modern higher-level language. Do you think Nintendo would look at that and say "well, he did a lot of work so he's escaped our license"? Of course not. It's just silly.
ingesting the source code and producing output in another language is quite clearly a derivative work. You don't need to be an IP lawyer to figure that out.
Now, if you went to Calude and gave it documentation and told it to produce something that was compatible, would that be a derivative work and thus covered by the GPL? I would guess probably. But I'm not 100% sure anymore. I wouldn't risk it however.
Here's another thought experiment: what if someone takes this supposedly MIT licensed source tree, plugs it into another LLM and asks it to produce the output in C? Now how is it licensed? It might be very similar. After all, there are only so many ways to produce a SHA1 hash and so many ways to do a command line parser.
But this then makes it an interesting legal issue. In the Oracle v. Google court case, this was a key issue. Google successfully argued there's only so many ways to write a loop so just because a loop is similar to the source, that doesn't mean it's copyright infringement (as Oracle argued).
> Knowing what you don't know is such an important skill in life and your career. And I 100% agree with you that the author is, well, off their rocker.
They aren't the only ones - look at the number of people in this thread who are arguing that this is analogous to producing a movie with ffmpeg - just because ffmpeg is GPL, does not make your movie GPL.
I am struggling to understand how such a high level of cognitive dissonance is possible: They believe both a) that the license can be laundered in this manner, and that b) the license they put on the result is effective!
Well that is already how it is done with numerous multi-decade open rewrites of closed games. They usually require the asset pack.
I don't know how this squares with law, but Oracle v Google gave a very valuable judgment to the public that an API is not copywritable. If we take the LLM out of it, that's all we are talking about in the pure case.
Of course, we can't take the LLM out, but it is the starting point.
> Well that is already how it is done with numerous multi-decade open rewrites of closed games
Serious such rewrites don't start with the code of the closed game!
> I don't know how this squares with law, but Oracle v Google gave a very valuable judgment to the public that an API is not copywritable. If we take the LLM out of it, that's all we are talking about in the pure case.
Not at all. The LLM used to write grit has seen the git code. That is what we're talking about here.
> Of course, we can't take the LLM out, but it is the starting point.
The LLM isn't the important thing. The important thing is that the git source code was used to make grit.
This is not a proper black-box reimplementation, I doubt they can get away with that. And that's not mentioning all other obvious ethical concerns of course.
Not a fan of this trend of "cleaning" GPL licensed software and releasing under permissive licenses. Also why I'm not a fan of UUtils nor Canonical's early adoption of it in Ubuntu.
The intent here is extraction of all the value provided by copyleft projects without the obligation to give back. Wether it's technically legal or not, it's disgusting behavior IMO.
It is also rather ungrateful. The only reason we have Linux desktops today, and the only reason companies like Red Hat and Canonical has a billion dollar business model is the GPL.
The BSDs had a head start, and were superior in almost every way for the better part of a decade at least, but have remained niche compared to Linux. It's not even close. Now, there may be many other reasons to this, including the personalities and culture of the Linux developers, but you simply can't ignore the impact of the license which have kept all the commercial Linux products inside the fold.
I'm not a copyright lawyer, but it seems pretty clear to me you can't wash a license using an LLM.
[US jurisdiction]:
Anything in the result written by the LLM can not be copyright by anyone.
Anything in the result written by a human can be, and if it was all emitted by the LLM then that portion originally written by a human carries its own copyright.
As a work of an LLM, the entirety presumably can not be copyright, at all. Portions written by humans presumably carry their original copyright.
> [US jurisdiction]: Anything in the result written by the LLM can not be copyright by anyone.
This is a bit stronger than the actual report where this has been discussed finds. See part 2 in https://www.copyright.gov/ai/ for details, but TL;DR, parts where humans have control over the expression may be copyrightable. But working out which parts those are is likely a difficult question (would likely require proof of provenance across many of those LLM sessions)
It might have missing pieces, but it’s easier to vibecode any needed networking additions to Gitoxide (which is maintained) than to just go and burn tokens trying to clone all of git again.
Git wants to add Rust. Gitoxide is a multi year project that’s going to be more maintained than an ad-hoc “it says it passes the test” vibeclone.
I’m not even against vibecloning things when it’s useful, but this shows no benefits. Git is a beloved tool that few people dislike, it’s not like vinext (people disliking the vendor lock-in they have with nextjs).
Also execs should keep in mind that “we burned thousands of dollars on tokens to re-create this beloved software so we can have our own copy”, even without the copyright/licensing argument, just isn’t something positive that the community will react positively to.
It doesn’t feel nice to see your favourite works cloned for no benefit. We’re past the “it was an experiment to see how far AI can go” stage now.
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’m all for memory safety and such but honestly what’s the use case for this? Showing off agentic development? In 10+ years git has never failed on a memory overflow or else. Sometimes software is “good as is” and I’m pretty confident git classifies as such. I’ve also never really hit the limitations of git, even with teams of 20+ developers and lots of binary artefacts. You got to really stretch git limitations, in which case you might need to move away from git, and a rust rewrite will not help in any way whatsoever. So again … why?
I addressed this in the post, but Git has no linkable library and never has. If you want to do even something small, you need to fork/exec a process and communicate with it via stdin/out. Or completely reimplement it and all of the edge cases - for example, reading even one object can be either loose (easy) or in a packfile (much more difficult). Reading a reference (what SHA does a branch point to) can be in a loose file, a packfile, or a reftable. etc.
There is no way anyone would ever use this for it's CLI - it will almost certainly always be slower and worse in every way, even if I get it stable (which it's currently not). You can use libgit2 (a project I also helped kickstart), or Gitoxide (a project GitButler also currently helps drive) - they are faster and better in nearly every way, but they are not feature complete.
This isn't for the person using Git. This is for someone trying to build a tool that wants to use parts of Git, which is different.
But libgit2 exists, right? It may not have 100% feature parity with git, but that's a linkable library that gives you a lot of functionality when working with git repos.
the author of this post (whom you were responding to) made `libgit`, the library that preceded `libgit2`, and contributed to libgit2 a long time ago as well. Here he is in 2010 writing about libgit2: https://github.blog/news-insights/libgit2-a-git-linkable-lib...
I work on Beagle, a git-compatible SCM [1]. I use ABC, Abstractionless C [2] dialect with slices, optional range checking, etc. So far, memory safety was the least of my concerns, frankly. Most of the thorny issues would be equally thorny in Rust (e.g. right now: reflog zeroed when VM ran out of disk space; must be some state machine issue or an OS level glitch). Also, forking off a C process (no runtime) is cheap enough that you actually want to do that more.
But, those are all technicalities. The key issue I see with the approach: the data structures and algos of git have been fanatically fine tuned for that particular application with those particular usage patterns. By very sophisticated low-level C programmers. So, quite likely, any other app/lib working with that store will always be a suboptimal fit. I would recommend read-only access only, esp for LLM code.
Meanwhile, git's underlying data model (blobs/trees/commits) is very simple and very much internet-standard level. Decoupling at that interface is so much easier with so much less issues looming.
May look differently from your vantage point though.
I hadn’t heard of libgit2. I wish more applications would expose library-style access, preferably available across different languages!
May not work for apps that want to launch their own threads and processes. But for almost everything else, I prefer function calls to launching processes, managing their lifecycle, communicating via stdout etc. If I wanted to do that, I’d be writing Bash ;)
> This isn't for the person using Git. This is for someone trying to build a tool that wants to use parts of Git, which is different.
I’m going out on a limb here but I’ll say that you are over engineering for the wrong problems. I’ve done it before, I tried libgit for some use case. At the end of the day it really is much simpler to use git. If you don’t want git at runtime use something like the git-gradle-properties plugin or the likes for your build system of choice.
I really can’t think of a super duper use case where forking processes is a massive enough issue that I’d want to instead port over all of git to another language.
Git for the most parts also offers a wide variety of export formats such that you get machine readable output too. If you really really need to fiddle with its internals, git pack lets you browse through the index fairly well.
Again, my humble opinion, but you’re trying to solve the wrong problems
This year, none of them. Historically most or all. So that is another caveat. If all future lpe are logic errors I'd start reconsidering the value proposition. I do actually like writing rust though. I don't feel like it slows me down. I also love the simplicity of c vim and gdb, though my first exposure was lattice on the amiga 1000. I wonder if strict typing makes it take fewer tokens to find bugs?
Did you create this account just to lament rust hype? I mean, it is excessive. But I also don't think it is manufactured. We are more like some mostly benign evangelical denomination trying to get everyone to see the joys of Ferris.
Honestly, if the language actually looked nicer, great. But I mean the source code looks like a steaming pile of crate-includes. We can do better, seriously.
You have touched on my biggest complaint, the supply chain depth. It has definite advantages, but a signed and vetted set of crates is sorely needed. I could always just write everything my self like I would in c, but the crates are right there...
Currently some act like it is fine to translate a project and change the license.
Recently Casey Muratori said in a adjacent context that the microsoft AI push may be related to the fact that they have a long standing and elaborate codebase. A large historic software company could have advantages to train models. They could provide extra value with their IP.
Now their IP is potentially in their models and accessible to anyone. If they actually train models on their IP, anyone could implement their APIs and slap a GPL license on it.
A lot of their IP has been leaked over the years anyways. Source code of Windows XP is easily available, and there was the 2022 leak that contained the sources of Bing, Bing Maps, Cortana, etc
This is simply plagiarism of GPL-licensed code, and license-washing as well.
I can understand working backwards from a test suite, but this literally just reads the original source:
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 terrified that this somehow seems acceptable to a large group of people.
I'm baffled that other IP holders (say those who own valuable pieces of proprietary software, or music, or movies, or even the LLMs themselves) don't think leopards will come eat their faces next. This erosion of IP has to stop, or anyone who does any intellectual work will be absolutely screwed. If that only meant FOSS people, I'd be worried that we'd just be thrown out with the bathwater – but surely this applies across the board!?
> The people doing the intellectual work are usually not the primary beneficiaries of IP laws. In fact it often constrains them unnecessarily.
In the sense that most people doing intellectual work do that work for someone else (say, a company) that you consider the primary beneficiary of IP law? Sure, fine – but this applies to almost any other type of work and the legal constructs that are in use there too, so it's not really a very useful distinction to make, even if technically correct.
Of course they are afraid of it, haven't you seen Dario being angry of Chinese companies paying for Claude access (tokens = test cases) and training their own model from those?
I'm well aware of situations of potentially upending changes where the rich and powerful stand to gain, and the little guy's worries are ignored.
This, however, is clearly a potentially upending change where also lots of the rich and powerful – including those who control the very technology driving the change – have everything to lose. I'm surprised, to say it mildly, that nothing seems to be happening. Does Dario really believe that a strict ToS and stern words will keep his IP protected without appealing to the legal system? (I guess that is par for the course for the people who "solve" world problems with bunkers and armed guards…)
How does intellectual work happen (beyond doing it for leisure) in a world without IP?
In a utopian world of abundance where we could all be the independently wealthy nobles of the 18th and 19th century who did intellectual work for fun: great. In the world of today where people need to be compensated for their work: what happens?
Any way anyone who wants, wants, that doesn't rely on legal control of information. There are infinite uncopyrightable things that never the less get done and make people a lot of livings.
I only said "might" and the point was obviously not the immediate surface idea but to point out how the tool of IP is not applied to everyone's benefit equally, but used only against some and only for some, with a side of "You know, fuck it, if they insist on making it worse, it becomes less crazy to consider just burning the house down".
But What are you so afraid of that you react only to the hypothetical as though it were the worst danger?
We'd actually manage to get yoked and abused by the same people no matter what the rules were, don't worry.
I'd add: why bother... except for fun. We shouldn't discount enjoyment as motivation. But I otherwise agree wholeheartedly with you. We need intellectual work that goes beyond "just for fun" as long as most people have to work to live.
> It's like giving wishes as a genie. You gotta be super explicit with the ground rules.
I have used the genie analogy before. It used to feel more like a Golem but now with the whole Fable sabotage mode https://jonready.com/blog/posts/claude-fable5-is-allowed-to-... it certainly feels more Genie-like.
Previously I described it as "Models give you what you ask, for not what you want". Now with Fable they don't even give you want you want so idk.
I'd be really interested in the opposite, just for the sake of experimentation since that's what these projects mostly are. They all seem to be rewrites for the sake of "performance", because the cost is now lower bc of AI. I'd be interested to see something like a port of Quake III in Python or Kubernetes in Perl, even Rails in Python would be goofy and really fun to see
For Natural Selection 2, it was mainly the gameplay logic that was Lua, all running on their bespoke C++ game engine called Spark. But yeah, modern Python and Lua can be pushed to high performance.
Ah my mistake - I know they ditched Source to pursue their own engine and thought they were going all in on Lua, but doing the whole engine in Lua would have been a struggle I think.
> They all seem to be rewrites for the sake of "performance".
And yet this performs dramatically worse.
A slower, untested, incomplete git implementation, all for the low low price of $10-$15,000.
And don’t forget it wasted a bunch of human time in the process.
So if someone mentioned somewhere else there is already a Rust port a group is doing somewhere. How much could they have accomplished with this much money and time in software development resources?
Ok. AI can seemingly port stuff if you don’t test it thoroughly. I think that’s already been proven. At this point I’m seeing less and less value from these kind of things. I’m sure it was fun for the author, but how does it help other people?
If the first stereotype of Rust programmers is announcing that a project is in Rust before any other desirable software property (e.g. stable, performant, etc), the second stereotype is that Rust programmers love rewriting stuff in Rust, just for the sake of Rust.
(The 2.a. corollary is that they love rewriting GPL projects specifically and downgrading them to MIT/Apache)
But there is already gitoxide, an established git reimplementation in git. It even provides a library
gitoxide was started in 2018, back when we were all writing code by hand, and has some reasonable adoption in the rust ecosystem. It's not feature complete, but if that was the issue then surely fixing that would be better than starting from scratch
Well, it's sort of for Rust. GitButler is written in Rust and Jujutsu is written in Rust and we're both depending on fork/exec'ing to an unknown Git binary with no linkable library and no control over the subprocess to do a range of networking stuff. Neither Gitoxide or libgit2 are capable of this either, as much as I love and support those projects.
This project is entirely about providing a feature complete (even if sloppy) library implementation of Git, which does not otherwise exist.
But... it's memory safe. Not that git has any important memory issue, but now people with skill issues in C can contribute to it without breaking stuff.
> They all seem to be rewrites for the sake of "performance", because the cost is now lower bc of AI.
If that was true they'd use the original license. They are not. The whole RiiR movement is very obviously switching away from a pro-user license (GPL).
> A pretty fun experiment and I think we can shape this into something truly useful to the whole community.
Agree with first half of this sentence, we should all have fun with experiments.
> It was never based on a linkable and reentrant library, but instead on a "Unix" philosophy of chaining together simpler commands, which means that it's difficult to use it in long running processes without fork/exec overhead for everything.
> It was never based on a linkable and reentrant library, but instead on a "Unix" philosophy of chaining together simpler commands, which means that it's difficult to use it in long running processes without fork/exec overhead for everything.
Added it in full. It still squarely falls under "this is for fun/are you seriously doing this for this purpose" territory for me.
git operate on the filesystem level, the unix behavior is just getting buried. You cannot rewrite git into a linkable library and decide it's now not unix. It's entire behavior is unix, which is why it's awesome.
My intent with this project is not to replace Git in any way. I don't care about the CLI part of this project.
The point is to provide a feature-complete reentrant linkable library. Even if it's an ugly and slow one, this is still the only one thing that exists that covers those points - Gitoxide and libgit2 are both awesome but they are not feature complete.
Git is famously not built around a (reusable) library, hence why we have things like libgit2 (unrelated to git) and why any porcelain on top of git has to resort to calling the binary and parsing its text output.
libgit.a isn't reentrant. It will call `die()` on many errors. If you link to it in a long running binary, it will kill your process on error.
Libgit2 is meant to address this and I was heavily involved in the development of that project 15 years ago. It's great but it's not feature complete and it's development is also completely separate from git development, so it's out of sync and constantly struggling to keep up.
This is a problem with people with LLM psychosis who now think they have superpowers, they are completely unaware and just do things naively, they've lost all ability to think for themselves. The LLMs that are thinking for them certainly aren't going to tell them doing X is a bad idea, they're there to produce as many tokens as possible for their owners.
This is coming from a cofounder at github, someone who probably knows precisely what the GPL is for. Whatever the legal merits, building on a GPL3 project's complete test suite and relicensing under MIT is not acting in good faith toward the original authors. I really find it disgusting and it makes me want to avoid gitbutler entirely.
I think you're saying that you don't believe in the freedoms to use the GPL licensed test suite for certain purposes which are explicitly allowed by the GPL.
You don't get to choose a license and then add extra terms to it when you don't feel like it's up to scratch. That's something explicitly not allowed by the GPL license.
> Where does the GPL say you have the freedom to relicense code or derivatives under MIT by fiat?
The first part of this sentence (where in the GPL) is unreached if the second part of it is unmet (relicense code or derivatives) which I contend it likely is. You're begging the question.
However:
> The output from running a covered work is covered by this License only if the output, given its content, constitutes a covered work
earlier:
> A “covered work” means either the unmodified Program or a work based on the Program.
It's that element that would be difficult to prove "work based on the Program"
Asking an LLM "here's a thing, rewrite it in Rust" is pretty clearly creating either a derivative work or a different form of the same work, just like asking a transpiler would.
There's no evidence that "here's a thing, rewrite it in Rust" is the technique Scott used here.
"here's a test suite, write code in rust that makes that suite pass" is reasonably supported by the article. That would likely not be a derivative work.
Ew. So it tells the LLM where the git source is for the thing they’re duplicating, but I don’t see instructions saying not to read or copy those files or algorithms.
I could have missed them. I didn’t read everything. I did some quick searches.
But the fact they’re not obvious is kind of troubling. Or that they didn’t just copy the tests and documentation for the LLM and not the source to prevent it from looking would hurt any case they had for clean-room privileges in my eyes, ignoring my other comment with concerns about using the tests at all.
If we assume an u licensed or MIT licensed test suite, an LLM could develop from that and documentation and you’d get something you could license MIT.
IMO, IANAL, etc.
And we’ll ignore the question of what the fact the LLM has certainly seen the git code during training means.
But the test suite would have to stay under the original license. And if you use a GPL test suite as they kernel to develop a program from can you license it non-GPL? I’d question that personally. Same acronyms above apply.
This is the exact thing I'm not sure about. See https://news.ycombinator.com/item?id=48470397 where I posit a simpler question: if a `test_sum()` function is copyrighted, does writing a `sum(a, b)` function infringe on the copyright of the software product that `test_sum()` is a part of. I'd say no. There's another part of the GPL that applies here:
> A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.
So assuming that sum(a, b) is non-infringing and not combined to form a larger program (i.e. the tests aren't compiled into the grit code), then the GPL explicitly doesn't apply to this use
test_sum is assumedly relatively trivial. So as a lay person I’d expect some sort of obviousness test to apply. Like so much of the stuff in the Google/Oracle lawsuit.
But if you take all the individual tests used to test git as a whole, that seems far more unique. Seems like at that point you’re really having to duplicate the actual git internals, and that seems like it should be covered.
> test_sum is assumedly relatively trivial. So as a lay person I’d expect some sort of obviousness test to apply. Like so much of the stuff in the Google/Oracle lawsuit.
Feel free to extrapolate to the threshold where it's not and at that point apply.
> you’re really having to duplicate the actual git internals
Copyright covers the expression, not the method. So the Rust function:
You're asking people to trust you and hand their codebase/IP to your tool while showing them exactly how you treat other people's code/licenses by "deciding" to not carry forward the GPL license.
It'd seem weird to plan to use this until the readme stops saying
> it has been nearly entirely written by agents and has not been used for realsies. It's probably currently unusably slow or completely broken in ways that are not exercised in the test suite.
Right now it's someone else's experiment that is still in the "might or might not pan out" stage.
There are a bunch of projects using the similar (not vibe coded, less fully featured) gitoxide project - there is demand for git-as-a-library.
I would not use this except to help us test it if interested. I'm announcing it because it's interesting and a milestone in the breadth of test coverage it can pass. It almost certainly cheated on a bunch of those tests and is not feature complete yet.
The author of gitoxide is also working on GitButler (who worked on this project) and we're pushing both projects forward and actively using and developing Gitoxide as well. This is simply a different and hopefully complimentary approach to the same problem.
> because it's interesting and a milestone in the breadth of test coverage it can pass.
Sorry, no. Let me be candid and point out that this has achieved exactly nothing except lighting $8k on fire.
Put it this way: if I suggest to my boss, "I want to spend $8k of company money to port git to Rust to just see how many tests can pass in that project, even though I don't plan to develop new features with the project, and I don't care about adoption", he is going to shot down the idea in half a second and seriously question my competence.
I was immediately excited about this wrapped in Python because the current Python git bindings are kind of obtuse, but they do work so I guess I can't complain.
Wordpress is/was successful because it's braindead and has a solid userbase. I am not to flame WP, but it's a quality to target a specific group of consumers.
It's an organic success, hard to replicate. If at all, CF can only make people migrate with massive effort. Marketing effort, selling lots of snake oil in the process. WP wont just hop on the hot new thing, WP is the definition of the opposite. It works for them. Why change.
Git is the same on the other side. It requires maintenance and improvements, surgical and correct. No git maintainer has time to learn a gigantic new codebase and they will stick with what works for them. For git users there are no advantages. So similarly it would require a long time effort to push the project, building trust that it is somehow better, probably requiring Linus to say "it's great".
> The full build of all Git functionality in Rust is currently around 27M, but since a large part of it is a library, it could clearly be easily split up into domains of functionality - subcrates that do specific things.
I downloaded v0.3.99 for Linux x86_64 and stripped the binary. It ends up at 31 MB. The .text section is 25 MB.
I'm surprised by the large size. On my system /usr/bin/git is 4.7 MB, although git is split up into multiple programs. I'm not comparing apples to apples, but this is weird.
If anyone digs into the binary size, please share what you find.
I haven't dug into this at all yet, nor have I tried to optimize the size (or really, anything else).
However, the library part will be less than half of this - a lot of code is spent on the CLI specific stuff and would not be part of the library, which is mostly what I care about for the purposes of this project. The CLI part is just to try to prove the point that it actually does what Git does. The library part is what might be useful in that nothing else exists that does all of the things that it does (provide a reentrant linkable library that is feature complete with Git).
Looking at just the `grit` executable, 58 of the top 200 largest file->resulting code sources are from clap-rs' derive functionality i.e. it's the command-line parsing. The #1 largest is, surprisingly, merge_trees[1] which comes in at 183kiB final binary size. There isn't so much code in that file that it seems reasonable, so it's potentially one of the derives in use (Debug being a common culprit for bloat) that's blowing it out. After those outliers it starts to level out quickly.
Splitting it by crate: `grit` is 13.6MiB, `grit_lib` is 4.8MiB and then it's `std`, `rustls` and `regex_automata` that are the next largest. So as pure library you could hopefully shave off quite a bit of that 25MiB.
Nice, I haven't dug into this yet. If we can get this usable, it would be pretty cool to have a small lib or a series of much smaller, directed libs that can be used by simpler interfaces and you can just compose the parts you need.
I have been working on the same problem in other areas. My ultimate goal is to rewrite nginx in Rust passing as much as the upstream tests as possible while leveraging the strongest aspects of Ruts ecosystem - i.e. rustls (modern memory safe OpenSSL), Tokio (async runtime), h2 (http 2 impl) rather than implementing from scratch like the upstream. I started with Lua, then porting over Valkey, and now working on nginx. The reason was because I wanted to learn the ins and outs before taking on the most complex portion.
Happy to answer any questions on the approach! When I started a few weeks ago the harnesses on their own were not good enough to get very far without a "meta harness" of sorts but that is changing largely with Claude Workloads and Mythos. A lot of the work is developing some custom tooling to move these along faster.
Yeah I got one, why? You aren't learning anything, you are just copying code from other codebases and smashing it together to make some nginx-rust thingie... for what actual goal?
Well the biggest goal was to be useful. Nginx serves ~20% of the web, memory unsafe languages might just become untractable for critical exposed to the web infra if the rate of critical CVE's on these rises faster than they can be patched, so a drop in replacement would be a big deal in that world.
But in terms of learning I'm learning relatively little about how to type Rust into an editor but a lot about how to set up agentic loops that can autonomously get tests to pass and improve performance.
For example if you just tell a frontier model (gpt5.5 or Claude Code 4.8) to make some portion of the tests pass they will take forever and just bang their heads against it. I developed a framework to mimic a lot of these tests in nginx... but in minimum non blocking ways so you can run many in parallel with short feedback loops.
Similar for performance - how to make tons of performance benchmark and expose maximum telemetry for agents to go and analyze the hotpaths etc.
> Nginx serves ~20% of the web, memory unsafe languages might just become untractable for critical exposed to the web infra if the rate of critical CVE's on these rises faster than they can be patched
That is true, however did you actually do any research into nginx? Is it particularly prone to memory bugs?
I honestly don't know the answer but you seem to be coming from a place of C bad, therefore nginx super vulnerable?
In my experience with other web servers the vast majority of security bugs are string handling related (path/header injection), which your rewrite will not protect you from.
The project was inspired by that. Also unlike most other projects, nginx is directly exposed to the internet often times which makes it more vulnerable than i.e. Redis/ Valkey or something that would be running within a companies network generally.
"C Bad" is a bit reductionist... but I think there is some truth to the take " Until you have the evidence, don’t bother with hypothetical notions that someone can write 10 million lines of C without ubiquitious memory-unsafety vulnerabilities – it’s just Flat Earth Theory for software engineers" [1]
NSA and other government orgs are also pushing people to stop using C [2] for important software.
I think the risks of a rewrite - especially when using AI - are far more problematic than memory safety. In the long run those C projects will be memory safe in the next five years using memory safe C implementations.
My perspective is that it is good to have a beta in a lot of directions.
No one really knows what the endgame of software security looks like.
So some people should try the port to rust angle, some should focus on hardening the C, some should explore more exotic options like formally provable languages etc
There is nothing wrong with trying different things. But the fundamental problem here is that projects and their communities are social projects and need to be to fulfill their purposes and to ensure long term maintenance. In a free software context, rewrites just like forks (1) are fundamentally an asocial (2) activity because they fragment the community (if successful) and then increase overall maintenance burden if not able to replace the original project completely (rarely the case). Disrespect the license choice of the original authors makes this worse.
1) There may be situation were are fork makes sense (e.g. because one project can not serve different use cases well):
2) Which is why usually a "higher goal" is used to justify this, e.g. authors pretend (or lie to themselves, or may be be stupid enough to actually believe this) that some improvement in memory safety is really that important.
You won't get anywhere pressing your case here. This group has already found you guilty, and no argument will change their minds.
You've been caricatured into a blind AI-follower rust-rewriter-just-because type, and that's the surface they'll continually attack (you're wasting time, hurting the community, v2-itis, bikeshedding, premature optimization, copyright violation, moustache-twirling-evil-intent-rug-pull-later, etc etc etc).
Just continue in your work. It's good, and we need people like you.
Please excuse me for being unnecessarily harsh for a moment, but web servers are a dime a dozen. Quite literally. The reason nginx is successful is because it is maintained. Unless you plan on maintaining your nginx-clone as well as nginx itself, it will not be useful.
Perhaps you do, in which case I am more than happy to be wrong, but sometimes people think the act of writing software itself is useful and that other people will happily swarm over it and maintain it in their absence, but that is usually not the case.
The world has tens of thousands of http daemons, increasing that number by one is not useful in itself. The act of maintaining software over time and keeping it useful for many people however, absolutely can be.
You mean you rewrote the nginx test suite with smaller leaner tests ? How did you bootstrap that ? How do you know the leaner tests are equivalent to the real ones ?
Basically I use these "kits" to prove that the behavior is working as expected with mocked data/ interfaces and then only after these kits pass I'll run the real test suite files as confirmation. So these let you iterate a lot faster than the official test suite because it is very slow.
These are bootstrapped from the real tests.
The other commenter was being a bit dismissive but this is the kind of thing I'm taking away as a real useful pattern to do verification of behavior at scale.
There are plenty of Rust based reverse proxies out there, why do you need to specifically rewrite nginx? You could also write a config adapter to Caddy, there are a billion options, but this is a wasted effort. The people who want to stick to their nginx configs won't use your project ever, and the people who actually care about security aren't going to use a vibe coded project.
I have no idea why you are making me spell this out, I thought it was pretty obvious.
What’s the long term strategy for this code base? Does the author expect community code contribution or just bug reports or maybe just test contributions?
I'm happy to take contributions if you want to throw some tokens at it. Bug reports would be amazing, since I haven't tested it for real very much (enough to know you can do basics).
I want to get it to the point where we can replace fork/exec'ing to an unknown Git binary or having said binary be an external dependency for GitButler. The networking stuff (push/fetch) is currently an external dep for both GitButler and Jujutsu (and pretty much every other Git-based tool in the world). I'm pretty sure I can get the project good enough at these networking ops (including all the hairy credential stuff) to be able to not need those fork/exec calls.
The agents did all the work but _somebody_ has to test it for real on their own data to find the edge cases overlooked by AI. That's what users are for nowadays.
The pattern I see here is people vibing slop rewrites of GPL projects to get them under more favorable licenses. Rust just happens to be the language this one picked (for various reasons that are not very relevant here.)
Goal is to be able to transfer context from one agent to another when switching which provider is being used. So when i hit usage limits on claude i can can run handoff claude codex and codex is given a md file to start from and continuing working.
Still early but ive found it useful in my daily flows already!
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.
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.
Grit was the name of a _Ruby_ implementation of git way back when: https://github.com/mojombo/grit/. I believe it's actually what GitHub was built on then.
I created and named the Grit library that used to power GitHub. Scott Chacon (fellow GitHub cofounder, now CEO of GitButler) specifically asked my permission to re-use Grit as the name of this project, which I gladly granted. R is for Ruby. R is for Rust! Grit is dead. Long live Grit!
I started the project as Gust, but felt like Grit was such a better name. I asked Tom if I could boot the name back up again because I always liked it and he said it was fine.
Also, I worked on the Ruby Grit pretty extensively during the early days of GitHub, so hopefully I earned the right to carry on the mantle. :)
I hate all you llm people, you're ruining everything, shoving slop down everyone's mouth and telling us you now have superpowers. No you're stealing and making everything as shitty as possible in the process.
I pray everything switches to usage based billing and the curtains can close on this era.
> Currently both Gitoxide and libgit2's networking functionality is either partial, slow or non-existant. Both GitButler and Jujutsu rely on forking out to Git in order to push or pull data. A big reason for this is the incredibly complicated credential logic involved, but all of this is (theoretically) currently covered in Grit.
if we conquer the universe, i would love to leave one planet alone for rust users. in this planet, the only allowed programming langauge is RUST! everything should be written in RUST
> Another possible use case is a WASM build that could be used to do a super wide range of interesting things. Run nearly any Git command in an edge Vercel function for example. Or maybe you could build things like Cloudflare Artifacts without relying on partial implementations like isomorphic-git but instead a fully compliant WASM build of Grit.
> You had me at WASM...
What does this mean? Does the OP want us to convert his AI-vibed code to a WASM-compatible build? Does the OP even understand what that entails?
they still haven't explained why I should bother. Is it faster, easier, more efficient, more capable, more scalable on large codebases, supports better workflows?
In fact, I would rather it stay C for 15 more years.
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.
I'm exhausted seeing this same mistake happen over and over and over.
Why nobody tries to write a spec from existing code is just crazy to me.
The git test suite is a behavioral spec. But at the same time it is not, why? It's archaeological site... I'd say. You can dig, and dig, and dig, and find some truth, but also a lot of historical decisions that doesn't matter today.
Here's the flow I suggest:
- first, reverse-engineer the behavioral intent from tests/docs/code
- build a taxonomy of what git promises
- group that into small "conformance slices"
- hand those slices to agents/humans/whatever
- start writing Rust... Or Visual Basic... At this point it doesn't matter almost
Without this critical layer, agents are optimizing for "make this test green" instead of "preserve this semantic contract". And this is exactly where the funny stuff happens... shelling to real git, hardcoding expectations, implementing sha256 metadata but not the behavior, etc.
Why are we doing stupid things and winning stupid prizes? I have to admit they are impressive, but I STRONGLY believe if we did this in two passes you would have not $15k check but maybe closer to $1-5k.
Who should I talk to, to make this happen? Making the first pass is almost deterministic. LLMs help. The only problem is making sure that YOU understand the spec, and this will be a bottleneck for a while (i.e. can't outsource understanding).
I can guide what exactly needs to happen. I already validated this idea on my own project and it worked: 10k LoC -> 250 acceptance criteria. And you can find it on my GitHub, I even described steps. If you're too lazy here it is:
You need a SCIP graph. Agent goes over it and builds ledger, one symbol at a time, looks at what kind of problem this symbol solves. This leads you to v0 specs, then you can figure out taxonomy, then you try to fit all those thousands of specs into taxonomy / groups that make sense. And that would be v1 spec but you might want to refine it to v2/v3. And then the only thing would be left is figure out what kind of tests those specs should have (e2e/unit/integration/api/whatever). This is tricky part but doable. I'm thinking for git you wanna do e2e specs. Yes, that's a lot of e2e but the purpose is that we build same expectations for git, and then we replace git with grit and spec should still stay green, right?
In the age of AI, writing things that used to take years can now be done in months or weeks if you have deep enough pockets for it.
Reimplementation is a particularly juicy target because it's easy to test. Imagine someone writing a better browser than Chrome from scratch in just a year.
Because of this moats around business due to difficulty of implementation are effectively gone.
> the result is Grit, a from-scratch, library-based, memory-safe, idiomatic Rust reimplentation of Git that passes over 99% of the entire Git test suite.
Why not 100%?
> It's not actually passing every single test, though that is on purpose. I did mark some parts of the testing suite as "skipped" because I don't think it's worth recreating them in a library like this
> 41,715 / 42,001 tests passing (99.3%)
So it is not entire then but somehow that was worth burning $8,000~ dollars worth of tokens?
> It's not actually passing every single test, though that is on purpose. I did mark some parts of the testing suite as "skipped" because I don't think it's worth recreating them in a library like this - email related stuff, i18n, perforce/svn importers, some of the midx/bitmap stuff - things of that nature. However, for everything that I'm sure is relevant to nearly anyone reading this, the Grit library/CLI can now fully pass the Git test suite.
I think we are talking about ROI in terms of solving real world problems and making real impact, not the fact that a tool has been ported from language X to language Y.
Given the author already admitted that the implementation was slow anyway, you are no better off of using gitoxide instead and that has support for Windows where-as Grit does not.
> Currently both Gitoxide and libgit2's networking functionality is either partial, slow or non-existant. Both GitButler and Jujutsu rely on forking out to Git in order to push or pull data. A big reason for this is the incredibly complicated credential logic involved, but all of this is (theoretically) currently covered in Grit.
> One of the main things I would like to be able to use it for is to be able to bundle complex push/fetch functionality into GitButler and other standalone Git tools needing network functionality (such as Jujutsu).
> Having parts of Git as discrete, embeddable slices of library also enables things like building custom Git servers or client functionality in Rust.
> The full build of all Git functionality in Rust is currently around 27M, but since a large part of it is a library, it could clearly be easily split up into domains of functionality - subcrates that do specific things. Perhaps you could simply use the subset you need.
The article starts out with paragraphs about the history and motivation.
> it made me wonder about the feasibility of using that same approach to accomplish something I've been dreaming about for 15 years now,
> which means that it's difficult to use it in long running processes without fork/exec overhead for everything.
> What if we used the same basic idea that Anthropic used on their from-scratch C compiler? Start a brand new implementation, design it as a Rust library, then throw a swarm of agents at the problem
There is often good reasons for these purposeful digressions. I.e. in nginx the unit tests cover cyphers that are considered unsafe and not supported by modern libraries like rustls https://github.com/rustls/rustls. It is reasonable to make a new implementation and leave behind a bit of baggage.
It depends whether the 0.7% failures are testing deliberately unimplemented features like email or is in corner cases in implemented features. It sounds like it's at least mostly the former, hopefully it's 100% the former.
I don't care if any git I use has email features. IIUC, even most of the people that use git with email don't directly use the email features, they use the patch set features like `git am`. I expect `git am` to work, I don't expect git to actually do email.
> In looking at the code that the LLMs have produced for the project, especially given the pretty massive and widespread architectural changes needed to make the implementation libified and memory safe, we decided that the codebase is not a derivative work that would require carrying forward the GPL license and have decided to release the code under the MIT instead.
Hmm. That's going to be interesting.
A translation of a book to a different language is a derivative work. So a translation of a computer program to a different programming language is also. But if in the translation of the book you start altering the plot and the personalities of that characters, does it at some point become not a derivative work? What point? IANAL, and I have no real idea, but I imagine that point has been probed significantly in case-law with respect to creative works. Given the current climate of ever-expanding scope of "intellectual property", if they admit that the LLM had access to git source code then I would say their case is weak at best.
The agents.md says “here’s the git source code” https://github.com/gitbutlerapp/grit/blob/main/AGENTS.md#sou...
This isn’t even a question of training data, thy fed the full git source code directly to the llm.
I would say it's worse, the whole C Git source code is checked in https://github.com/gitbutlerapp/grit/tree/main/git
I wonder if imitating clean room reverse engineering with two LLMs would be enough for licence compliance.
That already exists[1]. It looks like a joke but apparently they will accept your money to do it, which seems to cross the line of a joke.
[1]: https://malus.sh/
> translation.
It's not technically a translation, it's a re-implementation, with test suites acting as the destination. If it was a file by file translation your argument would have been valid.
Git is part of the LLM's training set though, so simply asking it to recreate git in another language is pretty equivalent. Like, you can almost certainly get these LLMs to output gits full source code with some prompting, so there's not that much difference (as much as we like to pretend that AI generated code has no copyright implications)
As mentioned in another comment, it's even more clear cut in this case. They actually put the original git sources in their project repo and instructed the agent to use it as the "source of truth".
Simple thought experiment. If you handed this same agents.md file (https://github.com/gitbutlerapp/grit/blob/main/AGENTS.md#sou...) to a human software developer and let them work on exactly the same goal, would their output be considered a derivative work?
That's something I have been wondering. If I as a human want to make a clean room reimplementation of some API or application, I must not have read the source code of the original implementation. I don't see why this shouldn't apply to LLMs as well. If an LLM might have been trained on the original source code, it should be considered "tainted".
Yes, and realistically any code that LLMs produce is a derivative work of its training data. There's going to be a huge disaster licensing wise
I have absolutely no idea how LLMs got through anyone's legal departments, I guess the hope is that if everyone breaks the law enough, it'll just be fine
> the hope is that if everyone breaks the law enough, it'll just be fine
Ever since the early 2010s when companies were started with the business idea "unlicensed hotels" and "unlicensed taxis" and made the owners really, really rich, this is said pretty much out loud. Look for words like "regulatory risks" and similar.
Maybe it started with the unlicensed gambling fad before that? That also made a lot of people filthy rich. Every time you have something under special license, or insuance requirements, then of course there is a margin for you if you can skimp on the license and hire gig workers instead.
The LLM situation with copyright and derived works in the 2020s is similar. Someone is likely to be rich, but there is a clear regulatory risk to it.
> if everyone breaks the law enough, it'll just be fine
That's pretty much what happened, isn't it? These concerns were all discussed in the beginning back in 2022, and I recall answers from many here on HN along the lines of "oh well, we can't stop it now or we'll risk falling behind China in AI development"
So yeah, the laws went out the window a long time ago the moment our government and the people decided to just look the other way willingly in the name of "progress."
Problem is there's a lot more than a single repo in training data, the corpus is massive... Should the author of a blog post on cats also be compensated for simply being in the same training data as the git repo?
Honestly? Yes. This is why its such a problem that most of the training data was not used with permission, and without the correct copyright status or license associated with it
There's a lot of arguments about humans doing the same thing, but the reality is that humans and robots don't enjoy the same legal protection. Its clearly a derivative work of all of its training data
> Honestly? Yes.
Then it works both ways. Say I manage to generate essentially a ripoff of your copyrighted song, release it and make a ton of money, you now have to split that royalty with keyboard cat. And Joe bloggs. You'd end up fractions of pennies
> If I as a human want to make a clean room reimplementation of some API or application, I must not have read the source code of the original implementation.
That is the difference between necessary and sufficient. Clean-room is sufficient to guarantee avoiding copyright, but it is not necessary. The line legally is south of there, but that position was chosen because they didn’t want to crossing and it was easier to argue for legally in court.
tl;dr: clean room is overkill for avoiding copyright infringement
> Like, you can almost certainly get these LLMs to output gits full source code with some prompting, so there's not that much difference (as much as we like to pretend that AI generated code has no copyright implications)
Are you sure? LLMs are in some way a compressed version of their input but it's a pretty lossy compression (arguably this makes them more like a compression algorithm than a compressed version of the data). I'm not sure you can prompt a full, accurate, copy of a nontrivial codebase out of them. Even with zero temperature their accuracy is just not that high.
> I'm not sure you can prompt a full, accurate, copy of a nontrivial codebase out of them. Even with zero temperature their accuracy is just not that high.
Granted, these are some of the most widely spread texts, and not codebases, but just fyi: https://arxiv.org/pdf/2601.02671
> For Claude 3.7 Sonnet, we were able to extract four whole books near-verbatim, including two books under copyright in the U.S.: Harry Potter and the Sorcerer’s Stone and 1984 (Section 4).
That paper is basically using the LLM as a compression algorithm: it's prompting with some section of the book and it's reprompting if it doesn't give the right output. Notably this only works if you already have a copy of the book in question!
Distributed a compressed copy of something is still copyright infringement
You misunderstand my point: the LLM is not a losslessly compressed version of the text: you need to supply additional information from the original in order to 'extract' it from the LLM (and from that point of view, the extra information would be the compressed form).
Wouldn't a re-implementation be akin to 'heres how it works, write the code' rather than 'heres the code, redo it in rust'?
Yes, but as soon as copyright became a problem for very rich people parts of it were cancelled.
1) re-implementation for compatibility (which was quickly "reestablished" through use of copyright-protecting encryption. In other words: do you get to write software that connects to MS/Apple/Google/Facebook servers without authorization from those companies? Yes. Do you get to copy an encryption key from their software to make it possible? No)
and, more recently,
2) violating copyright for LLM training
and, currently mostly attempted:
3) "uncopyrighting" run software through an LLM, and some people "believe" it comes out with your copyright on it! Because very rich people want to sell uncopyrighting.
Ie. the jury's still out what will happen when it's billionnaire vs billionnaire.
Of course, the question is what happens the second someone does this with a disney movie, or a big microsoft application ...
> Yes, but as soon as copyright became a problem for very rich people parts of it were cancelled.
When copyright law was established, not many poor people owned printing presses. That is to say, copyright law is a PROTECTION to the very rich, not an inconvenience
true but as the exception for model training (which can only be done by very, very rich people and organizations) shows, there's some new rich and they want new rules.
Against the will of the people, as evidenced by the court cases and protests online ...
Related, software API compability is not a derivate work, or eligible to protection, as ruled in the US and in the EU. Google, SAP R/3, etc. cases.
Or SCO Vs IBM.
If everything would be a derivate work we would not Linux.
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?
https://blog.gitbutler.com/series-a likely has a large part to play in it.
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
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.
Oof, thanks for the correction.
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."
Many eyerolls.
err my gud a ceo on haxer news.
Hey AI, please change my stolen code in a non-breaking way so that jplag reports less than 1,8% similarity.
I mean ”hey artist, take this stolen character and make them legally distinct” is already a common thing.
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.
Mickey Mouse was already a legally distinct Oswald the Rabbit.
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)
> Would you be happy for someone to do the same with the GitButler source code?
Honestly, that would be pretty awesome. We would be flattered.
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.]
Missing an 'f' in the project name.
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.
I mean, yes, clearly, LGPL is the explicitly obvious answer here. And they rejected it.
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.
(BTW im not a lawyer)
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.
GPL makes sure that the code remains open. Seems like these new gen devs are against open source.
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.
I removed it but I added that I hate these people. :P So yeah, it pisses me off, too.
"Don't hate the player, hate the game" as they say.
People want to get paid. They perceive the GPL as getting in their way.
Or, as it is also said: “It is difficult to get a man to understand something, when his salary depends on his not understanding it.”
s/open source/free software
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.
Yeah, pretty much. :)
Is there a point in license laundering? Where GPL stifles git adoption?
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).
Man, all they had to do was LGPL it and there'd be no ill will.
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.
they would be just wrong. I hope someone with standing sues
I don't think it's that clear cut. The functional parts probably aren't copyrightable, only the stylistic ones. It's going to be a mix of courts applying laws in new ways that hasn't been done before and fact specific questions about what actually persisted through the LLM if it goes to court.
I'd be fascinated to see what happens if it does. Both in the analyses that we'd get of what the LLM did to the codebase and on the legal decisions on what the copyrightable creative elements in code actually are.
If I was the author though... there would be no way that I would be volunteering to be a test case like this. Also seems just rude for no reason.
It probably would have been less bad if he had chosen MPL-2.0 or LGPL-2.1-or-later. But he chose MIT, which cuts at the core of the intent of licensing the project with a share-alike license.
Tell me, can I create a copyrighted video that's not GPL licensed using ffmpeg? Now tell me how creating a rust library using the git test suite is different?
> using the git test suite
That's not actually the case at hand here - the agents were given the original source to reference: https://github.com/gitbutlerapp/grit/blob/main/AGENTS.md#sou...
But for the sake of argument: The test suite itself is copyrighted. To the extent the resulting work is a derivative of the test suite it is possibly infringing. For example you might example that the agent would derive variable names, function names, structure sequence and organization of the code from the test suite. It might even copy comments wholesale. Those are copyrightable things. (Which is of course just the first step in analyzing if it is infringement, there would be interesting fair use, de-minimis copying, etc arguments following a conclusion that any of those were copyrighted. A product produced this way definitely could be infringing given the right facts though).
> That's not actually the case at hand here - the agents were given the original source to reference: https://github.com/gitbutlerapp/grit/blob/main/AGENTS.md#sou...
yeah fair - the "The canonical Git source code we're targeting to replicate the functionality of is in the git/ subdirectory." part makes this hard to argue against.
> To the extent the resulting work is a derivative of the test suite it is possibly infringing
It's this bit that I have a problem with. If I run the test, it fails and reports a failure. Now I write code and run the test again. What is the theory there that code that I wrote infringes.
Simplify this down:
Assume the following is copyrighted:
Does writing the following code: infringe on the test copyright?Writing
Doesn't infringe upon copyright period, because there's no creative element in that work.Imagine a more substantial example though. Perhaps you have a test that checks that some file written in a binary format is correct, and gives names (creative elements) to each field of the format that it prints when you mess up the field, and has comments describing why the bytes are laid out like they are (the comments being copyrightable even if the facts they describe aren't), and the LLM copies those field names and comments verbatim... Now it's quite likely that the LLMs work is a derivative of the test suite.
> Doesn't infringe upon copyright period, because there's no creative element in that work.
There's likely a threshold at some point. It's helpful to look at a minima and then continue from there though.
I'm curious if there's case law that supports your assertions here?
For that assertion in particular I believe I'm practically parroting a ruling by the district court in Oracle vs Google about some extremely simple Java functions that Oracle claimed Google copied. Though I can't say I checked to make sure I'm remembering right.
You're recalling it right, but there's a nice quote from Judge Alsup in that case that talks about this exact situation:
> “So long as the specific code used to implement a method is different, anyone is free under the Copyright Act to write his or her own code to carry out exactly the same function or specification...”
Here given that this is rust and the original expression is C, the implementations cannot be the same by definition.
That's essentially the same thing as modding a game, though. I know there have been lawsuits to stop modding, but I don't think any were successful.
I'd challenge you here to think about this in terms of the legal aspects rather than reaching specifically for similarities as similar is often meaningless in the law or contracts when specific acts are codified rather than generalized ones.
I'd say what we're talking about here is probably a fair bit different to modding a game in most aspects.
I haven't followed any relevant cases but I would be surprised if there's any serious dispute that the common methods of modding games generally create derivative works. I think the dispute would be downstream of that as to whether or not the mods are covered by fair use.
If you did it in a loop until the test passed, maybe?
Your result is essentially impossible without the original. With ffmpeg, your result does not depend on ffmpeg specifically - you can use any video creation tool.
Repetition isn't really a factor in deciding whether something is infringing or not - check the copyright law in your jurisdiction. Here if you look specifically at what an LLM's sampling stage is doing, it's choosing non infringing tokens (i.e. rust source code) over infringing ones (i.e. C source code). So it's making an intentional choice to do something similar rather than creating something that has the same expression. That doesn't seem like it's copyright infringement to me.
A GPL tool that processes data doesn't virally transfer the license to its output. Copyrighted ffmpeg code isn't incorporated into the video output. The LLM didn't just conjure up equivalent behavior to git without ingesting the code and transforming it as new output. There is no other behavioral description that would reproduce all needed functionality.
> There is no other behavioral description that would reproduce all needed functionality.
Tests often are exactly the information necessary to understand exactly what the output should be. See https://github.com/git/git/blob/master/t/t0000-basic.sh for an example of how detailed these tests are.
It would be reasonable to point an LLM at these and use them with a basic knowledge of git to produce a rust version of git in a non-infringing manner.
If you did this manually it would take a long time.
Medium, substitutibility, basics of copyright law.
Fair point on medium - this was a lazy example.
Substitutibility probably doesn't apply here in the way you're implying and if it did it would likely be hampered by the 9th circuits findings about transformation in sony v connectix. Arguments here likely would look at rust not having a stable ABI, and hence not being inherently substitutable as a libray (grit-lib), less clear as an executable (grit-cli) on that side
basics of copyright law - the fundamental thing being protected is the expression... is a rust program's expression the same expression as a c program? I'd say generally not.
The test suite could test aspects of the architecture/design of the codebase that are not necessary for interoperability and constitute novel expression of a piece of software in a way that is not at all language specific.
By definition a test suite is about testing interoperability with the test suite. An HTTP test suite should likely test for whether response code 418 is implemented a particular way and while humorous it would still be an interop test no?
No, the git test suite is about testing the git codebase. If you want something like that, you need a conformance suite, which does not exist for git.
[dead]
If feeding the source code through a complier yields a derivative work, why wouldn't feeding it to an LLM give the same result?
Because compilers and LLMs do different things, and what is done matters, so you can't reason by stepping from one to the other.
Compilers don't axiomatically yield derivative works, they simply in practice do because for non-trivial programs they preserve copyrightable elements of the work in the output.
Well compilers are a mechanical transformation and if that were sufficient to free you of IP law then IP law wouldn't work.
An LLM is also a computer program which takes input and produces output related in some way to that input. However I don't think most people would view it as a "mere" mechanical transformation. One could tautologically argue that an LLM blends the user input with the training inputs which is a sort of transformation and further that the LLM itself is a computer program thus it is mechanical in nature. However it should be immediately obvious that such an overly literal interpretation is in danger of subsuming human work as well. Where the boundary lies is an unanswered question.
Related, compilers can pose a problem depending on what the output includes. For example common lisp compilers that aren't under a permissive license are a minefield because regardless of what anyone might say the image that gets output includes (approximately) the full language implementation verbatim in addition to the user's program.
So, if we will compile or decompile code using LLM instead of a compiler, then we can use the result for free?
(LLM can translate code to/from other code or to/from a machine code).
functional parts not being copyrightable means that you can't claim a program is a copyright violation based on the fact it does the exact same thing based on compatibility reasons (you can copy what the program does). E.g. git stores refs in .git/refs, so does grit, that's not a violation. You still can't copy the program.
Yes... and now we get to the fact specific question of "did they copy the program". Or actually the answer to that is plainly "no" - they made something similar from it - and didn't run ctrl-c ctrl-v in an unlicensed manner, but "did they copy the relevant facets of the program into the new similar thing".
Making something similar is copying for the purpose of copyright law. If I trace over a Disney character it's still copyright Disney.
No. You're allowed to make a similar tool, the functional elements are not copyrightable. There's a long history, predating LLMs by many decades, of doing this in the software industry.
My use of the word "similar" does not imply here that I think it's obvious that they are "similar" in any copyrightable elements - whether they are or not is one of the interesting questions I think this case would have to resolve.
Incidentally you're also allowed to make similar creative elements so long as they aren't copies and you did so independently... which could actually come up in a case like this (imagine the LLM produced a similar function to some function in the original... but the original wasn't in the context window at the time. Not at all unlikely with code where there often is only one or two natural ways to write something).
I suspect that the issue is more likely that the LLM code doesn't have an author and hence some parts of it can't be licenses, it's less likely that it's infringing on git's copyright for various reasons. (I am not a lawyer, but I do read copyright law for funsies).
https://www.copyright.gov/newsnet/2025/1060.html
> It concludes that the outputs of generative AI can be protected by copyright only where a human author has determined sufficient expressive elements. This can include situations where a human-authored work is perceptible in an AI output, or a human makes creative arrangements or modifications of the output, but not the mere provision of prompts.
Well that's interesting.
Also "just" the legal opinion of a government office. It has yet to be tested in court
why wouldn't it? If you run git through a compiler it's still copyright the git devs, same if you run it through an LLM.
What makes you think that's what the article says that it did? There's a lot of specific nuance and it doesn't say that anywhere. In fact it speaks of making a test suite pass only. This is the classic cleanroom bios from specs approach but no need to extract it as the test is available to run and there's nothing in the GPL that suggests that running a test suite infects software that you run it on.
Surely git’s source is already in LLM’s training corpus. So this is far from clean room approach.
You've read books and they are in your brains corpus. You only infringe copyright if you reproduce the same actual words from the books in your memory (and then do infringing acts defined by copyright laws with that output).
Here that's not happening. The code being produced by the LLM is Rust, not C.
Make a small contribution to git then sue
Related:
Malus – Clean Room as a Service https://news.ycombinator.com/item?id=47350424
Just like for 1984 and the Torment Nexus, someone took the concept not as warning but as instruction manual.
Knowing what you don't know is such an important skill in life and your career. And I 100% agree with you that the author is, well, off their rocker.
Let me give an example: I could take Goldeneye from the N64, extract the binary and then run it through an LLM to disassemble it and possibly rewrite it in a modern higher-level language. Do you think Nintendo would look at that and say "well, he did a lot of work so he's escaped our license"? Of course not. It's just silly.
ingesting the source code and producing output in another language is quite clearly a derivative work. You don't need to be an IP lawyer to figure that out.
Now, if you went to Calude and gave it documentation and told it to produce something that was compatible, would that be a derivative work and thus covered by the GPL? I would guess probably. But I'm not 100% sure anymore. I wouldn't risk it however.
Here's another thought experiment: what if someone takes this supposedly MIT licensed source tree, plugs it into another LLM and asks it to produce the output in C? Now how is it licensed? It might be very similar. After all, there are only so many ways to produce a SHA1 hash and so many ways to do a command line parser.
But this then makes it an interesting legal issue. In the Oracle v. Google court case, this was a key issue. Google successfully argued there's only so many ways to write a loop so just because a loop is similar to the source, that doesn't mean it's copyright infringement (as Oracle argued).
Anyway, it's a crazy position to take.
> Knowing what you don't know is such an important skill in life and your career. And I 100% agree with you that the author is, well, off their rocker.
They aren't the only ones - look at the number of people in this thread who are arguing that this is analogous to producing a movie with ffmpeg - just because ffmpeg is GPL, does not make your movie GPL.
I am struggling to understand how such a high level of cognitive dissonance is possible: They believe both a) that the license can be laundered in this manner, and that b) the license they put on the result is effective!
Well that is already how it is done with numerous multi-decade open rewrites of closed games. They usually require the asset pack.
I don't know how this squares with law, but Oracle v Google gave a very valuable judgment to the public that an API is not copywritable. If we take the LLM out of it, that's all we are talking about in the pure case.
Of course, we can't take the LLM out, but it is the starting point.
> Well that is already how it is done with numerous multi-decade open rewrites of closed games
Serious such rewrites don't start with the code of the closed game!
> I don't know how this squares with law, but Oracle v Google gave a very valuable judgment to the public that an API is not copywritable. If we take the LLM out of it, that's all we are talking about in the pure case.
Not at all. The LLM used to write grit has seen the git code. That is what we're talking about here.
> Of course, we can't take the LLM out, but it is the starting point.
The LLM isn't the important thing. The important thing is that the git source code was used to make grit.
>Serious such rewrites don't start with the code of the closed game!
No, but they often involve reverse engineering the binary pretty heavily.
> No, but they often involve reverse engineering the binary pretty heavily.
… and those often end up in legally dubious situations.
heh - https://github.com/n64decomp/007
game decompilation and emulation is as old as computing
> Do you think Nintendo would look at that and say "well, he did a lot of work so he's escaped our license"? Of course not. It's just silly.
That's because you're re-using assets.
Obligatory: https://github.com/chardet/chardet/issues/327
This is not a proper black-box reimplementation, I doubt they can get away with that. And that's not mentioning all other obvious ethical concerns of course.
black-box/clean-room isn't necessarily required, though. It does make it a lot harder to argue in court, of course.
Not a fan of this trend of "cleaning" GPL licensed software and releasing under permissive licenses. Also why I'm not a fan of UUtils nor Canonical's early adoption of it in Ubuntu.
The intent here is extraction of all the value provided by copyleft projects without the obligation to give back. Wether it's technically legal or not, it's disgusting behavior IMO.
It is also rather ungrateful. The only reason we have Linux desktops today, and the only reason companies like Red Hat and Canonical has a billion dollar business model is the GPL.
The BSDs had a head start, and were superior in almost every way for the better part of a decade at least, but have remained niche compared to Linux. It's not even close. Now, there may be many other reasons to this, including the personalities and culture of the Linux developers, but you simply can't ignore the impact of the license which have kept all the commercial Linux products inside the fold.
I agree, I certainly can't comment on the legality of this license laundering but I would call them an asshole.
That’s explicitly not what’s happening with uutils; they have contributed fixes and test cases back to upstream
And just like that, it was forked by Microsoft a few days ago. Handed to them on a silver platter.
> Not a fan of this trend of "cleaning" GPL licensed software > Wether it's technically legal or not, it's disgusting behavior IMO.
GNU was originally developed to "clean" UNIX from the AT&T license.
I'm not a copyright lawyer, but it seems pretty clear to me you can't wash a license using an LLM.
[US jurisdiction]: Anything in the result written by the LLM can not be copyright by anyone.
Anything in the result written by a human can be, and if it was all emitted by the LLM then that portion originally written by a human carries its own copyright.
As a work of an LLM, the entirety presumably can not be copyright, at all. Portions written by humans presumably carry their original copyright.
> [US jurisdiction]: Anything in the result written by the LLM can not be copyright by anyone.
This is a bit stronger than the actual report where this has been discussed finds. See part 2 in https://www.copyright.gov/ai/ for details, but TL;DR, parts where humans have control over the expression may be copyrightable. But working out which parts those are is likely a difficult question (would likely require proof of provenance across many of those LLM sessions)
Particularly because LLM generated code is not licensable in any way. If you wrote it with an LLM you cannot own it.
I don't care if they can convince a judge. The fact that they even want to in the first place tells me what kind of people they are.
F-ing scumbags. It's already free, but they still decide to steal it.
An idea...
Take this (assuming it's not slop), relicence as GPL, submit upstream (imagine it's accepted for a moment...).
If they proceed with license washing then from the Rust version, it's certainly derived work.
I don’t understand. Gitoxide exists and is great.
It might have missing pieces, but it’s easier to vibecode any needed networking additions to Gitoxide (which is maintained) than to just go and burn tokens trying to clone all of git again.
Git wants to add Rust. Gitoxide is a multi year project that’s going to be more maintained than an ad-hoc “it says it passes the test” vibeclone.
I’m not even against vibecloning things when it’s useful, but this shows no benefits. Git is a beloved tool that few people dislike, it’s not like vinext (people disliking the vendor lock-in they have with nextjs).
Also execs should keep in mind that “we burned thousands of dollars on tokens to re-create this beloved software so we can have our own copy”, even without the copyright/licensing argument, just isn’t something positive that the community will react positively to.
It doesn’t feel nice to see your favourite works cloned for no benefit. We’re past the “it was an experiment to see how far AI can go” stage now.
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:
https://github.com/GitoxideLabs/gitoxide/pull/2538
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.
People are critiquing your current actions.
GitButler now employs/has hired the gitoxide maintainer, I think? So no doubt they’re aware.
I guess they found that gitoxide isn’t good enough and/or to expensive to extend/improve for their use cases?
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’m all for memory safety and such but honestly what’s the use case for this? Showing off agentic development? In 10+ years git has never failed on a memory overflow or else. Sometimes software is “good as is” and I’m pretty confident git classifies as such. I’ve also never really hit the limitations of git, even with teams of 20+ developers and lots of binary artefacts. You got to really stretch git limitations, in which case you might need to move away from git, and a rust rewrite will not help in any way whatsoever. So again … why?
I addressed this in the post, but Git has no linkable library and never has. If you want to do even something small, you need to fork/exec a process and communicate with it via stdin/out. Or completely reimplement it and all of the edge cases - for example, reading even one object can be either loose (easy) or in a packfile (much more difficult). Reading a reference (what SHA does a branch point to) can be in a loose file, a packfile, or a reftable. etc.
There is no way anyone would ever use this for it's CLI - it will almost certainly always be slower and worse in every way, even if I get it stable (which it's currently not). You can use libgit2 (a project I also helped kickstart), or Gitoxide (a project GitButler also currently helps drive) - they are faster and better in nearly every way, but they are not feature complete.
This isn't for the person using Git. This is for someone trying to build a tool that wants to use parts of Git, which is different.
But libgit2 exists, right? It may not have 100% feature parity with git, but that's a linkable library that gives you a lot of functionality when working with git repos.
the author of this post (whom you were responding to) made `libgit`, the library that preceded `libgit2`, and contributed to libgit2 a long time ago as well. Here he is in 2010 writing about libgit2: https://github.blog/news-insights/libgit2-a-git-linkable-lib...
To be clear, I 100% did not make libgit. I did help the libgit2 project get off the ground.
Nice experiment, but a bit expensive.
I work on Beagle, a git-compatible SCM [1]. I use ABC, Abstractionless C [2] dialect with slices, optional range checking, etc. So far, memory safety was the least of my concerns, frankly. Most of the thorny issues would be equally thorny in Rust (e.g. right now: reflog zeroed when VM ran out of disk space; must be some state machine issue or an OS level glitch). Also, forking off a C process (no runtime) is cheap enough that you actually want to do that more.
But, those are all technicalities. The key issue I see with the approach: the data structures and algos of git have been fanatically fine tuned for that particular application with those particular usage patterns. By very sophisticated low-level C programmers. So, quite likely, any other app/lib working with that store will always be a suboptimal fit. I would recommend read-only access only, esp for LLM code.
Meanwhile, git's underlying data model (blobs/trees/commits) is very simple and very much internet-standard level. Decoupling at that interface is so much easier with so much less issues looming.
May look differently from your vantage point though.
[1]: https://github.com/gritzko/beagle
[2]: https://replicated.wiki/blog/abc
I hadn’t heard of libgit2. I wish more applications would expose library-style access, preferably available across different languages!
May not work for apps that want to launch their own threads and processes. But for almost everything else, I prefer function calls to launching processes, managing their lifecycle, communicating via stdout etc. If I wanted to do that, I’d be writing Bash ;)
> This isn't for the person using Git. This is for someone trying to build a tool that wants to use parts of Git, which is different.
I’m going out on a limb here but I’ll say that you are over engineering for the wrong problems. I’ve done it before, I tried libgit for some use case. At the end of the day it really is much simpler to use git. If you don’t want git at runtime use something like the git-gradle-properties plugin or the likes for your build system of choice. I really can’t think of a super duper use case where forking processes is a massive enough issue that I’d want to instead port over all of git to another language. Git for the most parts also offers a wide variety of export formats such that you get machine readable output too. If you really really need to fiddle with its internals, git pack lets you browse through the index fairly well. Again, my humble opinion, but you’re trying to solve the wrong problems
License washing
"Grift"
(The f is for "feft")
How else could they launder the git license and set themselves up for a bait and switch later down the line?
[flagged]
When we go a full year without a lpe in the linux kernel I'll start considering it...
How many of the LPE would rust even fix? They mostly seem logical errors and not memory or threading related race conditions to me.
This year, none of them. Historically most or all. So that is another caveat. If all future lpe are logic errors I'd start reconsidering the value proposition. I do actually like writing rust though. I don't feel like it slows me down. I also love the simplicity of c vim and gdb, though my first exposure was lattice on the amiga 1000. I wonder if strict typing makes it take fewer tokens to find bugs?
I mean we’re almost there with Mythos/Fable so there ya go. In two years bye bye rust.
Did you create this account just to lament rust hype? I mean, it is excessive. But I also don't think it is manufactured. We are more like some mostly benign evangelical denomination trying to get everyone to see the joys of Ferris.
Honestly, if the language actually looked nicer, great. But I mean the source code looks like a steaming pile of crate-includes. We can do better, seriously.
You have touched on my biggest complaint, the supply chain depth. It has definite advantages, but a signed and vetted set of crates is sorely needed. I could always just write everything my self like I would in c, but the crates are right there...
I guess software licenses are meaningless now since anyone can decide their llm clone is not derivative.
Currently some act like it is fine to translate a project and change the license.
Recently Casey Muratori said in a adjacent context that the microsoft AI push may be related to the fact that they have a long standing and elaborate codebase. A large historic software company could have advantages to train models. They could provide extra value with their IP.
Now their IP is potentially in their models and accessible to anyone. If they actually train models on their IP, anyone could implement their APIs and slap a GPL license on it.
At that point, things will get very interesting.
A lot of their IP has been leaked over the years anyways. Source code of Windows XP is easily available, and there was the 2022 leak that contained the sources of Bing, Bing Maps, Cortana, etc
Yes but it's illegal to replicate it.
A different story if LLMs lift license restrictions.
No one is training their models on their closed sourced proprietary code. They own github, why would they need to do this.
More is better.
They were already quite meaningless since nearly every FOSS copyright owner doesn't sue violators.
A legal fund would help?
This is simply plagiarism of GPL-licensed code, and license-washing as well. I can understand working backwards from a test suite, but this literally just reads the original source:
https://github.com/gitbutlerapp/grit/blob/main/AGENTS.md#sou...
LLM users seem to live in another world where stealing everything that isn't bolted down, and passing it off as their own work, is acceptable.
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:
https://blog.gitbutler.com/signing-commits-in-git-explained
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.
Yet, you didn't write the code yourself.
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.
0: https://github.com/GitoxideLabs/gitoxide/discussions/253
1: https://github.com/GitoxideLabs/gitoxide/issues/925
> 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.
> 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
gitformat-pack?
> If you find any code in Grit that is clearly line-for-line copied, please point it out
Please hunt for specific lines to disprove your bold claim.
> and I will replace it.
Assuming the current claims here, that would just be license washing with volunteer assistance.
> 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.
> If you find any code in Grit that is clearly line-for-line copied, please point it out and I will replace it.
Why is it everyone else’s job to figure out if you’re compliant with the license? That’s your responsibility.
[flagged]
Ignore the haters, this site is turning into MAGA
My dude it's literally the opposite in this case.
I'm terrified that this somehow seems acceptable to a large group of people.
I'm baffled that other IP holders (say those who own valuable pieces of proprietary software, or music, or movies, or even the LLMs themselves) don't think leopards will come eat their faces next. This erosion of IP has to stop, or anyone who does any intellectual work will be absolutely screwed. If that only meant FOSS people, I'd be worried that we'd just be thrown out with the bathwater – but surely this applies across the board!?
The people doing the intellectual work are usually not the primary beneficiaries of IP laws. In fact it often constrains them unnecessarily.
> The people doing the intellectual work are usually not the primary beneficiaries of IP laws. In fact it often constrains them unnecessarily.
In the sense that most people doing intellectual work do that work for someone else (say, a company) that you consider the primary beneficiary of IP law? Sure, fine – but this applies to almost any other type of work and the legal constructs that are in use there too, so it's not really a very useful distinction to make, even if technically correct.
Or do you mean something else?
Of course they are afraid of it, haven't you seen Dario being angry of Chinese companies paying for Claude access (tokens = test cases) and training their own model from those?
Well exactly!
I'm well aware of situations of potentially upending changes where the rich and powerful stand to gain, and the little guy's worries are ignored.
This, however, is clearly a potentially upending change where also lots of the rich and powerful – including those who control the very technology driving the change – have everything to lose. I'm surprised, to say it mildly, that nothing seems to be happening. Does Dario really believe that a strict ToS and stern words will keep his IP protected without appealing to the legal system? (I guess that is par for the course for the people who "solve" world problems with bunkers and armed guards…)
I might even be fine with the loss of IP if everyone lost it.
How does intellectual work happen (beyond doing it for leisure) in a world without IP?
In a utopian world of abundance where we could all be the independently wealthy nobles of the 18th and 19th century who did intellectual work for fun: great. In the world of today where people need to be compensated for their work: what happens?
Any way anyone who wants, wants, that doesn't rely on legal control of information. There are infinite uncopyrightable things that never the less get done and make people a lot of livings.
I only said "might" and the point was obviously not the immediate surface idea but to point out how the tool of IP is not applied to everyone's benefit equally, but used only against some and only for some, with a side of "You know, fuck it, if they insist on making it worse, it becomes less crazy to consider just burning the house down".
But What are you so afraid of that you react only to the hypothetical as though it were the worst danger?
We'd actually manage to get yoked and abused by the same people no matter what the rules were, don't worry.
How is this an answer to the question? Good thing you aren't in government. Who would so much as bother to write a book?
I'd add: why bother... except for fun. We shouldn't discount enjoyment as motivation. But I otherwise agree wholeheartedly with you. We need intellectual work that goes beyond "just for fun" as long as most people have to work to live.
[flagged]
It’s all a bit voodoo to me but wouldn't the entire original source code be in the training data also?
Yes, and LLMs have been shown to store and be able to output their training data, so this is at best very sketchy
Thank you for the answer, I was curious if they could produce it all too from the weights.
> It's like giving wishes as a genie. You gotta be super explicit with the ground rules. I have used the genie analogy before. It used to feel more like a Golem but now with the whole Fable sabotage mode https://jonready.com/blog/posts/claude-fable5-is-allowed-to-... it certainly feels more Genie-like.
Previously I described it as "Models give you what you ask, for not what you want". Now with Fable they don't even give you want you want so idk.
I'd be really interested in the opposite, just for the sake of experimentation since that's what these projects mostly are. They all seem to be rewrites for the sake of "performance", because the cost is now lower bc of AI. I'd be interested to see something like a port of Quake III in Python or Kubernetes in Perl, even Rails in Python would be goofy and really fun to see
> Quake III in Python
Probably doable - I remember most of Natural Selection 2 was Lua and it's more than a decade old at this point.
For Natural Selection 2, it was mainly the gameplay logic that was Lua, all running on their bespoke C++ game engine called Spark. But yeah, modern Python and Lua can be pushed to high performance.
Link: https://unknownworlds.com/en/news/spark-engine-questions-and...
Ah my mistake - I know they ditched Source to pursue their own engine and thought they were going all in on Lua, but doing the whole engine in Lua would have been a struggle I think.
> They all seem to be rewrites for the sake of "performance".
And yet this performs dramatically worse.
A slower, untested, incomplete git implementation, all for the low low price of $10-$15,000.
And don’t forget it wasted a bunch of human time in the process.
So if someone mentioned somewhere else there is already a Rust port a group is doing somewhere. How much could they have accomplished with this much money and time in software development resources?
Ok. AI can seemingly port stuff if you don’t test it thoroughly. I think that’s already been proven. At this point I’m seeing less and less value from these kind of things. I’m sure it was fun for the author, but how does it help other people?
It's not for performance, it's for Rust.
If the first stereotype of Rust programmers is announcing that a project is in Rust before any other desirable software property (e.g. stable, performant, etc), the second stereotype is that Rust programmers love rewriting stuff in Rust, just for the sake of Rust.
(The 2.a. corollary is that they love rewriting GPL projects specifically and downgrading them to MIT/Apache)
But there is already gitoxide, an established git reimplementation in git. It even provides a library
gitoxide was started in 2018, back when we were all writing code by hand, and has some reasonable adoption in the rust ecosystem. It's not feature complete, but if that was the issue then surely fixing that would be better than starting from scratch
It's not for Rust, it's for Library.
Well, it's sort of for Rust. GitButler is written in Rust and Jujutsu is written in Rust and we're both depending on fork/exec'ing to an unknown Git binary with no linkable library and no control over the subprocess to do a range of networking stuff. Neither Gitoxide or libgit2 are capable of this either, as much as I love and support those projects.
This project is entirely about providing a feature complete (even if sloppy) library implementation of Git, which does not otherwise exist.
> It's not for Rust, it's for Library.
Prove it - put it under GPL, like the original sources you ingested were.
But... it's memory safe. Not that git has any important memory issue, but now people with skill issues in C can contribute to it without breaking stuff.
They can still break stuff memory safely.
> They all seem to be rewrites for the sake of "performance", because the cost is now lower bc of AI.
If that was true they'd use the original license. They are not. The whole RiiR movement is very obviously switching away from a pro-user license (GPL).
> A pretty fun experiment and I think we can shape this into something truly useful to the whole community.
Agree with first half of this sentence, we should all have fun with experiments.
> It was never based on a linkable and reentrant library, but instead on a "Unix" philosophy of chaining together simpler commands, which means that it's difficult to use it in long running processes without fork/exec overhead for everything.
Ahhh now we have philosophical disagreement in the only place in the entire article that says "why". Unix is a feature, it's arguably more important in current time: https://aperocky.com/blog/post.html?slug=unix-philosophy-age...
You cut that citation conveniently short.
> It was never based on a linkable and reentrant library, but instead on a "Unix" philosophy of chaining together simpler commands, which means that it's difficult to use it in long running processes without fork/exec overhead for everything.
Added it in full. It still squarely falls under "this is for fun/are you seriously doing this for this purpose" territory for me.
git operate on the filesystem level, the unix behavior is just getting buried. You cannot rewrite git into a linkable library and decide it's now not unix. It's entire behavior is unix, which is why it's awesome.
My intent with this project is not to replace Git in any way. I don't care about the CLI part of this project.
The point is to provide a feature-complete reentrant linkable library. Even if it's an ugly and slow one, this is still the only one thing that exists that covers those points - Gitoxide and libgit2 are both awesome but they are not feature complete.
> The point is to provide a feature-complete reentrant linkable library.
If that was the goal, why change the license?
Isn’t git already just an interface over libgit? How is that different?
Git is famously not built around a (reusable) library, hence why we have things like libgit2 (unrelated to git) and why any porcelain on top of git has to resort to calling the binary and parsing its text output.
I was not aware of that. I knew it was split but didn’t know that split wasn’t useful to others.
Thanks.
libgit.a isn't reentrant. It will call `die()` on many errors. If you link to it in a long running binary, it will kill your process on error.
Libgit2 is meant to address this and I was heavily involved in the development of that project 15 years ago. It's great but it's not feature complete and it's development is also completely separate from git development, so it's out of sync and constantly struggling to keep up.
In 15+ years of using Git, I have not had a single crash. What problem are you solving???
A feature complete, reentrant, linkable library. Reading the article often helps with questions like this.
> In 15+ years of using Git, I have not had a single crash. What problem are you solving???
The pro-user license (GPL).
I've seen plenty of crashes over the years. Primary in one private repo where gc and pruning triggered unexpected exits for a fixed duration of time.
That said, stability overall has been nothing short of fantastic. And I can't answer the question of "why?" for this particular rewrite.
This is a problem with people with LLM psychosis who now think they have superpowers, they are completely unaware and just do things naively, they've lost all ability to think for themselves. The LLMs that are thinking for them certainly aren't going to tell them doing X is a bad idea, they're there to produce as many tokens as possible for their owners.
The motivation and rationale is there and was mentioned early on in the article.
I’m all for the hundreds of reasonable objections but this sort of trash mindless critique is as useless as what it denounces.
[flagged]
This is coming from a cofounder at github, someone who probably knows precisely what the GPL is for. Whatever the legal merits, building on a GPL3 project's complete test suite and relicensing under MIT is not acting in good faith toward the original authors. I really find it disgusting and it makes me want to avoid gitbutler entirely.
I think you're saying that you don't believe in the freedoms to use the GPL licensed test suite for certain purposes which are explicitly allowed by the GPL.
You don't get to choose a license and then add extra terms to it when you don't feel like it's up to scratch. That's something explicitly not allowed by the GPL license.
Where does the GPL say you have the freedom to relicense code or derivatives under MIT by fiat?
Isn’t having to stay under the GPL a very big part of the GPL license?
> Where does the GPL say you have the freedom to relicense code or derivatives under MIT by fiat?
The first part of this sentence (where in the GPL) is unreached if the second part of it is unmet (relicense code or derivatives) which I contend it likely is. You're begging the question.
However:
> The output from running a covered work is covered by this License only if the output, given its content, constitutes a covered work
earlier:
> A “covered work” means either the unmodified Program or a work based on the Program.
It's that element that would be difficult to prove "work based on the Program"
Asking an LLM "here's a thing, rewrite it in Rust" is pretty clearly creating either a derivative work or a different form of the same work, just like asking a transpiler would.
There's no evidence that "here's a thing, rewrite it in Rust" is the technique Scott used here.
"here's a test suite, write code in rust that makes that suite pass" is reasonably supported by the article. That would likely not be a derivative work.
It's actually murkier than I suggest here. https://github.com/gitbutlerapp/grit/blob/main/AGENTS.md#sou...
Ew. So it tells the LLM where the git source is for the thing they’re duplicating, but I don’t see instructions saying not to read or copy those files or algorithms.
I could have missed them. I didn’t read everything. I did some quick searches.
But the fact they’re not obvious is kind of troubling. Or that they didn’t just copy the tests and documentation for the LLM and not the source to prevent it from looking would hurt any case they had for clean-room privileges in my eyes, ignoring my other comment with concerns about using the tests at all.
If we assume an u licensed or MIT licensed test suite, an LLM could develop from that and documentation and you’d get something you could license MIT.
IMO, IANAL, etc.
And we’ll ignore the question of what the fact the LLM has certainly seen the git code during training means.
But the test suite would have to stay under the original license. And if you use a GPL test suite as they kernel to develop a program from can you license it non-GPL? I’d question that personally. Same acronyms above apply.
This is the exact thing I'm not sure about. See https://news.ycombinator.com/item?id=48470397 where I posit a simpler question: if a `test_sum()` function is copyrighted, does writing a `sum(a, b)` function infringe on the copyright of the software product that `test_sum()` is a part of. I'd say no. There's another part of the GPL that applies here:
> A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.
So assuming that sum(a, b) is non-infringing and not combined to form a larger program (i.e. the tests aren't compiled into the grit code), then the GPL explicitly doesn't apply to this use
test_sum is assumedly relatively trivial. So as a lay person I’d expect some sort of obviousness test to apply. Like so much of the stuff in the Google/Oracle lawsuit.
But if you take all the individual tests used to test git as a whole, that seems far more unique. Seems like at that point you’re really having to duplicate the actual git internals, and that seems like it should be covered.
> test_sum is assumedly relatively trivial. So as a lay person I’d expect some sort of obviousness test to apply. Like so much of the stuff in the Google/Oracle lawsuit.
Feel free to extrapolate to the threshold where it's not and at that point apply.
> you’re really having to duplicate the actual git internals
Copyright covers the expression, not the method. So the Rust function:
is distinct from the C function:That's not copyrightable because it's trivial.
Please feel free to strongman. Extend the argument until it hits a point of non-triviality and then apply reasoning.
You're asking people to trust you and hand their codebase/IP to your tool while showing them exactly how you treat other people's code/licenses by "deciding" to not carry forward the GPL license.
GitButler's source code is available, so we're not asking you to trust us much at all.
https://github.com/gitbutlerapp/gitbutler
That's great because we don't.
Does anyone plan to use this?
Similarly, is there any momentum left for Cloudflare's EmDash? I can barely find any discussion after April.
It'd seem weird to plan to use this until the readme stops saying
> it has been nearly entirely written by agents and has not been used for realsies. It's probably currently unusably slow or completely broken in ways that are not exercised in the test suite.
Right now it's someone else's experiment that is still in the "might or might not pan out" stage.
There are a bunch of projects using the similar (not vibe coded, less fully featured) gitoxide project - there is demand for git-as-a-library.
I would not use this except to help us test it if interested. I'm announcing it because it's interesting and a milestone in the breadth of test coverage it can pass. It almost certainly cheated on a bunch of those tests and is not feature complete yet.
The author of gitoxide is also working on GitButler (who worked on this project) and we're pushing both projects forward and actively using and developing Gitoxide as well. This is simply a different and hopefully complimentary approach to the same problem.
> because it's interesting and a milestone in the breadth of test coverage it can pass.
Sorry, no. Let me be candid and point out that this has achieved exactly nothing except lighting $8k on fire.
Put it this way: if I suggest to my boss, "I want to spend $8k of company money to port git to Rust to just see how many tests can pass in that project, even though I don't plan to develop new features with the project, and I don't care about adoption", he is going to shot down the idea in half a second and seriously question my competence.
I was immediately excited about this wrapped in Python because the current Python git bindings are kind of obtuse, but they do work so I guess I can't complain.
But why switch to this?
Why not just make better Python bindings to libgit?
Wordpress is/was successful because it's braindead and has a solid userbase. I am not to flame WP, but it's a quality to target a specific group of consumers.
It's an organic success, hard to replicate. If at all, CF can only make people migrate with massive effort. Marketing effort, selling lots of snake oil in the process. WP wont just hop on the hot new thing, WP is the definition of the opposite. It works for them. Why change.
Git is the same on the other side. It requires maintenance and improvements, surgical and correct. No git maintainer has time to learn a gigantic new codebase and they will stick with what works for them. For git users there are no advantages. So similarly it would require a long time effort to push the project, building trust that it is somehow better, probably requiring Linus to say "it's great".
> The full build of all Git functionality in Rust is currently around 27M, but since a large part of it is a library, it could clearly be easily split up into domains of functionality - subcrates that do specific things.
I downloaded v0.3.99 for Linux x86_64 and stripped the binary. It ends up at 31 MB. The .text section is 25 MB.
I'm surprised by the large size. On my system /usr/bin/git is 4.7 MB, although git is split up into multiple programs. I'm not comparing apples to apples, but this is weird.
If anyone digs into the binary size, please share what you find.
I would also be interested.
I haven't dug into this at all yet, nor have I tried to optimize the size (or really, anything else).
However, the library part will be less than half of this - a lot of code is spent on the CLI specific stuff and would not be part of the library, which is mostly what I care about for the purposes of this project. The CLI part is just to try to prove the point that it actually does what Git does. The library part is what might be useful in that nothing else exists that does all of the things that it does (provide a reentrant linkable library that is feature complete with Git).
Looking at just the `grit` executable, 58 of the top 200 largest file->resulting code sources are from clap-rs' derive functionality i.e. it's the command-line parsing. The #1 largest is, surprisingly, merge_trees[1] which comes in at 183kiB final binary size. There isn't so much code in that file that it seems reasonable, so it's potentially one of the derives in use (Debug being a common culprit for bloat) that's blowing it out. After those outliers it starts to level out quickly.
Splitting it by crate: `grit` is 13.6MiB, `grit_lib` is 4.8MiB and then it's `std`, `rustls` and `regex_automata` that are the next largest. So as pure library you could hopefully shave off quite a bit of that 25MiB.
[1] https://github.com/gitbutlerapp/grit/blob/main/grit-lib/src/...
Nice, I haven't dug into this yet. If we can get this usable, it would be pretty cool to have a small lib or a series of much smaller, directed libs that can be used by simpler interfaces and you can just compose the parts you need.
Why not just rewrite the networking part of gitoxide with an agent? Wouldn't gitoxide already be 90% there for your usecase? Why slopfork all of git?
I have been working on the same problem in other areas. My ultimate goal is to rewrite nginx in Rust passing as much as the upstream tests as possible while leveraging the strongest aspects of Ruts ecosystem - i.e. rustls (modern memory safe OpenSSL), Tokio (async runtime), h2 (http 2 impl) rather than implementing from scratch like the upstream. I started with Lua, then porting over Valkey, and now working on nginx. The reason was because I wanted to learn the ins and outs before taking on the most complex portion.
[1]. https://github.com/ianm199/lua-rs/tree/main Lua
[2]. https://github.com/ianm199/valdr Valkey/ Redis
[3]. https://github.com/ianm199/nginx-rs-port nginx
Happy to answer any questions on the approach! When I started a few weeks ago the harnesses on their own were not good enough to get very far without a "meta harness" of sorts but that is changing largely with Claude Workloads and Mythos. A lot of the work is developing some custom tooling to move these along faster.
Yeah I got one, why? You aren't learning anything, you are just copying code from other codebases and smashing it together to make some nginx-rust thingie... for what actual goal?
Well the biggest goal was to be useful. Nginx serves ~20% of the web, memory unsafe languages might just become untractable for critical exposed to the web infra if the rate of critical CVE's on these rises faster than they can be patched, so a drop in replacement would be a big deal in that world.
But in terms of learning I'm learning relatively little about how to type Rust into an editor but a lot about how to set up agentic loops that can autonomously get tests to pass and improve performance.
For example if you just tell a frontier model (gpt5.5 or Claude Code 4.8) to make some portion of the tests pass they will take forever and just bang their heads against it. I developed a framework to mimic a lot of these tests in nginx... but in minimum non blocking ways so you can run many in parallel with short feedback loops.
Similar for performance - how to make tons of performance benchmark and expose maximum telemetry for agents to go and analyze the hotpaths etc.
> Nginx serves ~20% of the web, memory unsafe languages might just become untractable for critical exposed to the web infra if the rate of critical CVE's on these rises faster than they can be patched
That is true, however did you actually do any research into nginx? Is it particularly prone to memory bugs?
I honestly don't know the answer but you seem to be coming from a place of C bad, therefore nginx super vulnerable?
In my experience with other web servers the vast majority of security bugs are string handling related (path/header injection), which your rewrite will not protect you from.
https://securityaffairs.com/192132/hacking/nginx-rift-an-18-...
The project was inspired by that. Also unlike most other projects, nginx is directly exposed to the internet often times which makes it more vulnerable than i.e. Redis/ Valkey or something that would be running within a companies network generally.
"C Bad" is a bit reductionist... but I think there is some truth to the take " Until you have the evidence, don’t bother with hypothetical notions that someone can write 10 million lines of C without ubiquitious memory-unsafety vulnerabilities – it’s just Flat Earth Theory for software engineers" [1]
NSA and other government orgs are also pushing people to stop using C [2] for important software.
[1]. https://alexgaynor.net/2020/may/27/science-on-memory-unsafet... [2]. https://linuxsecurity.com/news/government/nsa-s-plea-stop-us...
I think the risks of a rewrite - especially when using AI - are far more problematic than memory safety. In the long run those C projects will be memory safe in the next five years using memory safe C implementations.
My perspective is that it is good to have a beta in a lot of directions.
No one really knows what the endgame of software security looks like.
So some people should try the port to rust angle, some should focus on hardening the C, some should explore more exotic options like formally provable languages etc
There is nothing wrong with trying different things. But the fundamental problem here is that projects and their communities are social projects and need to be to fulfill their purposes and to ensure long term maintenance. In a free software context, rewrites just like forks (1) are fundamentally an asocial (2) activity because they fragment the community (if successful) and then increase overall maintenance burden if not able to replace the original project completely (rarely the case). Disrespect the license choice of the original authors makes this worse.
1) There may be situation were are fork makes sense (e.g. because one project can not serve different use cases well): 2) Which is why usually a "higher goal" is used to justify this, e.g. authors pretend (or lie to themselves, or may be be stupid enough to actually believe this) that some improvement in memory safety is really that important.
You won't get anywhere pressing your case here. This group has already found you guilty, and no argument will change their minds.
You've been caricatured into a blind AI-follower rust-rewriter-just-because type, and that's the surface they'll continually attack (you're wasting time, hurting the community, v2-itis, bikeshedding, premature optimization, copyright violation, moustache-twirling-evil-intent-rug-pull-later, etc etc etc).
Just continue in your work. It's good, and we need people like you.
There was no caricature as a "AI follower" etc. I gave my arguments you didn't.
> the biggest goal was to be useful
Please excuse me for being unnecessarily harsh for a moment, but web servers are a dime a dozen. Quite literally. The reason nginx is successful is because it is maintained. Unless you plan on maintaining your nginx-clone as well as nginx itself, it will not be useful.
Perhaps you do, in which case I am more than happy to be wrong, but sometimes people think the act of writing software itself is useful and that other people will happily swarm over it and maintain it in their absence, but that is usually not the case.
The world has tens of thousands of http daemons, increasing that number by one is not useful in itself. The act of maintaining software over time and keeping it useful for many people however, absolutely can be.
You mean you rewrote the nginx test suite with smaller leaner tests ? How did you bootstrap that ? How do you know the leaner tests are equivalent to the real ones ?
Here is an example https://github.com/ianm199/nginx-rs-port/blob/main/crates/ng...
Basically I use these "kits" to prove that the behavior is working as expected with mocked data/ interfaces and then only after these kits pass I'll run the real test suite files as confirmation. So these let you iterate a lot faster than the official test suite because it is very slow.
These are bootstrapped from the real tests.
The other commenter was being a bit dismissive but this is the kind of thing I'm taking away as a real useful pattern to do verification of behavior at scale.
Buddy, I think it is time to not engage with these models for a bit, you seem to have lost your mind.
We're literally in a thread on converting legacy C projects to idiomatic Rust? It seems many people are working on this same problem.
There are plenty of Rust based reverse proxies out there, why do you need to specifically rewrite nginx? You could also write a config adapter to Caddy, there are a billion options, but this is a wasted effort. The people who want to stick to their nginx configs won't use your project ever, and the people who actually care about security aren't going to use a vibe coded project.
I have no idea why you are making me spell this out, I thought it was pretty obvious.
nit: well-written C projects to legacy Rust
One very strong draw I feel, that's mentioned in this article: Rust's portability, it's ability to be compiled to wasm & run very well anywhere.
Because C code in production is a ticking time bomb.
What’s the long term strategy for this code base? Does the author expect community code contribution or just bug reports or maybe just test contributions?
In 6 months, seeing no adoption, move the repo to maintenance mode. Archive in 12 months.
I'm happy to take contributions if you want to throw some tokens at it. Bug reports would be amazing, since I haven't tested it for real very much (enough to know you can do basics).
I want to get it to the point where we can replace fork/exec'ing to an unknown Git binary or having said binary be an external dependency for GitButler. The networking stuff (push/fetch) is currently an external dep for both GitButler and Jujutsu (and pretty much every other Git-based tool in the world). I'm pretty sure I can get the project good enough at these networking ops (including all the hairy credential stuff) to be able to not need those fork/exec calls.
I won't touch relicensed code even if you payed me.
This is morally, if not legally, wrong.
The agents did all the work but _somebody_ has to test it for real on their own data to find the edge cases overlooked by AI. That's what users are for nowadays.
He will be probably super happy for starring the project.
Is there a term yet for Rust projects rewriting GPL code to get it under non-gpl licenses?
Rustwashing?
Stealing is the word you're looking for
What does rust have to do with it?
The pattern I see here is people vibing slop rewrites of GPL projects to get them under more favorable licenses. Rust just happens to be the language this one picked (for various reasons that are not very relevant here.)
I continue to be surprised by the lack of understanding around copyright law when it comes to AI.
The section about handoffs being frustrating is the same thing ive experienced and why i built https://github.com/TStansel/handoff.
Goal is to be able to transfer context from one agent to another when switching which provider is being used. So when i hit usage limits on claude i can can run handoff claude codex and codex is given a md file to start from and continuing working.
Still early but ive found it useful in my daily flows already!
This is great, does it work in the browser via wasm? There’s an emcripten libgit2 out there but the wasm is a little big too be any fun
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.
pretty dystopian to ask a robot to recreate your favorite software just so you can relicense it for your business venture
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.
> We clearly learned from how Git does operations and emulated it in order to function interoperably
So you didn't just let an AI go nuts with access to the source code of Git so as to produce a derivative work?
> We're choosing a license that is usable by the entire community. Our goal is a linkable library, which makes GPL impossible.
And what issues did GPL impose on the community all these 21 years of git existence?
The license change is more than just concerning. This isn't the first time it happens, and won't be the last, without legal action.
Grit was the name of a _Ruby_ implementation of git way back when: https://github.com/mojombo/grit/. I believe it's actually what GitHub was built on then.
I created and named the Grit library that used to power GitHub. Scott Chacon (fellow GitHub cofounder, now CEO of GitButler) specifically asked my permission to re-use Grit as the name of this project, which I gladly granted. R is for Ruby. R is for Rust! Grit is dead. Long live Grit!
I started the project as Gust, but felt like Grit was such a better name. I asked Tom if I could boot the name back up again because I always liked it and he said it was fine.
Also, I worked on the Ruby Grit pretty extensively during the early days of GitHub, so hopefully I earned the right to carry on the mantle. :)
Okay name is taken. Let's rename it to Grift.
Never had even single issue with the git for a 10 years, doesn't see real reason to switch to this :D
I hate all you llm people, you're ruining everything, shoving slop down everyone's mouth and telling us you now have superpowers. No you're stealing and making everything as shitty as possible in the process.
I pray everything switches to usage based billing and the curtains can close on this era.
Theres already git-in-rust project that is making good progress
https://github.com/gitoxidelabs/gitoxide
Gitoxide is mentioned in this write up, yes,
> Currently both Gitoxide and libgit2's networking functionality is either partial, slow or non-existant. Both GitButler and Jujutsu rely on forking out to Git in order to push or pull data. A big reason for this is the incredibly complicated credential logic involved, but all of this is (theoretically) currently covered in Grit.
Gitoxide is also developed primarily by Byron, who also is part of the GitButler team. We're pushing both projects forward.
if we conquer the universe, i would love to leave one planet alone for rust users. in this planet, the only allowed programming langauge is RUST! everything should be written in RUST
Of course it has the MIT license, when the original was GPL. To hell with these Rust rewrites!
So, they "decided" it's not a derivative and thus can be listened under MIT instead of GPL....
Yeah, that's usually how contracts work.
You decide whether you have followed it or not. The other party will decide if they agree. If in dispute, you go to a judge and they decide also.
Where's the crowdfunded lawsuit I can donate to?
a lot of things are just "decided" really.
it's just in this case it's the author. we'll have to wait and see who decides to challenge it
$10-15k in tokens??? Holy frick someone tell this man about deepseek-v4-pro and quick
i wish there was an option in hackernews so i could filter out such crappy titles! DUH
> Another possible use case is a WASM build that could be used to do a super wide range of interesting things. Run nearly any Git command in an edge Vercel function for example. Or maybe you could build things like Cloudflare Artifacts without relying on partial implementations like isomorphic-git but instead a fully compliant WASM build of Grit.
> You had me at WASM...
What does this mean? Does the OP want us to convert his AI-vibed code to a WASM-compatible build? Does the OP even understand what that entails?
I did something similar and called it gitredoxide since I started with gitoxide.
they still haven't explained why I should bother. Is it faster, easier, more efficient, more capable, more scalable on large codebases, supports better workflows?
In fact, I would rather it stay C for 15 more years.
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.
grep didn’t indicate anything interesting. S/n was very low. Thanks.
I'm exhausted seeing this same mistake happen over and over and over. Why nobody tries to write a spec from existing code is just crazy to me.
The git test suite is a behavioral spec. But at the same time it is not, why? It's archaeological site... I'd say. You can dig, and dig, and dig, and find some truth, but also a lot of historical decisions that doesn't matter today.
Here's the flow I suggest:
- first, reverse-engineer the behavioral intent from tests/docs/code
- build a taxonomy of what git promises
- group that into small "conformance slices"
- hand those slices to agents/humans/whatever
- start writing Rust... Or Visual Basic... At this point it doesn't matter almost
Without this critical layer, agents are optimizing for "make this test green" instead of "preserve this semantic contract". And this is exactly where the funny stuff happens... shelling to real git, hardcoding expectations, implementing sha256 metadata but not the behavior, etc.
Why are we doing stupid things and winning stupid prizes? I have to admit they are impressive, but I STRONGLY believe if we did this in two passes you would have not $15k check but maybe closer to $1-5k.
Who should I talk to, to make this happen? Making the first pass is almost deterministic. LLMs help. The only problem is making sure that YOU understand the spec, and this will be a bottleneck for a while (i.e. can't outsource understanding).
I can guide what exactly needs to happen. I already validated this idea on my own project and it worked: 10k LoC -> 250 acceptance criteria. And you can find it on my GitHub, I even described steps. If you're too lazy here it is:
You need a SCIP graph. Agent goes over it and builds ledger, one symbol at a time, looks at what kind of problem this symbol solves. This leads you to v0 specs, then you can figure out taxonomy, then you try to fit all those thousands of specs into taxonomy / groups that make sense. And that would be v1 spec but you might want to refine it to v2/v3. And then the only thing would be left is figure out what kind of tests those specs should have (e2e/unit/integration/api/whatever). This is tricky part but doable. I'm thinking for git you wanna do e2e specs. Yes, that's a lot of e2e but the purpose is that we build same expectations for git, and then we replace git with grit and spec should still stay green, right?
Hope that makes sense.
[dead]
In the age of AI, writing things that used to take years can now be done in months or weeks if you have deep enough pockets for it.
Reimplementation is a particularly juicy target because it's easy to test. Imagine someone writing a better browser than Chrome from scratch in just a year.
Because of this moats around business due to difficulty of implementation are effectively gone.
> can now be done in months or weeks if you have deep enough pockets for it.
Especially if there's the same thing that already exists in open source that the model can plagiarize for you.
This looks more like a blog-blurb (if blogs had blurbs) than a comment.
> the result is Grit, a from-scratch, library-based, memory-safe, idiomatic Rust reimplentation of Git that passes over 99% of the entire Git test suite.
Why not 100%?
> It's not actually passing every single test, though that is on purpose. I did mark some parts of the testing suite as "skipped" because I don't think it's worth recreating them in a library like this
> 41,715 / 42,001 tests passing (99.3%)
So it is not entire then but somehow that was worth burning $8,000~ dollars worth of tokens?
> Why not 100%?
From the article
> It's not actually passing every single test, though that is on purpose. I did mark some parts of the testing suite as "skipped" because I don't think it's worth recreating them in a library like this - email related stuff, i18n, perforce/svn importers, some of the midx/bitmap stuff - things of that nature. However, for everything that I'm sure is relevant to nearly anyone reading this, the Grit library/CLI can now fully pass the Git test suite.
So .7% tests fail therefor it was 100% a waste of time?
I think we are talking about ROI in terms of solving real world problems and making real impact, not the fact that a tool has been ported from language X to language Y.
Given the author already admitted that the implementation was slow anyway, you are no better off of using gitoxide instead and that has support for Windows where-as Grit does not.
> Currently both Gitoxide and libgit2's networking functionality is either partial, slow or non-existant. Both GitButler and Jujutsu rely on forking out to Git in order to push or pull data. A big reason for this is the incredibly complicated credential logic involved, but all of this is (theoretically) currently covered in Grit.
Regardless, what's the point?
> One of the main things I would like to be able to use it for is to be able to bundle complex push/fetch functionality into GitButler and other standalone Git tools needing network functionality (such as Jujutsu).
> Having parts of Git as discrete, embeddable slices of library also enables things like building custom Git servers or client functionality in Rust.
> The full build of all Git functionality in Rust is currently around 27M, but since a large part of it is a library, it could clearly be easily split up into domains of functionality - subcrates that do specific things. Perhaps you could simply use the subset you need.
The article starts out with paragraphs about the history and motivation.
> it made me wonder about the feasibility of using that same approach to accomplish something I've been dreaming about for 15 years now,
> which means that it's difficult to use it in long running processes without fork/exec overhead for everything.
> What if we used the same basic idea that Anthropic used on their from-scratch C compiler? Start a brand new implementation, design it as a Rust library, then throw a swarm of agents at the problem
maybe it's an academic project. proof they could reimplement something useful & complex?
There is often good reasons for these purposeful digressions. I.e. in nginx the unit tests cover cyphers that are considered unsafe and not supported by modern libraries like rustls https://github.com/rustls/rustls. It is reasonable to make a new implementation and leave behind a bit of baggage.
The author actually estimated $10-$15,000 worth of tokens.
It depends whether the 0.7% failures are testing deliberately unimplemented features like email or is in corner cases in implemented features. It sounds like it's at least mostly the former, hopefully it's 100% the former.
I don't care if any git I use has email features. IIUC, even most of the people that use git with email don't directly use the email features, they use the patch set features like `git am`. I expect `git am` to work, I don't expect git to actually do email.