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.
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.
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.
I’d recommend spending some time reading about it. It’s not as hard as he thinks. Applications developed for Linux are quite easy to port to Redox. It supports many of the same system calls and has a compatible libc implementation. The kernel does have abstractions to ease the porting process. And if you’re going to make a new kernel today, you should do it right and make a microkernel like Redox. One of the benefits of having a microkernel is that it doesn’t matter what language you write drivers in. They’re isolated to their own processes. Rust, C, C++, whatever.
It does work like this, but as with justice, the wheels can be slow at times.
What report are you referring to?
What GPU configuration do you have? I don’t have any of these issues. If NVIDIA, you have to wait for NVIDIA to release explicit sync Wayland drivers.
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.