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 <[email protected]>
>> >> ---
>> >> 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/[email protected]/
>> >> -
>> >> https://lwn.net/ml/linux-fsdevel/[email protected]/
>> >> -
>> >> 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
