Jilayne, J Lovejoy <opensource@xxxxxxxxxxx> writes: >> On May 22, 2019, at 3:10 PM, John Sullivan <johns@xxxxxxx> wrote: >> >> J Lovejoy <opensource@xxxxxxxxxxx> writes: >> >>> Richard, >>> >>> As you raised this concern and yet I’m noticing you continue to review >>> the patches and sign off, am I correct to assume that you don’t think >>> this is a big concern? >>> >> >> I was late to subscribe and am just catching up on the conversation >> here, so apologies if I missed earlier explanation, but I remember >> discussing this issue a while back on either -legal or -general (I'll >> look when I have a few more moments). On https://spdx.org/ids-how it >> currently says: >> >>> When a license defines a recommended notice to attach to files under >>> that license (sometimes called a "standard header"), the SPDX project >>> recommends that the standard header be included in the files, in >>> addition to an SPDX ID. >> >>> Additionally, when a file already contains a standard header or other >>> license notice, the SPDX project recommends that those existing notices >>> should not be removed. The SPDX ID is recommended to be used to >>> supplement, not replace, existing notices in files. >> >>> Like copyright notices, existing license texts and notices should be >>> retained, not replaced ‐ especially a third party's license notices. >> >> - > > John, > > that text is from the SPDX website and is very generalized, > conservative and non-contextual. The reality we live in today is that > people are choosing to use the SPDX identifiers in their files instead > of the full license text (for MIT) or the standard license notice (for > Apache-2.0 or GPL), etc. - this is good because SPDX identifiers are > more concise and easier for tooling to parse. Even when there is a > standard license header recommended, like the GPL has done, it doesn’t > get faithfully reproduced which causes headaches for tooling to parse > even when the intent is clear. This is what Thomas is dealing with and > you can see the many examples of this on the many other emails on this > list. > > The question Richard was posing (if I may paraphrase) if someone would > have a viable argument for non-compliance with section 1 just for > replacing a messy, but clear (in terms of what license variant > applies) with an SPDX identifier. Considering that Stallman encouraged > the use of the SPDX identifiers we adopted based on his concern for > lack of clarity, I can hardly think that the FSF is now going to go > back on that sentiment? > I totally get that nonstandard notices that have already been accepted are a problem. It's an annoying problem to deal with and I'm not trying to take anything away from the effort Thomas and others here are putting into this -- it's in the category of thankless work that we need a lot more of. I do think removing notices raises GPL compliance questions, for the same reasons Allison outlined. Project copyrightholders can as always make their own decisions about questions like this. What Linux does will be looked to by others as a practice to model, so I'm interested to participate in the conversation here for that reason (I see there are also a few cases of actual FSF copyrighted materials up for consideration, so will try to watch for those but would also appreciate a ping if anyone can spare one as they come up). As for FSF's overall recommendation for SPDX -- I wasn't raising any issue there. I'm assuming that SPDX isn't going back on the public recommendation to keep notices intact that's been there throughout our conversations; I know that SPDX doesn't control how projects may decide to use parts of the system. FSF recommends SPDX because it is a very useful and consistent addition to our set of licensing best practice recommendations -- which also include file-level notices. -john -- John Sullivan | Executive Director, Free Software Foundation GPG Key: A462 6CBA FF37 6039 D2D7 5544 97BA 9CE7 61A0 963B https://status.fsf.org/johns | https://fsf.org/blogs/RSS Do you use free software? Donate to join the FSF and support freedom at <https://my.fsf.org/join>.
