[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANiq72=-NffQz9jMxoznoRGkeQz+1oTb6__r3c1z+BzOsWxfRw@mail.gmail.com>
Date: Thu, 10 Aug 2023 09:56:18 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: Gary Guo <gary@...yguo.net>, Miguel Ojeda <ojeda@...nel.org>,
Alex Gaynor <alex.gaynor@...il.com>,
Wedson Almeida Filho <wedsonaf@...il.com>,
Boqun Feng <boqun.feng@...il.com>,
Björn Roy Baron <bjorn3_gh@...tonmail.com>,
Benno Lossin <benno.lossin@...ton.me>,
Andreas Hindborg <a.hindborg@...sung.com>,
Alice Ryhl <aliceryhl@...gle.com>,
linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org
Subject: Re: [PATCH] rust: macros: add `paste!` proc macro
On Thu, Aug 10, 2023 at 7:08 AM Greg KH <gregkh@...uxfoundation.org> wrote:
>
> 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...
I see, thanks!
> 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.
It is the common one used in Rust projects, which we are using for
other bits too, e.g. vendoring the `alloc` standard library.
Since these couple functions are essentially a compiler plugin (a proc
macro) that is useful in userspace and other contexts too, Gary wanted
to use that license (he contributes the other kernel code under
GPL-2.0). For instance, he may possibly want to put those functions in
crates.io or similar, I imagine (like the linked crate this replaces
as a simplification).
He is also OK with GPL-2.0, so we can just do that here, of course.
But I am mentioning the above because, if this one is problematic,
then perhaps we should revisit again `rust/alloc`, our `std_vendor.rs`
files and the `pinned-init` library (which all use the same dual
license).
> 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.
That is our default, definitely. I OK'd these two functions for the
reasons above only.
Thanks for keeping an eye on our list, by the way.
Cheers,
Miguel
Powered by blists - more mailing lists