On Tue, Dec 19, 2023 at 11:10 AM Greg KH <gre...@linuxfoundation.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-licens...@google.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-licens...@google.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