From: David Sterba <dsterba@suse.cz>
To: "Bradley M. Kuhn" <bkuhn@ebb.org>
Cc: Christoph Hellwig <hch@infradead.org>,
linux-btrfs@vger.kernel.org, linux-spdx@vger.kernel.org,
linux-fscrypt@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH v2 10/20] btrfs: factor a fscrypt_name matching method
Date: Mon, 19 Sep 2022 19:20:40 +0200 [thread overview]
Message-ID: <20220919172040.GS32411@twin.jikos.cz> (raw)
In-Reply-To: <YyfNMcUM+OHn5qi8@ebb.org>
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.
next prev parent reply other threads:[~2022-09-19 17:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1662420176.git.sweettea-kernel@dorminy.me>
[not found] ` <685c8abce7bdb110bc306752314b4fb0e7867290.1662420176.git.sweettea-kernel@dorminy.me>
[not found] ` <20220909101521.GS32411@twin.jikos.cz>
2022-09-09 13:00 ` [PATCH v2 10/20] btrfs: factor a fscrypt_name matching method Christoph Hellwig
2022-09-09 13:34 ` David Sterba
2022-09-16 22:18 ` J Lovejoy
2022-09-19 2:00 ` Bradley M. Kuhn
2022-09-19 17:20 ` David Sterba [this message]
2022-09-19 16:52 ` David Sterba
2022-09-09 13:41 ` Chris Mason
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=20220919172040.GS32411@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=bkuhn@ebb.org \
--cc=hch@infradead.org \
--cc=kernel-team@fb.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-spdx@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).