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 have no intension to make this discussion look heated. I mean what I original code is under MIT and i've learned that Linux is GPL-2.0, so I naively thought it's OK to dual licensed this to support flexibility according the Wikipedia, should 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]. Since it says multiple licenses does not necessarily indicate that the recipient can freely choose one or other,I thought the strictest license applies here and it should GPL-2.0-only in this case. I don't have any previous experience in Kernel Development so I really just have no ideas about you guys attitude towards this kind of issue. If insisted on switching back to GPL-2.0-only code, It's fine for me and i'llchange this in the next version. Again I don't have this kind of knowledge in advance, and if multi-license is inspected case-by-case, project-by-project, then I will take notes and never make this kind of mistakes again. Best Regards, Yiyang Wu.
