|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [RFC PATCH] CODING_STYLE: Establish a policy with regards to copyright notices
On Wed Jan 28, 2026 at 10:41 AM CET, Roger Pau Monné wrote: > On Wed, Jan 28, 2026 at 10:18:03AM +0100, Alejandro Vallejo wrote: >> Hi, >> >> On Wed Jan 28, 2026 at 9:10 AM CET, Roger Pau Monné wrote: >> > On Tue, Jan 27, 2026 at 07:24:01PM +0100, Alejandro Vallejo wrote: >> >> This patch modifies CODING_STYLE to severely discourage use of copyright >> >> notices when their presence is not legally mandatory. >> >> >> >> Copyright notices are redundant on commit, misleading from the time the >> >> file >> >> receives contributions from anyone not represented by such notice, and >> >> actively >> >> harmful for attribution by the time the original code is long gone. They >> >> are >> >> plain wrong when added on code motion.... the list goes on. >> >> >> >> All attribution worth keeping is version-controlled through Signed-off-by, >> >> Co-authored and the like, DCO and the cumulative contents of git history. >> >> License banners have already been superseded by the contents of licenses/ >> >> and >> >> SPDX tags. >> >> >> >> Other FOSS projects have already moved away from explicit copyright >> >> notices >> >> where possible, and severely discourage their use when not. >> >> >> >> Apache and LLVM take active issue with copyrighted contributions and >> >> Chromium >> >> takes issues with copyrighted contributions not attributed to the >> >> project. Some >> >> Linux subsystem maintainers already frown upon copyright notices too, >> >> even if >> >> it hasn't reached the point of being a mandated requirement yet. >> >> >> >> Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@xxxxxxx> >> >> --- >> >> The actual changes are almost verbatim from the LLVM guideline, but it's >> >> not >> >> exact. Wording can be adjusted as needed. I care about the core of the >> >> proposal. >> >> Saying "please, drop the notice" on contributions where it's clearly not a >> >> legal requirement, or have the contributor state that it is a legal >> >> requirement >> >> and why. For fairness sake for all contributors to the project. >> >> >> >> I'd prefer taking the Apache approach for new contributions, but I want >> >> some discussions to happen first. >> >> >> >> Thoughts? >> >> >> >> Relevant examples: >> >> >> >> - LLVM: They banned copyright notices, unless part of a vendored >> >> components. >> >> - Links: >> >> - >> >> https://llvm.org/docs/DeveloperPolicy.html#embedded-copyright-or-contributed-by-statements >> >> - Relevant quote: >> >> The LLVM project does not accept contributions that include >> >> in-source copyright notices except where such notices are >> >> part of a larger external project being added as a vendored >> >> dependency. >> >> >> >> - Apache: They banned optional copyright notices and relegated >> >> mandatory notices to a NOTICES file that also contains an >> >> Apache copyright notice. See links. >> >> - Links: >> >> - https://www.apache.org/legal/src-headers.html >> >> - https://infra.apache.org/licensing-howto.html#mod-notice >> >> - Relevant quote: >> >> If the source file is submitted with a copyright notice included >> >> in it, the copyright owner (or owner's agent) must either: >> >> * remove such notices, or >> >> * move them to the NOTICE file associated with each applicable >> >> project release, or >> >> * provide written permission for the ASF to make such removal >> >> or relocation of the notices. >> >> >> >> - btrfs: They are highly discouraged. >> >> - Links: >> >> - https://lore.kernel.org/20220909101521.GS32411@xxxxxxxxxxxxx/ >> >> - >> >> https://lwn.net/ml/linux-fsdevel/20221026074145.2be5ca09@xxxxxxxxxxxxxxxxxx/ >> >> - >> >> https://archive.kernel.org/oldwiki/btrfs.wiki.kernel.org/index.php/Developer's_FAQ.html#Copyright_notices_in_files.2C_SPDX >> >> - https://lwn.net/Articles/912355/ >> >> - Relevant quote: >> >> Let's say it's OK for substantial amount of code. What if somebody >> >> moves existing code that he did not write to a new file and adds >> >> a copyright notice? We got stuck there, both sides have different >> >> answer. I see it at minimum as unfair to the original code authors >> >> if not completely wrong because it could appear as "stealing" >> >> ownership. >> >> >> >> There's more cases of other projects taking similar stances. >> >> --- >> >> CODING_STYLE | 18 ++++++++++++++++++ >> >> 1 file changed, 18 insertions(+) >> >> >> >> diff --git a/CODING_STYLE b/CODING_STYLE >> >> index aae5a47ac2..97f80245ed 100644 >> >> --- a/CODING_STYLE >> >> +++ b/CODING_STYLE >> >> @@ -24,6 +24,24 @@ license, e.g.: >> >> >> >> See LICENSES/ for a list of licenses and SPDX tags currently used. >> >> >> >> +Copyright notices >> >> +----------------- >> >> + >> >> +Copyright for the code in the Xen Project is held by the respective >> >> +contributors. Because you (or your company) retain ownership of the code >> >> you >> >> +contribute, you know it may only be used under the terms of the open >> >> source >> >> +license you contributed it under: the license for your contributions >> >> cannot be >> >> +changed in the future without your approval. >> > >> > The usage of such direct language here, by using you to refer to the >> > reader / contributor, set a different tone from the rest of the >> > document. Maybe something like: >> > >> > "Copyright for the code in the Xen Project is held by the respective >> > contributors. The author of the code is the owner of it as stated in >> > the DCO. The project cannot retroactively change the copyright of >> > contributions, unless explicitly accepted by all authors of the >> > code." >> >> Ack for the tone. The particulars of the wording might need tweaking even in >> this version to constraint the scope of "contribution", "the code", and so >> on. > > Yeah, it probably needs even more integration to make sure the terms > used match the rest of the document. I didn't take much care into > that, as I was writing this in the email reply and didn't have much > context. > >> ----------------- >> >> I have the same question for you I asked Jan elsewhere. >> >> There's 1 question in 2 forms I'd like to have an answer to from a core >> maintainers. >> >> Would you be willing to ack a change along these lines? >> 1. to a Copyright Notice policy within CODING_STYLE. > > I'm fine with that. > >> 2. to the relegation of existing notices to a NOTICES file in the style of >> Apache. Apache in particular mandates the file not be touched unless >> absolutely required for legal reasons. > > Hm, that might be more complicated. I am however not a lawyer, don't > expect the rants below to have any kind of legal base. Neither am I, for the public record. > > What about the public headers in xen/include/public? I don't think we > can just remove the copyright notices from those files and place them > in a top level NOTICES file. Then OSes would copy the headers > without the NOTICES file and end up effectively dropping the original > copyright notices. > > Also, what about people importing files from Xen into different > projects (apart from the public headers)? If we remove the copyright > notices the imported files won't have them either, and people is not > simply going to pickup the top level Xen NOTICES and import it into > their project? > > How does Apache deal with people importing their code into separate > projects, do they mandate the NOTICES file to also be included as part > of any code import? They do. It's part of the Apache license. See point 4.d: https://www.apache.org/licenses/LICENSE-2.0 This would require some sort of ammendment to xen/COPYING. OTOH, to avoid being a PITA to Linux and others by changing how we do things it'd be sensible to keep the existing headers on everything under xen/include/ public/ for being-a-good-citizen reasons. Anyone actively copying an internal file (say, msi.c) would thus be forced to also copy NOTICES, but that's a heck of a lot rarer and not much to ask. Cheers, Alejandro
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |