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 Xen Project does not accept contributions that include in-source copyright
+notices except in the following cases:
+ * where a committed file already contains it.
+ * where a committed file is renamed.
+ * where such notices are on files from an external project being imported.
+
+The best way to track contributions is through revision control history. See DCO
+under CONTRIBUTING for existing mechanisms of attribution.
+
MISRA C
-------
base-commit: 02bbdda863697096b63e83c2c0a37aa167045476
--
2.43.0On 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." > +The Xen Project does not accept contributions that include in-source copyright > +notices except in the following cases: > + * where a committed file already contains it. IMO we should also prevent expanding the existing list of copyright owners in the headers, and hence don't accept expanding the copyright notice of existing files in any way. I don't think contributors to Xen have been expanding those headers in a long time, but would be good to have it written down. > + * where a committed file is renamed. > + * where such notices are on files from an external project being imported. "where such notices are on files imported from an external project." Seems easier to read to me, but I'm not a native speaker. Thanks, Roger.
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.
But yes, the difference in tone is a direct consequence of the paragraph being a
semi-verbatim copy of the LLVM policy. My intention was less about consistency
with the existing style guide and more about bringing the point accross.
>
>> +The Xen Project does not accept contributions that include in-source copyright
>> +notices except in the following cases:
>> + * where a committed file already contains it.
>
> IMO we should also prevent expanding the existing list of copyright
> owners in the headers, and hence don't accept expanding the copyright
> notice of existing files in any way. I don't think contributors to
> Xen have been expanding those headers in a long time, but would be
> good to have it written down.
Jan made the same appreciation. I agree.
>
>> + * where a committed file is renamed.
>> + * where such notices are on files from an external project being imported.
>
> "where such notices are on files imported from an external project."
>
> Seems easier to read to me, but I'm not a native speaker.
I agree too.
-----------------
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.
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.
(1) can be done without (2) if (2) proves to be "risky" in whatever legal way
it could possibly be risky.
This is httpd's NOTICES file as of today.
Apache HTTP Server
Copyright 2026 The Apache Software Foundation.
This product includes software developed at
The Apache Software Foundation (https://www.apache.org/).
Portions of this software were developed at the National Center
for Supercomputing Applications (NCSA) at the University of
Illinois at Urbana-Champaign.
This software contains code derived from the RSA Data Security
Inc. MD5 Message-Digest Algorithm, including various
modifications by Spyglass Inc., Carnegie Mellon University, and
Bell Communications Research, Inc (Bellcore).
This software contains code derived from the PCRE library pcreposix.c
source code, written by Philip Hazel, Copyright 1997-2004
by the University of Cambridge, England.
Cheers,
Alejandro
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. 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? Thanks, Roger.
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
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@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. 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.
On Wed Jan 28, 2026 at 11:31 AM CET, Roger Pau Monné wrote: > 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@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. > > 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. Any licenses still around as banners we neither need nor want to keep. That's what SPDX tags are for, and why we have them collected under licenses/. Irrespective of the copyright amalgamation, licensing is still per file, with each file having an SPDX line. But yes, every copyright owner would need a "row". Unless we can contact them and ask for permission for removal. > > 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. I don't think so. Apache definitely doesn't do that. They might reference which file was imported, but that's the extent of it. At most, I'd consider file+hash-at-its-commit so it doesn't need updating and it reflects accurately the contribution at hand. Conversely, when code moves around and files evaporate so do copyright notices even though the copyrighted contribution is still around. It's not the file that's copyrighted, but it's contents. In any case, the first thing to do is to prevent MORE coming in. This can be a discussion for later when the set of existing notices is more or less fixed, possibly alongside another RFC with how a NOTICE file might look like. It may very well be too unwieldy, as you suggest, and this discussion be moot. I'll wait a bit for more answers before sending a non-RFC more carefully written version of this. Cheers, Alejandro
On 27.01.2026 19:24, 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. This "is a legal requirement" ... > --- 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 Xen Project does not accept contributions that include in-source copyright > +notices except in the following cases: > + * where a committed file already contains it. > + * where a committed file is renamed. > + * where such notices are on files from an external project being imported. ... may want (need?) reflecting as another bullet point here. The wording of the first bullet point also can be taken to mean that adding to such pre-existing notices is acceptable. This may not be the intention? Jan
On Wed Jan 28, 2026 at 8:04 AM CET, Jan Beulich wrote:
> On 27.01.2026 19:24, 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.
>
> This "is a legal requirement" ...
>
>> --- 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 Xen Project does not accept contributions that include in-source copyright
>> +notices except in the following cases:
>> + * where a committed file already contains it.
>> + * where a committed file is renamed.
>> + * where such notices are on files from an external project being imported.
>
> ... may want (need?) reflecting as another bullet point here.
Hmmm. Yes, that would make sense.
>
> The wording of the first bullet point also can be taken to mean that adding to
> such pre-existing notices is acceptable. This may not be the intention?
Good point. That was very definitely not my intention.
The refinement also applies to the second bullet point, so I can add it as a
separate paragraph stating existing notices are to never be modified and only
removed with the express consent of the current holder(s).
------------------
Do you have a take for/against moving all existing notices to a separate NOTICES
file (a-la Apache). The existing file for them (in httpd) looks like this, so
they took the liberty to rewording the banners to be more digestible in single
file inclusion.
Apache HTTP Server
Copyright 2026 The Apache Software Foundation.
This product includes software developed at
The Apache Software Foundation (https://www.apache.org/).
Portions of this software were developed at the National Center
for Supercomputing Applications (NCSA) at the University of
Illinois at Urbana-Champaign.
This software contains code derived from the RSA Data Security
Inc. MD5 Message-Digest Algorithm, including various
modifications by Spyglass Inc., Carnegie Mellon University, and
Bell Communications Research, Inc (Bellcore).
This software contains code derived from the PCRE library pcreposix.c
source code, written by Philip Hazel, Copyright 1997-2004
by the University of Cambridge, England.
It'd blur the scope of existing holders, but code moves and so do their
contributions. Keeping a banner on a file after a refactor is just
misattribution.
------------------
In short. 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.
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.
(1) can be done without (2) if (2) proves to be "risky" in whatever legal way
it could possibly be risky.
Cheers,
Alejandro
On 28.01.2026 10:09, Alejandro Vallejo wrote: > The refinement also applies to the second bullet point, so I can add it as a > separate paragraph stating existing notices are to never be modified and only > removed with the express consent of the current holder(s). That's interesting, as it may be getting increasingly difficult in practice. Often you can't get hold of the holder(s), to the degree that - as we're all growing older - at some point they may not be there at all anymore. Yet if not having such notices is going to be a goal of the project, retaining some indefinitely can't be the intention either. > Do you have a take for/against moving all existing notices to a separate NOTICES > file (a-la Apache). The existing file for them (in httpd) looks like this, so > they took the liberty to rewording the banners to be more digestible in single > file inclusion. > > Apache HTTP Server > Copyright 2026 The Apache Software Foundation. > > This product includes software developed at > The Apache Software Foundation (https://www.apache.org/). > > Portions of this software were developed at the National Center > for Supercomputing Applications (NCSA) at the University of > Illinois at Urbana-Champaign. > > This software contains code derived from the RSA Data Security > Inc. MD5 Message-Digest Algorithm, including various > modifications by Spyglass Inc., Carnegie Mellon University, and > Bell Communications Research, Inc (Bellcore). > > This software contains code derived from the PCRE library pcreposix.c > source code, written by Philip Hazel, Copyright 1997-2004 > by the University of Cambridge, England. > > It'd blur the scope of existing holders, but code moves and so do their > contributions. Keeping a banner on a file after a refactor is just > misattribution. > > ------------------ > > In short. 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. Likely, once we've agreed on suitable wording. > 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. Very unlikely. While likely I wouldn't veto it, I don't like such moving around of things. If we want to get them out of the source files, they should be dropped altogether. Jan
On Wed Jan 28, 2026 at 11:45 AM CET, Jan Beulich wrote:
> On 28.01.2026 10:09, Alejandro Vallejo wrote:
>> The refinement also applies to the second bullet point, so I can add it as a
>> separate paragraph stating existing notices are to never be modified and only
>> removed with the express consent of the current holder(s).
>
> That's interesting, as it may be getting increasingly difficult in practice.
> Often you can't get hold of the holder(s), to the degree that - as we're all
> growing older - at some point they may not be there at all anymore. Yet if
> not having such notices is going to be a goal of the project, retaining some
> indefinitely can't be the intention either.
Sorry, I missed this part. Many things are unavoidable non-intentions, I'm
afraid. A file might have a notice indefinitely, but that doesn't mean the project
_must_ keep that file indefinitely.
I'd definitely prefer to drop them all. Alas, I don't feel confident enough you
(nor anyone) can legally commit such changes without the holders' approval.
Unless we were to base the rationale on "the notice is already in git history"
or some such. At that point it becomes mandatory to ship the full git tree as
part of a release, which is incompatible with tarball releases. This might
affect downstreams more than upstream, but it's a consideration nonetheless.
It is true that having some already in, with new ones severely restricted
creates asymmetry with prior contributions, but I argue this asymmetry already
exists with banners present for some original contributors, when folks (e.g:
you) have been heavily modifying those files for well over 10y and not added
their name. And if everyone were to add their name we'd have to scroll hundreds
of lines on each file before seeing the first #include.
TL;DR: Yes, some banners are bound to stay unless files were fully rewritten, if
anything because their current holder(s) can refuse to have them removed
or not be available at all.
Cheers,
Alejandro
On Wed, 28 Jan 2026, Alejandro Vallejo wrote: > On Wed Jan 28, 2026 at 11:45 AM CET, Jan Beulich wrote: > > On 28.01.2026 10:09, Alejandro Vallejo wrote: > >> The refinement also applies to the second bullet point, so I can add it as a > >> separate paragraph stating existing notices are to never be modified and only > >> removed with the express consent of the current holder(s). > > > > That's interesting, as it may be getting increasingly difficult in practice. > > Often you can't get hold of the holder(s), to the degree that - as we're all > > growing older - at some point they may not be there at all anymore. Yet if > > not having such notices is going to be a goal of the project, retaining some > > indefinitely can't be the intention either. > > Sorry, I missed this part. Many things are unavoidable non-intentions, I'm > afraid. A file might have a notice indefinitely, but that doesn't mean the project > _must_ keep that file indefinitely. > > I'd definitely prefer to drop them all. Alas, I don't feel confident enough you > (nor anyone) can legally commit such changes without the holders' approval. > Unless we were to base the rationale on "the notice is already in git history" > or some such. At that point it becomes mandatory to ship the full git tree as > part of a release, which is incompatible with tarball releases. This might > affect downstreams more than upstream, but it's a consideration nonetheless. > > It is true that having some already in, with new ones severely restricted > creates asymmetry with prior contributions, but I argue this asymmetry already > exists with banners present for some original contributors, when folks (e.g: > you) have been heavily modifying those files for well over 10y and not added > their name. And if everyone were to add their name we'd have to scroll hundreds > of lines on each file before seeing the first #include. From an engineering perspective I understand the intention of this patch and I myself suggested something similar a while back. However, I later found out that legal systems differ across countries, and copyright law does not function in exactly the same way in the US, UK and the EU. For example, it is not a good idea to remove copyright notices or discourage their use because they carry legal significance in certain jurisdictions, particularly in Europe. Given this, I think we should leave things as they are. Let me clarify what I mean by "copyright notice". For instance, the following: * Copyright (C) 2000 - 2007, R. Byron Moore * All rights reserved. On the other hand, the boilerplate such as: * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT etc. etc. can be removed and replaced with the SPDX tag. There is no controversy there. The SPDX tag refers to the licenses under LICENSES which contain exactly the same text.
On Wed Jan 28, 2026 at 11:45 AM CET, Jan Beulich wrote: > On 28.01.2026 10:09, Alejandro Vallejo wrote: >> The refinement also applies to the second bullet point, so I can add it as a >> separate paragraph stating existing notices are to never be modified and only >> removed with the express consent of the current holder(s). > > That's interesting, as it may be getting increasingly difficult in practice. > Often you can't get hold of the holder(s), to the degree that - as we're all > growing older - at some point they may not be there at all anymore. Yet if > not having such notices is going to be a goal of the project, retaining some > indefinitely can't be the intention either. > >> Do you have a take for/against moving all existing notices to a separate NOTICES >> file (a-la Apache). The existing file for them (in httpd) looks like this, so >> they took the liberty to rewording the banners to be more digestible in single >> file inclusion. >> >> Apache HTTP Server >> Copyright 2026 The Apache Software Foundation. >> >> This product includes software developed at >> The Apache Software Foundation (https://www.apache.org/). >> >> Portions of this software were developed at the National Center >> for Supercomputing Applications (NCSA) at the University of >> Illinois at Urbana-Champaign. >> >> This software contains code derived from the RSA Data Security >> Inc. MD5 Message-Digest Algorithm, including various >> modifications by Spyglass Inc., Carnegie Mellon University, and >> Bell Communications Research, Inc (Bellcore). >> >> This software contains code derived from the PCRE library pcreposix.c >> source code, written by Philip Hazel, Copyright 1997-2004 >> by the University of Cambridge, England. >> >> It'd blur the scope of existing holders, but code moves and so do their >> contributions. Keeping a banner on a file after a refactor is just >> misattribution. >> >> ------------------ >> >> In short. 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. > > Likely, once we've agreed on suitable wording. > >> 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. > > Very unlikely. While likely I wouldn't veto it, I don't like such moving around > of things. If we want to get them out of the source files, they should be > dropped altogether. Ack to both, thanks for the input! Cheers, Alejandro
© 2016 - 2026 Red Hat, Inc.