Hi folks, I'm a little late to this discussion, but I think I should weigh in. To me this discussion is very odd, at least from the context of the Kernel Enforcement Statement. I don't think it makes any sense to encode the KES in an SPDX tag, and I am leaning in the same direction on the GPLCC. In fact, I think it is actively harmful to do this.
When I proposed and drafted first version of the KES, the intent was to provide a body of work that effectively says "We think the GPL means /this/". It was right in the middle of when many of us knew of the McHardy lawsuits that presented unorthodox interpretations of the GPL, but none of us could talk about it in public. There was (perhaps oddly) little in the way of material that any of us could point at to argue that we generally agree on what the GPL means, and more importantly, that the interpretations and enforcement activity being presented in court are outside the widely accepted interpretation. The KES is a document that can be shown to companies and individuals that can give them confidence that a GPL licensed project is safe and well understood. Hopefully it is a document that will be considered by a court when challenging an infringement action that does not line up with the interpretation agreed by a large body of the community. (Insert here comment about I am not a lawyer, followed by dodgy legal advice -- I approached this problem from the point of view of a community member, and I have to believe that when a large group of the community share a common understanding then surely that understanding carries some weight. Those of you with law degrees can comment on how naïve I'm being) The KES was not intended to change the interpretation of the GPL. The GPLv2 is exactly the same license as it always was. What the KES does, or attempts to do, is claim that what the GPL /means/ is well understood, and that it has always meant that. The last bit is really important. McHardy, or anybody else, doesn't get to claim that the GPL on their code is interpreted differently than the GPL on the code I've contributed. I think putting the KES or GPLCC into a SPDX tag undermines that exact arguement. By encoding them into SPDX tags, it seems to argue that there are two different classes of GPL. Vanilla GPL, and Super Special Blessed GPL when the project has adopted the KES or GPLCC. This is actively harmful to solving the problem the KES and GPLCC are trying to solve. Without a really strong use case for how KES and GPLCC tags would be used, I strongly oppose both of them. I'll leave aside the arguements about logistics of adding a new tag to the kernel flags, or about not every contributor to the kernel has signed the KES. James and Jilayne have argued those well and I don't need to rehash those arguments. Cheers, g. On 08/12/2018 06:51, Richard Fontana wrote: > I've thought further about the issue of whether GPLCC, as a possible > future SPDX exception identifier, should cover the three GPLCC > variants (Corporate, Indivdiual and Project), as seemed to be the > consensus on the recent call, or whether instead it should just refer > to the Project version (which was my original proposal). > > There's an argument that someone might want to use a convenient SPDX > identifier to reference the non-Project variants when annotating some > source code wholly or partially covered by one of those > commitments. (This is related to some of the arguments Bradley has > been making in connection with the Kernel Enforcement Statement, I > think.) I suspect this will be unlikely, but who knows? > > My concern though is the effort to use markup to generalize the > textual differences among the three variants might have the > problematic effect (from Red Hat's perspective) that some unknown set > of additional variants, unauthorized by the GPLCC initiative, could > match to the GPLCC SPDX identifier. To put it simply, I see value in > an SPDX identifier for GPLCC if the identifier can be mapped to from > the three official GPLCC variants, but I see no value in the > possibility of anything else matching GPLCC. I am not clear on whether > the markup can be crafted so precisely that it could only match the > three documents in question. I think the problem I am highlighting > would be tolerable if we (Red Hat) actually cared about having an > identifier for the Corporate and Individual variants, but we really > don't. If SPDX adopts an identifier solely for the Project variant, > let's say "GPLCC-1.0", we'd be happy to use that as an abbreviation > for all three variants on https://gplcc.github.io/gplcc and other > informational and promotional materials. > > Richard > > > > > > > On Thu, Nov 29, 2018 at 11:54:08AM -0700, J Lovejoy wrote: >> Hi all, >> >> I know I just wrote in the minutes that this task was on Richard F, but I >> was too curious not to have a cursory look myself! >> >> Attached is a compare of the project to corporate variant; and of the >> individual to project variant. The main difference seem to be: >> - in the use of pronouns (I, We, name of coroporation) - easily accommodated >> with markup. >> - likewise, the associated definition of We or the corporation name, or the >> absence of a definition for individual at the end >> - likewise, lead-in text for the individual version clarifying it only >> applies to their sole copyright >> - there is also an additional term that the corporate variant has about the >> ability to modify the commitment by posting a new edition - this is not >> included at all in the project or individual variants. I think this could be >> omitable in some way? if a cooperation did make a modified version, then it >> would not match >> >> >> Interested to hear other thoughts. This will still need some expert markup >> attention!! >> >> >> Jilayne >> >> >> >> > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2465): https://lists.spdx.org/g/Spdx-legal/message/2465 Mute This Topic: https://lists.spdx.org/mt/28502129/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
