Get the latest update on our Vizio court case
●News
Press Releases
Press
Blog
Vizio Lawsuit in the News
Our Issues in the News
●About
Sponsors
Sustainers
Board of Directors
Staff
Evaluation Committee
Outside Counsel, et alia
Transparency
Contact
●Our Work
Copyleft Compliance
We defend and uphold the rights of software users and consumers under copyleft licenses.
Impact Litigation
We defend the legal rights of software users. Learn the details, status, and stakes of our court cases.
Give Up GitHub
We urge FOSS Developers to Give Up GitHub! Learn why.
Outreachy
We offer internships for anyone who faces underrepresentation, systemic bias, or discrimination in the tech industry.
FOSSY
Our annual community-oriented conference focused on the creation and impact of free and open source software.
●Tools
Member Projects
We provide non-profit infrastructure and services to our members creating Free/Libre and Open Source Software.
Use The Source
Our tool for evaluating the source code candidates companies must provide for GPLed software.
OpenWrt One
We designed and built the first ever wireless Internet router designed with software freedom and right to repair in mind.
●Learn
The Corresponding Source
A bi-weekly oggcast about legal, policy, and many other issues in the Free, Libre, and Open Source Software (FLOSS) world.
Glossary of Terms
A list of terms you might be unfamiliar with but occur frequently in our work.
FAQ About the Vizio Lawsuit
Your most frequently asked questions about the Vizio lawsuit, answered in one place.
●
Donate
●News
Press Releases
Press
Blog
Vizio Lawsuit in the News
Our Issues in the News
●About
Sponsors
Sustainers
Board of Directors
Staff
Evaluation Committee
Outside Counsel, et alia
Transparency
Contact
●Our Work
Copyleft Compliance
We defend and uphold the rights of software users and consumers under copyleft licenses.
Impact Litigation
We defend the legal rights of software users. Learn the details, status, and stakes of our court cases.
Give Up GitHub
We urge FOSS Developers to Give Up GitHub! Learn why.
Outreachy
We offer internships for anyone who faces underrepresentation, systemic bias, or discrimination in the tech industry.
FOSSY
Our annual community-oriented conference focused on the creation and impact of free and open source software.
●Tools
Member Projects
We provide non-profit infrastructure and services to our members creating Free/Libre and Open Source Software.
Use The Source
Our tool for evaluating the source code candidates companies must provide for GPLed software.
OpenWrt One
We designed and built the first ever wireless Internet router designed with software freedom and right to repair in mind.
●Learn
The Corresponding Source
A bi-weekly oggcast about legal, policy, and many other issues in the Free, Libre, and Open Source Software (FLOSS) world.
Glossary of Terms
A list of terms you might be unfamiliar with but occur frequently in our work.
FAQ About the Vizio Lawsuit
Your most frequently asked questions about the Vizio lawsuit, answered in one place.
●Donate
Thanks to so many donors, we met our largest match donation ever of $211,939.
Two generous anonymous donors have provided another $40,012ofadditional matching funds.
Give now to help us reach this stretch goal!
For only 4 more days, the
next $13,079offinancial support we receive will be matched!
$26,933 matched!
$13,079 to go!
$211,927 fully matched!
Home / News / Blog
Choosing a GPLv3-termination Backport to GPLv2 (KESAP vs. GPLCC)
byBradley M. Kühn and Karen M. Sandler
on May 11, 2019
About four years ago,
Conservancy (in collaboration with the Free Software Foundation)
published the
Principles of Community-Oriented GPL enforcement. Our goal was to
conduct our enforcement ethically and respectfully, treating today's violators as tomorrow's contributors. Accordingly, the Principles advocate a holistic approach to GPL enforcement that truly seeks to gain
GPL compliance to advance software freedom. We were so happy about the way the Principles assisted the Netfilter team and we were excited that there was
substantial interest in codifying these long standing ad-hoc
Principles into a widely adopted and published consensus.
Ideas in FOSS also have a way of taking on a life of their own; we share our ideas
in the hopes that others will build on them. We have been pleasantly surprised that the last
Principle, “Community-oriented compliance processes should extend the
benefit of GPLv3-like termination, even for GPLv2-only works”,
received so much interest.
This interest led to two independent initiatives to
“backport” the GPLv3 termination provisions — by way of
an additional permission — to GPLv2-only-licensed works. Additional
permissions to GPLv2 have been used for various purposes since the early
1990s (such as for
the Bison
exception). Additional permissions grant more leeway — relaxing some requirement of the default license — in an effort to reach some policy goal for the project. In this case, the additional permission softens the strict terms of the GPLv2 termination provisions, which state that any attempt
otherwi
se to copy, modify, sublicense o
r distribute the Program is
void,
and will automatically terminat
e your rights under this
License.
That means permissions under GPLv2 are instantly and permanently lost on even
easily-correctable violations and require reinstatement of permissions by
copyright holders. In contrast, the GPLv3 version gives downstream
violators short time periods to comply and receive automatic
reinstatement of permissions,
via the following
clause:
If you cease all violation of this License, then your license from a
particular copyright holder is reinstated (a) provisionally, unless and
until the copyright holder explicitly and finally terminates your
license, and (b) permanently, if the copyright holder fails to notify
you of the violation by some reasonable means prior to 60 days after
the cessation. Moreover, your license from a particular copyright
holder is reinstated permanently if the copyright holder notifies you
of the violation by some reasonable means, this is the first time you
have received notice of violation of this License (for any work) from
that copyright holder, and you cure the violation prior to 30 days
after your receipt of the notice.
This improved policy can indeed be “backported” to GPLv2 via an
additional permission.
Two Choices
Two efforts over the last year and a half have
“implemented” these backports. The first released was the
solution now used by the Linux community, which states:
Notwithstanding the termination provisions of the GPL-2.0, we agree
that it is in the best interests of our development community to adopt
the following provisions of GPL-3.0 as additional permissions under our
license with respect to any non-defensive assertion of rights under the
license, However:
[Quotes GPLv3 termination provisions as above]
We call this sub-document the Kernel Enforcement Statement Additional
Permission (“KESAP”), as it is published as part of a
larger document named “Kernel
Enforcement Statement”. (The rest of that document does not contain legally binding
terms.)
The second effort, inspired by this
KESAP, was released later by
Red Hat, which they call the GPL Cooperation Commitment
(often abbreviated GPL-CC or GPLCC), but which we will call here “RHCC” to avoid any
confusion with FSF initiatives around the GPL and license drafting, and because to most people in licensing, CC refers to “Creative Commons”. The
RHCC is
available on github.
Adopting One of the Additional Permissions
Conservancy finds both documents intriguing and worthy of additional study
and consideration. Moreover, Conservancy has decided that we will adopt
one of these GPLv3-termination-backport provisions for copyrights we hold,
and advocate adoption for other copyrights held by contributors for our
member projects. While we don't demand this of anyone (and won't
make use of such an additional permission mandatory for our GPLv2'd
projects), we make a strong recommendation for use of a
GPLv3-termination-backporting additional permission.
We have for months carefully considered which of the two options is the
best to adopt. This was a difficult decision, since the two are similar
and both have some problematic aspects. While we applaud both the Linux
community and Red Hat for promulgating these useful additional permissions,
on balance we prefer KESAP, and so we are adopting and endorsing KESAP.
Below we discuss our reasons for this choice between the two for those who
wish more detail. Anyone interested can also listen to
episode 0x67 of Free as in Freedom where we discuss these
issues in detail.
Length and Complexity
KESAP is about half as long as
RHCC. When you remove the direct quote in both documents that come from
GPLv3's text itself (which obviously must be included in both), the RHCC
adds 1,180 words and KESAP adds only 323.
The RHCC is also more complex. It adds
additional defined terms, including redefining “We”, which is
already a term used in GPLv2's preamble to refer to the FSF. It adds an
irrevocability clause, which is not harmful, but it is unnecessary since
unilaterally granted copyright permissions are generally irrevocable
anyway. Furthermore, given that the word “irrevocable” doesn't appear
in GPLv2, adding a redundant irrevocable clause
could easily confuse license readers into thinking that
GPLv2 itself is otherwise revocable even while the additional permission is not.
Aggressive Defensive Termination Violates Principles
Our biggest concern with both KESAP and RHCC is that they only apply in “non-defensive”
situations. This allows copyright holders to fail to provide 30 days for
violators to repair violations when those violators are already aggressors
in some other form of litigation.
While we are somewhat sympathetic to those who might seek to use GPL enforcement to
retaliate against other bad actions, we believe that even potential bad actors
deserve the benefit of the doubt and the meager 30 days to repair a violation
before facing aggressive enforcement tactics. Furthermore, defensive actions that bring the GPL into
court as part of business dispute otherwise unrelated to free software are also the most likely litigation to generate bad legal precedent regarding the GPL. (Indeed, many of the lawsuits that have already been brought over the GPL are in this category. While so far these have settled out of court, there's no reason to expect that to always happen in the future.) We are disappointed that both sets of drafters feel that copyright holders should hold back this permission in those cases. As the Principles state, we continue to discourage any legal action (defensive or otherwise) against a copyright holder who otherwise
succeeds in producing a compliant GPL'd source release within 30 days of violation notice. We ask Red Hat and the Linux community to also
make this same cure commitment universally, perhaps in an updated version of these additional permissions.
We do note that RHCC is slightly better on this point,
since it does narrow non-defensive via a defined term, but it does not narrow it enough to make a real difference, while also adding additional complexity. Moreover, the text specifically mentions legal proceedings and claims, which draws attention
to the very activities that make nervous copyleft software adopters skittish.
Additional Permissions Should Not Codify Assent Mechanisms
RHCC has its own orthogonal assent mechanism, based on
the presence of a file in the repository. This assent mechanism, while it seems similar to a traditional inbound=outbound regime,
is actually novel and untested. The mechanism attempts to gain assent based on a specific date of inclusion of the RHCC file
in a repository. Contributors, however, do not necessarily receive any notice of the addition of that file, and therefore their assent is unclear.
For example, imagine a pull request from two levels downstream that waits for merge for months. The modern DVCS-based software
development process allows developers to work indefinitely on a forked copy
of the repository and there is no way to know that the contributor had
a copy of the repository that pre-dated the addition of the file, and they
may not have a copy of the RHCC in their repository. When
all is merged, it will appear that their commit postdated the
addition of the RHCC, but the contributor may be unaware
that the exception is added.
Furthermore, many projects already have licensing assent systems that are
likely incompatible with one that is baked into the RHCC. Indeed, Linux
itself has decided that they cannot make KESAP part of the DCO assent,
since too many Linux developers already believe Signed-Off-By
means assent merely to GPLv2-only-compatible licensing. The RHCC, when
added to a existing project, cannot be adapted to fit a DCO process without
modification of the DCO. Since Signed-Off-By tags rarely
assent specifically to a version of the Project's DCO, RHCC is
incompatible with a DCO-assent-based inbound=outbound assent system.
By contrast, the KESAP is flexible on assent. The entire KES, which
includes the actual additional permission that is the KESAP, asks
contributors to affirmatively assent with a patch that adds their own name
to the file — explicitly indicating assent. Extracted from the KES,
the KESAP text can be combined easily with virtually any assent mechanism
in use in FOSS today. RHCC simply cannot.
Adding KESAP to your project
Linux is the gold standard of frictionless legal assent that is
well-accepted by both individual hobbyists and contributors and corporate
contributions and users alike. Recommending the Linux solution to this
particular GPLv3-termination backport is simply the best way to quickly
promulgate these additional permissions to GPLv2'd projects. We'll be
working over the coming months to encourage, and hopefully assist,
Conservancy's LGPLv2'd and GPLv2'd (or-later) member projects to implement
KESAP. We will also relicense all Conservancy's own GPLv2 (or-later) copyrights to
include the KESAP.
[permalink]
Tags:
conservancy,
GPL,
law,
licensing
Please email any comments on this entry to
info@sfconservancy.org.
Other Conservancy Blog entries…
Blog Index by Year
●2026
●2025
●2024
●2023
●2022
●2021
●2020
●2019
●2018
●2017
●2016
●2015
●2014
●2013
●2012
●2011
●2010
Blogs by Tag
●conservancy
●GPL
●supporter
●licensing
●conferences
●law
●events
●software freedom for everyone
●Member Projects
●Outreachy
●FOSS Sustainability
●diversity
●resources
●Copyleft Conf
●ContractPatch
●Filings
●Godot
●Reproducible Builds
●Year In Review 2016
●fundraiser
●CLA
●Wine
●Year In Review 2015
●Kallithea
●QEMU
●Selenium
●Google Summer of Code
●Homebrew
●inkscape
●patent
●security
●Clojars
●Git
●Hackfests
●Racket
●cyborg
●phpMyAdmin
●pypy
●volunteer
●Accounting
●LibreHealth
●Shotwell
●inclusion
●jQuery
●microblocks
●sourceware
Blogs by Author
●Vladimir Bejdo
●Kate Chapman
●Pamela Chestek
●Denver Gingerich
●Bradley M. Kühn and Denver Gingerich
●Will Hawkins
●Fred Jennings
●Deb and Karen
●Jeff King
●Bradley M. Kühn
●Conservancy + Bro LT
●Christine Lemmer-Webber
●Deb Nicholson
●Sourceware PLC
●Rick Sanders
●Bradley M. Kühn and Karen M. Sandler
●Karen Sandler
●Tony Sebro
●Sage A. Sharp
●Brett Smith
●Conservancy's Staff
●Daniel Takamori
●Outreachy Team
●Marina Zhurakhinskaya
●Molly deBlanc
●Main Page
●Contact
●Sponsors
●RSS Feed
●
Software Freedom Conservancy is a 501(c)(3) non-profit charity.
Privacy Policy last updated 22 December 2020.
This page and its contents are licensed under a Creative Commons Attribution-Share Alike 4.0 International License.
