Rar is proprietary. Good luck.
https://law.stackexchange.com/a/83552
I suppose the question is whether the author had ever entered into a contract limiting reverse engineering...
Rars: a Rust RAR implementation, mostly written by LLMs
51–60 of 92 posts
Re: Rars: a Rust RAR implementation, mostly written by LLMs
#52Earlier quoted context omitted.
Thus all software that can be used is correct? You know what I meant: How can we have confidence that this implementation of RAR is functionally identical to what it's based on? What would give me the confidence to use it in a critical piece of infrastructure?
Validating compression systems is usually really straightforward. There are 3 layers - decode known values from compressed files (or encode, same), round trip without any alterations, and fuzzing with arbitrary binaries Because it's a defined format there can be binary exact comparisons between the input and output files - we already have an oracle in the form of proper RAR format software, so if they are identical,…
Right, that's very different from "using it" and it's also different from "Have an LLM generate code that compiles".
Re: Rars: a Rust RAR implementation, mostly written by LLMs
#53Earlier quoted context omitted.
By using it.
Thus all software that can be used is correct? You know what I meant: How can we have confidence that this implementation of RAR is functionally identical to what it's based on? What would give me the confidence to use it in a critical piece of infrastructure?
> Thus all software that can be used is correct?
You also know what I meant, since I spelled it out in more detail a comment later. But even though you're being facetious, yes, that really is the case. If it works it works. That's the bar for the vast, vast majority of software, and has been since forever. Demonstrated practical correctness. If you stumble into a bug, you log it as a defect and then either wait for a fix or fix it yourself depending. That's all that regular people ever have. In the case of this project, this was achieved via fuzz testing.
It's literally no different to e.g. validating the NTFS driver that ships in the Linux kernel, or validating any other (re)implementation of anything. You just do a bunch of empirical testing and hope for the best. It is also why reimplementations always lag behind, which I'm not suggesting is not a real concern (or that defects wouldn't be). It's just not a gotcha.
Hell, I'm 99% sure this is exactly what the actual vendor does too, or at least I sure hope that they do have tests at least. Cause they're sure as shit not using a formally verified compiler toolchain, meaning they definitely don't have a formal proof about whether even the official implementation in itself is correct. Only empirical data at best too.
Re: Rars: a Rust RAR implementation, mostly written by LLMs
#54> It’s sloppy, it’s slow, it’s almost two megabytes in size and somewhat worse than WinRAR on compression. As mathematicians say, optimization is left as an exercise to the reader. You did the hard part.
I mean, not really...? A vibecoded mess that runs badly, that's not really the hard part for something like compression/decompression tools.
What's your easy way of reverse engineering every previous version of this file format, if you don't think that was the hard part?
Re: Rars: a Rust RAR implementation, mostly written by LLMs
#55Earlier quoted context omitted.
I read the post you're replying to as saying "this is copyright-encumbered and nonfree because it's a derivative work of everything in Claude's and GPT-5.5's training corpus", which is an argument I find fairly tiresome. (Realistically, if courts actually rule that this is the case, this tiny little project will be the least of anyone's concerns.) "This is copyright-encumbered and nonfree because it's a derivative wo…
The point is, excepting current legal standards which are already very murky, how can _you_ claim copyright, if you don't _know_ it isn't encumbered? You can get these LLMs to generate copyrighted outputs both intentionally and accidentally. This is a known fact; therefore, if you're not checking the output to see if this has occurred then you're potentially generating legal risks for yourself and anyone who uses you…
What do you mean by "checking the output"? Is there some kind of check the author says he didn't do that you think he should have? Or is your claim that using an LLM for coding is always copyright infringement? If so, I think the risk that I'll personally be the test case that resolves whatever ambiguities exist in the law is basically zero, and I don't think derailing the thread to be about that topic enlightens anyone.
Re: Rars: a Rust RAR implementation, mostly written by LLMs
#56I have never attempted something so ambitious with AI, but this feels spot on in terms of experience. As you cede more control to the model, you will find yourself losing control on things like code quality and performance.
You have to make performance part of the spec. It will then create benchmarks and plan differently. If you omit this, you get what you get.
Re: Rars: a Rust RAR implementation, mostly written by LLMs
#57Earlier quoted context omitted.
By using it.
I could be correct but way too slow in edge cases (unlikely with Rust but you never know), leaking temporary files, having security holes, etc. There's much more about correctness of a piece of software than: "produces the same output as the original on x test cases" . I'm not saying it's a bad implementation and, if anything, LLMs are much better at translating/porting existing code (and finding bugs) than at writin…
[dead]
Re: Rars: a Rust RAR implementation, mostly written by LLMs
#58Earlier quoted context omitted.
The human wasn't looking at the copyrighted code and was giving high level steering instructions. If you look at the spec generated it doesn't look like a derivative work of the copyrighted material. The program was generated from the spec. It seems mostly fine from my perspective.
If I use a decompiler on existing binaries, then some machine translation utility to turn that into a different language, that still feels like a derivative work, even if no human were reviewing the specifics.
The idea is to make it so that the parts of the output that are derived from the existing binary are not themselves eligible for copyright protection. I.e., factual descriptions of the file format, without any implementation details from the binary.
Re: Rars: a Rust RAR implementation, mostly written by LLMs
#59Earlier quoted context omitted.
Yes? What do you think fuzzing, unit testing, integration testing is for? It's an empirical evaluation of correctness. Literally just try and see. For actual correctness verification in the strong sense, you'd need to start from a specification written in a formal language so that it's machine checkable, which if I had to guess not even win.rar GmbH has.
You're being needlessly dismissive. From a philosophical perspective, there's no way to know that any piece of software is truly correct without formal verification. But in the present, non-philosophical context, it's obvious that what we mean is, colloquially, "how well-tested is this against a variety of edge-case files which the official winrar handles correctly? Is there a test suite, and how robust is it? Plenty…
The post mentions the existence of an extensive test suite, which you can peruse for yourself if you're so inclined: https://github.com/bitplane/rars/tree/master/crates/rars-for...
I don't know how all these test cases were generated, but at least some of them seem to have been copied (with attribution) from the test suites of earlier FOSS RAR implementations.
The ideal would be to test it against a representative corpus of real-world legacy RAR files, but I'm not sure where you'd find one.
Re: Rars: a Rust RAR implementation, mostly written by LLMs
#60> But, it works, and the world now has a free software RAR implementation. Does it? How are you legally intending to use copyright to license this machine output? How would you know it's not encumbered in any way?
In all seriousness, why should anyone care?
I always found software IP to be absurd, but this is a particularly absurd situation. We're talking here about a small utility tool implemented from scratch and open sourced, with no apparent intent to make any money from it.
Are you concerned about the "encumberence" of using "unlicensed" tools to manipulate .doc, or .pdf, or .mp3 files?! Well I'm not, and if anyone ever tried to sue me for improper access to their proprietary formats, I'll show them some old testament impropriety.