Re: GPL Cooperation Commitment variations

Grant Likely

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

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.


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 and other
informational and promotional materials.


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!!


Join { to automatically receive all group messages.