[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Alejandro Vallejo <alejandro.garciavallejo@xxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Wed, 28 Jan 2026 09:10:29 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=PyGjkinb1hyYGCkuldyZbiBsPLybp4MPqlOF3Z9+SZo=; b=XpaG7CGTkL4ZUJqN3/Fp2NKqXLGI3pYdBfKDUiCli0TFa1WtqN7eQ02y1wc3qz/o67oaWS7KU2oe+rBINv0FbweeeruhRyppFXmfn2614OdbHK3Kbimg6z2OPhqfftGCX/e83Idiltk2ON/zO4dP35ISYD6aJt8GXz41OGpOSqKlhIrVqpsDzD/Gf0k5PEOxbDpmGCAuyx92h9X4q3tZGF+uNF9BTxVSNDQCBQnaDnBAA99q4jCrwOwgCHxZR/lo9AWBVMo5t89jHoY7Ypp1H5Sa5/z47a1ncQmvfP+vlvp+Ghp9aknGhpV5J0ZHiorEh1cSKH9MADJpR2LK97au6Q==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=tWbUk1IRZVl8VMdmg5e1l8bMIRq1tJlMnYHabOT127b1qtkthcqSd9COpXlTFmuyXBpS1iPjJ7FDGdIam3TCkAJNnYb3C/C59HFXIZ1TK+idU8zGhBnY+PiPIz7WyQz7PKxh+ZneBBij+dtRI/XpQJVJxI6otOR8+cFWWapqXSFTAy1hNVFIdSoRJb9pXjRWDSh1SIsiZJ68jxgdNbcqdKSGo4OdSInC05pKYL7y76ZqCwPkMGkwvkOsJiZWyNqylz4PRGt09d6JDzG+j9yFc7CdqjPTLd+iZB5gClDTl+NyGYzm7I+Nv1igpxQmQbTRSYBct9ZCAe/OzlOecFaAiA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • Delivery-date: Wed, 28 Jan 2026 08:10:57 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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."

> +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.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.