91–100 of 163 posts
Earlier quoted context omitted.
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).
What is a "pushover" license?
Earlier quoted context omitted.
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.
> 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.
Earlier quoted context omitted.
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 Linu…
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.
How does this compare to https://github.com/nuta/kerla ?
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 embedd…
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…
Not true. Yes, companies choose not to contribute, so they discourage themselves. It's not inherent to the GPL.
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 embedd…
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.
Earlier quoted context omitted.
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.
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 value…
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 embedd…
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.
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…
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.