[HN Gopher] Moss: a Rust Linux-compatible kernel in 26,000 lines...
___________________________________________________________________
Moss: a Rust Linux-compatible kernel in 26,000 lines of code
Author : hexagonal-sun
Score : 367 points
Date : 2025-11-22 07:11 UTC (6 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| hexagonal-sun wrote:
| Hello!
|
| For the past 8 months, or so, I've been working on a project to
| create a Linux-compatible kernel in nothing but Rust and
| assembly. I finally feel as though I have enough written that I'd
| like to share it with the community!
|
| I'm currently targeting the ARM64 arch, as that's what I know
| best. It runs on qemu as well as various dev boards that I've got
| lying around (pi4, jetson nano, AMD Kria, imx8, etc). It has
| enough implemented to run most BusyBox commands on the console.
|
| Major things that are missing at the moment: decent FS driver
| (only fat32 RO at the moment), and no networking support.
|
| More info is on the github readme.
|
| https://github.com/hexagonal-sun/moss
|
| Comments & contributions welcome!
| bramadityaw wrote:
| shouldn't this be a ShowHN?
| Rochus wrote:
| Cool project, congrats. I like the idea with libkernel which
| makes debugging easier before going to "hardware". It's like
| the advantages of a microkernel achievable in a monolithic
| kernel, without the huge size of LKL, UML or rump kernels.
| Isn't Rust async/awat depending on runtime and OS features?
| Using it in the kernel sounds like an complex bootstrap
| challenge.
| kaoD wrote:
| Rust's async-await is executor-agnostic and runs entirely in
| userspace. It is just syntax-sugar for Futures as state
| machines, where "await points" are your states.
|
| An executor (I think this is what you meant by runtime) is
| nothing special and doesn't need to be tied to OS features at
| all. You can poll and run futures in a single thread. It's
| just something that holds and runs futures to completion.
|
| Not very different from an OS scheduler, except it is
| cooperative instead of preemptive. It's a drop in the ocean
| of kernel complexities.
| rcxdude wrote:
| Yeah, for example embassy-rs is an RTOS that uses rust
| async on tiny microcontrollers. You can hook task execution
| up to a main loop and interrupts pretty easily. (And RTIC
| is another, more radically simple version which also uses
| async but just runs everything in interrupt handlers and
| uses the interrupt priority and nesting capability of most
| micros to do the scheduling)
| Rochus wrote:
| Interesting references, thanks. Moss seems to be doing
| the same thing as Embassy.
| boguscoder wrote:
| Sorry for nit but embassy is not a RTOS (or any OS), its
| a framework
| Rochus wrote:
| Ok, I see. I spent a lot of time with .Net VMs, where you
| cannot simply separate await from the heavy machinery that
| runs it. I now understand that in a kernel context, you
| don't need a complex runtime like Tokio. But you still need
| a way to wake the executor up when hardware does something
| (like a disk interrupt); but this indeed is not a runtime
| dependency.
|
| EDIT: just found this source which explains in detail how
| it works: https://os.phil-opp.com/async-await/
| vlovich123 wrote:
| There's got to be some complexity within the executor
| implementation though I imagine as I believe you have to
| suspend and resume execution of the calling thread which
| can be non-trivial.
| kaoD wrote:
| You can implement an executor with threading to achieve
| parallelism, but it's not a fundamental characteristic of
| Future executors.
|
| To reiterate: an executor is just something that runs
| Futures to completion, and Futures are just things that
| you can poll for a value.
|
| See sibling comments for additional details.
| vlovich123 wrote:
| I'm aware; you're not adding new information. I think
| you're handwaving the difficulty of implementing work
| stealing in the kernel (interrupts and whatnot) + the
| mechanics of suspending/resuming the calling thread which
| isn't as simple within the kernel as it is in userspace.
| eg you have to save all the register state at a minimum
| but it has to be integrated into the scheduler because
| the suspension has to pick a next task to execute and
| resume the register state for. On top of that you've got
| the added difficulty of doing this with work stealing (if
| you want good performance) and coordinating other
| CPUs/migrating threads between CPUs. Now you can use non
| interruptible sections but you really want to minimize
| those if you care about performance if I recall
| correctly.
|
| Anyway - as I said. Implementing even a basic executor
| within the kernel (at least for something more involved
| than a single CPU machine) is more involved, especially
| if you care about getting good performance (and threading
| 100% comes up here as an OS concept so claiming it
| doesn't belies a certain amount of unawareness of how
| kernels work internally and how they handle syscalls).
| kaoD wrote:
| No. I am adding new information but I think you are stuck
| on your initial idea.
|
| There's no work stealing. Async-await is cooperative
| multitasking. There is no suspending or resuming a
| calling thread. There is no saving register state. There
| is not even a thread.
|
| I will re-reiterate: async-await is _just_ a state
| machine and Futures are _just_ async values you can poll.
|
| I'm sure moss has an actual preemptive scheduler for
| processes, but it's completely unrelated to its internal
| usage of async-await.
|
| See embassy in sibling comments.
| vlovich123 wrote:
| Embassy is a single threaded RTOS. Moss implements
| support for Linux ABI which presumes the existence of
| threads. The fact that async/await doesn't itself imply
| anything about threads doesn't negate that using it
| within the context of a kernel implementation of the
| Linux kernel ABI does require thread suspension by
| definition - the CPU needs to stop running the current
| thread (or process) and start executing the next thread
| if there's any blocking that's required. Clue: there's a
| scheduler within the implementation which means there's
| more than 1 thread on the system.
|
| You're arguing about the technical definition of
| async/await while completely ignoring what it means to
| write a kernel.
| netbsdusers wrote:
| I find it interesting that this fulfills some of Dennis
| Ritchie's goals for what became the STREAMS framework for
| byte-oriented I/O:
|
| > I decided, with regret, that each processing module could
| not act as an independent process with its own call record.
| The numbers seemed against it: on large systems it is
| necessary to allow for as many as 1000 queues, and I saw no
| good way to run this many processes without consuming
| inordinate amounts of storage. As a result, stream server
| procedures are not allowed to block awaiting data, but
| instead must return after saving necessary status
| information explicitly. The contortions required in the
| code are seldom serious in practice, but the beauty of the
| scheme would increase if servers could be written as a
| simple read-write loop in the true coroutine style.
|
| The power of that framework was exactly that it _didn 't_
| need independent processes. It avoided considerable
| overhead that way. The cost was that you had to write
| coroutines by hand, and at a certain point that becomes
| very difficult to code. With a language that facilitates
| stackless coroutines, you can get much of the strengths of
| an architecture like STREAMS while not having to write
| contorted code.
| hexagonal-sun wrote:
| This has been a real help! The ability to easily verify the
| behavior of certain pieces of code (especially mem management
| code) must have saved me hours of debugging.
|
| Regarding the async code, sibling posts have addressed this.
| However, if you want to get a taste of how this is
| implemented in Moss look at src/sched/waker.rs,
| src/sched/mod.rs, src/sched/uspc_ret.rs. These files cover
| the majority of the executor implementation.
| IshKebab wrote:
| Impressive work! Do you have any goals, other than learning and
| having fun?
|
| Also how does it's design compare with Redox and Asterinas?
| cies wrote:
| Are the collaborations possible/foreseeable?
| F3nd0 wrote:
| Congratulations on the progress. If I may ask, I'm curious what
| considerations have motivated your choice of licence
| (especially since pushover licences seem extremely popular with
| all kinds of different Rust projects, as opposed to copyleft).
| dymk wrote:
| I've pretty much only seen MIT and to a lesser extent GPL on
| most open source projects. Would you expect a different
| license?
| tingletech wrote:
| What is a "pushover" license?
| WD-42 wrote:
| It's a play on "permissive" license.
| nmz wrote:
| A derogatory term for copyfree licenses
| SAI_Peregrinus wrote:
| Permissive license + complaining when companies don't
| contribute back from their forks.
| cryptonector wrote:
| I've worked on plenty of BSD and MIT licensed code. I've
| never complained about lack of contribution. You're
| projecting. Please stop.
| andrewl-hn wrote:
| > no networking support
|
| Would something like Smoltcp be of help here?
| https://github.com/smoltcp-rs/smoltcp
|
| Great project either way!
|
| How do you decide which sys calls to work on? Is is based on
| what the user space binaries demand?
| hexagonal-sun wrote:
| Yip, I panic whenever I encounter a syscall that I can't
| handle and that prompts me to implement it.
|
| Yeah, I was thinking of integrating that at some point.
| They've done a really nice job of keeping it no_std-friendly.
| phkahler wrote:
| Love the MIT license. If this were further along we could use
| this as the foundation of our business without having to "give
| back" device drivers and other things.
| bfrog wrote:
| This should be the sort of red flag to take note of. There's
| an LLVM fork for every esoteric architecture now and this
| sort of thinking will lead to never being able to run your
| own software on your own hardware again. A reversion to the
| dark ages of computing.
| imiric wrote:
| Seriously.
|
| To the author: kudos for the interesting project, but
| please strongly consider a copyleft license moving forward.
| cryptonector wrote:
| Seriously: stop it. It's none of your business what the
| author's license choice is. You don't know what the
| author is trying to accomplish by their choice of
| license. It could be a mindless choice, or it could be an
| informed choice. Perhaps the author wants to build
| interest and later plans to switch licenses (it's not
| like others are likely to fork _and_ do an excellent job
| of evolving and maintaining the fork). Perhaps the author
| is looking to get hired. Perhaps the author believes that
| BSD/MIT licensing is more free than the GPL. You really
| don't need to be shaming the author for not making the
| choice you made.
| 533474 wrote:
| Great, an MIT license to accelerate planned obsolescence
| and hardware junk. Truly a brilliant move
| surajrmal wrote:
| Linux magically solves this problem how? GPL isn't magic.
| It doesn't compel contributing upstream. And half of
| modern driver stacks live in userspace anyways.
| mikelpr wrote:
| > And half of modern driver stacks live in userspace
| anyways ??? I haven't touched hardware whose driver lives
| in userspace since 2017 and it was a DMX512 controller of
| a shitty brand
| surajrmal wrote:
| They seem to be primarily targeting arm. A lot of drivers
| live in userspace for arm socs, especially on the higher
| end.
| woodruffw wrote:
| > There's an LLVM fork for every esoteric architecture now
|
| Can you provide examples of these? I'm aware of temporary
| forks for things like Xtensa, but these typically get
| merged back upstream.
| RealityVoid wrote:
| Infineon tricore compiler from hightec. Compilers are
| actually, IMO, one of the things that are the most easy
| to have GPL because you can use it internally however you
| want without releasing the source outside. You could
| build whatever you want and you don't have to ship it on
| the final HW. A kernel does not afford you such a thing,
| you MUST ship it with your product.
| nickpsecurity wrote:
| MIT licensed code is a gift. A gift indeed doesn't require
| the recipient to give back anything related to the gift.
|
| A "gift" requiring GPL-like conditions isn't really a gift in
| the common sense. It's more like a contractual agreement with
| something provided and specific, non-negotiable obligations.
| They're giving while also asserting control over others'
| lives, hoping for a specific outcome. That's not just a gift.
|
| People doing MIT license are often generous enough where the
| code is a gift to everyone. They don't try to control their
| lives or societal outcomes with extra obligations. They're
| just giving. So, I'm grateful to them for both OSS and
| business adaptations of their gifts.
| imiric wrote:
| A gift where the recipient can remove the freedoms that
| they've been enjoying themselves is a bad deal for ensuring
| those freedoms are available to everyone. A permissive
| license is a terrible idea for a F/LOSS kernel.
|
| This is the paradox of tolerance, essentially.
|
| Also, seeing F/LOSS as a "gift" is an awful way of looking
| at it.
| naasking wrote:
| MIT is throwing a free party where food and drinks are paid
| for, and copyleft is where food is paid for but you BYOB.
| Both are fine, so what's the problem?
| cryptonector wrote:
| That's my question. Why is this thread full of license
| choice flamewar? Do we have nothing of substance to
| contribute?
|
| Here, I'll make a substantive contribution. I hope this
| succeeds and causes a lowest-common denominator Linux ABI
| to exist that user-land can target, thus freeing us all
| from the Linux kernel as the only viable option.
| Solaris/Illumos, the BSDs, and even Windows have all gone
| through one or two phases of attempting Linux ABI
| compatibility, ultimately giving up because the Linux ABI
| is such a fast-moving and underdocumented target.
| vacuity wrote:
| While the FSF's vision for the GPL is clear, the GPL itself
| is not so powerful that it is more than a "gift" that has
| some terms _if you want to do certain things you are not
| obligated to do_. It is like a grant that enforces some
| reasonable conditions so the money isn 't just
| misappropriated. I wouldn't give that to a friend for their
| birthday, but I think it's reasonable that powerful
| organizations should not be free to do whatever they want.
| Not that the GPL is perfect for that use, but it's good.
| pessimizer wrote:
| > It's more like a contractual agreement with something
| provided and specific, non-negotiable obligations.
|
| The obligation is not to the author of the code, it is to
| the public. MIT-style licenses are gifts to people and
| companies who produce code and software, copyleft licenses
| are gifts to the public.
|
| I don't give a shit about the happiness of programmers any
| more than the happiness of garbage collectors, sorry. I
| don't care more that you have access to the library you
| want to use at your job writing software for phones than I
| care that somebody has access to the code on their own
| phone. You're free to care about what you want, but the
| pretense at moral superiority is incoherent.
|
| It _is_ non-negotiable. GPL is basically proprietary
| software. It 's owned by the public, and all of the work
| that you do using it belongs to the public. If you steal
| it, you should be sued into the ground.
| pstoll wrote:
| I get what your saying but I think it's not the best way
| to describe it - "GPL is property"? Hardly - it's a
| societal common good that can be used by anyone
| interested in helping that common good.
|
| Are parks "proprietary"? I can't run my car dealership
| from one, so it's ...proprietary? No. So using the
| terminology of "proprietary" doesn't do justice to what
| it actually is.
| wredcoll wrote:
| The phrasing is a little awkward but I like the
| sentiment: gpl software is owned by the
| public/humanity/the commons/etc in the same way something
| like the grand canyon should be.
| mcdonje wrote:
| Public property is different from private property, which
| is different from personal property.
| eggy wrote:
| I agree, and even if a company doesn't give back, they
| further the popularity and sustainability of the project.
| Isn't Python an MIT-like license (PSFL)? As well as React
| and Godot? And Tensorflow is also permissive with Apache
| 2.0, corrrect?
| surajrmal wrote:
| Do you think soup kitchens and food banks should only serve
| food to those who volunteer? MIT is a perfectly fine FOSS
| license.
| imiric wrote:
| No, but if someone takes the free food and builds a
| business by selling it to others, without giving anything
| back to the original places, it harms everyone other than
| the person doing that.
|
| F/LOSS is not a charity or a gift, so your analogy is not
| appropriate. It is a social movement and philosophy with
| the goal of sharing knowledge and building software for the
| benefit of _everyone_. It invites collaboration, and
| fosters a community of like-minded people. Trust is an
| implicit requirement for this to succeed, and individuals
| and corporations who abuse it by taking the work of others
| and not giving anything back are harmful to these goals.
| Copyleft licenses exist precisely to prevent this from
| happening.
|
| MIT is a fine license for many projects, but not for an
| operating system kernel.
| surajrmal wrote:
| This feels eerily close to having someone try to convince
| me to be join their religion. You don't need to force
| your opinions into others. Let them choose. If folks
| agree then the license will hold them back in terms of
| building a community. There are plenty of great open
| source kernels that don't use GPL, including freebsd. I
| think most embedded os kernels are not gpl (zephyr,
| freertos, etc). I would argue that Linux does well in
| spite of its license not because of it.
| vacuity wrote:
| Just as people who strongly prefer permissive licenses
| deny copyleft licenses, this is the same in reverse. If
| you don't want to touch GPL projects, then don't.
| surajrmal wrote:
| Im not trying to suggest non gpl licenses are superior
| and folks writing kernels with gpl are making a mistake.
| On the contrary I'm advocating that both are fine options
| and you shouldn't make people feel bad for choosing to
| not use gpl. There is a difference here and it matters
| greatly. Most people will not care for the differences
| between the two and the ones that do will choose the one
| that aligns with their values. If I'm even a hint of anti
| gpl, it's due to zealotry of it's supporters.
| vacuity wrote:
| I think a lot of the backlash for the GPL is
| unreasonable, and not really better than a lot of the
| backlash for permissive licenses, and furthermore I
| believe there are reasonable ideological opinions to
| prefer one or the other (though ideology isn't an excuse
| to be mean). But I concede that the person you responded
| to set a poor standard of discussion.
| knowitnone3 wrote:
| yes
| cryptonector wrote:
| I take this as an oblique critique of TFA's choice of
| license. What's it to you? Why must we all use the GPL always
| in order to satisfy busybodies?
| 0x457 wrote:
| You just described android.
| Onavo wrote:
| How does android compatibility look? Can this be compiled to
| WebAssembly and run in browser?
| maxloh wrote:
| In what extent is this compatible with Linux?
|
| Could I swap Ubuntu's or Android's kernel with this, while
| keeping those OSes bootable?
| tuyiown wrote:
| While it's very legitimate question, the answer is between the
| lines in the README, and it mostly means that there is a user
| space binary compatibility for everything that is implemented.
|
| It might seem obscure, but syscalls to get access to kernel
| requires a tight integration on compilation and linking. So
| this is their approach and this is where the compatibility
| really means something : since you can cross compile on another
| machine, they don't need the full toolchain right away. Just
| compile your code on a linux machine, and run it there. You're
| at the mercy of all missing kernel API implementations, but it
| looks like a very good strategy if you aim is to code a kernel,
| as you only have to focus on actual syscalls implementation
| without getting distracted by toolchain.
| HackerThemAll wrote:
| At this stage you'd need to contribute to it, not treat it as a
| finished product.
| marty-oehme wrote:
| Very cool project! I do have to admit - looking far, far into the
| future - I am a bit scared of a Linux ABI-compatible kernel with
| an MIT license.
| stingraycharles wrote:
| Why?
| p0w3n3d wrote:
| because otherwise big tech companies will take it and modify
| and release hardware with it without releasing patches etc?
| Basically being selfish and greedy?
| sneak wrote:
| It is neither selfish nor greedy to accept and use a gift
| freely given to you.
|
| Receiving a gift does not confer obligations on the
| recipient.
| Hendrikto wrote:
| True, but you would probably still be pissed if somebody
| took your gift and hit you over the head with it.
| mordae wrote:
| It does. There is an implied expectation that the
| recipient will will not be selfish. They can pay it back,
| pay it forward, possibly later when they can afford it,
| etc., but they are expected not to be selfish and also
| give someone something eventually.
| surajrmal wrote:
| Does this happen to freebsd? I know plenty of closed source
| Linux drivers.
| bmicraft wrote:
| Isn't that basically every router out there?
| wmf wrote:
| Most routers are on Linux now.
| WD-42 wrote:
| Routers are all running ddwrt which we only have access
| to because of a GPL lawsuit against Linksys. The GPL
| works.
| mnau wrote:
| Because unlike most other functionality, you generally need
| hw specs or cooperation to write drivers (see Nvidia GSP).
|
| Anyone can write Photoshop (provided reasonable resources).
| The problem is going to be proprietary file format and
| compatibility with the ecosystem. It's same with hardware,
| except several orders of magnitude worse.
| viraptor wrote:
| Too late? https://docs.freebsd.org/en/books/handbook/linuxemu/
| jorvi wrote:
| Somewhere there is a dark timeline where the BSDs won, there
| are 50 commercial and open source variants all with their own
| kernel and userland. The only promise of interoperability is
| in extremely ossified layers like POSIX. There is, however,
| something terrible gathering its strength. A colossus. The
| great Shade that will eat the net. In boardroom meetings
| across the land, CTOs whisper its name and tremble... "OS/2."
| maybewhenthesun wrote:
| Waaaarp
| andrewl-hn wrote:
| Also, AFAIK SmartOS / Ilumos has had a combat layer for it,
| too.
| juliangmp wrote:
| I agree, I know a lot of people aren't huge fans of it but in
| the long run Linux being GPL2 was a huge factor in its success.
| devnullbrain wrote:
| It will be compatible for ~5 minutes:
|
| https://www.kernel.org/doc/html/v4.10/process/stable-api-non...
| athrowaway3z wrote:
| > [Moss has] binary compatibility with Linux userspace
| applications (currently capable of running most BusyBox
| commands).
|
| Per your link
|
| > Note: Please realize that this article describes the in
| kernel interfaces, not the kernel to userspace interfaces.
| cryptonector wrote:
| > I am a bit scared of a Linux ABI-compatible kernel with an
| MIT license.
|
| What's the threat? Solaris/Illumos, the BSDs, even Windows,
| have all tried -sometimes more than once- to be compatible with
| the Linux ABI, and in the end they've all given up because the
| Linux ABI evolves way too fast to keep up and is
| underdocumented. Someday someone -perhaps TFA- will succeed in
| building momentum for a well-defined and highly functional
| least common denominator subset of the Linux ABI, and that will
| be a very good thing (IMO) regardless of their choice of
| license.
|
| I guess you imagine that everyone will switch to Moss and oh-
| noes!-everyone-will-be-free-to-not-contribute-back!! So what?
| meisel wrote:
| Really neat. Do you have any specific long term goals for it? Eg,
| provide an OS distro (using Linux drivers?) to provide memory
| safety for security-critical contexts?
|
| Also, are there any opportunities to make this kernel
| significantly faster than Linux's?
| hexagonal-sun wrote:
| Eventually, It'd be amazing to use Moss as my daily driver OS.
| That means targeting the specific hardware that I have, but in
| doing so, I hope to build up enough of the abstractions to
| allow easier porting of hardware.
|
| A more concrete mid-term goal is for it to be 'self-hosting'.
| By that I mean you could edit the code, download dependencies
| and compile the kernel from within Moss.
| meisel wrote:
| Are you interested in beating Linux performance-wise? Eg:
|
| - Moving away from the too-small 4kb default page size (while
| having a good strategy for dealing with fragmentation)?
|
| - Make it easy to minimize/track interrupts on a core, for
| low-latency contexts
| nikanj wrote:
| Just a hobby, won't be big and professional like Linux?
| hexagonal-sun wrote:
| ;-)
| noumenon1111 wrote:
| I see what you did there, fair human.
| cedws wrote:
| I don't know much about Linux internals - how difficult would it
| be to reimplement KVM? I'm guessing a big undertaking.
| erichocean wrote:
| This plus using Fil-C for the BusyBox commands is a nice
| combination (once Fil-C supports ARM64).
| forgotpwd16 wrote:
| Or... rewrite BusyBox in Rust. (And most certainly such a
| project already exists.)
| estebank wrote:
| Isn't that https://uutils.github.io/?
| gslepak wrote:
| How does this compare to https://github.com/nuta/kerla ?
| scns wrote:
| > This software is no longer maintained.
| cryptonector wrote:
| The question is still relevant.
| leo_e wrote:
| The choice of MIT for a kernel feels like setting up the project
| to be cannibalized rather than contributed to.
|
| We've seen this movie before with the BSDs. Hardware vendors love
| permissive licenses because they can fork, add their proprietary
| HAL/drivers, and ship a closed binary blob without ever
| upstreaming a single fix.
|
| Linux won specifically because the GPL forced the "greedy" actors
| to collaborate. In the embedded space, an MIT kernel is just free
| R&D for a vendor who will lock the bootloader anyway.
| KerrAvon wrote:
| Not meaning to single you out specifically, but this entire
| discussion -- all of this license gatekeeping is ridiculous.
| This is a very cool project, but if the license ruins it for
| you, there are zillions of open source GPL3 kernels.
|
| I mean, this is not different from bitching about someone
| writing their custom kernel in C++ instead of Rust, or Zig.
| It's not your project! Let people do their own thing! MIT is a
| perfectly fine license; maybe the lack of zealotry associated
| with it would even be a positive thing for whatever community
| might be built around this eventually, if the author is even
| interested in having other contributions.
| leo_e wrote:
| That's the truth
| dejung wrote:
| Why is a proven effect "ridiculous" to discuss? It's a valid
| concern and the discussion could make the authors rethink
| their choice.
| LeFantome wrote:
| Not sure why am getting in the middle of this but I need to
| point out that you are not even correct for Linux.
|
| Linux rather famously has avoided the GPL3 and is distributed
| under a modified GPL2. This license allows binary blob modules.
| We are all very familiar with this.
|
| As a result, the kernel that matches your description above
| that ships in the highest volume is Linux by a massive margin.
| Can you run a fully open source Linux kernel on your Android
| phone? Probably not. You do not have the drivers. You may not
| pass the security checks.
|
| Do companies like Broadcomm "collaborate" on Linux even in the
| PC or Mac space? Not really.
|
| On the other side, companies that use FreeBSD do actually
| contribute a lot of code. This includes Netflix most famously
| but even Sony gives back.
|
| The vast majority of vendors that use Linux embedded never
| contribute a single line of code (like 80% or more at least -
| maybe 98%). Very few of them even make the kernel code they use
| available. I worked in video surveillance where every video
| recorder and camera in the entire industry is Linux based at
| this point. Almost none of them distribute source code.
|
| But even the story behind the GPL or not is wrong in the real
| world.
|
| You get great industry players like Valve that contribute a lot
| of code. And guess what, a lot of that code is licensed
| permissively. And a lot of other companies continue to Mesa,
| Wayland, Xorg, pipewire, and other parts of the stack that are
| permissively licensed. The level of contribution has nothing to
| do with the GPL.
|
| How about other important projects? There are more big
| companies contributing to LLVM/Clang (permissive) than there
| are to GCC (GPL).
|
| In fact, the GPL often discourages collaboration. Apple is a
| great example of a company that will not contribute to even the
| GPL projects that they rely on. But they do contribute a fair
| bit of Open Source code permisssively. And they are not even
| one of the "good guys" in Open Source.
|
| This comment is pure ideological mythology.
| rendx wrote:
| > In fact, the GPL often discourages collaboration
|
| Not true. Yes, companies choose not to contribute, so they
| discourage themselves. It's not inherent to the GPL.
| drob518 wrote:
| ?!?!?
| olejorgenb wrote:
| A real life case where someone try to force a vendor to
| release the kernel source code:
| https://sfconservancy.org/copyleft-compliance/vizio.html
| wmf wrote:
| That's 1980s-90s thinking. Nobody is making proprietary BSD
| forks any more and new kernels probably have no chance of
| reaching production anyway so worrying about proprietary forks
| is irrelevant.
| nmz wrote:
| The most recent and most used fork for freebsd is for the ps4
|
| https://en.wikipedia.org/wiki/PlayStation_4_system_software
| kev009 wrote:
| I think GCC is the real shining example of a GPL success, it
| broke through a rut of high cost developer tooling in the 1990s
| and became the de facto compiler for UNIX and embedded BSPs
| (Board Support Packages) while training corporations on how to
| deal with all this.
|
| But then LLVM showed up and showed it is no longer imperative
| to have a viral license to sustain corporate OSS. That might've
| not been possible without the land clearing GCC accomplished,
| but times are different now and corporations have a better
| understanding and relationship with OSS.
|
| The GPL has enough area to opt out of contributing (i.e.
| services businesses or just stacking on immense complexity in a
| BSP so as to ensure vendor lockin) that it isn't a defining
| concern for most users.
|
| Therefore I don't think Linux' success has much to do with GPL.
| It has been effective in the BSP space, but the main parts most
| people care about and associate with Linux could easily be MIT
| with no significant consequence on velocity and participation.
| In fact, a lot of the DRM code (graphics drivers) are dual-
| licensed thusly.
| josefx wrote:
| > But then LLVM showed up and showed it is no longer
| imperative to have a viral license
|
| I am not sure I remember everything right, but as far as I
| remember Apple originally maintained a fork of gcc for its
| objective-c language and didn't provide clean patches
| upstream, instead it threw its weight behind LLVM the moment
| it became even remotely viable so it could avoid the issue
| entirely.
|
| Also gcc didn't provide APIs for IDE integration early on,
| causing significant issues with attempts to implement
| features like refactoring support on top of it. People had
| the choice of either using llvm, half ass it with ctags or
| stick with plain text search and replace like RMS intended.
| cryptonector wrote:
| This comment does not contribute to discussion of TFA: it's
| just license flamewar bait.
|
| The authors almost certainly gave a bit of thought to their
| choice of license. The choice of license is a "business choice"
| that has to do with the author(s)' goals, and it is a choice
| best seen as intending to achieve those goals. Those goals can
| be very different from your own goals, and that's fine! There
| is no need to shame TFA for their choice of license, or
| implicitly for their goals as opposed to yours.
| netbsdusers wrote:
| > Linux won specifically because the GPL forced the "greedy"
| actors to collaborate.
|
| How do we know that? It seems to me that a greater factor in
| the success of Linux was the idealism and community. It was
| about freedom. Linux was the "Revolution OS" and the hacker
| community couldn't but fall in love with Linux and its
| community that embodied their ideals. They contributed to it
| and they founded new kinds of firms that (at least when they
| began) committed themselves to respect those principles.
|
| I realise the memory of Linux's roots in hacker culture is
| fading away fast but I really do think this might have been the
| key factor in Linux's growth. It reached a critical mass that
| way.
|
| I'm quite certain of the fact that this was more important
| anyway than the fact that, for instance, Linksys had to
| (eventually! they didn't at first) release the source code to
| their modifications to the Linux kernel to run on the WRT54G. I
| don't think things like that played much of a role at all.
|
| Linksys were certainly kind enough to permit people to flash
| their own firmware to that router, and that helped grow Linux
| in that area. They even released a special WRT54GL edition to
| facilitate custom firmware. But they could just as easily have
| Tivoised it (something that the Linux licence does not forbid)
| and that would've been the end of the story.
| wmf wrote:
| We can't really prove it but I noticed a lot of people worked
| on BSD for a few years, got poached by Sun/NeXT/BSDI/NetApp,
| then mostly stopped contributing to open source. Meanwhile
| early Linux devs continued contributing to Linux for decades.
| phendrenad2 wrote:
| Kinda sad that the top comment on this really interesting
| project is complaining about the license, reiterating the trite
| conventional wisdom on this topic,which is based on basically
| two data points (Linux and BSD) (probably because any time
| someone tries something new, they get beaten down by people who
| complain that BSD and Linux already exist, but that's another
| topic).
| theoldgreybeard wrote:
| > MIT license
|
| What have you done?!
___________________________________________________________________
(page generated 2025-11-28 23:00 UTC)