All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Bradley M. Kuhn" <bkuhn@ebb.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: 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: Sun, 18 Sep 2022 19:00:17 -0700	[thread overview]
Message-ID: <YyfNMcUM+OHn5qi8@ebb.org> (raw)
In-Reply-To: <b4d3d155-e614-2075-8918-3082c42e099f@jilayne.com>

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.

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.

J Lovejoy wrote:
> Can you update the wiki text to remove "SPDX" from the heading and remove
> the sentence stating, "An initiative started in 2017 [1] aims to unify
> licensing information in all files using SPDX tags, this is driven by the
> Linux Foundation."

All of that seems accurate to me.  What part is not accurate?

Splitting the information to talk about copyright and license separately
seems a good idea, but removing accurate explanations doesn't seem like a
good idea to me …

 -- bkuhn

  reply	other threads:[~2022-09-19  2:18 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-06  0:35 [PATCH v2 00/20] btrfs: add fscrypt integration Sweet Tea Dorminy
2022-09-06  0:35 ` [PATCH v2 01/20] fscrypt: expose fscrypt_nokey_name Sweet Tea Dorminy
2022-09-08 13:41   ` Josef Bacik
2022-09-06  0:35 ` [PATCH v2 02/20] fscrypt: add flag allowing partially-encrypted directories Sweet Tea Dorminy
2022-09-08 13:43   ` Josef Bacik
2022-09-12  1:42   ` Eric Biggers
2022-09-15 18:58     ` Sweet Tea Dorminy
2022-09-13 10:07   ` Anand Jain
2022-09-13 11:02     ` Neal Gompa
2022-09-06  0:35 ` [PATCH v2 03/20] fscrypt: add fscrypt_have_same_policy() to check inode compatibility Sweet Tea Dorminy
2022-09-08 13:53   ` Josef Bacik
2022-09-06  0:35 ` [PATCH v2 04/20] fscrypt: allow fscrypt_generate_iv() to distinguish filenames Sweet Tea Dorminy
2022-09-08 14:01   ` Josef Bacik
2022-09-06  0:35 ` [PATCH v2 05/20] fscrypt: add extent-based encryption Sweet Tea Dorminy
2022-09-07 19:59   ` Omar Sandoval
2022-09-08 15:33   ` Josef Bacik
2022-09-10 18:53   ` kernel test robot
2022-09-12  1:34   ` Eric Biggers
2022-09-06  0:35 ` [PATCH v2 06/20] fscrypt: document btrfs' fscrypt quirks Sweet Tea Dorminy
2022-09-08 15:34   ` Josef Bacik
2022-09-06  0:35 ` [PATCH v2 07/20] btrfs: store directory's encryption state Sweet Tea Dorminy
2022-09-08 15:37   ` Josef Bacik
2022-09-06  0:35 ` [PATCH v2 08/20] btrfs: use fscrypt_names instead of name/len everywhere Sweet Tea Dorminy
2022-09-07 20:04   ` David Sterba
2022-09-06  0:35 ` [PATCH v2 09/20] btrfs: setup fscrypt_names from dentrys using helper Sweet Tea Dorminy
2022-09-08 19:11   ` Josef Bacik
2022-09-06  0:35 ` [PATCH v2 10/20] btrfs: factor a fscrypt_name matching method Sweet Tea Dorminy
2022-09-08 19:27   ` Josef Bacik
2022-09-09 10:15   ` David Sterba
2022-09-09 13:00     ` Christoph Hellwig
2022-09-09 13:34       ` David Sterba
2022-09-16 22:18         ` J Lovejoy
2022-09-19  2:00           ` Bradley M. Kuhn [this message]
2022-09-19 17:20             ` David Sterba
2022-09-19 16:52           ` David Sterba
2022-09-09 13:41       ` Chris Mason
2022-09-06  0:35 ` [PATCH v2 11/20] btrfs: disable various operations on encrypted inodes Sweet Tea Dorminy
2022-09-06  6:36   ` kernel test robot
2022-09-07 20:11   ` David Sterba
2022-09-06  0:35 ` [PATCH v2 12/20] btrfs: start using fscrypt hooks Sweet Tea Dorminy
2022-09-07 20:17   ` David Sterba
2022-09-07 20:42     ` Sweet Tea Dorminy
2022-09-12  1:50       ` Eric Biggers
2022-09-08 19:42   ` Josef Bacik
2022-09-06  0:35 ` [PATCH v2 13/20] btrfs: add fscrypt_context items Sweet Tea Dorminy
2022-09-07 20:43   ` David Sterba
2022-09-08 20:06   ` Josef Bacik
2022-09-06  0:35 ` [PATCH v2 14/20] btrfs: translate btrfs encryption flags and encrypted inode flag Sweet Tea Dorminy
2022-09-08 20:07   ` Josef Bacik
2022-09-06  0:35 ` [PATCH v2 15/20] btrfs: store a fscrypt extent context per normal file extent Sweet Tea Dorminy
2022-09-07 21:10   ` David Sterba
2022-09-07 21:39     ` Sweet Tea Dorminy
2022-09-09 10:04       ` David Sterba
2022-09-06  0:35 ` [PATCH v2 16/20] btrfs: Add new FEATURE_INCOMPAT_FSCRYPT feature flag Sweet Tea Dorminy
2022-09-09 11:35   ` David Sterba
2022-09-12  1:36   ` Eric Biggers
2022-09-06  0:35 ` [PATCH v2 17/20] btrfs: reuse encrypted filename hash when possible Sweet Tea Dorminy
2022-09-07 21:24   ` David Sterba
2022-09-06  0:35 ` [PATCH v2 18/20] btrfs: adapt directory read and lookup to potentially encrypted filenames Sweet Tea Dorminy
2022-09-08 20:15   ` Josef Bacik
2022-09-06  0:35 ` [PATCH v2 19/20] btrfs: encrypt normal file extent data if appropriate Sweet Tea Dorminy
2022-09-08 20:19   ` Josef Bacik
2022-09-06  0:35 ` [PATCH v2 20/20] btrfs: implement fscrypt ioctls Sweet Tea Dorminy
2022-09-07 21:33   ` David Sterba
2022-09-06 22:35 ` [PATCH v2 00/20] btrfs: add fscrypt integration Eric Biggers
2022-09-06 23:01   ` Sweet Tea Dorminy
2022-09-06 23:10     ` Eric Biggers
2022-09-07  0:01       ` Sweet Tea Dorminy
2022-09-07 19:38 ` David Sterba

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=YyfNMcUM+OHn5qi8@ebb.org \
    --to=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.