On Mon, Sep 16, 2024 at 07:55:43PM GMT, 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 :) > > thanks, > > greg k-h C'mon, I just don't want this discussion to be heated. I mean my original code is licensed under MIT and I've already learned that Linux is under GPL-2.0. So i originally thought modifying it to dual licenses can help address incompatiblity issues. According to wikipedia, may I quote: "When software is multi-licensed, recipients can typically choose the terms under which they want to use or distribute the software, but the simple presence of multiple licenses in a software package or library does not necessarily indicate that the recipient can freely choose one or the other."[1], so according to this, I believe putting these under a GPL-2.0 project should be OK, since it will be forcily licensed **only** under GPL-2.0. Since I wasn't involved in Kernel Development before, I just don't know you guys attitudes towards this kind of stuff. If you guys are not pretty happy with this, I can just switch back to GPL-2.0 and it's a big business for me. Best Regards, Yiyang Wu.
