On 2024/9/17 13:34, Greg KH wrote:
On Tue, Sep 17, 2024 at 08:18:06AM +0800, Gao Xiang wrote:
Hi Greg,
On 2024/9/17 01:55, Greg KH wrote:
On Mon, Sep 16, 2024 at 09:56:12PM +0800, Yiyang Wu wrote:
diff --git a/fs/erofs/rust/erofs_sys.rs b/fs/erofs/rust/erofs_sys.rs
new file mode 100644
index 000000000000..0f1400175fc2
--- /dev/null
+++ b/fs/erofs/rust/erofs_sys.rs
@@ -0,0 +1,22 @@
+#![allow(dead_code)]
+// Copyright 2024 Yiyang Wu
+// SPDX-License-Identifier: MIT or GPL-2.0-or-later
Sorry, but I have to ask, why a dual license here? You are only linking
to GPL-2.0-only code, so why the different license? Especially if you
used the GPL-2.0-only code to "translate" from.
If you REALLY REALLY want to use a dual license, please get your
lawyers to document why this is needed and put it in the changelog for
the next time you submit this series when adding files with dual
licenses so I don't have to ask again :)
As a new Rust kernel developper, Yiyang is working on EROFS Rust
userspace implementation too.
I think he just would like to share the common Rust logic between
kernel and userspace.
Is that actually possible here? This is very kernel-specific code from
what I can tell, and again, it's based on the existing GPL-v2 code, so
you are kind of changing the license in the transformation to a
different language, right?
It's possible, Yiyang implemented a total userspace Rust crates
to parse EROFS format with limited APIs:
https://github.com/ToolmanP/erofs-rs
Also take another C example, kernel XFS (fs/libxfs) and xfsprogs
(userspace) use the same codebase. Although they both use GPL
license only.
Since for the userspace side, Apache-2.0
or even MIT is more friendly for 3rd applications (especially
cloud-native applications). So the dual license is proposed here,
if you don't have strong opinion, I will ask Yiyang document this
in the next version. Or we're fine to drop MIT too.
If you do not have explicit reasons to do this, AND legal approval with
the understanding of how to do dual license kernel code properly, I
would not do it at all as it's a lot of extra work. Again, talk to your
lawyers about this please. And if you come up with the "we really want
to do this," great, just document it properly as to what is going on
here and why this decision is made.
Ok, then let's stay with GPL only. Although as I mentioned,
cloud-native applications are happy with Apache-2.0 or MIT, which
means there could be diverged for kernel and userspace on the Rust
side too.
Thanks,
Gao Xiang
thanks,
greg k-h
