From: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>,
"Anthony PERARD" <anthony.perard@vates.tech>,
"Michal Orzel" <michal.orzel@amd.com>,
"Julien Grall" <julien@xen.org>,
"Roger Pau Monné" <roger.pau@citrix.com>,
"Stefano Stabellini" <sstabellini@kernel.org>,
xen-devel@lists.xenproject.org
Subject: Re: [RFC PATCH] CODING_STYLE: Establish a policy with regards to copyright notices
Date: Wed, 28 Jan 2026 12:32:13 +0100 [thread overview]
Message-ID: <DG06TMTPTXUR.79SR3GGH8OHW@amd.com> (raw)
In-Reply-To: <ace6c97f-aeeb-40c9-9c0b-d6ad45fe09d6@suse.com>
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
next prev parent reply other threads:[~2026-01-28 11:32 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-27 18:24 [RFC PATCH] CODING_STYLE: Establish a policy with regards to copyright notices Alejandro Vallejo
2026-01-28 7:04 ` Jan Beulich
2026-01-28 9:09 ` Alejandro Vallejo
2026-01-28 10:45 ` Jan Beulich
2026-01-28 11:14 ` Alejandro Vallejo
2026-01-28 11:32 ` Alejandro Vallejo [this message]
2026-01-28 22:07 ` Stefano Stabellini
2026-01-28 8:10 ` Roger Pau Monné
2026-01-28 9:18 ` Alejandro Vallejo
2026-01-28 9:41 ` Roger Pau Monné
2026-01-28 10:16 ` Alejandro Vallejo
2026-01-28 10:31 ` Roger Pau Monné
2026-01-28 11:13 ` Alejandro Vallejo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DG06TMTPTXUR.79SR3GGH8OHW@amd.com \
--to=alejandro.garciavallejo@amd.com \
--cc=andrew.cooper3@citrix.com \
--cc=anthony.perard@vates.tech \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=michal.orzel@amd.com \
--cc=roger.pau@citrix.com \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.