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

David Sterba
2022-09-19T17:27:04Z

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.