Uutils: an attempt at writing cross-platform CLI utilities in Rust
github.com
github.com
2016, 490 comments: https://news.ycombinator.com/item?id=11337399
> tldr: Rust/coreutils ( https://github.com/uutils/coreutils/ ) is now available in Debian, good enough to boot a Debian with GNOME, install the top 1000 packages, build Firefox, the Linux Kernel and LLVM/Clang.
BTW some notes on how the GNU coreutils are tested are at: https://www.pixelbeat.org/docs/coreutils-testing.html
This makes me really happy.
Separately from this, I've been wondering for a long time if there's a way for standards (and de facto standards) to share test suites for other implementers to re-use. Sort of a npm but only for test suites. Does such a thing exist? I wrote a TOML parser recently and had to re-derive the test suite from the specs.
I don't think it would be easy to cheat if:
- tested implementation is open source: it would make cheating too obvious,
- tests are constantly updated: it would make cheating too cumbersome and
- tests include a randomization: it would not always work.
> If you made a hypothetical JSON implementation in your language of choice, would you use it?
On my machine? I use my own hacked kernel on my machine! In production? Only if tests indicate my implementation is as good as the best ones available.
However I doubt this applies to coreutils' tests, which I suspect are more about conformance.
For straightforward corner case acceptance tests (which I would assume covers most of the coreutils test suite) there's not really a danger of overfitting unless the developers are literally writing if statements that match a single input from the test and provide the correct output.
> Could we get the best of both worlds by treating specification and compliance (testing) as a single problem? This hypothetical approach i call specification-driven development, whereby a specification document is intended both for human and machine consumption. In that case, the specification contains a written presentation of concepts, in addition to a machine-readable test suite that follows a certain format to programmatically ensure that the concepts and behavior described in the specification are implemented properly.
I've centered the document on my personal usecases (CLI and sysadmin checks) but i don't see a reason it couldn't be employed for API/ABI checks.
- Fix their own existing bugs - Help other projects to fix their bugs - Be explicit about what they support and what they don't - Help writing new libraries (eg in a faster language, or for another ecosystem)
> ./target/debug/cp /dev/null /dev/zero
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }', src/uu/cp/src/cp.rs:1295:54
> ./target/debug/mv . .
./target/debug/mv: cannot stat '.': No such file or directory
Anyways the point is that there's lots of legitimate institutional knowledge baked into coreutils and a naive RiiR effort will re-introduce previously fixed bugs.
The last one is a different kind. Rusts std lib indeed cannot stat . Which means they would have to translate . into the coreutils meaning manually. Their tests should have cought that one tho.
But the kernel can! I mean, stat() isn't a standard library function, it's a system call with (reasonably) well-defined semantics. And "." is a valid path, which returns a valid struct stat block representing a guaranteed-valid (cwd is always live; you're always "somewhere" even if the filesystem has removed the directory) directory.
Coming at this from the perspective of "translate . into the coreutils meaning" is almost certainly the wrong way to think about it. It's rust that has the broken picture of the filesystem environment, coreutils is just doing unix.
This isn't a Linux project, it is a cross-platform project.
Or I guess what you're saying is that uutils is a cross platform project? Which is true enough, but it's still responsible for faithfully representing the behavior of the underlying system. And when running uutils on linux, stating "." (in this case to detect that src and dst are the same file) is legal and valid.
It's true there are other ways to solve the same problem than emulating a linux syscall layer, but you have to pick one. You don't get to use "the standard library can't stat ." or "we have to run on windows" as an excuse.
[1] And I'll admit that I don't have any understanding of the actual low level issue here or why native pathnames are being interpreted by the runtime and not passed through to the OS layer.
[1] Maybe this is all just a semantic argument about this use of the word "broken"? This is a long-standing usage. It doesn't mean that Rust's standard library isn't useful for anything, it means that it isn't useful here because of design choices that don't match the problem at hand. If it were something that can be fixed, it would just be "buggy". But it can't (for the reasons you mention!). Therefore it's "broken", not "buggy".
I don't see the problem for something that was just released as a very preliminary version
(Though I don't know where cp is getting "PermissionDenied" from)
Fwiw the project os half a decade old.
> (Though I don't know where cp is getting "PermissionDenied" from)
Have not looked at the problematic code but e.g. copy_file_range(2) says
> EPERM fd_out refers to an immutable file.
The reason I say this is that while users will expect this behavior, doing it well (so that it can be parallelized, for example) requires careful thinking about how errors should flow, how lines are printed to stdout, etc.
There is "done" and there is "not done"...
In this case, semi-done probably means what it usually means: some common cases are handled, while others aren't yet.
I think we need to be more flexible than classifying things as done/not-done. Even GNU coreutils has open issues[0] - is it "done" or "not done"?
[0] = https://debbugs.gnu.org/cgi/pkgreport.cgi?pkg=coreutils
1. Not done. :-(
2. A lot has been done already, i.e. not just-started.
3. Not almost-done, i.e. there's significant work still to be done
GNU coreutils is one of the pillars of our civilization. Re-implementing it in several new languages can only benefit everybody, as it will lead to a higher understanding of all the implementations, including the original one.
So far, the tests of this Rust version seem to be used to compare against GNU coreutils, with a goal to attain feature parity. I hope in the near future, the careful memory management of Rust will motivate new tests that will be passed by the Rust version but failed bu the C one (e.g., some memory leak, or an input that triggers a segfault in the C version). Then, you will see a new curve in the graph concerning the number of tests failed by the C version, which at some point will cross the decreasing curve of the Rust version! The coverage of the rust implementation is still a bit sparse for that, but hopefully it will improve.
There is one feature, though, that is unfortunately missing in this Rust re-implementation: the fact that users of coreutils will always be able to examine the source code of the programs that they run. This is guaranteed by the original copyleft license. Βut this Rust version uses a "stealable" license that allows distributors of these programs to strip users of that right. This is really sad.
Thanks for the interest!
It's an interesting experiment to replace such a fundamental dependency with a rewrite. A lot of the build failures are due to uutils not implementing GNU extensions, some of which can get pretty involved.
[0] https://github.com/NixOS/nixpkgs/pull/116274
[1] https://github.com/NixOS/nixpkgs/pull/116274#issuecomment-85...
[2] https://github.com/NixOS/nixpkgs/pull/116274#issuecomment-86...
If this truly injures you, you can either do your own rewrite or, like Muse Group, outright buy the rights to the software and relicense.
https://github.com/uutils/coreutils/issues/1781
Honestly, it sounds like they're deeply scared of long-standing FSF-backed software having to compete (or even be replaced) with alternatives that just happen not to be GPL (e.g. they have similar thoughts on LLVM/clang), to the point where they decide to troll the issue trackers. It feels really childish.
LLVM/clang is worse than just GPL, as far as I understand the design of GCC is intentionally horribly bad to make it painful to integrate with a proprietary tool chain. Of course this means that things like refactoring support end up being basically impossible to build on GCC, so people move to clang out of necessity.
These days GCC does have a plugin interface, but they came up with a really funny hack to try to stop people from using proprietary plugins. Programs compiled with gcc can require linking with libgcc, and the libgcc license is "GPL, except it doesn't apply to software compiled with GCC and all-Free plugins". So their idea is that if you add a proprietary plug-in to GCC, that makes all code compiled like that have to be GPLed instead.
It is, of course, questionable whether this hack would hold up in court. It is also rather useless, because it's not hard to reimplement enough of libgcc to make it work. For example, the Linux kernel only links with libgcc for a few architectures.
They are, for good reason. Big companies hate open source, despite their claims to the contrary. Look at Apple's proprietary forks of all the BSD stuff, and handset manufacturers' proprietary forks of Android. The FSF should absolutely be doing everything in their power to minimize how often this happens.
What forks of what stuff?
Here's the kernel, including all the BSD stuff:
https://opensource.apple.com/source/xnu/xnu-7195.141.2/
You can compile it yourself and run macOS with your own kernel build. Here's a blog by Apple's head of XNU development explaining how that works:
https://kernelshaman.blogspot.com/2021/02/building-xnu-for-m...
You made a claim about "proprietary forks of all the BSD stuff". The kernel is open source. The rest of the OS is written from scratch by Apple, and originally by NeXT, and is not a fork of anything.
Are you standing by your original claim?
Not to shit on the project, just that the title made it seem like something ready to use .. (most of the tests are still failing)
But to answer your question about Windows:
Because requiring an emulation layer is a huge step up in complexity from being able to distribute your shell as a single static binary which is just a few MB. Right now Elvish and Nushell, for example, can be deployed on Windows as binaries that don't require any external dependencies, any installation procedure, or any configuration. If they could link against uutils statically, they could also come with basic utilities without having an environment to manage.
WSL (along with MSYS2 and Cygwin) is deeply stateful. Now to make sure everything is working you have to check the compatibility of your whole system, and the versions of coreutils can still vary in addition to the version of the shell interpreter.
WSL2 also requires virtualization, which can complicate using it under virtual machines.
You may not want everything you run under your shell to depend on WSL, which is also happens with WSL2.
Even with WSL1, a script that requires a chroot environment to deploy and run it is way less portable than one that doesn't.
(rm, cp require -r, mv doesn’t, no auto-directory creation for mv - if you don’t believe me look at git/hg which don’t copy the semantics + I’d like reliable dry run and by default confirm every destructive action)
These are all like that on purpose.
mv doesn't have -r because it's a safety feature for rm and cp, since deleting or copying an entire directory is expensive so you should have to specify it explicitly. Moving a directory is really just renaming it, which isn't expensive when it's on the same filesystem (and it usually is).
The most common case for the destination directory not existing when moving something is a typo in the path. Then you'd end up creating a directory you didn't intend to, possibly on a filesystem you didn't intend to, and moving all the other arguments over there. It could be useful to make it possible to explicitly specify that you want this, similar to mkdir -p, but you could add that to the existing mv without breaking anything.
rm /home/john/some/file.txt
But you accidentally type:
rm /home/john some/file.txt
It says:
rm: cannot remove '/home/john': Is a directory
Instead of john not having a home directory anymore.
And people aren't going to use a dry run option or interactive confirmation every time they run a simple command like that.
- listing how many files/directories would be moved
- listing how many files/directories would be overwritten
- telling whether the transfer will cross drives (especially for mv)
reasonably speaking this should not be included in the base posix cp and mv, but could be maybe provided as intrinsics in bash for example
And copying them is still actually expensive. Data expands to consume all available space. Accidentally copy a 16TB directory structure and you're going to max out the I/O on your machine for hours and maybe run it out of space. It's not a big ask to type two characters to confirm that you want to do that.
These make total sense for me.
also, a minor nit: there are still a lot of work [1] that needs to be done, and imho, it is a bit premature to title this article as is presented here.
I think most don’t care, and big corps love the MIT license
Doesn't Microsoft love using Linux for azure, and contributes to it heavily in code and money? Using binary blobs is how they can get around others using their contributions, and it seems like copilot has made a mockery of all the licenses anyway.
>Mastodon
Oh interesting, looks like it was forked by corporations though including Trump's Truth Media, and Gab, and Truth Media just shows the boilerplate github source code. To me it still seems they love all free code.
Which isn’t to say anything about how a project ought to be licensed; just that MIT enjoys overwhelming popularity with newer projects.
What matters is whether they contribute back anything to open source. And it's a hell of a lot easier to get Legal to sign off on contributing back bug fixes and enhancements on a piecemeal basis rather than adding a recurring obligation to the books.
A lot is companies would have preferred to have proprietary operating systems, but the Linux license prevents them.
I don't see this as a valid point.
The point of copyleft is to make this not true. Most companies don't have the resources to reimplement Linux from scratch, so they won't be allowed to make their drivers/kernel modifications proprietary.
well, ever wondered why router vendors include GPL license paper in the box? this [1] is why...
[1] https://www.crn.com/news/applications-os/205100091/busybox-s...
You have been misinformed. The GPL is a much better license for users. MIT is arguably better for the authors because they can deny certain freedoms to their users (the ability to change the code on a system, for instance).
Flame war! Flame war! Flame war!
You're stupid and probably ugly for wanting a flamewar!
FreeBSD and clang communities, maybe not so much.
For me. I want my software to be as much gplv3 as possible. Not trolling. Also not arguing, it's just the way I roll.
...or perhaps they did not like the last part of your comment, the "it's just the way I roll" one.
Just to elaborate then, I personally want my software to use gplv3 because I side with the ideological/ethical aspects of free software. I want to support projects/teams/orgs that build this future. An mit licence would allow a company to capitalise on the community's effort withought giving nothing back. Or even worse, make modifications and deliver closed source blobs to users. I personally do not like that. Thus, I wouldn't support/use this library.
To be clear, I am not running 100% gpl software atm, but I see it as a journey going there, slowly transitioning.
For me, for example. I personally prefer my foundations on xGPL (preferably V3 and later), because some company or set of companies just can't fork and run away with it.
I personally consider computing utilities and compilers essential infrastructure and their sustainability while being completely transparent are critical for me.
All "xGPL to shenanigans" incidents have underlying copyright transfer problems. Recently, an emulator had gone the same way. They asked for copyright transfer to be able to relicense from GPL, and some folks here have used derogatory adjectives for people who didn't want to transfer their copyrights.
So where are the others stepping in to fill the void reaching C++20 compliance and catching up to GCC and VC++?
MySQL -> MariaDB
OpenOffice -> LibreOffice
Chrome -> Chromium
VSCode -> VSCodium
and so on.
GPL protects my rights.
RedHat built a company on that model? Provide value and GPL won't threaten your business model.
Seeing something useful and then having to do it myself anyway because I cannot use it due to the license is painful.
EDIT: Just checked, it is still there! And... It doesn't contains sudo. Can't see a good reason why.
(I understand being worried about the license of libs you're going to deploy, but the license of cli utils isn't something you need to worry about "infecting" your proprietary code.)
The problem with POSIX is that, while it's possible to implement the bare minimum, it's hard to not have a few extensions. There are some truly braindead ideas that GNU coreutils have absolutely improved upon.
Sadly, a new coreutils collection simply brings further incompatibility. There's already significant switching logic out there to handle BSD vs GNU coreutils (have you ever used sed -i?), adding another flavor makes this sort of thing dead on arrival, at least to me. I'm not retrofitting my scripts to support these implementations too.
Aside, Nix is the only real solution to this problem, as it can replace these tools wholesale, hermetically. Being able to depend on a specific implementation in a portable manner is rather compelling.
I wonder why some people in the Rust community seem to remind us every few sentences how Rust is superior to C because it's safer.
/s And now it's C, yesterday it was C++... what's next, ASM ?
than
"We did it in Rust, and we believe it's better because ..."
?
> However, those projects are written in platform-specific C, a language considered unsafe compared to Rust
Or to paraphrase it using your wording: "We did it in Rust and we believe it is better because it does not have memory unsafety issues that are the number #1 reason for security issues every year"
"We have security issues every year because we program in unsafe languages like C, and to solve this, we should start rewriting things in Rust because it's 'memory safe'."
Amazing!
I know in GNU Guix the more Rust is used has lead to struggles in packaging and building from source for non-x86-64 architectures (demands of building the Rust toolchain, bootstrapping), e.g. [0]. With something like librsvg [1] being a very low level dependency now, Rust has become rather integral to many parts, with any changes to these libraries requiring massive rebuilds for a source-based reproducible distro like GNU Guix.
[0] https://lists.gnu.org/r/guix-devel/2021-11/msg00197.html
I fell in love with the performance of rust CLI tools and mainly see its utility as a fast performing binary, memory safety is a bonus but if I had known about its performance earlier I would have ignored anti rust propaganda like quoting Linus saying “Nothing better than C”.
This article is a good example
http://dtrace.org/blogs/bmc/2018/09/28/the-relative-performa...
And, yes, so-called "free concurrency" ended up being an incredible performance story, although, full disclosure, I/we were just able to use rayon in many places because Rust is just that composable.
See, for example: https://github.com/uutils/coreutils/issues/2757
EDIT: You may also be interested in https://github.com/mvdan/sh
Go and Rust are optimized for different types of environments. There are a lot of situations when selecting Go over Rust would be a more pragmatic choice. I don't see how coreutils is one of these.
I would feel differently if it were something else, like gawk, for example. Rust would be a better fit there.
https://news.ycombinator.com/item?id=29456115
I've tried making non-confrontational arguments in favor of the switch. Consider adding to them if you agree (or counter-arguing if you oppose, I guess) - but please keep the tone there less argumentative than here.
[1] And gcc with clang when bootstrapping
There's nothing wrong with GNU coreutils.
Again, would be nice, just not where I'd start. But kudos to anyone doing the work.
Not to mention that memory safety is just one aspect of security. Rust's ownership model might have prevented those 4 vulnerabilities, but that doesn't mean that a whole host of others couldn't have slipped through.
Rust itself has had 9 CVEs relating to memory safety in 2021 alone[0], which you can justify because Rust's development is highly active.
https://www.cvedetails.com/vulnerability-list/vendor_id-1902...
At least, that's my understanding.
https://github.com/uutils/coreutils/issues/1781
I'm curious as to what extent GNU coreutils governance is tied to the FSF these days.
Personally, most of the software I write is under a 3-BSD or MIT license - unfortunately. I wish I were in a position to write more GPL code.
GNU coreutils are protected against a hypothetical proprietary ownership and I value that protection a lot.
What counts as a "distribution"? Well, that's a contract interpretation question, and if you are not asking that question of a lawyer, then you have a fool for a client. I suspect that there's actually a lot of technical GPL violations going on, but since the open source community is not litigious in general, there's little realization of those violations and even less care that those are going on.
Personally, I am not a fan of the GPL licenses for this reason. If you are trying to use legal contracts to enforce norms, it is disingenuous to argue that you don't need lawyers to be involved. Using social contracts and pressure instead would truly allow everybody to avoid lawyers and achieve much the same goals.
Really?
https://www.gnu.org/licenses/gpl-3.0.en.html
>It's an actual contract between the source provider and anyone who uses it.
I don't want a contract, especially NOT with the FSF and their shady GPLv3 introduction...not thanks. If i want a contract i go to Oracle.
I protest this dichotomy. But even beyond the dichotomy, you're atomizing in the way you discuss people. A community or large group of users have among them both developers and resources to recruit developers to further their collective needs. When MIT/BSD-licensed software ends up being developed beyond the original freely-accessible base within commercial entities, as in:
> MIT code can be used in a closed source system a lot easier than a GPL one can.
then those communities and groups are stuck with a thorn in their side they can't remove, which warps technical fields to accommodate it and is utterly frustrating.
This has been my personal experience in more than one field. As an example it's like that with the CUDA ecosystem for GPU use, much of it is closed and hidden while employing technologies like LLVM, and likely a lot of other FOSS and free academic publications regarding effective computing. I really wish their choice was either much crappier closed-source commercial stuff, or, say, a GPL'ed LLVM, and having their drivers and user-mode toolchains open. If they were to choose the latter, than great; if they were to choose the former, than they would be at a competitive disadvantage and hopefully others (e.g. AMD) would use that to gain more traction with GPL'ed software. I'm not saying that this would _necessarily_ happen, but it might very well.
> Developers love to talk about the freedoms they have with licenses, while ignoring that the whole point of the GPL family is disregarding that in favor of the user's rights.
I think you meant MIT and BSD? Anyway, the point of the GPL and Free Software (using FSF/RMS terms) is to get enough software to have GPL-style license that it becomes unreasonable to license software any other way, with the end result being that essentially all released software will be free for use, dissemination and modification and we will be able to forget about software licenses altogether since people will stop trying to limit that and what is now the GPL would essentially be the legal default.
I like that, and i like free flovers. What i don't like are lawyers and stuff like the GPLv3, AGPL and all the licenses who try to put some political view on me.
Look it's like that. If you fork and close down a BSD/MIT code base, you loose all those devs (no free flowers from hippies anymore), instead you have to pay your own dev's, juniper can sing a song about that problem. So without any pressure, just with the logic of economy you try to stay as near as possible to the free codes base with your product (and integrate your changes), netflix can sing a song about that too.
Continuation has nothing todo with the license but with interest of developers see -> Hurd
>Continuation has nothing todo with the license but with interest of developers see -> Hurd
i think developer interest has far more to do with technical viablity of a project than license choice. besides, as in all software some projects fail, some succeed, and some are just beginning
Why is that a problem? There was already toybox (BSD), muslc (MIT), llvm (UIUC (BSD-style)). The dominant issue the FSF has is that they are no technically interested anymore but politically, and so no one need's them, no one wants them.
And listening to Stallman is really boring, the last time he was kind of self-aware was with the Religion of Emacs, since then just repetition and being rude to interviewers and trying to trick devs (Linus and the GPLv3)
BTW: I am NOT talking about the GNU project, just the FSF
simple. imagine: you value free software; you invest a lot of effort to make a really important critical piece of software; you license it under MIT; some company uses your software as a critical component, develops a lot of software on top of it, keeps the source closed, makes massive profit for itself, dominates the market and becomes a monopoly, all thanks to your critical component.
now the question is: are you pissed off? if you are not, choose MIT. if you are pissed off choose a self-perpetuating copyleft license
Like to give a real world example for that? Or is it just theory?
one of the other posters also mentioned CUDA's reliance on LLVM. i think that is a very good example also
No they would buy a license for one of the hundreds proprietary compilers, and you will eat their dogfood like you do today with cuda itself.
>or have cuda released under a free license.
Dreamer...it's nvidia....you know the ones with the "driver" that runs with the GPLv2 kernel.
i thought you said you are a hippy
anyway at this point everything becomes hypothetical. however what is certain is that copyleft licenses could make life much more difficult for monopoly companies than permissive licenses, and i am ok with that, just as i am ok with FSF being agressive about matters pertaining to software freedom. could they have a better and more effective approach, i dont know. maybe. i am not involved in any shape or form with them, but i guess that right now they have my support
FSF can be as aggressive as they want, they will not change anything...quite the opposite actually.
they exist for over 35 years now. are you sure they haven't achieved anything? :)
MIT license basically allows you to do whatever you want. however it should be well noted that if you really belive in software freedom and write your code for sake of furthering free software, choosing MIT is a naive choice since you let any derivates of your work to be closed source
"Were all Unix commands re-written in Linux?"' https://unix.stackexchange.com/questions/85189/were-all-unix...
"Is the GNU Coreutils copied from Unix?" https://unix.stackexchange.com/questions/81302/is-the-gnu-co...
Heck, POSIX stands for Portable Operating System (POS) + IX because X is a cool letter and IX because POSIX is cooler than POSIX plus, you know, UNIX.
If I implement it in Rust now, dont think I will be accused of copying IBM?
* GNU Coreutils: GPL licensed
* uutils: MIT licensed
right?
The MIT license is not only an Open Source license, but it's even a Free Software license according to the FSF itself.
So this is nitpicking of the 100th degree at this point.
If someone makes proprietary extensions to "ls", they are just going to be stuck maintaining a fork. There is no realistic threat here.
"While this may superficially look like a noble strategy, it is a condition that is typically unacceptable for commercial use of software. So in practice, it usually ends up hindering free sharing and reuse of code and ideas rather than encouraging it..."
> it is a condition that is typically unacceptable for commercial use of software
https://en.m.wikipedia.org/wiki/Viral_license#Criticism_of_t...
That's not true for most uses of other GPL licensed libraries and software, where the license makes your code a "derivative work".
I just don't think Linux is a great example to explain to a company why they should be fine with licensing their software under the GPL. It's not a good direct comparison in most cases.
Many people assume all of Linux is GPL. I say "special case" because not everyone knows the most-linked-to stuff isn't.
Depends by what metric and the definition of "commercially". I'm not sure this is the case for (physical) devices sold with software pre-installed.
I mainly see BSD licensed binaries on network appliances (routers, firewalls and other security appliances), apple hardware, automotive headunits, ...
But, for some manufacturers, you can. Synology is a good example...see Xpenology.
disclaimer: I did actually make the first commit on one of these tools, but I didn't look at the source of the original C code.
For example, significantly identical code flow, variable naming, or function structure would be red flags, especially if it's not the "obvious" implementation.
Unlike for example, Java 1.5 and C# 2. I think at the time you could almost copy paste Java code into a C# and have it compile after tinkering with it for 2 minutes.
In this case, the "spec" of the coreutils would probably the man pages.
Changes to the C code to be idiomatic Rust does throw a wrench into the whole thing, and it would have to be sorted out by a court, but it's not as simple as people like to think.
As usual: IANAL
Copyright protects creative output. That means if you copy creative aspects of the code - things like the structure, naming, algorithms down to small details of the implementation - then you are creating a derivative work (this is what happens if you translate code from one language to another verbatim - not trying to be idiomatic - most of the time). If you merely read the original code to understand what it does and create an implementation that produces the same behavior, but is otherwise not substantially related to the original, then you have not copied any creative aspects and you have not created a derivative work.
"Clean room reverse engineering" (which, done properly, is extremely rare and the vast majority of open source projects related to reverse engineering do not do it to a proper standard) is a strong legal defense to show that creative aspects could not have possibly been copied. However, it is neither water-tight (the spec could've conveyed unnecessary creative aspects accidentally), nor is it required to show non-infringement. It's merely a defense; not doing clean-room RE doesn't mean you are doing anything infringing.
> Changes to the C code to be idiomatic Rust does throw a wrench into the whole thing, and it would have to be sorted out by a court, but it's not as simple as people like to think.
Practically speaking, given the significant differences between what is idiomatic in both languages, and the relative simplicity of what most coreutils actually do, there's a good chance that even a careless "translation" into idiomatic Rust would erase most creative aspects and put you well on the way to being able to claim it's not a derivative work. Effectively, the translation would involve a round-trip through an abstraction to the level of a spec, simply because what's idiomatic is so different. This is, of course, not a hard guarantee, nor would I bet the legality of my project on this aspect alone, but rather just an observation of what is likely to happen in many cases. In other words, you'd have to be really careless to end up creating a derivative work of coreutils here; the language difference works significantly in your favor.
IANAL, but I've been doing reverse engineering projects for over 15 years and my main job these days is leading an open source project to support an undocumented platform via reverse engineering. So I have a bit of experience with this matter :-)
All cows are animals, but not all animals are cows.
Not looking is a strong legal defense for whatever you wrote not being a derivative work. Looking just means you can't use that defense, it doesn't mean you actually copied code.
Given the significantly different paradigms of Rust and C, and that most coreutils don't really do that much algorithmically, it would be pretty easy to avoid accidental copying with this kind of project.
As anybody can also see, from the reference you provided, the way the discussion was closed, with not a hint of an effort to reply, already raises a small red light. Had the project replied along the lines of: "Its the one we choose for the project" even without a rationale attached, would turn it less into the interesting event I think it is.
I think closing the discussion like that was entirely the right choice; this project already had to deal with a prior issue from FSF-affiliated individuals complaining about the license choice. It isn't the FSF's job to go around telling people their license choice is wrong on their issue trackers. This is just a waste of everyone's time.
As the project is called Coreutils...Its not to the FSF to tell others what license to use but its reasonable to ask for a clarification the project uses a different license.
As we seem to try to save time for everybody...Do you know if the project has a public reference, with the rationale for the current choice of license? ( Note: No criticism implied concerning their current choice)
> Fred Bronson reported for Billboard that Fältskog told him in a 1988 interview that "[ABBA] had to ask permission and the factory said, 'O.K., as long as you don't make us feel ashamed for what you're doing'
This is an interesting take on the story but now have to get back to work... https://youtu.be/gC09BnFmQ30?t=118
https://books.google.com/books?id=CILUDgAAQBAJ&pg=PT297&dq=%... has:
> Stig phone up the managing director who enthusiastically approved, the only condition being that the group wouldn't discredit his company.
https://books.google.com/books?id=6lu_BgAAQBAJ&pg=PT57&dq=%2... says:
> There was just one tiny problem with formalising the anagram; ABBA was also the name of Sweden's premier brand of canned fish. Fortunately, after some brief negotiations, Stig was able to placate the fish firm and they gave ABBA, the pop group, their blessing.
https://books.google.com/books?id=-hkbqflhfKoC&pg=PT7&dq=%22...
> ... the name was also that of a Swedish company which sold canned fish; whose directors were worried lest ABBA the quartet should bring the name into disrepute, but after Stig Anderson had assured them that ABBA were aiming to publicise the name in a very positive way, the convern abated.
What become of the ABBA Seafood brand has a take on the history:
https://www.orkla.se/brands/abba/
"The Abba brand and the pop group ABBA have been the subject of some confusion over the years. During the 1970s, Abbas' switchboard usually received calls from Swedish and foreign fans who, if they were not allowed to talk to any of the group's members, could settle for a signed idol card.
Before the group Abba broke through in 1974, they actually called from the record company Polar and asked for the green light to use the name. Per Brolund, then HR manager at Abba, gave his consent to a reservation. "That the young people behaved and did not damage Abbas' good reputation."
If your memory predates Google's ~1998 search services offering, it's surely possible that you've misremembered what Benny said?
And the first reference I gave was to a copy of "Bright Lights, Dark Shadows: The Real Story of ABBA" from 2001, only a few years after Google. I don't see how Google search per se is relevant.
The Orkla link you gave is in Swedish(!). Good thing there's Google Translate. It essentially supports the point that Abba was concerned about behavior, not jocular opposition to becoming fishmongers as you suggested.
I do find it interesting that the first source I gave says "managing director" while the one you gave says "HR director". I expected "managing director" to mean CEO.
Ha! There's an ABBA fandom entry about it (because of course there is), at https://abba.fandom.com/wiki/Abba_seafood , which references the same page and translates the term to "staff manager".
Perhaps there are organizational differences between Sweden and US/UK which make direct translation difficult?
a key person from FSF commented on the project. he didnt say it is not notable
on the other hand this is a rewrite of GNU coreutils, and as such FSF has every right to comment in the project
He did say that the most notable thing about the work was the license, which effectively dismisses the technical work as not notable.
that being your interpretation and deduction. i am a bit more empirical and judge only what he actually said. moreover i am also not that much of a rust-lang fanboy, at least not to the extent that i see every rust rewrite of a c-lang code base as a technological marvel
Sure, and FSF also has every right to tell anyone who writes proprietary software that they hate their guts, if that was how they felt. My point is that this is not a particularly effective strategy for advertising the GPL to developers.
maybe the strategy sucks, maybe not. but maybe speak for yourself. i actually like their quirkiness and lack of shyness
Seems a bit counterproductive.
True, it's incredible how badly the FSF has done in terms of actually marketing their licensing structure. At this point I doubt most developers care much.
>Rust provides a good, platform-agnostic way of writing systems utilities that are easy to compile anywhere, and this is as good a way as any to try and learn it.
If you want some software to be platform agnostic, you can write it in C in a way that is not platform specific. So rewriting some software in Rust to be platform agnostic doesn't seem a good reason for a rewrite. Also, even if the C software to be rewritten isn't platform-agnostic, at least some part of it is, so by using C you don't have to rewrite everything.
I'm sure that Rust can have a lot of valid use cases but the trend of "Hey, let's rewrite X in Rust just because ..." I don't agree with.