142
'Rust makes coding fun again': Why Linux is moving away from C, according to Greg Kroah-Hartman (www.zdnet.com)
submitted 3 months ago by to c/rust@programming.dev
63 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[+] -30 points 3 months ago (14 children)

Isn't also half the point behind Rust the ability to evade the GPL and make Linux more vulnerable to takeover by corporate? Last I checked Ubuntu is replacing some GNU stuff like coreutils with Rust.

  • permalink
  • fedilink
  • source
  • hideshow 14 child comments
    •
  • [–] 42 points 3 months ago (5 children)

    are you claiming that a program written in rust evades thr gpl? thats not a thing.

    or...

    are you saying , things are being rewritten (regardless of language) with a different license. scary but not a rust thing.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 8 points 3 months ago (4 children)

    The second.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 2 points 3 months ago (3 children)

    Do you seriously think that's how IP law works? If you weren't able to write GPL Rust code, Rust would not be free software. That would require the Rust project to issue software licences to programmers that stipulate that you must not create GPL-licensed software using Rust.

    Rust is free and open-source, like most programming languages. That means you are allowed to make whatever software you want with it, including GPL software. There's nothing stipulating that you can't...

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 1 point 3 months ago (2 children)

    You can write GPL rust code, you can also write non-gpl rust code. Gnu coreutils are gpl, if I choose to write functionality compatible with coreutils from scratch in rust I can relicense that as I please (ie not GPL) OP is postulating the driver behind rust rewrites is not for the language features but to allow coreutils functionality to be relicensed as closed source software.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 3 months ago

    OP is postulating the driver behind rust rewrites is not for the language features but to allow coreutils functionality to be relicensed as closed source software.

    And that postulation is extra laughable because non-GPL coreutils implementations always existed. And by always, I mean they actually predate the GNU implementation itself (which was a originally a "rewrite" btw 😉).

    And yes, they don't target GNU compatibility, but some of them are perfectly serviceable as is (e.g. the freebsd ones), and adding GNU compat to them would have been infinitely easier than starting a Rust implementation from scratch anyway.

    Another laughable aspect regarding the coreutils/uutils case in particular is that uutils didn't even start as a corpo-driven or corpo-backed project. It was literally a Mozilla employee having fun in his free time, especially during Covid, and community contributions in the same vein. Rewrites of non-GPL projects (e.g. sudo) were ironically much better backed.

    From my experience here and elsewhere, the people who make such stipulations don't even know which licenses the core packages in their own systems adopt. Many of them don't even know what these licenses' provisions precisely entail. They just perpetuate some retarded circlejerk probably started by some clueless+malicious e-celeb that goes like:

    linux distro -> C -> gpl -> not corpo -> good
    rust -> not gpl -> corpo -> bad

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 3 months ago

    I mean, you can create a GPL fork of the Rust coreutils if you so please. Or you could do a rewrite in any programming language of your choice and license permissively.

    In any case, I profoundly cannot bring myself to care about the fact that you can legally create a proprietary fork of permissively licensed FOSS. I don't think it's right to impose any restrictions on what people can do with software/code, which of course conflicts with the fact that other people can take your code and restrict what other people can do with it. So choosing between copyleft and permissive licensing is a balancing act of that contradiction. I don't think it's wrong to end up on the side of permissive licensing.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 22 points 3 months ago (5 children)

    Yes, that's correct. Whenever you write something in Rust, the license is automatically permissive. In fact, both US and EU copyright law automatically grant an irrevocable, perpetual license to use any and all Rust code that has ever been written for any purpose at all, including for commercial purpose, unless the code was written by a corporation.

    Or, you know, you could just:

    [package]
license = "GPL-3.0-only"
  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 20 points 3 months ago

    To be fair, projects implemented in Rust and adopting the GPL/AGPL are just not that notable.

    I mean, you can't expect people here to have heard of, let's say, that thing called Lemmy.

  • permalink
  • fedilink
  • source
  • parent
  • [–] -4 points 3 months ago (3 children)

    Now that would be a horror story. Then again, it's one of the reasons why I'm asking. Rust fame is just too coincidental with a number of things to not be suspicious. There was a whole thing in C++ (dunno if it's still ongoing) about the "memory safety" meme, as well.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 7 points 3 months ago (1 child)

    I feel ya. To me, it's really sad that some new projects now use licenses that are really good for businesses but do not even protect the projects themselves. I'd rather live in a world where GPL share would increase. (Instead, GPL grows, but its share is diminishing.) All my projects so far are GPL/AGPL.

    At the same time, Rust being picked for Linux has really nothing to do with the license. It's just what you said - a coincidence. The actual choice is made because of the language itself. It's a great language BTW.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 4 points 3 months ago

    Since you seem to be in good faith: no, you’re wrong. Using a language cannot force you into adopting a licence, because automatically everything you produce will be all rights reserved unless otherwise specified. It’s then up to the developer to choose a license.

    Rust doesn’t even populate the license metadata in your manifest, it’s up to you.

    I think MIT dominance came about thanks to GitHub’s choose a license.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 34 points 3 months ago
    • Linux kernel code is GPLv2 licensed irrespective of language.
    • There are thousands of (A)GPL rust crates/libraries out there.
    • The majority of crates are indeed still liberally licensed, but so are most new projects from the last decade, irrespective of the choice of implementation language.
    • Rust project rewrites don't exclusively replace GPL projects, because there aren't actually that many core GPL software packages to replace. Neither sudo nor zlib are GPL software, just to give two examples. A lot of implemented-in-C core packages in your system right now are actually liberally licensed.
    • And just for the sake of accuracy, the supposed threat of liberal vs. copyleft is not about the so called corporate take over or control. It's about the ability to have proprietary forks/spin-offs. Plenty of GPL projects are corporate-controlled and always have been (see what projects Red Hat maintains).

    You should try properly educating yourself on matters, instead of just taking whatever bullshit random often-clueless if not also malicious e-celebs spout at face value, or wherever you're getting these retarded theories from.

  • permalink
  • fedilink
  • source
  • parent