[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2024091702-easiest-prelude-7d4f@gregkh>
Date: Tue, 17 Sep 2024 07:34:33 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Gao Xiang <hsiangkao@...ux.alibaba.com>
Cc: Yiyang Wu <toolmanp@...p.cc>, linux-fsdevel@...r.kernel.org,
linux-erofs@...ts.ozlabs.org, LKML <linux-kernel@...r.kernel.org>,
rust-for-linux@...r.kernel.org
Subject: Re: [RFC PATCH 02/24] erofs: add superblock data structure in Rust
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?
> 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.
thanks,
greg k-h
Powered by blists - more mailing lists