Re: [PATCH v2 10/20] btrfs: factor a fscrypt_name matching method

On Sun, Sep 18, 2022 at 07:00:17PM -0700, Bradley M. Kuhn wrote:
> Regarding
> https://btrfs.wiki.kernel.org/index.php/Developer%27s_FAQ#Copyright_notices_in_files.2C_SPDX
> 
> On Fri, Sep 09, 2022 at 06:00:13AM -0700, Christoph Hellwig wrote:
> 
> > > > The wiki is incorrect.  The SPDX tag deals with the licensing tags
> > > > only.  It is not a replacement for the copyright notice in any way, and
> > > > having been involved with Copyright enforcement I can tell you that at
> > > > least in some jurisdictions Copytight notices absolutely do matter.
> 
> This is a very good point.

I've expanded the page hopefully correcting the confusion. It has 3
sections, about spdx, about copyright and the community perspective.

> The current Wiki page for btrfs (linked above) says:
> > There's no need to put the copyright notices in individual files that are
> > new, renamed or split.
> …
> > Note that removing the copyright from existing files is not trivial and
> > would require asking the original authors or current copyright holders. The
> > status will be inconsistent but at least new contributions won't continue
> > adding new ones. The current licensing practices are believed to be
> > sufficient.
> 
> This is admittedly a very tough problem to solve.  Nevertheless, the concern
> that I have with that recommendation above is that it gives copyright holders
> whose notices are grandfathered an additional notice preservation that new
> copyright holders don't have equal access to.  It's particular problematic
> because new contributors are unable to have contributions included unless
> they remove copyright notices.
>
> Again, I realize the trade-offs are really tough here; removing existing
> copyright notices without explicit permission is a *serious* problem (both a
> GPL violation and a statutory violation of copyright generally in many
> jurisdictions).  OTOH, a list of every last copyright holder is painfully
> unwieldy — even if you combine it into a single location.
> 
> Most importantly, I want to point out the bigger, implicit trade-off here
> that some may not realize.  If you relying on Git history to have copyright
> notice information, it does make the entire Git repository a required part of
> the complete, corresponding source under GPLv2.  This will become even more
> certain when contributors are being told that they may *not* include a
> copyright notice and that their copyright information will appear in metadata
> instead.  They can reasonably interpret the “appropriately publish on each
> copy an appropriate copyright notice” in GPLv2§1 to mean the copyright
> notices in the Git metadata.

Thanks for the reply.  Oh well, so we basically don't have good options.