[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, 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.



 


Rackspace

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