* Re: [PATCH v2 10/20] btrfs: factor a fscrypt_name matching method [not found] ` <20220909101521.GS32411@twin.jikos.cz> @ 2022-09-09 13:00 ` Christoph Hellwig 2022-09-09 13:34 ` David Sterba 2022-09-09 13:41 ` Chris Mason 0 siblings, 2 replies; 7+ messages in thread From: Christoph Hellwig @ 2022-09-09 13:00 UTC (permalink / raw) To: David Sterba Cc: Sweet Tea Dorminy, Theodore Y. Ts'o, Jaegeuk Kim, Eric Biggers, Chris Mason, Josef Bacik, David Sterba, linux-fscrypt, linux-btrfs, kernel-team, Omar Sandoval, linux-spdx 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2 10/20] btrfs: factor a fscrypt_name matching method 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-09 13:41 ` Chris Mason 1 sibling, 1 reply; 7+ messages in thread From: David Sterba @ 2022-09-09 13:34 UTC (permalink / raw) To: Christoph Hellwig Cc: David Sterba, Sweet Tea Dorminy, Theodore Y. Ts'o, Jaegeuk Kim, Eric Biggers, Chris Mason, Josef Bacik, David Sterba, linux-fscrypt, linux-btrfs, kernel-team, Omar Sandoval, linux-spdx 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2 10/20] btrfs: factor a fscrypt_name matching method 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 16:52 ` David Sterba 0 siblings, 2 replies; 7+ messages in thread From: J Lovejoy @ 2022-09-16 22:18 UTC (permalink / raw) To: dsterba, Christoph Hellwig Cc: Sweet Tea Dorminy, Theodore Y. Ts'o, Jaegeuk Kim, Eric Biggers, Chris Mason, Josef Bacik, David Sterba, linux-fscrypt, linux-btrfs, kernel-team, Omar Sandoval, linux-spdx 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2 10/20] btrfs: factor a fscrypt_name matching method 2022-09-16 22:18 ` J Lovejoy @ 2022-09-19 2:00 ` Bradley M. Kuhn 2022-09-19 17:20 ` David Sterba 2022-09-19 16:52 ` David Sterba 1 sibling, 1 reply; 7+ messages in thread From: Bradley M. Kuhn @ 2022-09-19 2:00 UTC (permalink / raw) To: Christoph Hellwig; +Cc: linux-btrfs, linux-spdx, linux-fscrypt, kernel-team 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2 10/20] btrfs: factor a fscrypt_name matching method 2022-09-19 2:00 ` Bradley M. Kuhn @ 2022-09-19 17:20 ` David Sterba 0 siblings, 0 replies; 7+ messages in thread From: David Sterba @ 2022-09-19 17:20 UTC (permalink / raw) To: Bradley M. Kuhn Cc: Christoph Hellwig, linux-btrfs, linux-spdx, linux-fscrypt, kernel-team 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2 10/20] btrfs: factor a fscrypt_name matching method 2022-09-16 22:18 ` J Lovejoy 2022-09-19 2:00 ` Bradley M. Kuhn @ 2022-09-19 16:52 ` David Sterba 1 sibling, 0 replies; 7+ messages in thread From: David Sterba @ 2022-09-19 16:52 UTC (permalink / raw) To: J Lovejoy Cc: dsterba, Christoph Hellwig, Sweet Tea Dorminy, Theodore Y. Ts'o, Jaegeuk Kim, Eric Biggers, Chris Mason, Josef Bacik, David Sterba, linux-fscrypt, linux-btrfs, kernel-team, Omar Sandoval, linux-spdx 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2 10/20] btrfs: factor a fscrypt_name matching method 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-09 13:41 ` Chris Mason 1 sibling, 0 replies; 7+ messages in thread From: Chris Mason @ 2022-09-09 13:41 UTC (permalink / raw) To: Christoph Hellwig, David Sterba Cc: Sweet Tea Dorminy, Theodore Y. Ts'o, Jaegeuk Kim, Eric Biggers, Josef Bacik, David Sterba, linux-fscrypt, linux-btrfs, kernel-team, Omar Sandoval, linux-spdx 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2022-09-19 17:27 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [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 2022-09-19 16:52 ` David Sterba 2022-09-09 13:41 ` Chris Mason
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 NNTP newsgroup(s).