|
[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
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |