Closed nbdd0121 closed 1 month ago
I think that preference is only intended for Rust official projects. After all, anybody can licence their own projects however they wish (assuming by ecosystem you mean the Rust one, i.e. crates.io etc.).
In any case, if we end up with a custom alloc
-like library, it would likely be tailored for usage within the kernel unless we explicitly design it with general usage in mind. Furthermore, maintaining it as a separate project could be a significant effort which we need to consider. On the other hand, sharing it with other projects has many advantages, of course, so it is a good question.
Nevertheless, even if the code ends up being only useful for the Linux kernel, parts of the code could still be useful for others, so the question still applies. Another point is that we may reuse/share some parts from alloc
anyway, and so those are likely to remain under the same licence.
It's a requirement only for Rust official projects, but all libraries in the Rust ecosystem are encouraged to adopt MIT and Apache dual license, see https://rust-lang.github.io/api-guidelines/necessities.html#crate-and-its-dependencies-have-a-permissive-license-c-permissive.
Many parts of the kernel are dual licensed, e.g. (GPL-2.0 OR MPL-1.1)
or (GPL-2.0 OR MIT)
. I wonder if such code can be merged back upstream into dual-licensed Rust? Possibly, this requires a legal opinion from lawyers.
@ojeda sorry to hijack the thread with a question but is there a plan or work being done on the alloc
library? I couldn't find anything but I'd love to help out in any capacity.
It's a requirement only for Rust official projects, but all libraries in the Rust ecosystem are encouraged to adopt MIT and Apache dual license, see https://rust-lang.github.io/api-guidelines/necessities.html#crate-and-its-dependencies-have-a-permissive-license-c-permissive.
My reading of that document is different. It talks about libraries that need the compatibility, not all of them. For instance, if you write a library that you would like to be used by rustc
, you would need to do it. In general, if you write a library that is intended to be used by everyone, including proprietary projects and companies, then you need to use a permissive licence.
@ojeda sorry to hijack the thread with a question but is there a plan or work being done on the
alloc
library? I couldn't find anything but I'd love to help out in any capacity.
Thanks! I would recommend that you join the meetings in that case.
(Also, for general questions like this, please use the mailing list. The relevant issue is #199.)
The ecosystem prefers MIT + Apache 2.0 dual licensing while Linux is GPL-2.0. Linux-related would certainly be GPL-2.0, but at the same time Rust-for-linux may produce some libraries (e.g. fallible alloc) that are useful for other libraries as well, and license them in GPL-2.0 may hinder adoption and can potentially split the ecosystem as it cannot be merged back upstream.
Would it make sense to have a policy on which parts could be licensed in MIT + Apache 2.0 (I envision the fallible alloc fork be licensed this way)?