This is a follow-up to Jon’s original post on Carefully (but purposefully) oxidising Ubuntu and Julian’s migration spec for 25.10. We promised transparency throughout this process, and this post is written in that spirit. What happened after the announcement Following the decision to adopt rust-coreutils, we got to work. Any package shipped by default in Ubuntu must be promoted to Ubuntu Main, which requires passing a thorough security review. We quickly assembled an internal team spanning Ubun...
mit lets companies take them without contributing back critical stuff like security fixes.
their money and resources are very important to keep foss alive and this relies a lot on the gpl because it just means they are forced to take some responsibility for the projects they use to make their billions.
That’s great, except they could already just use a permissively licensed implementation. This is in fact what a lot of companies already do. For instance, Android uses Toybox, macOS uses utilities originally ripped from NetBSD (mostly), etc.
Generally, a lot of companies also don’t contribute back fixes upstream. They’ll often just dump the code in some hidden away corner of their site as a giant source blob.
For something like coreutils, where a significant change is sort of unlikely in the first place, thinking the GPL makes a difference is bizarre to me.
Because it was started as a project to learn Rust by one dude.
Also, that was back when Rust had bad documentation (at least a couple years before 1.0), so by far the easiest way to learn was by making something like this and looking through other existing projects like the compiler or Servo.
That doesn’t answer the question why use different license than the original. And why not change the license/fork to gpl when it became more than a fun project. As we see it is a major issue with the project.
Being able to take someone else’s code used as a learning exercise for your own learning without worrying about it being GPL’d is quite useful. You seem to be arguing permissive licenses should never be used, which I think is ridiculous. A project meant to just learn about XYZ language/framework/whatever by implementing “simple” tasks is one of the most basic examples of a project that should be under a permissive license.
The only thing that could realistically be done is to license all changes going forward as GPL. If someone wanted to fork the project to do something like that, they could. But of course no one will bother, because the people who are terminally rabid online about this project not being under the GPL contribute to neither this project nor GNU coreutils.
It is not a major issue. It’s only really an “issue” at all because people who don’t contribute and likely would never contribute anyway constantly complain about it. I will state this again: there are multiple already existing implementations of the coreutils programs, so there is practically nothing keeping companies tied to it. There is little actual benefit to the coreutils programs in particular being under the GPL.
mit lets companies take them without contributing back critical stuff like security fixes.
their money and resources are very important to keep foss alive and this relies a lot on the gpl because it just means they are forced to take some responsibility for the projects they use to make their billions.
That’s great, except they could already just use a permissively licensed implementation. This is in fact what a lot of companies already do. For instance, Android uses Toybox, macOS uses utilities originally ripped from NetBSD (mostly), etc.
Generally, a lot of companies also don’t contribute back fixes upstream. They’ll often just dump the code in some hidden away corner of their site as a giant source blob.
For something like coreutils, where a significant change is sort of unlikely in the first place, thinking the GPL makes a difference is bizarre to me.
So why did they choose to use permissive license instead of the license of the original?
Because it was started as a project to learn Rust by one dude.
Also, that was back when Rust had bad documentation (at least a couple years before 1.0), so by far the easiest way to learn was by making something like this and looking through other existing projects like the compiler or Servo.
That doesn’t answer the question why use different license than the original. And why not change the license/fork to gpl when it became more than a fun project. As we see it is a major issue with the project.
Being able to take someone else’s code used as a learning exercise for your own learning without worrying about it being GPL’d is quite useful. You seem to be arguing permissive licenses should never be used, which I think is ridiculous. A project meant to just learn about XYZ language/framework/whatever by implementing “simple” tasks is one of the most basic examples of a project that should be under a permissive license.
The only thing that could realistically be done is to license all changes going forward as GPL. If someone wanted to fork the project to do something like that, they could. But of course no one will bother, because the people who are terminally rabid online about this project not being under the GPL contribute to neither this project nor GNU coreutils.
It is not a major issue. It’s only really an “issue” at all because people who don’t contribute and likely would never contribute anyway constantly complain about it. I will state this again: there are multiple already existing implementations of the coreutils programs, so there is practically nothing keeping companies tied to it. There is little actual benefit to the coreutils programs in particular being under the GPL.