Weakened license protection
Weakened license protection
Posted Mar 18, 2025 17:21 UTC (Tue) by lmb (subscriber, #39048)Parent article: Oxidizing Ubuntu: adopting Rust utilities by default
That's saddening, because otherwise, I'm a huge fan of Rust vs C(++), static linking aside.
Posted Mar 18, 2025 22:03 UTC (Tue)
by tchernobog (guest, #73595)
[Link] (19 responses)
However, in the case of such base utilities, you basically have to provide bug-by-bug compatibility with gnu coreutils by now.
I kinda doubt a company will take these utils, close source them, and resell them without redistributing sources. It would bring only marginal benefit.
I am much more worried about new, innovative implementations with a higher degree of complexity. For instance rsync, or the new ripgrep implementation are much more sophisticated and would be more worrisome without copyleft.
But most of these tools are just painful to write to wrap correctly POSIX or Windows API, but not inherently hard to code.
Posted Mar 19, 2025 0:06 UTC (Wed)
by parametricpoly (subscriber, #143903)
[Link] (13 responses)
Yes, there's C23, but the ML family of languages is much better if correctness is valued. Algebraic types are more expressive, dependent typing allows specifying useful invariants, automatic memory management makes a lot of sense now that systems have 64+ gigabytes of RAM. Parsing those languages is easier because the grammar is more straightforward. C has some nasty limitations: the lack of modules, the need for complex pre-processor makes incremental and efficient parsing almost impossible.
If people are going to switch to new apps, they will be making the switch based on the technical merits. If a Rust app is more secure, less crash prone, and faster to develop, it's a big win for the users. Now, to avoid being replaced by non-copyleft clones, new copyleft apps are needed. This means GNU needs to come up with new languages. I don't think Guile helps here.
Posted Mar 19, 2025 0:57 UTC (Wed)
by Paf (subscriber, #91811)
[Link] (11 responses)
Posted Mar 19, 2025 8:52 UTC (Wed)
by anselm (subscriber, #2796)
[Link] (9 responses)
I obviously don't speak for the GNU project, but I would assume they prefer code they can compile with gcc, and the gcc-based Rust compiler isn't quite there yet.
Posted Mar 19, 2025 11:42 UTC (Wed)
by excors (subscriber, #95769)
[Link] (8 responses)
It seems typical for a successful new language to take 10-15 years to reach a reasonable level of maturity and acceptance. If there's an urgent need to defend copyleft, you can't afford to pause and build a whole new language first.
Posted Mar 19, 2025 12:18 UTC (Wed)
by anselm (subscriber, #2796)
[Link] (7 responses)
Which is, if anything, an argument for finishing the gcc-based Rust compiler, rather than coming up with an entirely new language from scratch.
I don't believe that the GNU project has a problem in principle with Rust, the language. The fact that a Rust frontend for gcc is in the works seems to suggest otherwise.
Of course if you're a “GPL maximalist” it kinda sucks if people who used to use the GPL'ed coreutils in C are jumping ship to a different package which is technically superior, coincidentally written in Rust, and unfortunately happens to be more liberally licensed. Having said that, if the GNU project is primarily interested in a more modern coreutils replacement for the mythical “GNU operating system”, then once gcc-rs can compile uutils it can simply declare that uutils is now “part of the GNU operating system” much like, e.g., X11 or TeX (neither of which were GPL-licensed, nor part of the GNU project) were stipulated to be “part of the GNU operating system” back when the idea was new.
In any case there is certainly no urgent need for the GNU project to come up with an entirely new “GNU language” just to be able to implement a new version of the GPL coreutils. The GNU project could always write their own version, under the GPL, in Rust, to be compiled with gcc-rs once that is ready. It's just that right now the GNU project may perhaps be excused for not doing development in Rust while their own compiler can't deal with it yet.
Posted Mar 19, 2025 13:38 UTC (Wed)
by ceplm (subscriber, #41334)
[Link] (4 responses)
Actually, I am not sure about, and I am not even sure we shouldn't have a problem.
Posted Mar 19, 2025 14:38 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link] (3 responses)
> https://softwarefreedom.org/podcast/2009/jul/07/0x11/
Don't see any relevance to this podcast on Rust. Why would FSF/GNU have any problems at all with Rust and if they have a problem, have they explained it?
Posted Mar 19, 2025 15:01 UTC (Wed)
by ceplm (subscriber, #41334)
[Link] (2 responses)
Posted Mar 19, 2025 15:08 UTC (Wed)
by daroc (editor, #160859)
[Link] (1 responses)
Cyclone was released in 2001, so even if someone had a patent before that which they could argue covered borrow checking, it has pretty clearly expired by now.
There are absolutely risks to using newer programming languages, but I'm not convinced that patent encumbrance is a particular problem in Rust's case.
Posted Mar 20, 2025 9:06 UTC (Thu)
by taladar (subscriber, #68407)
[Link]
Posted Mar 19, 2025 14:07 UTC (Wed)
by farnz (subscriber, #17727)
[Link]
Note, though, that the NBSoI is not the only way to end up with a new language - you can also have languages that are basically the same combination of ideas as existing languages, but with a different syntax or emphasis (e.g. the huge family of Lisp-like languages). It's just that the NBSoI is where things get interesting, since it's where techniques move from "great in theory, lousy in practice" to "this is usable now".
Posted Mar 20, 2025 23:22 UTC (Thu)
by jwakely (subscriber, #60262)
[Link]
The GNU project doesn't control GCC, so I don't think you can draw any conclusions about GNU's view on Rust from the existence of gccrs.
Posted Mar 19, 2025 11:46 UTC (Wed)
by tux3 (subscriber, #101245)
[Link]
Posted Mar 19, 2025 21:38 UTC (Wed)
by jmalcolm (subscriber, #8876)
[Link]
Posted Mar 19, 2025 10:53 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link]
`rclone` already exists: <https://rclone.org/>. It's not a drop-in, but it also supports way more remote storage protocols (e.g., I `rclone` my `restic` backups to Google Drive and Backblaze (S3-ish) with it).
Posted Mar 21, 2025 22:39 UTC (Fri)
by ndiddy (subscriber, #167868)
[Link] (3 responses)
There was a podcast interview here: https://youtu.be/5qTyyMyU2hQ?t=1270 with the lead uutils maintainer where he brought up that some car manufacturers had already started using uutils in their products instead of the GNU core utils because it means they don't have to comply with the GPL. From a corporate standpoint, when you have one set of tools where you have to comply with the GPL, and then a drop-in replacement for them where you don't, of course you'll use the tools that don't require GPL compliance.
Posted Mar 22, 2025 9:18 UTC (Sat)
by Wol (subscriber, #4433)
[Link]
What it DOES bring them is a big reduction in pain. If I can ship a product, based on a publicly available tree, without all the hassle of tracking, responding to requests, etc etc, then that's a big attraction.
And regardless of whether you're an engineer, a programmer, an analyst, people at the sharp end like to collaborate. It's bean counters who all too often don't see the benefit of collaboration, but they do see the cost of getting sued.
What we need is a GPL-lite, that contains all the downstream protections, and rather than saying "you have to share the source" replaces it with "you must develop in public, and tell your customers where to find it". Basically, it has to be publicly readable, 3rd-party hosted, and advertised to upstream and downstream alike.
At the end of the day, engineers want to share, but they don't want all the GPL Administrative Hassle that comes with the GPL. All bean counters can see is the cost. The GPL is making the wrong person pay! There's a good chance I will push my changes upstream because I can see the benefit. If I don't, upstream may (or may not) mine my respository because they see a benefit. And any customer who wants the source may have a bit of grief working out exactly which source they've got, but they have got it (and if I can't tell them, that may well be a cost to me). (Programming in Excel it's costing me dear at the moment!)
Cheers.
Posted Mar 23, 2025 1:48 UTC (Sun)
by himi (subscriber, #340)
[Link] (1 responses)
Unless they're actually modifying the code, of course. Which . . . well, for coreutils? I'd have to assume that's just going to be compilation support for whatever platform they're using, in which case it'd make far more sense to submit patches upstream than to maintain their own fork in-house, and the same logic would apply whether they're using GNU coreutils or uutils.
It sounds like either the companies in question don't actually understand the way the GPL works (which shouldn't be an issue if they have competent lawyers), or they're pulling an Apple and avoiding any GPLed code on ideological grounds.
Posted Mar 23, 2025 7:09 UTC (Sun)
by Wol (subscriber, #4433)
[Link]
"6. Conveying Non-Source Forms.
You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways:
a) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by the Corresponding Source fixed on a durable physical medium customarily used for software interchange."
Have you read the GPL? Have you understood it? I haven't quoted the entirety of section 6, but if you are a business there is a hell of a lot more than just "documenting you got it from upstream". You - CORPORATELY - are on the hook for making sure your customer can get the source. And that is expensive administrative hassle companies would much rather avoid.
There are "sort of" getouts, 6c, and 6e, but they're not aimed at corporates, and they still come with grief companies don't want. I've only just noticed 6e, but unless the company controls that location, they're probably not complying with it, and if they do control it it's more hassle that again they don't want.
Cheers,
Posted Mar 19, 2025 11:16 UTC (Wed)
by ballombe (subscriber, #9523)
[Link]
Weakened license protection
Weakened license protection
Weakened license protection
Weakened license protection
Weakened license protection
Weakened license protection
The gcc-based Rust compiler is still a long way ahead of the gcc-based compiler for a hypothetical GNU language that hasn't been invented yet.
Weakened license protection
Weakened license protection
Weakened license protection
Weakened license protection
Weakened license protection
Against that, we're at about the right time in Rust's lifecycle for the Next Big Synthesis of Ideas (NBSoI) in programming language design to come together and produce something that's practically useful and academically interesting. If someone's going to do that under the GNU umbrella, that'd be great.
A new "GNU language"
Weakened license protection
Weakened license protection
There is no technical issue with shipping GPL software that depends on an MIT compiler, but I imagine this wouldn't feel very satisfying from the GNU point of view.
Weakened license protection
Weakened license protection
Weakened license protection
Weakened license protection
Wol
Weakened license protection
Weakened license protection
Wol
Weakened license protection