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

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

[Christoph Hellwig]

On Fri, Sep 09, 2022 at 12:15:21PM +0200, David Sterba wrote:
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2020 Facebook
> > + */
> 
> Please use only SPDX in new files
> 
> https://btrfs.wiki.kernel.org/index.php/Developer%27s_FAQ#Copyright_notices_in_files.2C_SPDX

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.

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

[David Sterba]

On Fri, Sep 09, 2022 at 06:00:13AM -0700, Christoph Hellwig wrote:
> On Fri, Sep 09, 2022 at 12:15:21PM +0200, David Sterba wrote:
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * Copyright (C) 2020 Facebook
> > > + */
> > 
> > Please use only SPDX in new files
> > 
> > https://btrfs.wiki.kernel.org/index.php/Developer%27s_FAQ#Copyright_notices_in_files.2C_SPDX
> 
> 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.

I believe you and can update the wiki text so it's more explicit about
the license an copyright.

Otherwise I don't see much point in the copyright notices unless they're
complete list of every person and company that touched that file. With
that we haven't been adding that to new files for some time and I want
to be consistent with that. In each case the patch author was asked to
resubmit without the notice. It worked so far.

If not, either the patch will be respectfully rejected or somebody
else creates the file first and then the patch applied.

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

[Chris Mason]

On 9/9/22 9:00 AM, Christoph Hellwig wrote:
> On Fri, Sep 09, 2022 at 12:15:21PM +0200, David Sterba wrote:
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * Copyright (C) 2020 Facebook
>>> + */
>>
>> Please use only SPDX in new files
>>
>> https://btrfs.wiki.kernel.org/index.php/Developer%27s_FAQ#Copyright_notices_in_files.2C_SPDX
> 
> 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.

I agree, SPDX != copyright, and they should probably be in different 
paragraphs in the wiki because it's misleading as it stands.

Signed-off-by is targeted at declaring that you have permission to put 
this code into this project, which is somewhat different from copyright.

For Meta code, I'm happy to use the git history method.  But, I'm not 
completely comfortable with enforcing that on other companies or 
individuals unless it's common practice elsewhere in the kernel.

-chris

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

[J Lovejoy]

On 9/9/22 7:34 AM, David Sterba wrote:
> On Fri, Sep 09, 2022 at 06:00:13AM -0700, Christoph Hellwig wrote:
>> On Fri, Sep 09, 2022 at 12:15:21PM +0200, David Sterba wrote:
>>>> +// SPDX-License-Identifier: GPL-2.0
>>>> +/*
>>>> + * Copyright (C) 2020 Facebook
>>>> + */
>>> Please use only SPDX in new files
>>>
>>> https://btrfs.wiki.kernel.org/index.php/Developer%27s_FAQ#Copyright_notices_in_files.2C_SPDX
>> 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.
> I believe you and can update the wiki text so it's more explicit about
> the license an copyright.

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."

Thanks,
Jilayne

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

[Bradley M. Kuhn]

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

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

[David Sterba]

On Fri, Sep 16, 2022 at 04:18:47PM -0600, J Lovejoy wrote:
> 
> 
> On 9/9/22 7:34 AM, David Sterba wrote:
> > On Fri, Sep 09, 2022 at 06:00:13AM -0700, Christoph Hellwig wrote:
> >> On Fri, Sep 09, 2022 at 12:15:21PM +0200, David Sterba wrote:
> >>>> +// SPDX-License-Identifier: GPL-2.0
> >>>> +/*
> >>>> + * Copyright (C) 2020 Facebook
> >>>> + */
> >>> Please use only SPDX in new files
> >>>
> >>> https://btrfs.wiki.kernel.org/index.php/Developer%27s_FAQ#Copyright_notices_in_files.2C_SPDX
> >> 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.
> > I believe you and can update the wiki text so it's more explicit about
> > the license an copyright.
> 
> 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."

I can consider that if you tell me why I should do that, but I don't
find anything wrong with the sentence (and I wrote it originally). It's
merely stating that something happened and points to a well known linux
kernel related web site with more details about it.

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

[David Sterba]

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.