Linux maintainers are unwilling to get rust into the kernel, so some rust folks decided to start writing a new kernel with same ABI. This allows them to make new architectural decisions. An example being their “frame kernel” (something between a monolithic kernel and a microkernel).

If I may say, it’s more legible and the tooling is way better, right off the bat.

  • toothbrush
    link
    fedilink
    arrow-up
    43
    ·
    2 months ago

    I was interested until the website proudly stated that the kernel is not under the GPL, but the weak copyleft MPL. Great, an alternative to the linux kernel for companies to steal, yay…

    • adr1an@programming.devM
      link
      fedilink
      arrow-up
      11
      ·
      2 months ago

      I’d love to live in a solarpunk world where intellectual property was abolished. In the meantime, compromises are met and it’s no horror at all.

      I feel you, but maybe GPL is just an unpopular option (linux kernel never upgraded to v3, only a few oss web apps use affero, etc.)

      As much as I love libre software, I have to say that Linux had bad support for drivers because of it, and its mainstream adoption for desktops was hindered for decades because of it. Only today, we celebrate a 5% user share.

      An alternative permissive license doesn’t immediately mean companies will do the worst. We live under capitalism, perhaps we can’t just change that with a license. Their decision might future-proof the project to higher heights that are hardly seen today.

      Look at Android, yeah it’s a hell of a locked down system when you buy a new phone. But it works quite well, and their user share is at the very top (or second to Apple? Maybe, if you’re American). However, Android allows us to have LineageOS and Graphene (which is MIT license, but that’s beyond my point, iiuc it could very well be GPL for all of its customizations), and no matter which license these forks(?) use, privacy is preserved and taken to new levels. Meanwhile, Android or any of these alternatives support ARM architecture with great integrated video acceleration that is low power. These are not simply “nice features” but a requirement (e.g. saves energy, improved user experience, competitive to other platforms, etc.) and privacy is not really compromised.

      P.s. I’m suprising myself with this comment, nearly 10 years ago I was obsessed with libre software. Today I find it more of a niche hobby, or intellectual challenge. Valuable nonetheless, sure. And hell yeah I’d like to have a linux phone which fully supports all software and hardware… But then, reality.

      • toothbrush
        link
        fedilink
        arrow-up
        22
        ·
        edit-2
        2 months ago

        ok, just a few points from me, typed very quickly because im in a hurry so forgive me if its not very coherent:

        1. the gpl is very popular, its the apgl that has less popularity. The gpl is used by thousands of software projects, and the linux kernel is one of the few projects that did not upgrade to v3, many did, but still, they use the gpl! Thats not an argument against it! Using gplv2 is still fine!

        2. if the linux kernel was more permissive we would absolutely not have better drivers. The linux kernel supports a crazy amount of hardware, a lot more than any other OS! How can you say that support is poor? Bad Drivers are mostly nvidia, broadcom, and chinese vendors that ignore the gpl, and yes, these drivers are bad because they dont want to open source anything(or, my guess, its because of low market share). But imagine that the kernel was MIT. Suddenly, wow, nvidia and broadcom might release more drivers, amazing my laptop wifi card works now! Exept 5 years later the driver breaks in creative ways and broadcom isnt interested in fixing it because its out of support. Proprietary drivers arent the solution to bad drivers, they are bad drivers by their design. its the reson why nvidia drivers are hated, because they are mostly closed binaries so nobody can fix them, and they develop them their way so wayland etc is still buggy. If it was MIT nothing would change in this situation, exept they have more legal possibilities of making badly integrated drivers.

        3. you gave andoid as an example, but that uses the linux kernel? The “good” driver support is kernel modules for the andoid kernel, aka gpl compatible? And support for ARM is good, yes, that is by the way also true for regular linux. And when it is not, its because they didnt mainline their drivers, which is a lot of work and doesnt benefit them apart from goodwill, not because of licensing. What is your argument here?

        4. Do you think that android would have been open source if the gpl didnt force them to?

        5. a permissive license doesnt mean it immediately gets abused. But it does mean that abuse is possible, and it does happen. I dont want to live in a world where the best linux is microsoft© linux™ which has ads and their own packages, which are for some reason, incompatible with free linuxes because of extra features in microlinux©®™

        • adr1an@programming.devM
          link
          fedilink
          arrow-up
          4
          ·
          2 months ago

          I’m absolutely with you on point 5. As for the rest, I will have to admit that I may have said some things plain wrong. I’m just trying to drive the point that it’s not inmoral and people should be happy anyway. Perhaps in 10 years this is the OS we are all using on our desktops, phones, and wearables. It would be a pity that’s not GPL and it has ads, sure (like maybe Android on x-brand flagship mew phone). But we could then have the LineageOS version of this. And I’d be happy. My poiny being, if that happens (it turns out to be the biggest OS), it will be thanks to its license, allowing it to be a thing for both people, and companies.

        • adr1an@programming.devM
          link
          fedilink
          arrow-up
          2
          ·
          2 months ago

          Oh… I just saw your point. I’m comparing to Android (LineageOS) when it should be to iOS… void

          Well, then this news are just sad.

      • Scoopta@programming.dev
        link
        fedilink
        arrow-up
        7
        ·
        2 months ago

        Eh? I daily drive only FOSS software with basically no problems, the only exception I make is for firmware and JS, firmware because it’s realistically not a choice and JS because it’s extremely sandboxed and I use librewolf with container tabs to isolate cookies etc cross sites, even drivers are not exempt from this rule. FOSS specifically being programs under a GNU approved free software license or software found in the Debian main repos and therefore complying with the DFSG. It’s, surprisingly easy. In fact when I made the decision to do this it was primarily because I needed so little proprietary software that it just wasn’t even much of a challenge?? I guess my main point in saying this is I don’t get where you’re coming from, I’d love a Linux phone but it’s not realistic there, but on the desktop? It’s extremely realistic??

        • adr1an@programming.devM
          link
          fedilink
          arrow-up
          5
          ·
          2 months ago

          Linux made huge strides in the last years. But if we go back 10 years, or 15 things were quite bleak. And there are many reasons to that. It’s license is one. That’s my point. Correct or not, okay.

          And Linux never embraced GPLv3 for reasons that are in common probably as to why this project chose a permissive license. So, I think we should all support them in that regard.

          • Scoopta@programming.dev
            link
            fedilink
            arrow-up
            4
            ·
            edit-2
            2 months ago

            The decision not to support GPLv3 makes sense and I understand Linus’ perspective on that. GPLv3 branched out into something beyond traditional copy left by ensuring that users can run the modified code by restricting hardware design. That’s a separate thing. I disagree with the decision to go with a permissive license in most cases including this one. Permissive licensing leads to the problems the BSDs have with companies like Sony taking the code and running with it without giving back and it’s why I prefer strong copy left licenses like GPLv2 or v3.

            One other thing, yes it was rough in the past but now due to the massive market penetration Linux has we have a large swath of GPLv2 drivers making it far less of a relevant issue.

            • adr1an@programming.devM
              link
              fedilink
              arrow-up
              2
              ·
              2 months ago

              We can’t really know if BSD “lost” a sell to Sony. Right? I ask sincerely, maybe there’s more to the case you cited.

              From my naïve view, this new project can win new associated companies and get some income to pay new devs when some maturity is achieved on this framework since it’s quite innovative and those companies can really participate whereas with a GPL they would just be left out.

              I only mean to say that we might be discussing if the glass is half empty or half full. That’s why I’m trying to put into this new perspective (like considering GrapheneOS as an example. In the long run, the license might not be that much of a hurdle. At least let’s hope that’s the case since they probably won’t change to GPL.

    • trevor
      link
      fedilink
      English
      arrow-up
      8
      ·
      2 months ago

      Eww… You’re right. What a waste.

    • qaz@lemmy.world
      link
      fedilink
      English
      arrow-up
      7
      ·
      2 months ago

      Our choice of the weak-copyleft MPL license reflects a strategic balance:

      1. Commitment to open-source freedom: We believe that OS kernels are a communal asset that should benefit humanity. The MPL ensures that any alterations to MPL-covered files remain open source, aligning with our vision. Additionally, we do not require contributors to sign a Contributor License Agreement (CLA), preserving their rights and preventing the possibility of their contributions being made closed source.

      2. Accommodating proprietary modules: Recognizing the evolving landscape where large corporations also contribute significantly to open-source, we accommodate the business need for proprietary kernel modules. Unlike GPL, the MPL permits the linking of MPL-covered files with proprietary code.

      Wouldn’t the LGPL also allow this?

      • Michael Murphy (S76)@lemmy.world
        link
        fedilink
        English
        arrow-up
        4
        ·
        edit-2
        2 months ago

        All source code in Rust is statically-linked when compiled, which thereby renders the LGPL no different from the GPL in practice. For Rust, the MPL-2.0 is a better license because it does not have the linking restriction.

        • qaz@lemmy.world
          link
          fedilink
          English
          arrow-up
          1
          ·
          2 months ago

          Interesting. Is that because the kernel can’t load a a module as dylib (I don’t know a lot about kernel development) or because dylibs are also somehow statically linked in Rust?

      • toothbrush
        link
        fedilink
        arrow-up
        3
        ·
        2 months ago

        I think it would. Its still a bad idea to allow proprietary modules though. It also allows for EEE shenanigans. I hope they reconsider.

        • Michael Murphy (S76)@lemmy.world
          link
          fedilink
          English
          arrow-up
          2
          ·
          edit-2
          2 months ago

          The Linux kernel already allows proprietary modules via DKMS, and a handful of vendors have been using this for decades, so this is no different. Case in point: NVIDIA driver, and Android vendor drivers.

    • Michael Murphy (S76)@lemmy.world
      link
      fedilink
      English
      arrow-up
      3
      ·
      edit-2
      2 months ago

      In practice, because Rust libraries are always statically-linked, the MPL-2.0 is equivalent to the LGPL in spirit. Meanwhile, because of the static linking restrictions in the LGPL, the LGPL is effectively no different from the GPL. Hence, you’re going to find a lot of open source copyleft projects from the Rust ecosystem preferring either GPL or MPL-2.0, where MPL-2.0 is used in libraries where LGPL would have used previously in C projects. Dynamic linking is essentially going the way of the Dodo.

    • onlinepersona@programming.devOP
      link
      fedilink
      English
      arrow-up
      3
      ·
      2 months ago

      You could create an issue to address it. I’m not sure why they consider MPL to be a good license for the project. Of course somebody could contact the linux rust contributors and suggest they create another project with GPLv3 or even AGPL.

      Anti Commercial-AI license

    • anon5621@lemmy.ml
      link
      fedilink
      arrow-up
      3
      ·
      2 months ago

      I feel you,same thing about redox os.Core and system applications have to under gpl no doubt.