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
| ||
|
Message-ID: <CAKwvOdnW_vZyiO3BE=Vce4OrcX4+pb6QrEFbmeya0Z+w_5d=zw@mail.gmail.com> Date: Tue, 19 Dec 2023 15:00:22 -0800 From: Nick Desaulniers <ndesaulniers@...gle.com> To: Greg KH <gregkh@...uxfoundation.org>, Tanzir Hasan <tanzirh@...gle.com>, Ingo Molnar <mingo@...nel.org> Cc: Kees Cook <keescook@...omium.org>, Andy Shevchenko <andy@...nel.org>, linux-hardening@...r.kernel.org, linux-kernel@...r.kernel.org, Andrew Morton <akpm@...ux-foundation.org>, llvm@...ts.linux.dev, Al Viro <viro@...iv.linux.org.uk>, Andy Shevchenko <andy.shevchenko@...il.com> Subject: Re: [PATCH v4 1/2] kernel.h: removed REPEAT_BYTE from kernel.h On Tue, Dec 19, 2023 at 11:10 AM Greg KH <gregkh@...uxfoundation.org> wrote: > > > > Legal note, this file is NOT copyright Google as no Google employe > > > actually wrote the logcal contents of it. > > > > > > Please be VERY careful when doing stuff like this, it has potentially > > > big repercussions, and you don't want to have to talk to lots of > > > lawyers a few years from now and explain how you messed it all up :( > > > > > > Nick, odds are there's a Google copyright class that Tanzir should take > > > here, if not, I recommend the free LF one that anyone can take online > > > that explains the issues here: > > > https://training.linuxfoundation.org/training/open-source-licensing-basics-for-software-developers/ > > Please take the time to either learn what the Google-specific rules are, > or take the above training, before submitting a new version of the > patch. It was my mistake to suggest to Tanzir to add his copyright to this newly created header. I'm sorry; we do have such resources available and I should have reviewed them. I've: 1. reviewed our internal training materials on copyright assignment - go/gti-os-self-study - go/patching#license-headers-and-copyright-notices 2. reviewed kernel docs: - Documentation/process/1.Intro.rst - Documentation/process/kernel-enforcement-statement.rst 3. asked Tanzir to do the same 4. discovered who to ask internally for further questions <opensource-licensing@...gle.com> Is there further due diligence you would like to see? --- For Google specific guidance, I'll quote what they have: > License Headers and Copyright Notices > Googlers should add Google's copyright notice (or a "The Project Authors" style copyright notice) to new files being added to the library if permitted by the project maintainers. Then the relevant section of 1.Intro.rst: > Copyright assignments are not required (or requested) for code contributed > to the kernel. Shall I interpret those together to mean that the "project maintainers" don't permit copyright assignments for "new files being added," and thus Tanzir SHOULD NOT be adding a copyright assignment to the newly created header? Or shall I leave the interpretation up to an explicit discussion with opensource-licensing@...gle.com? --- While I think we have the answer for Tanzir's patch, I don't think we do for if we intend to split other header files in the future if those have explicit copyright assignments. I wonder if this question has come up in Ingo's header refactoring work, and if so, what the guidance is there? For example, consider include/linux/sysfs.h. It's 600+ lines long and contains 4 copyright assignments explicitly in sources. If we split that header file in half, which copyright assignments do we transfer to the new half, if any? -- Thanks, ~Nick Desaulniers
Powered by blists - more mailing lists