Re: [PATCH] rust: macros: add `paste!` proc macro

[Greg KH <gregkh@linuxfoundation.org>]

On Thu, Aug 10, 2023 at 12:29:06AM +0200, Miguel Ojeda wrote:
> > All my kernel contributions are permissively licensed if possible, so I
> > am fine with this being either MIT or GPL-2.0 (I think GPL-2.0 is
> > deprecated in as a SPDX license identifier and it should be
> > GPL-2.0-only going forward, though).
> 
> Yeah, the 3.0 version of the SPDX license list deprecated `GPL-2.0`,
> but the kernel still allows `GPL-2.0` and lists it first. I recall
> thinking about this before the initial merge, and I think I went with
> the original form because the main `COPYING` file still uses that.
> After that I am just keeping it consistent, though I am not sure when
> the kernel will migrate.

The kernel will migrate when we have converted all files in the tree to
SPDX and can worry about things like the SPDX version level.  We have a
ways to go still...

> > Given this is non-kernel specific generic code, I think it might worth
> > following the convention of the paste and pin-init code and make it
> > `Apache-2.0 OR MIT`? This would also make it the same license as the
> > `paste` crate (although we don't have to keep the same license as this
> > is a different implementation).
> >
> > I'll leave the final decision to you.
> 
> Since you prefer it and it makes sense that someone may want to use it
> (`concat` and `expand`) elsewhere, let's go with that. I will add:
> 
>     // SPDX-License-Identifier: Apache-2.0 OR MIT

Be VERY careful with dual licenses please, and especially non-GPL ones
in the kernel tree.  It gets tricky very very quickly and you need to
know what you are doing.  So much so that I really want to see a lawyer
sign off on such a thing so that everyone involved understands the
issues that this requires.

Otherwise please, just default to GPL-2.0 for kernel code, unless you
have real reasons why it can't be that way, as remember, the overall
license of the codebase is that.

thanks,

greg k-h