| Message ID | 20171107020607.GA26910@magnolia (mailing list archive) |
|---|---|
| State | Accepted, archived |
| Headers | show |
NAK, for both the libxfs patch and the kernel one. I wrote the file and it has no copyright header because it conatians trivial, non-copyrightable code. I don't know why people think they can touch license information on files I've written without even asking me. Seems like this happened to various other files as well. Greg: why do you think you can add licensing information to other peoples files without even talking to them? On Mon, Nov 06, 2017 at 06:06:07PM -0800, Darrick J. Wong wrote: > From: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > Source kernel commit: b24413180f5600bcb3bb70fbed5cf186b60864bd > > Many source files in the tree are missing licensing information, which > makes it harder for compliance tools to determine the correct license. > > By default all files without license information are under the default > license of the kernel, which is GPL version 2. > > Update the files which contain no license information with the 'GPL-2.0' > SPDX license identifier. The SPDX identifier is a legally binding > shorthand, which can be used instead of the full boiler plate text. > > This patch is based on work done by Thomas Gleixner and Kate Stewart and > Philippe Ombredanne. > > How this work was done: > > Patches were generated and checked against linux-4.14-rc6 for a subset of > the use cases: > - file had no licensing information it it. > - file was a */uapi/* one with no licensing information in it, > - file was a */uapi/* one with existing licensing information, > > Further patches will be generated in subsequent months to fix up cases > where non-standard license headers were used, and references to license > had to be inferred by heuristics based on keywords. > > The analysis to determine which SPDX License Identifier to be applied to > a file was done in a spreadsheet of side by side results from of the > output of two independent scanners (ScanCode & Windriver) producing SPDX > tag:value files created by Philippe Ombredanne. Philippe prepared the > base worksheet, and did an initial spot review of a few 1000 files. > > The 4.13 kernel was the starting point of the analysis with 60,537 files > assessed. Kate Stewart did a file by file comparison of the scanner > results in the spreadsheet to determine which SPDX license identifier(s) > to be applied to the file. She confirmed any determination that was not > immediately clear with lawyers working with the Linux Foundation. > > Criteria used to select files for SPDX license identifier tagging was: > - Files considered eligible had to be source code files. > - Make and config files were included as candidates if they contained >5 > lines of source > - File already had some variant of a license header in it (even if <5 > lines). > > All documentation files were explicitly excluded. > > The following heuristics were used to determine which SPDX license > identifiers to apply. > > - when both scanners couldn't find any license traces, file was > considered to have no license information in it, and the top level > COPYING file license applied. > > For non */uapi/* files that summary was: > > SPDX license identifier # files > ---------------------------------------------------|------- > GPL-2.0 11139 > > and resulted in the first patch in this series. > > If that file was a */uapi/* path one, it was "GPL-2.0 WITH > Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: > > SPDX license identifier # files > ---------------------------------------------------|------- > GPL-2.0 WITH Linux-syscall-note 930 > > and resulted in the second patch in this series. > > - if a file had some form of licensing information in it, and was one > of the */uapi/* ones, it was denoted with the Linux-syscall-note if > any GPL family license was found in the file or had no licensing in > it (per prior point). Results summary: > > SPDX license identifier # files > ---------------------------------------------------|------ > GPL-2.0 WITH Linux-syscall-note 270 > GPL-2.0+ WITH Linux-syscall-note 169 > ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 > ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 > LGPL-2.1+ WITH Linux-syscall-note 15 > GPL-1.0+ WITH Linux-syscall-note 14 > ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 > LGPL-2.0+ WITH Linux-syscall-note 4 > LGPL-2.1 WITH Linux-syscall-note 3 > ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 > ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 > > and that resulted in the third patch in this series. > > - when the two scanners agreed on the detected license(s), that became > the concluded license(s). > > - when there was disagreement between the two scanners (one detected a > license but the other didn't, or they both detected different > licenses) a manual inspection of the file occurred. > > - In most cases a manual inspection of the information in the file > resulted in a clear resolution of the license that should apply (and > which scanner probably needed to revisit its heuristics). > > - When it was not immediately clear, the license identifier was > confirmed with lawyers working with the Linux Foundation. > > - If there was any question as to the appropriate license identifier, > the file was flagged for further research and to be revisited later > in time. > > In total, over 70 hours of logged manual review was done on the > spreadsheet to determine the SPDX license identifiers to apply to the > source files by Kate, Philippe, Thomas and, in some cases, confirmation > by lawyers working with the Linux Foundation. > > Kate also obtained a third independent scan of the 4.13 code base from > FOSSology, and compared selected files where the other two scanners > disagreed against that SPDX file, to see if there was new insights. The > Windriver scanner is based on an older version of FOSSology in part, so > they are related. > > Thomas did random spot checks in about 500 files from the spreadsheets > for the uapi headers and agreed with SPDX license identifier in the > files he inspected. For the non-uapi files Thomas did random spot checks > in about 15000 files. > > In initial set of patches against 4.14-rc6, 3 files were found to have > copy/paste license identifier errors, and have been fixed to reflect the > correct identifier. > > Additionally Philippe spent 10 hours this week doing a detailed manual > inspection and review of the 12,461 patched files from the initial patch > version early this week with: > - a full scancode scan run, collecting the matched texts, detected > license ids and scores > - reviewing anything where there was a license detected (about 500+ > files) to ensure that the applied SPDX license was correct > - reviewing anything where there was no detection but the patch license > was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied > SPDX license was correct > > This produced a worksheet with 20 files needing minor correction. This > worksheet was then exported into 3 different .csv files for the > different types of files to be modified. > > These .csv files were then reviewed by Greg. Thomas wrote a script to > parse the csv files and add the proper SPDX tag to the file, in the > format that the file expected. This script was further refined by Greg > based on the output to detect more types of files automatically and to > distinguish between header and source .c files (which need different > comment types.) Finally Greg ran the script using the .csv files to > generate the patches. > > Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> > Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> > Reviewed-by: Thomas Gleixner <tglx@linutronix.de> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > --- > libxfs/xfs_cksum.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/libxfs/xfs_cksum.h b/libxfs/xfs_cksum.h > index 8211f48..999a290 100644 > --- a/libxfs/xfs_cksum.h > +++ b/libxfs/xfs_cksum.h > @@ -1,3 +1,4 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > #ifndef _XFS_CKSUM_H > #define _XFS_CKSUM_H 1 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ---end quoted text--- -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Nov 06, 2017 at 11:20:40PM -0800, Christoph Hellwig wrote: > NAK, for both the libxfs patch and the kernel one. What libxfs patch? And what "kernel one" are you referring to here? > I wrote the file and it has no copyright header because it conatians > trivial, non-copyrightable code. What file exactly? And from what I know, there is nothing that is "non-copyrightable". And this isn't changing the copyright of _ANYTHING_ it is just putting the explicit license of the file, on each file in the kernel, because it needs to be tracked. > I don't know why people think they can touch license information on > files I've written without even asking me. Nothing was changed, the license should be the exact same as it was before. But as I don't know what file you are referring to here, it's a bit hard to determine what you are talking about exactly :( thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 7 Nov 2017 08:39:40 +0100 Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > On Mon, Nov 06, 2017 at 11:20:40PM -0800, Christoph Hellwig wrote: > > NAK, for both the libxfs patch and the kernel one. > > What libxfs patch? And what "kernel one" are you referring to here? > > > I wrote the file and it has no copyright header because it conatians > > trivial, non-copyrightable code. > > What file exactly? > > And from what I know, there is nothing that is "non-copyrightable". You'd be wrong on that. Lots of things are not copyrightable. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Nov 07, 2017 at 05:07:44PM +0000, Alan Cox wrote: > On Tue, 7 Nov 2017 08:39:40 +0100 > Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > > On Mon, Nov 06, 2017 at 11:20:40PM -0800, Christoph Hellwig wrote: > > > NAK, for both the libxfs patch and the kernel one. > > > > What libxfs patch? And what "kernel one" are you referring to here? > > > > > I wrote the file and it has no copyright header because it conatians > > > trivial, non-copyrightable code. > > > > What file exactly? > > > > And from what I know, there is nothing that is "non-copyrightable". > > You'd be wrong on that. Lots of things are not copyrightable. Ok, fair enough, but code is not one of those :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Nov 07, 2017 at 08:39:40AM +0100, Greg Kroah-Hartman wrote: > On Mon, Nov 06, 2017 at 11:20:40PM -0800, Christoph Hellwig wrote: > > NAK, for both the libxfs patch and the kernel one. > > What libxfs patch? And what "kernel one" are you referring to here? > > > I wrote the file and it has no copyright header because it conatians > > trivial, non-copyrightable code. > > What file exactly? > > And from what I know, there is nothing that is "non-copyrightable". > > And this isn't changing the copyright of _ANYTHING_ it is just putting > the explicit license of the file, on each file in the kernel, because it > needs to be tracked. > > > I don't know why people think they can touch license information on > > files I've written without even asking me. > > Nothing was changed, the license should be the exact same as it was > before. But as I don't know what file you are referring to here, it's a > bit hard to determine what you are talking about exactly :( fs/xfs/libxfs/xfs_cksum.h --D > > thanks, > > greg k-h > -- > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> > > And from what I know, there is nothing that is "non-copyrightable". > > > > You'd be wrong on that. Lots of things are not copyrightable. > > Ok, fair enough, but code is not one of those :) You'd still be wrong. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Nov 07, 2017 at 09:20:42AM -0800, Darrick J. Wong wrote: > On Tue, Nov 07, 2017 at 08:39:40AM +0100, Greg Kroah-Hartman wrote: > > On Mon, Nov 06, 2017 at 11:20:40PM -0800, Christoph Hellwig wrote: > > > NAK, for both the libxfs patch and the kernel one. > > > > What libxfs patch? And what "kernel one" are you referring to here? > > > > > I wrote the file and it has no copyright header because it conatians > > > trivial, non-copyrightable code. > > > > What file exactly? > > > > And from what I know, there is nothing that is "non-copyrightable". > > > > And this isn't changing the copyright of _ANYTHING_ it is just putting > > the explicit license of the file, on each file in the kernel, because it > > needs to be tracked. > > > > > I don't know why people think they can touch license information on > > > files I've written without even asking me. > > > > Nothing was changed, the license should be the exact same as it was > > before. But as I don't know what file you are referring to here, it's a > > bit hard to determine what you are talking about exactly :( > > fs/xfs/libxfs/xfs_cksum.h Given that it had no license text on it at all, it "defaults" to GPLv2, so the GPLv2 SPDX identifier was added to it. No copyright was changed, nothing at all happened except we explicitly list the license of the file, instead of it being "implicit" before. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Nov 07, 2017 at 05:25:17PM +0000, Alan Cox wrote: > > > > And from what I know, there is nothing that is "non-copyrightable". > > > > > > You'd be wrong on that. Lots of things are not copyrightable. > > > > Ok, fair enough, but code is not one of those :) > > You'd still be wrong. Ok, fine, I don't want to argue nuances, there's lots of exceptions to the rule for stuff like this, let's just say that "most" code is copyrightable and leave it at that :) And that's not what this thread is about, no copyrights got changed at all with this pull request. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> Given that it had no license text on it at all, it "defaults" to GPLv2, > so the GPLv2 SPDX identifier was added to it. > > No copyright was changed, nothing at all happened except we explicitly > list the license of the file, instead of it being "implicit" before. Well if Christoph owns the copyright (if there is one) and he has stated he believes it is too trivial to copyright then it needs an SPDX tag that indicates the rightsholder has stated it's too trivial to copyright and (by estoppel) revoked any right they might have to pursue a claim. I'm sure there's a correct SPDX tag for that ;-) Alan -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Nov 07, 2017 at 06:46:58PM +0000, Alan Cox wrote: > > Given that it had no license text on it at all, it "defaults" to GPLv2, > > so the GPLv2 SPDX identifier was added to it. > > > > No copyright was changed, nothing at all happened except we explicitly > > list the license of the file, instead of it being "implicit" before. > > Well if Christoph owns the copyright (if there is one) and he has stated > he believes it is too trivial to copyright then it needs an SPDX tag that > indicates the rightsholder has stated it's too trivial to copyright and > (by estoppel) revoked any right they might have to pursue a claim. If Cristoph has revoked any right to pursue a claim, then he's also legally given up the right to complain if, say, Bradley Kuhn starting distributing a version with a GPLv3 permission statement --- or if Greg K-H adds a GPLv2 SPDX identifier. :-) - Ted > I'm sure there's a correct SPDX tag for that ;-) > > Alan -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Nov 07, 2017 at 02:15:26PM -0500, Theodore Ts'o wrote: > On Tue, Nov 07, 2017 at 06:46:58PM +0000, Alan Cox wrote: > > > Given that it had no license text on it at all, it "defaults" to GPLv2, > > > so the GPLv2 SPDX identifier was added to it. > > > > > > No copyright was changed, nothing at all happened except we explicitly > > > list the license of the file, instead of it being "implicit" before. > > > > Well if Christoph owns the copyright (if there is one) and he has stated > > he believes it is too trivial to copyright then it needs an SPDX tag that > > indicates the rightsholder has stated it's too trivial to copyright and > > (by estoppel) revoked any right they might have to pursue a claim. > > If Cristoph has revoked any right to pursue a claim, then he's also > legally given up the right to complain if, say, Bradley Kuhn starting > distributing a version with a GPLv3 permission statement --- or if Greg > K-H adds a GPLv2 SPDX identifier. :-) First Christoph really appreciateѕ spelling his name right. Second Christoph really appreciates talking to him when trying to slap on licensing bits on his code. I'm not evil, but I'd really like to understand what you are doing and why, and I might be fairly agreeable if that makes sense. Doing batch annotations of code where you do not the know any of the history of is a receipt for a desaster if we want to use that information anywhere. So Greg, please explain WTF you are trying to do and talk to the people who wrote the code you are "annotating". -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Nov 07, 2017 at 11:28:46AM -0800, Christoph Hellwig wrote: > On Tue, Nov 07, 2017 at 02:15:26PM -0500, Theodore Ts'o wrote: > > On Tue, Nov 07, 2017 at 06:46:58PM +0000, Alan Cox wrote: > > > > Given that it had no license text on it at all, it "defaults" to GPLv2, > > > > so the GPLv2 SPDX identifier was added to it. > > > > > > > > No copyright was changed, nothing at all happened except we explicitly > > > > list the license of the file, instead of it being "implicit" before. > > > > > > Well if Christoph owns the copyright (if there is one) and he has stated > > > he believes it is too trivial to copyright then it needs an SPDX tag that > > > indicates the rightsholder has stated it's too trivial to copyright and > > > (by estoppel) revoked any right they might have to pursue a claim. > > > > If Cristoph has revoked any right to pursue a claim, then he's also > > legally given up the right to complain if, say, Bradley Kuhn starting > > distributing a version with a GPLv3 permission statement --- or if Greg > > K-H adds a GPLv2 SPDX identifier. :-) > > > First Christoph really appreciateѕ spelling his name right. > > Second Christoph really appreciates talking to him when trying to slap > on licensing bits on his code. I'm not evil, but I'd really like to > understand what you are doing and why, and I might be fairly agreeable > if that makes sense. I already described it in the pull request, and in this patch itself, and in this thread already, what is happening, why it was done, and how it was done. I don't know how everyone who was on the original email thread got dropped and the xfs mailing list added, that's just odd... > Doing batch annotations of code where you do not the know any of > the history of is a receipt for a desaster if we want to use that > information anywhere. But we did research the history as well as we could when touching 11k files at a single time. It's been months of research and work, as described in the patch. If we got something wrong, very sorry, not a problem, please, let's put the proper license on the file and all will be good. What file are you concerned about, and what license belongs on it? This patch only touched files without any license header, so again, by default that implied it was GPLv2. Again, no copyright was changed at all. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Nov 07, 2017 at 09:26:48PM +0100, Greg Kroah-Hartman wrote: > On Tue, Nov 07, 2017 at 11:28:46AM -0800, Christoph Hellwig wrote: > > On Tue, Nov 07, 2017 at 02:15:26PM -0500, Theodore Ts'o wrote: > > > On Tue, Nov 07, 2017 at 06:46:58PM +0000, Alan Cox wrote: > > > > > Given that it had no license text on it at all, it "defaults" to GPLv2, > > > > > so the GPLv2 SPDX identifier was added to it. > > > > > > > > > > No copyright was changed, nothing at all happened except we explicitly > > > > > list the license of the file, instead of it being "implicit" before. > > > > > > > > Well if Christoph owns the copyright (if there is one) and he has stated > > > > he believes it is too trivial to copyright then it needs an SPDX tag that > > > > indicates the rightsholder has stated it's too trivial to copyright and > > > > (by estoppel) revoked any right they might have to pursue a claim. > > > > > > If Cristoph has revoked any right to pursue a claim, then he's also > > > legally given up the right to complain if, say, Bradley Kuhn starting > > > distributing a version with a GPLv3 permission statement --- or if Greg > > > K-H adds a GPLv2 SPDX identifier. :-) > > > > > > First Christoph really appreciateѕ spelling his name right. > > > > Second Christoph really appreciates talking to him when trying to slap > > on licensing bits on his code. I'm not evil, but I'd really like to > > understand what you are doing and why, and I might be fairly agreeable > > if that makes sense. > > I already described it in the pull request, and in this patch itself, The upstream commit b24413180f5600 ("License cleanup: add SPDX GPL-2.0 license identifier to files with no license") mentions: Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. We typically have not cared bout this, what has changed for us to want to actually go ahead and do all this work? What happened? It further states: By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. It says a bit about legally binding stuff, that's strong language, however its unclear to me about what it could mean for dual licensed stuff where the goal is for the GPL to apply say on Linux but another license outside of Linux. So what type of legally binding definition was being concocted here, how did such consensus get reached and why did we turn around and decide to embrace it all of a sudden whereas we had not done so before? If you had already described this please let me know, I really tried looking and could not find it on commit b24413180f5600 ("License cleanup: add SPDX GPL-2.0 license identifier to files with no license"), a pointer would help. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Nov 07, 2017 at 10:42:59PM +0100, Luis R. Rodriguez wrote: > On Tue, Nov 07, 2017 at 09:26:48PM +0100, Greg Kroah-Hartman wrote: > > On Tue, Nov 07, 2017 at 11:28:46AM -0800, Christoph Hellwig wrote: > > > On Tue, Nov 07, 2017 at 02:15:26PM -0500, Theodore Ts'o wrote: > > > > On Tue, Nov 07, 2017 at 06:46:58PM +0000, Alan Cox wrote: > > > > > > Given that it had no license text on it at all, it "defaults" to GPLv2, > > > > > > so the GPLv2 SPDX identifier was added to it. > > > > > > > > > > > > No copyright was changed, nothing at all happened except we explicitly > > > > > > list the license of the file, instead of it being "implicit" before. > > > > > > > > > > Well if Christoph owns the copyright (if there is one) and he has stated > > > > > he believes it is too trivial to copyright then it needs an SPDX tag that > > > > > indicates the rightsholder has stated it's too trivial to copyright and > > > > > (by estoppel) revoked any right they might have to pursue a claim. > > > > > > > > If Cristoph has revoked any right to pursue a claim, then he's also > > > > legally given up the right to complain if, say, Bradley Kuhn starting > > > > distributing a version with a GPLv3 permission statement --- or if Greg > > > > K-H adds a GPLv2 SPDX identifier. :-) > > > > > > > > > First Christoph really appreciateѕ spelling his name right. > > > > > > Second Christoph really appreciates talking to him when trying to slap > > > on licensing bits on his code. I'm not evil, but I'd really like to > > > understand what you are doing and why, and I might be fairly agreeable > > > if that makes sense. > > > > I already described it in the pull request, and in this patch itself, > > The upstream commit b24413180f5600 ("License cleanup: add SPDX GPL-2.0 license > identifier to files with no license") mentions: > > Many source files in the tree are missing licensing information, which > makes it harder for compliance tools to determine the correct license. > > We typically have not cared bout this, what has changed for us to want > to actually go ahead and do all this work? Many of us have cared about it for years, and nothing "changed" except the fact that Kate and Thomas and Philippe spent about 10 months doing the real work. This patch was the result of that work. > It further states: > > By default all files without license information are under the default > license of the kernel, which is GPL version 2. > > Update the files which contain no license information with the 'GPL-2.0' > SPDX license identifier. The SPDX identifier is a legally binding > shorthand, which can be used instead of the full boiler plate text. > > It says a bit about legally binding stuff, that's strong language, however its > unclear to me about what it could mean for dual licensed stuff where the goal > is for the GPL to apply say on Linux but another license outside of Linux. That is not the case with these files, so I don't understand your issue. > So what type of legally binding definition was being concocted here, how did such > consensus get reached and why did we turn around and decide to embrace it all > of a sudden whereas we had not done so before? The implicit license of files in the kernel that did not have an explicit license in them is GPLv2, all this patch does is explicitly mark them with that license. It has nothing to do with dual licenses at all. However, follow on patches for some subsystems are adding the correct dual license SPDX identifiers for files that are dual licensed. See the patches in the USB git tree for examples of that in places, if you are curious about how that works with SPDX. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Nov 7, 2017 at 8:28 PM, Christoph Hellwig <hch@infradead.org> wrote: > On Tue, Nov 07, 2017 at 02:15:26PM -0500, Theodore Ts'o wrote: >> On Tue, Nov 07, 2017 at 06:46:58PM +0000, Alan Cox wrote: >> > > Given that it had no license text on it at all, it "defaults" to GPLv2, >> > > so the GPLv2 SPDX identifier was added to it. >> > > >> > > No copyright was changed, nothing at all happened except we explicitly >> > > list the license of the file, instead of it being "implicit" before. >> > >> > Well if Christoph owns the copyright (if there is one) and he has stated >> > he believes it is too trivial to copyright then it needs an SPDX tag that >> > indicates the rightsholder has stated it's too trivial to copyright and >> > (by estoppel) revoked any right they might have to pursue a claim. >> >> If Cristoph has revoked any right to pursue a claim, then he's also >> legally given up the right to complain if, say, Bradley Kuhn starting >> distributing a version with a GPLv3 permission statement --- or if Greg >> K-H adds a GPLv2 SPDX identifier. :-) > > > First Christoph really appreciateѕ spelling his name right. > > Second Christoph really appreciates talking to him when trying to slap > on licensing bits on his code. I'm not evil, but I'd really like to > understand what you are doing and why, and I might be fairly agreeable > if that makes sense. > > Doing batch annotations of code where you do not the know any of > the history of is a receipt for a desaster if we want to use that > information anywhere. > > So Greg, please explain WTF you are trying to do and talk to the > people who wrote the code you are "annotating". Christoph: I am not speaking for Greg but let me highlight some issues and benefits as I chipped in a bit to help: Some data points in the 4.14.rc7 kernel: - there are 64,742 distinct license statements ... in 114,597 blocks of text ... in 42,602 files - license statements represent 480,455 lines of text - licenses are worded in 1,015 different ways - there are about 85 distinct licenses, the bulk being the GPL NB: All of these tallies were computed with scancode-toolkit [1] License text lines represent about 14.7% of all source comments. (using a CLOC to count comment lines) From an engineering perspective this feels to me as pure madness, unless everyone in kernel land is in love with legalese! I like to think of it this way: Licensing is important but repetitive long boilerplate in patches and in every file is just a noisy distraction from the code substance. Imagine if the kernel had 500 versions of a printf() function? Maintainers would refactor the hell of it to use a few functions. Replacing the boilerplate with licensing ids is exactly the same: a sane refactoring to remove duplicated boilerplate. In the end and ideally there should be no more than one line of licensing info per file, so no more than 70Kish: so there are about 400K lines of boilerplate to remove. The benefits now and later: - no distraction with licensing boilerplate cr*p in patches and files - no guessing licensing needed when sending a patch - anyone can grep the kernel tree for licensing, no extra tool needed - Greg must feel really good about deleting so much things for once The downsides: - folks can no longer express their creativity in licensing texts like licensing thermal code under the "therms" of the GPL [2] - legalese lovers need to find another codebase to satisfy their addiction Note also that beside the kernel, U-Boot has adopted the same approach for quite a while, and in the application world the Eclipse Foundation, JavaScript NPMs and Rubygems are some examples that adopted SPDX license ids to simplify and clarify licensing documentation. [1] https://github.com/nexB/scancode-toolkit [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/w1/slaves/w1_therm.c?h=v4.14-rc8#n8
On Wed, Nov 08, 2017 at 01:35:46PM +0100, Philippe Ombredanne wrote: > The benefits now and later: > - no distraction with licensing boilerplate cr*p in patches and files > - no guessing licensing needed when sending a patch > - anyone can grep the kernel tree for licensing, no extra tool needed > - Greg must feel really good about deleting so much things for once This patch didn't delete anything, it added random notes. I see now Greg deletes things from files he maintains which is even worse, given that the kernel tree doesn't document anywhere what these tags actually mean. So he deletes a lot of license tags and replaces them with tags he puts a great significance on, but which aren't defined. A quick googles shows some Linuxfoundation web page defines them, but they could change them any time they want, nevermind that we don't even have a reference to them either. > > The downsides: > - folks can no longer express their creativity in licensing texts like > licensing thermal code under the "therms" of the GPL [2] I'd love something like that to happen. But for that we don't need a sneaky patch that doesn't talk to kernel contributors. For that we need to a) agree on which licensing schemes we accept for future contributions b) cleary document that policy in the kernel tree c) reject anything that doesn't matter the above policy by manual and/or automated review An automated tag scheme might help with b) and c) above if done properly. But for that we need to document it, agree on it, discuss it with everyone involved, etc. None of that has happened. Instead Greg farted arcane tags that he thinks have a legal singnificance all over three three without talking to the people whos code he tagged, without any RFC or public discussion, without documenting what his tags mean or any future strategy towards making use of them. -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> By default all files without license information are under the default > license of the kernel, which is GPL version 2. Which is factually incorrect. They are under a licence that is at least as permissive as GPL v2. However they may be under a more permissive licence and as you are not the rightsholder you don't have the right to relicence them mroe restrictvely. For example I find a reference piece of code whose author says it is 'too trivial to copyright'. I (not the author0 place that code in the kernel. The licence on that code is still 'too trivial to copyright' (by estoppel). That's GPL 2 compliant but it is *NOT* GPL. As anyone can contribute third party code that is GPL compliant legitimately you can't assume any unmarked code is GPL, merely 'at least GPL'. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
And I swear I wrote the previous mail before I read this announcement: https://fsfe.org/news/2017/news-20171108-01.en.html But the actual practices there are pretty much what I'd expect as a start (plus a list of acceptable licenses), they even use the same identifiers as you are adding, but they also back them up with the actual license texts in the source tree, which makes them a whole lot more useful. On Wed, Nov 08, 2017 at 07:11:21AM -0800, Christoph Hellwig wrote: > On Wed, Nov 08, 2017 at 01:35:46PM +0100, Philippe Ombredanne wrote: > > The benefits now and later: > > - no distraction with licensing boilerplate cr*p in patches and files > > - no guessing licensing needed when sending a patch > > - anyone can grep the kernel tree for licensing, no extra tool needed > > - Greg must feel really good about deleting so much things for once > > This patch didn't delete anything, it added random notes. > > I see now Greg deletes things from files he maintains which is even > worse, given that the kernel tree doesn't document anywhere what these > tags actually mean. > > So he deletes a lot of license tags and replaces them with tags he > puts a great significance on, but which aren't defined. A quick googles > shows some Linuxfoundation web page defines them, but they could change > them any time they want, nevermind that we don't even have a reference > to them either. > > > > > The downsides: > > - folks can no longer express their creativity in licensing texts like > > licensing thermal code under the "therms" of the GPL [2] > > I'd love something like that to happen. But for that we don't need a > sneaky patch that doesn't talk to kernel contributors. > > For that we need to > > a) agree on which licensing schemes we accept for future contributions > b) cleary document that policy in the kernel tree > c) reject anything that doesn't matter the above policy by manual > and/or automated review > > An automated tag scheme might help with b) and c) above if done > properly. But for that we need to document it, agree on it, discuss > it with everyone involved, etc. None of that has happened. Instead > Greg farted arcane tags that he thinks have a legal singnificance > all over three three without talking to the people whos code he tagged, > without any RFC or public discussion, without documenting what his > tags mean or any future strategy towards making use of them. ---end quoted text--- -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Nov 07, 2017 at 09:26:48PM +0100, Greg Kroah-Hartman wrote: > On Tue, Nov 07, 2017 at 11:28:46AM -0800, Christoph Hellwig wrote: > > On Tue, Nov 07, 2017 at 02:15:26PM -0500, Theodore Ts'o wrote: > > > On Tue, Nov 07, 2017 at 06:46:58PM +0000, Alan Cox wrote: > > > > > Given that it had no license text on it at all, it "defaults" to GPLv2, > > > > > so the GPLv2 SPDX identifier was added to it. > > > > > > > > > > No copyright was changed, nothing at all happened except we explicitly > > > > > list the license of the file, instead of it being "implicit" before. > > > > > > > > Well if Christoph owns the copyright (if there is one) and he has stated > > > > he believes it is too trivial to copyright then it needs an SPDX tag that > > > > indicates the rightsholder has stated it's too trivial to copyright and > > > > (by estoppel) revoked any right they might have to pursue a claim. > > > > > > If Cristoph has revoked any right to pursue a claim, then he's also > > > legally given up the right to complain if, say, Bradley Kuhn starting > > > distributing a version with a GPLv3 permission statement --- or if Greg > > > K-H adds a GPLv2 SPDX identifier. :-) > > > > > > First Christoph really appreciateѕ spelling his name right. > > > > Second Christoph really appreciates talking to him when trying to slap > > on licensing bits on his code. I'm not evil, but I'd really like to > > understand what you are doing and why, and I might be fairly agreeable > > if that makes sense. > > I already described it in the pull request, and in this patch itself, > and in this thread already, what is happening, why it was done, and how > it was done. I don't know how everyone who was on the original email > thread got dropped and the xfs mailing list added, that's just odd... This thread is a result of regular efforts to keep the xfsprogs libxfs code roughly in-sync with the kernel libxfs code. That's how the xfs mailing is on cc on this thread. That said, it's pretty obvious from Christoph's reaction that nobody emailed Christoph (the original author of xfs_cksum.h) about the original change to the kernel source. Nobody emailed the XFS maintainers for an ack to the kernel change, and nobody cc'd the linux-xfs mailing list as a heads-up. Neither XFS maintainer were invited to the summit where this change was discussed. I always thought the rules in SubmittingPatches[1] existed to facilitate cooperation with Linux subprojects and I strongly protest your decision to ignore us. Had anyone involved us, I would have suggested fixing the whole XFS tree to use the shortened tag instead of each file containing its own mutations of the GPL, and our broader XFS community could have worked with you on this. --D [1] submitting-patches.rst, section 5: 5) Select the recipients for your patch --------------------------------------- You should always copy the appropriate subsystem maintainer(s) on any patch to code that they maintain; look through the MAINTAINERS file and the source code revision history to see who those maintainers are. The script scripts/get_maintainer.pl can be very useful at this step. If you cannot find a maintainer for the subsystem you are working on, Andrew Morton (akpm@linux-foundation.org) serves as a maintainer of last resort. > > Doing batch annotations of code where you do not the know any of > > the history of is a receipt for a desaster if we want to use that > > information anywhere. > > But we did research the history as well as we could when touching 11k > files at a single time. It's been months of research and work, as > described in the patch. > > If we got something wrong, very sorry, not a problem, please, let's put > the proper license on the file and all will be good. What file are you > concerned about, and what license belongs on it? This patch only > touched files without any license header, so again, by default that > implied it was GPLv2. Again, no copyright was changed at all. > > thanks, > > greg k-h > -- > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Nov 07, 2017 at 07:29:03PM +0100, Greg Kroah-Hartman wrote: > On Tue, Nov 07, 2017 at 09:20:42AM -0800, Darrick J. Wong wrote: > > On Tue, Nov 07, 2017 at 08:39:40AM +0100, Greg Kroah-Hartman wrote: > > > On Mon, Nov 06, 2017 at 11:20:40PM -0800, Christoph Hellwig wrote: > > > > NAK, for both the libxfs patch and the kernel one. > > > > > > What libxfs patch? And what "kernel one" are you referring to here? > > > > > > > I wrote the file and it has no copyright header because it conatians > > > > trivial, non-copyrightable code. > > > > > > What file exactly? > > > > > > And from what I know, there is nothing that is "non-copyrightable". > > > > > > And this isn't changing the copyright of _ANYTHING_ it is just putting > > > the explicit license of the file, on each file in the kernel, because it > > > needs to be tracked. > > > > > > > I don't know why people think they can touch license information on > > > > files I've written without even asking me. > > > > > > Nothing was changed, the license should be the exact same as it was > > > before. But as I don't know what file you are referring to here, it's a > > > bit hard to determine what you are talking about exactly :( > > > > fs/xfs/libxfs/xfs_cksum.h > > Given that it had no license text on it at all, it "defaults" to GPLv2, > so the GPLv2 SPDX identifier was added to it. I'll point out here that this file is shared with a userspace package that has a mixed LGPL/GPL code base, so even if we disregard what Christoph says, this file could actually be LGPL (like fs/xfs/libxfs/xfs_fs.h) and not GPL. So from that perspective alone, your process on deciding what license tag should be used is flawed and these changes needed, at minimum, maintainer review. IMO, unannounced, unreviewed tree wide change via a back-door commits sent straight to Linus reek of an attempt to avoid review and oversight. And that is *completely unacceptible* when making claims about important details like licenses for *code you do not know anything about*. We have a documented process for a reason: to stop shit like this from happening. > No copyright was changed, nothing at all happened except we explicitly > list the license of the file, instead of it being "implicit" before. You keep saying "no copyright has changed", despite being given an explicit statement by the code author that this is *exactly what you have done*. Cheers, Dave.
On Thu, Nov 09, 2017 at 10:47:04AM +1100, Dave Chinner wrote: > On Tue, Nov 07, 2017 at 07:29:03PM +0100, Greg Kroah-Hartman wrote: > > On Tue, Nov 07, 2017 at 09:20:42AM -0800, Darrick J. Wong wrote: > > > On Tue, Nov 07, 2017 at 08:39:40AM +0100, Greg Kroah-Hartman wrote: > > > > On Mon, Nov 06, 2017 at 11:20:40PM -0800, Christoph Hellwig wrote: > > > > > NAK, for both the libxfs patch and the kernel one. > > > > > > > > What libxfs patch? And what "kernel one" are you referring to here? > > > > > > > > > I wrote the file and it has no copyright header because it conatians > > > > > trivial, non-copyrightable code. > > > > > > > > What file exactly? > > > > > > > > And from what I know, there is nothing that is "non-copyrightable". > > > > > > > > And this isn't changing the copyright of _ANYTHING_ it is just putting > > > > the explicit license of the file, on each file in the kernel, because it > > > > needs to be tracked. > > > > > > > > > I don't know why people think they can touch license information on > > > > > files I've written without even asking me. > > > > > > > > Nothing was changed, the license should be the exact same as it was > > > > before. But as I don't know what file you are referring to here, it's a > > > > bit hard to determine what you are talking about exactly :( > > > > > > fs/xfs/libxfs/xfs_cksum.h > > > > Given that it had no license text on it at all, it "defaults" to GPLv2, > > so the GPLv2 SPDX identifier was added to it. > > I'll point out here that this file is shared with a userspace > package that has a mixed LGPL/GPL code base, so even if we disregard > what Christoph says, this file could actually be LGPL (like > fs/xfs/libxfs/xfs_fs.h) and not GPL. So from that perspective alone, > your process on deciding what license tag should be used is > flawed and these changes needed, at minimum, maintainer review. > > IMO, unannounced, unreviewed tree wide change via a back-door > commits sent straight to Linus reek of an attempt to avoid review > and oversight. This was not unannounced, it was posted to lkml and discussed at the kernel summit ahead of time. > And that is *completely unacceptible* when making claims about > important details like licenses for *code you do not know anything > about*. When a file does not have a license, again, all lawyers I have worked with said it is implicitly GPLv2, so we did the best we knew how at the time. If we got a few files wrong, please fix them up, I hit 11k files at once here. And how an internal file is shared with userspace is, to be fair, completely strange, you have to agree :) > We have a documented process for a reason: to stop shit like this > from happening. > > > No copyright was changed, nothing at all happened except we explicitly > > list the license of the file, instead of it being "implicit" before. > > You keep saying "no copyright has changed", despite being given an > explicit statement by the code author that this is *exactly what you > have done*. Again, no, the copyright was not changed. Whom ever held the original copyright still holds it today. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Nov 08, 2017 at 10:46:15AM -0800, Darrick J. Wong wrote: > Had anyone involved us, I would have suggested fixing the whole XFS tree > to use the shortened tag instead of each file containing its own > mutations of the GPL, and our broader XFS community could have worked > with you on this. Great, I'll gladly send you a patchset to do this, what tree do you want me to base it against? Note, all this original patchset did was hit the 11k files in the tree with no license text in it at all. That required a tree-wide change to resolve everything at once. Unification of the way we describe licenses in individual files will go on a subsystem-by-subsystem basis. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Nov 08, 2017 at 07:11:21AM -0800, Christoph Hellwig wrote: > On Wed, Nov 08, 2017 at 01:35:46PM +0100, Philippe Ombredanne wrote: > > The benefits now and later: > > - no distraction with licensing boilerplate cr*p in patches and files > > - no guessing licensing needed when sending a patch > > - anyone can grep the kernel tree for licensing, no extra tool needed > > - Greg must feel really good about deleting so much things for once > > This patch didn't delete anything, it added random notes. > > I see now Greg deletes things from files he maintains which is even > worse, given that the kernel tree doesn't document anywhere what these > tags actually mean. The documentation of this process is lagging the patches, as usually happens, sorry about that. Thomas is working on a document to describe the process, and what a file should contain, based on the work he has been doing. This was discussed at the kernel summit, and sorry for it not getting out wider than that audience, things take time, which is why I was only touching my subsystems with the "general license cleanups" at the moment until his document was ready. Hopefully a draft of it will go out today, Thomas? > So he deletes a lot of license tags and replaces them with tags he > puts a great significance on, but which aren't defined. A quick googles > shows some Linuxfoundation web page defines them, but they could change > them any time they want, nevermind that we don't even have a reference > to them either. SPDX is an industry-wide accepted set of tags for all licenses, some projects have been using it for years (like Uboot). These are not going to change randomly, and again, the document that Thomas has will describe these in detail. sorry for the confusion, it was not intended at all, but it what happens in time with distributed developers, all working at different rates on different parts of the tree. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Nov 09, 2017 at 09:23:35AM +0100, Greg Kroah-Hartman wrote: > The documentation of this process is lagging the patches, as usually > happens, sorry about that. In cases like this the documentation is the most important part. Without documentation it is completely pointless. > > Thomas is working on a document to describe the process, and what a file > should contain, based on the work he has been doing. This was discussed > at the kernel summit, and sorry for it not getting out wider than that > audience, things take time, which is why I was only touching my > subsystems with the "general license cleanups" at the moment until his > document was ready. > > Hopefully a draft of it will go out today, Thomas? It would help to Cc him, I've done that. > SPDX is an industry-wide accepted set of tags for all licenses, some > projects have been using it for years (like Uboot). These are not going > to change randomly, and again, the document that Thomas has will > describe these in detail. It is not an 'industry-wide accepted set of tags' (did you get a company discount on buzzwords). Yes, it it a scheme someone can up with (seems like an industry consortium that happens to employ you, what a coincidence), and from a quick look it even seems like a pretty reasonable scheme. But without backing it with an explanation of those tags in the tree, and explaining people how to use them and how they are relevant it is absolutely useless. And to come up with a scheme we need to have a broad discussion on what we are doing. > sorry for the confusion, it was not intended at all, but it what happens > in time with distributed developers, all working at different rates on > different parts of the tree. Sorry but I call bullshit on this. We have absolutely no problem working together if we try. You clearly did not even try to cooperate with anyone - the clear indicator is that no RFC was posted, no questions were asked but you just sent a pull requests right before the end of the merge window. -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> When a file does not have a license, again, all lawyers I have worked > with said it is implicitly GPLv2 I am surprised that they did not immediately see the fact that since the code contributor was not neccessarily the rights holder you could make no assumption as to the actual licencing beyond it being GPL compatible (or having a right to sue whoever put it there). Did you explain the contribution process sufficiently clearly ? > Again, no, the copyright was not changed. Whom ever held the original > copyright still holds it today. On the contrary if it was implicitly LGPL you've just exercised the right to make it GPL and messed it up for others. In the other cases your error is probably legally actionable in certain jurisdictions if someone was so unpleasantly minded. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue 2017-11-07 14:15:26, Theodore Ts'o wrote: > On Tue, Nov 07, 2017 at 06:46:58PM +0000, Alan Cox wrote: > > > Given that it had no license text on it at all, it "defaults" to GPLv2, > > > so the GPLv2 SPDX identifier was added to it. > > > > > > No copyright was changed, nothing at all happened except we explicitly > > > list the license of the file, instead of it being "implicit" before. > > > > Well if Christoph owns the copyright (if there is one) and he has stated > > he believes it is too trivial to copyright then it needs an SPDX tag that > > indicates the rightsholder has stated it's too trivial to copyright and > > (by estoppel) revoked any right they might have to pursue a claim. > > If Cristoph has revoked any right to pursue a claim, then he's also > legally given up the right to complain if, say, Bradley Kuhn starting > distributing a version with a GPLv3 permission statement --- or if Greg > K-H adds a GPLv2 SPDX identifier. :-) Yes, maybe Greg can legaly do that. That does not make it good idea... and we have higher standards than "not illegal in most countries" :-). Pavel
Hi! > Christoph: > > I am not speaking for Greg but let me highlight some issues and > benefits as I chipped in a bit to help: > > Some data points in the 4.14.rc7 kernel: > - there are 64,742 distinct license statements > ... in 114,597 blocks of text > ... in 42,602 files > - license statements represent 480,455 lines of text > - licenses are worded in 1,015 different ways > - there are about 85 distinct licenses, the bulk being the GPL > > NB: All of these tallies were computed with scancode-toolkit [1] > > License text lines represent about 14.7% of all source comments. > (using a CLOC to count comment lines) > > >From an engineering perspective this feels to me as pure madness, > unless everyone in kernel land is in love with legalese! > > I like to think of it this way: > > Licensing is important but repetitive long boilerplate in patches and > in every file is just a noisy distraction from the code substance. > > Imagine if the kernel had 500 versions of a printf() function? > Maintainers would refactor the hell of it to use a few functions. > > Replacing the boilerplate with licensing ids is exactly the same: > a sane refactoring to remove duplicated boilerplate. > > In the end and ideally there should be no more than one line of > licensing info per file, so no more than 70Kish: so there are > about 400K lines of boilerplate to remove. > > The benefits now and later: > - no distraction with licensing boilerplate cr*p in patches and files Well... No distraction you say? > Note also that beside the kernel, U-Boot has adopted the same > approach for quite a while, and in the application world the Eclipse Yes, it works nicely for U-Boot. But someone actually _added_ distraction. Top-level Makefile had no distraction there and boom, here it is, totally uninteresting and just at line one. Lets look at random file in usb: // SPDX-License-Identifier: GPL-2.0+ /* * Driver for SMSC USB3503 USB 2.0 hub controller driver * * Copyright (c) 2012-2013 Dongjin Kim (tobetter@gmail.com) */ ... MODULE_LICENSE("GPL"); ...do we agree that this is nowhere near distration-free? Ugly // comment that screams for attention, away from other copyright info, it hurts your eyes... This would be improvement: /* * Driver for SMSC USB3503 USB 2.0 hub controller driver * * Copyright (c) 2012-2013 Dongjin Kim (tobetter@gmail.com) * * SPDX-License-Identifier: GPL-2.0+ */ ...but what is above is just uuuugly. ...as is MODULE_LICENSE having completely different tags from SPDX. This would be even better: /* * Driver for SMSC USB3503 USB 2.0 hub controller driver * * Copyright (c) 2012-2013 Dongjin Kim (tobetter@gmail.com) */ ... SPDX_MODULE_LICENSE("GPL-2.0+") So yes, SPDX can be improvement. But in current implementation it is not. Pavel
On Wed, Nov 22, 2017 at 06:07:13PM +0100, Pavel Machek wrote: > Lets look at random file in usb: > > // SPDX-License-Identifier: GPL-2.0+ > /* > * Driver for SMSC USB3503 USB 2.0 hub controller driver > * > * Copyright (c) 2012-2013 Dongjin Kim (tobetter@gmail.com) > */ > ... > MODULE_LICENSE("GPL"); > > ...do we agree that this is nowhere near distration-free? Ugly // > comment that screams for attention, away from other copyright info, it > hurts your eyes... > > This would be improvement: > > /* > * Driver for SMSC USB3503 USB 2.0 hub controller driver > * > * Copyright (c) 2012-2013 Dongjin Kim (tobetter@gmail.com) > * > * SPDX-License-Identifier: GPL-2.0+ > */ > > ...but what is above is just uuuugly. > > ...as is MODULE_LICENSE having completely different tags from SPDX. > > This would be even better: > > /* > * Driver for SMSC USB3503 USB 2.0 hub controller driver > * > * Copyright (c) 2012-2013 Dongjin Kim (tobetter@gmail.com) > */ > ... > SPDX_MODULE_LICENSE("GPL-2.0+") > > So yes, SPDX can be improvement. But in current implementation it is > not. Again, as people seem to keep still missing this point, Linus asked for the format to look like it does today, using // at the top. Thomas and I originally did it first the way with the SPDX line in the big comment block. If you don't like the format, complain and convince him otherwise, you are not getting anywhere by responding to this old topic about it again. Having it be the first line of the file is good, it's obvious, and stands out, which is the point, you want it to, it's a license :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi! > > This would be even better: > > > > /* > > * Driver for SMSC USB3503 USB 2.0 hub controller driver > > * > > * Copyright (c) 2012-2013 Dongjin Kim (tobetter@gmail.com) > > */ > > ... > > SPDX_MODULE_LICENSE("GPL-2.0+") > > > > So yes, SPDX can be improvement. But in current implementation it is > > not. > > Again, as people seem to keep still missing this point, Linus asked for > the format to look like it does today, using // at the top. Thomas and > I originally did it first the way with the SPDX line in the big comment > block. > > If you don't like the format, complain and convince him otherwise, you > are not getting anywhere by responding to this old topic about it > again. Hey, Linus. This // SPDX at the begining of file looks really ugly. Can we get something that looks less bad? And BTW I responded to this uglyness before, but you just tried to make me shut up, and then did not reply. Given what quality you normally expect from patch submitters, you are doing pretty poor job here. > Having it be the first line of the file is good, it's obvious, and > stands out, which is the point, you want it to, it's a license :) What is good about that? License is about the least interesting thing about the file. Point of SPDX conversion (see the mail I was replying to?) was to make license information _less_ intrusive, not more. Tools can find SPDX anywhere in the file for the people that really care. That's how it works in U-Boot, which people are using as example of reasonable SPDX conversion: /* * Copyright (c) 2012 The Chromium OS Authors. All rights reserved. * Copyright (c) 2010-2011 NVIDIA Corporation * NVIDIA Corporation <www.nvidia.com> * * SPDX-License-Identifier: GPL-2.0+ */ Pavel
On Sat, 2017-11-25 at 20:12 +0100, Pavel Machek wrote: > [Linus Torvalds...] > > Having it be the first line of the file is good, it's obvious, and > > stands out, which is the point, you want it to, it's a license :) > > What is good about that? License is about the least interesting thing > about the file. Point of SPDX conversion (see the mail I was replying > to?) was to make license information _less_ intrusive, not more. Tools > can find SPDX anywhere in the file for the people that really care. > > That's how it works in U-Boot, which people are using as example of > reasonable SPDX conversion: > > /* > * Copyright (c) 2012 The Chromium OS Authors. All rights reserved. > * Copyright (c) 2010-2011 NVIDIA Corporation > * NVIDIA Corporation <www.nvidia.com> > * > * SPDX-License-ers/ d > .c: GPL-2.0+ > */ fwiw: I agree with Pavel. My preferred header listing order: // Simple description/purpose // Copyright/Author // License -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Nov 25, 2017 at 08:12:23PM +0100, Pavel Machek wrote: > Hi! > > > > This would be even better: > > > > > > /* > > > * Driver for SMSC USB3503 USB 2.0 hub controller driver > > > * > > > * Copyright (c) 2012-2013 Dongjin Kim (tobetter@gmail.com) > > > */ > > > ... > > > SPDX_MODULE_LICENSE("GPL-2.0+") > > > > > > So yes, SPDX can be improvement. But in current implementation it is > > > not. > > > > Again, as people seem to keep still missing this point, Linus asked for > > the format to look like it does today, using // at the top. Thomas and > > I originally did it first the way with the SPDX line in the big comment > > block. > > > > If you don't like the format, complain and convince him otherwise, you > > are not getting anywhere by responding to this old topic about it > > again. > > Hey, Linus. This // SPDX at the begining of file looks really > ugly. Can we get something that looks less bad? > > And BTW I responded to this uglyness before, but you just tried to > make me shut up, and then did not reply. Given what quality you > normally expect from patch submitters, you are doing pretty poor job > here. > > > Having it be the first line of the file is good, it's obvious, and > > stands out, which is the point, you want it to, it's a license :) > > What is good about that? License is about the least interesting thing > about the file. Point of SPDX conversion (see the mail I was replying > to?) was to make license information _less_ intrusive, not more. Tools > can find SPDX anywhere in the file for the people that really care. > > That's how it works in U-Boot, which people are using as example of > reasonable SPDX conversion: > > /* > * Copyright (c) 2012 The Chromium OS Authors. All rights reserved. > * Copyright (c) 2010-2011 NVIDIA Corporation > * NVIDIA Corporation <www.nvidia.com> > * > * SPDX-License-Identifier: GPL-2.0+ > */ Agree. If/when anyone /does/ get to SPDX'ing the xfs files that already have a comment blob at the top, this is my preferred format for doing that. (versus having a sole //-style comment right before a multiline comment) --D > > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/libxfs/xfs_cksum.h b/libxfs/xfs_cksum.h index 8211f48..999a290 100644 --- a/libxfs/xfs_cksum.h +++ b/libxfs/xfs_cksum.h @@ -1,3 +1,4 @@ +/* SPDX-License-Identifier: GPL-2.0 */ #ifndef _XFS_CKSUM_H #define _XFS_CKSUM_H 1