Live data from Hacker News

Rewriting essential Linux packages in Rust

lwn.net

171–175 of 175 posts

Re: Rewriting essential Linux packages in Rust

#171

Earlier quoted context omitted.

What is released under MIT (or BSD) will stay under that license forever, so it cannot "be closed anytime". The owner can change the license, but that will affect only future developments.

Permissive licenses sometimes allow sublicensing, which allows changing of the license, and does not require source code be made available when changes made. IOW, this is de-facto closed source distribution. What happens when a company decides to add their own secret sauce and release that version only, or what happens tons of slightly incompatible, closed source variants pop-up, what happens upstream decides to not…

> Permissive licenses sometimes allow sublicensing, which allows changing of the license, and does not require source code be made available when changes made.

If I own the code, I can redistribute that code under a non-GPL license any time I want to (or not release changes at all). The GPL license that I grant to you on my code only affects what YOU can do with it. Consider the common practice of dual-licensed GPL code (a very common strategy for FOSS libraries to extort license fees).

And yes, an MIT license permits sub-licensing. Which is a good thing. (So does GPL). Maybe that word doesn't mean what you think it means. Perhaps you meant re-licensing.

> What happens when a company decides to add their own secret sauce

Then you use the old code without the secret sauce.

> what happens tons of slightly incompatible, closed source variants pop-up,

The same thing that happens when tons of slightly incompatible GPL-licensed variants pop up.

> What happens when upstream decides not to release future version's source code.

GPL does't help with that either.

> We have seen it all

To be perfectly honest, coming to Linux world, I find the various creative strategies to extort license fees for GPL code to be extremely distasteful. Off the top of my head: Juce: three dozen dual-GPL- and GPL-incompatible (not-for commercial use without paid license) libraries and tools with no upfront documentation on which libraries and tools are distributed under which license. You have to download them one by one to find out which license they are distributed under. Ubuntu: withholds (currently) 21 security fixes unless you pay for a license! Reaper, which is GPL-licensed, but demands that you purchase a license when you run it; sources are available but are impossible to build. GPL libraries that require use of non-GPL services in the cloud. Seems much more like a dystopia to me.

All I want is for people to be able to use my code. For whatever. And I am grateful to those who have provide code that I use under equally generous terms. And not at all impressed by somebody who added four hundred lines of code to a huge MIT-licensed library, and licensed them under a GPL license. (It took me less time to rewrite from scratch than I spent trying to get a fix pulled into the GPL project).

Re: Rewriting essential Linux packages in Rust

#172
post #168

Earlier quoted context omitted.

What is released under MIT (or BSD) will stay under that license forever, so it cannot "be closed anytime". The owner can change the license, but that will affect only future developments.

> that will affect only future developments. There's a term for that: Embrace-Extend-Extinguish

Also known as Embrace, Extend and Innovate. Which would be a good thing.

Re: Rewriting essential Linux packages in Rust

#173
post #167

Earlier quoted context omitted.

> GNU/Linux is the most successful free software project in the world and that is in part thanks to the GPL. I don't disagree, but you're missing the point which is -- the reason why the GPL is not popular is not only because corporations disfavor it, it's because devs disfavor it too. You might ask yourself, "Why?" > Blender and OBS are also heavy hitters. And so is Firefox which is MPL2, etc. If your point is -- OS…

Your points are valid and the comparisons between liberal and copyleft licenses have been discussed a million times. But scroll up to the original context here: what's the advantage of rewriting large swathes of critical OS infra that already works fine?

> what's the advantage of rewriting large swathes of critical OS infra that already works fine?

If you don't get it, then, it's not for you.

The reality -- the project became a way for new Rust devs to get their first Github commit. It became popular. MIT/Apache 2 is the default for new Rust projects.

But I think you need to also consider the downside risk. Because I don't see one. uutils are valuable only because they exactly replicate the GNU version. You'll always have GNU!

Re: Rewriting essential Linux packages in Rust

#174

Earlier quoted context omitted.

> contains notes on compiling for IRIX, HPUX, AIX, and OSF/1. Again, how well tested do you imagine the OSF/1 target is? Do you imagine each merge pops off a CI test for that platform? My guess is -- it's been a long time since anyone connected with the GNU coreutils project built for that platform. See the reply from estebank to me, below: > Platform support goes beyond "does a compiler happen to produce a binary".

Okay, so I was curious enough to check... I can install NetBSD on an emulated VAX (opensimh), run pkgin install coreutils and those binaries do in fact work. I can't seem to find documentation of whether they run tests on every build, but I'm going to tentatively take that as a strong signal that GNU coreutils is still portable across more machines than even Linux can run on.

> I'm going to tentatively take that as a strong signal that GNU coreutils is still portable across more machines than even Linux can run on

And I'm saying -- yes, if "Does it compile?" portability is a value that you care about, the GNU version is probably your version. But what if the Q is (as it was): "Is Rust (llvm?) supported on all platforms Linux targets?"

Then -- I think you need to dig more carefully into what you mean by "support" of non-standard platforms, and why it might be important to you. Would say -- we can move our entire stack to an emulated PDP-11 because Linux and GNU coreutils seem to compile? My guess is no. For lots of reasons, but one reason is "It compiles"/"Seems to work" is not a good measure of support.

Re: Rewriting essential Linux packages in Rust

#175
post #54

A big reason the GNU utilities were game changing is not because of their existence, or their functionality, but because of their license... a license which, in no small part, is what not merely motivated but then allowed for their continued existence and functionality: a tit-for-tat, sharing is caring, we're all in this together, fighting for the users approach to software development, one which ensures that no one…

I feel like this shouldn't be surprising. If you use GPL, you give others strong incentive to rewrite an alternative, because GPL is just very heavy burden. I'd even go as far as to say this is an example of failure of GPL. If the intent was to set up incentives to make sure people share the improvements with the community for mutual benefit, but the result is an incentive to rather burn resources to do complete rewr…

It's not a heavy burden at all. Releasing source code is quick and easy. Github will host it for you for free. The issue isn't the burden. The issue is that they don't want to comply with the license. Let's cut the crap. This is an attack on the four essential freedoms by means of replacement of the foundational libraries. If you want to talk about burning resources to do complete rewrites, let's start with uutils.
Post reply on HN