Re: [RFC PATCH] CODING_STYLE: Establish a policy with regards to copyright notices

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Wed, Jan 28, 2026 at 11:16:39AM +0100, Alejandro Vallejo wrote:
> 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.

Possibly a very dummy question, but won't our NOTICES file be fairly
big and complex?  If we have to move every single variation of the
different copyright headers we currently have in the tree.  We have
GPL-2 only, >= GPL-2, MIT, LGPL, BSD... Each with a possibly different
set of copyright owners.

Also, would we need to somehow reference which notices go with which
files in the tree?  Otherwise we would effectively loose tracking of
the specific copyright owners of each file I fear.  Figuring those out
would need to be done by going back to the last commit before the
copyright notices were removed.

Thanks, Roger.