Recently I have been following a lot of debate about Canonical reimplementing GNU projects coreutils in Rust. Much of it very negative and much of it very anti-Rust.
Some of the criticism is very practical:
It's crazy to waste effort reimplementing such a big, old, battle tested software just for the sake of a new language.
The reimplementation is incomplete and full of bugs, failing many tests.
Most of the criticism is about licensing. The reimplementation being MIT licensed instead of GPL. Its tin foil hat arguments about Canonical wanting to eliminate Free Software. A case which grows now the Microsoft has adopted that Rust reimplementation. It is supposed that this is Rust and the Rust creators cunning plan and the ultimate purpose of Rust!
Now, I don't really want to get into a discussion about that here, there is enough of it all over the net already. But it does prompt a question in my mind:
If I wanted to release my Rust creations under the GPL is that even possible? What would I have to do to ensure everything is in order?
First obvious problem is that Rust projects tend to have masses of dependencies, no doubt coming with all kind of licences. How can I be sure I can release binaries containing those dependencies under the GPL?
I'm going to assume that if I only publish source code I can license it how I like, GPL or whatever. After all I'm not including anyone else code in my crate(s). It might be a pain. for users if they cannot build the thing into a GPL binary but that is not my concern.
Returning to the original concern, is it really so that Canonical could not release their reimplementation of coreutils under the GPL?
You can release your own software under whatever licence you want, Rust itself places no restrictions.
If you have dependencies, your code can be provided under its own licence, independently of dependencies (as long as you are not overriding dependency licence). GPL app with MIT dependencies is fine. Though perhaps distribution matters here - there might be a difference between including dependency in your codebase and listing it in cargo.toml for the user to obtain by themselves. Ask a lawyer.
is it really so that Canonical could not release their reimplementation of coreutils under the GPL?
It isn't their code. This is independent project. Canonical may have made some contribution or have its own fork, but they didn't created it and do not own it.
This is possible specifically in this case, because MIT is compatible with GPL However, it could not be practical for them: what do you if you want to send patch upstream, and your code is under different licence than upstream? Licence your patch as MIT, but relicense whole project as GPL? What's the point?
IMHO any distributor should redistribute under original licence, it is not Canonical job to be evangelists here. If anyone wants some software to be GPL, they can talk to original authors, or write better implementation themselves.
As far as I understand things it is Canonicals code. They have written an implementation of core Unix utilities from scratch in Rust, As such they do own it. In the same way that GNU created their own implementation of Unix utilities from scratch back in the day.
The worry among the tin hat folks is that by releasing those core utils under a non-GPL license they (or other, like MS as noted above) could potentially ship binaries that are not built with the published sources but from "secrete" different sources containing whatever they like.
I don't really have an issue with any of that. As far as I'm concerned anyone can publish their creations under whatever licence they like.
So. It seems to me that:
A) I can publish my Rust source under the GPL with no problems. Shifting the licensing problems to anyone wanting to build, use and distribute binaries from it.
B) If were ever to want to publish binaries under the GPL as well I would have to ensure:
i) Ensure I don't build in any dependencies with GPL incompatible licenses.
ii) Ensure I can deliver all the source code from which the binaries are built if someone obtaining the binaries asks for it.
Is there an easy perhaps automated, way I can check all is correct if I do B)
I'm usually releasing my libraries under MIT and Apache, at the option of their users. It doesn't prevent them from releasing their own work under GPL, provided there's a notice as required by those licences (not that I personally care much about it). For instance, you could use them in your GPL crate without any problem.
However, I think the reverse isn't possible, which is why I don't choose GPL—it's only a personal choice, and I do see why some prefer GPL. In the same example as above, I wouldn't be able to use your library without changing my licence.
Rewriting existing GPL libraries and publishing them under MIT is something else entirely. Yes, Canonical again, I'm not surprised.
It is not. Nothing in the code says so and there are multiple independent contributors.
Contribution does not require giving any rights to Canonical. Canonical is free to use it as anyone, but they are not exclusive owners and do not have any special rights. This is different then say Java codebase, where Oracle has all rights and can release it under any licence it wants and if you contribute, you sign agreement that provides them all rights to relicense..
In the same way that GNU created their own implementation of Unix
I am not familiar with GNU history, but now GNU does not "own" the codebase in any sense that would allow them to relicense it without asking multiple contributors for permission.
they (or other, like MS as noted above) could potentially ship binaries that are not built with the published sources but from "secrete" different sources containing whatever they like
That is possible, but Canonical is not the one who made it possible, or at least not the only one.
Again, If anyone wants to argue here, they should talk to (all) contributors of this projects and convince them.
Is there an easy perhaps automated, way I can check all is correct if I do B)
Yes. Set up emails to your lawyer. Anything else would be only a guess.
I wouldn't say "most" of software is a rewrite, no. Although now that some people are using LLMs, it could become more and more the case if we let that happen. But some software has been rewritten from other languages, sure.
I know the core of GNU comes from the need of having a "free" version of what was originally in Unix and was under more and more restrictive licensing from AT&T, so it was created from scratch but heavily inspired by Unix.
If it's rewritten in Rust to increase safety, I think it's also a valid reason. I was mislead by "Canonical reimplementing GNU projects coreutils in Rust" and the general confusion surrounding uutils, hence my previous comment. I looked a little more into it, and it appears that Canonical wasn't behind it but simply adopting it too early (for who knows what reason, but that's another matter), and that the licensing issue isn't one of the goals but rather a debatable choice.
I think there's still a major difference: the new coreutils must be entirely compatible with the previous one to avoid integration issues. So if you put that with the change of licence, it's still not comparable to choosing a licence for original code.
Bottom line, it seems disconnected from the question of the relative compatibility between GPL and MIT.
PS: I don't know if the link below was related to your quoting me or anything else, so I didn't look at it.
Depends on what your definition of rewrite is? Was Lotus 1-2-3 a rewrite of VisiCalc? Some of the same people were involved, but code all-new. What about Excel? There only general principles survived, but the general ideas are still the exact same. At what point mimicry stops being rewrite and becomes its own thing?
At some level most of the solvate (and most of the literature!) is a rewrite of earlier works.
Once per blue moon something truly new is invented, but 99.9% of all “creative” works are things done before with minor variations.
That's actually why coding agents work at all: they are absolutely incapable of doing something that's relatively novel (I wouldn't even say “creative”, just merely something not discussed to the death in hundreds of blog posts), but they sure as hell are capable of doing the exact same thing that was done thousand times before.
A proper solution for this problem is bit-for-bit reproducible builds, not licensing.
The usually discussed risk in MIT vs GPL debates is the EEE strategy where a company creates a proprietary fork based on a public liberally licensed open source project, adds to it new "shiny" features, and eventually uses it to "extinguish" the original project. But I don't think it's a relevant risk in the context of core utils.
Nothing prevents a company from shipping GPL-licensed binaries with "secret" different sources as well. And they will stay secret until someone explicitly requests the sources and most people would just assume that some unmodified version from public repository was used. And a malicious company just could give you some non-secret slightly tweaked sources and it will be on you to prove that different sources were used to compile the binary. And even after all this effort the company could finally give you the "secret" source, claim "it was a simple mistake", and get off mostly scot-free.
So, no, using legal tools provided by GPL is not a proper solution for this problem.
My take is that this topic is beating the dead horse. As only you started AI assisted coding including vibe coding, you already took the code of dozen of GPL projects. The difference is only that you are taking whole or by parts. Probably the law should be reconsidered as using vibe coding requires you to publish the final project code? Just kidding.
As I opened this thread I have to assume that by "you" there you mean me, So as a correction I have to say: As it happens there is a project in our little company that we would like to release under some Open Source/Free software licence (TBD). That code was mostly written before AI assisted coding was a thing.
But really, before AI assisted coding we all learned to do all kind of things by reading masses of code we find on the net. Be it in tutorials, blogs, source code of open projects, whatever. We learn from that, take ideas and code snippets from here and there and modify it, reimplement it, translate it, mash it around to serve our purposes in our own work. All without worrying about the license attached to what we had seen.
It's not clear to me that what AI assisted coding is doing now is different to that. Except working on a much larger and faster scale I guess.
We see the same in other fields of human endeavour. In music you can identifies styles and sounds that belong to certain eras or cultural groups. Why so? Because musicians are listening to each other and influenced by each other and end up producing similar things. It's not necessarily just outright copying though.
"Battle tested" is of course no proof that software is correct and secure.
But I will argue that the fact that those CVE were discovered this year is all part of battle testing. Ergo "battle testing" is not totally hollow. The more such investigation and testing the better. Shame to throw years of that away when rewriting something.
It works perfectly for functionality, but doesn't work for security. Our software is pile if insanely complicated and convoluted Goldberg machines with very poor testing for error paths. Normal use doesn't need to exploit these error paths thus they stay untested. But of course crackers, be they made from flesh and blood or from silicone, try to hit in precisely these error paths…
However I looked into the two critical CVE's in sudo that were found this year. At least one of them was found by people wanting to use sudo (something to do with an EV charging system) and took the trouble to do analysis of it, including error handling.
That to me is part of "battle testing". Software goes out to user, user beats it up. Cracks found.
But some software has been rewritten from other languages, sure.