Philpax3 hours ago
> 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.
nextaccountic3 hours ago
they would be just wrong. I hope someone with standing sues
gpm2 hours ago
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.
Conan_Kudoan hour ago
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.
joshkaan hour ago
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?
NewJazz11 minutes ago
Medium, substitutibility, basics of copyright law.
trumpdong14 minutes ago
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.
joshkaan hour ago
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).
trumpdong15 minutes ago
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.
joshkaa few seconds ago
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.
hankbond15 minutes ago
> 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.
usernametaken298 minutes ago
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?
absintini3 minutes ago
Soon all the crustaceans will realize that C is better because AI can find all the vulnerabilities anyway.
Rust is some ugly poo.
heyts3 hours ago
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
MBCookan hour ago
> 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?
blastonico18 minutes ago
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.
uecker13 minutes ago
They can still break stuff memory safely.
jamesfinlayson3 hours ago
> 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.
jordandan hour ago
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...
stefanhaan hour ago
> 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.
ianm2182 hours ago
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.
jabwd2 hours ago
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?
ianm2182 hours ago
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.
fvdessen2 hours ago
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 ?
ianm21830 minutes ago
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.
tredre3an hour ago
> 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.
ianm21833 minutes ago
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...
uecker9 minutes ago
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.
jabwd2 hours ago
Buddy, I think it is time to not engage with these models for a bit, you seem to have lost your mind.
ianm2182 hours ago
We're literally in a thread on converting legacy C projects to idiomatic Rust? It seems many people are working on this same problem.
feelamee2 minutes ago
nit: well-written C projects to legacy Rust
jabwdan hour ago
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.
jauntywundrkind2 hours ago
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.
squidsoup2 hours ago
I guess software licenses are meaningless now since anyone can decide their llm clone is not derivative.
trumpdong18 minutes ago
They were already quite meaningless since nearly every FOSS copyright owner doesn't sue violators.
Yokohiiian hour ago
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.
Aperocky2 hours ago
> 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...
Levitating2 hours ago
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.
Aperocky2 hours ago
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.
MBCookan hour ago
Isn’t git already just an interface over libgit? How is that different?
tredre3an hour ago
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.
dabedee2 hours ago
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.
fg1373 hours ago
Does anyone plan to use this?
Similarly, is there any momentum left for Cloudflare's EmDash? I can barely find any discussion after April.
gpm2 hours ago
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.
linsomniacan hour ago
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.
MBCookan hour ago
But why switch to this?
Why not just make better Python bindings to libgit?
Yokohiiian hour ago
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".
anonovaan hour ago
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.
mojomboan hour ago
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!
Yokohiiian hour ago
Okay name is taken. Let's rename it to Grift.
imoverclocked3 hours ago
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?
0x000xca0xfean hour ago
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.
fg1372 hours ago
In 6 months, seeing no adoption, move the repo to maintenance mode. Archive in 12 months.
Yokohiii2 hours ago
He will be probably super happy for starring the project.
boredatoms2 hours ago
Theres already git-in-rust project that is making good progress
jauntywundrkind2 hours ago
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.
dabedee2 hours ago
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.
joshkaan hour ago
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.
MBCookan hour ago
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?
joshkaan hour ago
> 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"
trumpdong17 minutes ago
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.
joshka5 minutes ago
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.
ewy12 hours ago
pretty dystopian to ask a robot to recreate your favorite software just so you can relicense it for your business venture
tonymet3 hours ago
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.
gdgghhhhh3 hours ago
So, they "decided" it's not a derivative and thus can be listened under MIT instead of GPL....
madeofpalk2 hours ago
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.
subygan3 hours ago
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
huflungdung3 hours ago
[dead]
rvz3 hours ago
> 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?
gpm2 hours ago
> 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.
insanitybit3 hours ago
So .7% tests fail therefor it was 100% a waste of time?
fg1373 hours ago
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.
rvz3 hours ago
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.
sharkjacobs3 hours ago
> 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.
Zopieux3 hours ago
Regardless, what's the point?
sharkjacobs3 hours ago
> 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.
insanitybit2 hours ago
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
tonymet3 hours ago
maybe it's an academic project. proof they could reimplement something useful & complex?
ianm2182 hours ago
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.
MBCookan hour ago
The author actually estimated $10-$15,000 worth of tokens.
bryanlarsen3 hours ago
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.