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

[Alejandro Vallejo <alejandro.garciavallejo@amd.com>]

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@amd.com>
>> >> ---
>> >> 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@twin.jikos.cz/
>> >>       - https://lwn.net/ml/linux-fsdevel/20221026074145.2be5ca09@gandalf.local.home/
>> >>       - 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