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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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