![[RSS]](/static/img/feed-icon-14x14.2168a573d0d4.png)
Conservancy Blog
Displaying posts by Bradley M. Kuhn and Karen M. Sandler
Choosing a GPLv3-termination Backport to GPLv2 (KESAP vs. GPLCC)
by 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
otherwise to copy, modify, sublicense or distribute the Program is
void, and will automatically terminate 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.
Understanding LF's New “Community Bridge”
by on March 13, 2019
Yesterday, the Linux Foundation (LF) launched a new service, called “Community Bridge” — an ambitious platform that promises a self-service system to handle finances, address security issues, manage CLAs and license compliance, and also bring mentorship to projects. These tasks are difficult work that typically require human intervention, so we understand the allure of automating them; we and our peer organizations have long welcomed newcomers to this field and have together sought collaborative assistance for these issues. Indeed, Community Bridge's offerings bear some similarity to the work of organizations like Apache Software Foundation, the Free Software Foundation (FSF), the GNOME Foundation (GF), Open Source Initiative (OSI), Software in the Public Interest (SPI) and Conservancy. People have already begun to ask us to compare this initiative to our work and the work of our peer organizations. This blog post hopefully answers those questions and anticipated similar questions.
The first huge difference (and the biggest disappointment for the entire FOSS community) is that LF's Community Bridge is a proprietary software system. §4.2 of their Platform Use Agreement requires those who sign up for this platform to agree to a proprietary software license, and LF has remained silent about the proprietary nature of the platform in its explanatory materials. The LF, as an organization dedicated to Open Source, should release the source for Community Bridge. At Conservancy, we've worked since 2012 on a Non-Profit Accounting Software system, including creating a tagging system for transparently documenting ledger transactions, and various support software around that. We and SPI both now use these methods daily. We also funded the creation of a system to manage mentorship programs, which now runs the Outreachy mentorship program. We believe fundamentally that the infrastructure we provide for FOSS fiscal sponsorship (including accounting, mentorship and license compliance) must itself be FOSS, and developed in public as a FOSS project. LF's own research already shows that transparency is impossible for systems that are not FOSS. More importantly, LF's new software could directly benefit so many organizations in our community, including not only Conservancy but also the many others (listed above) who do some form of fiscal sponsorship. LF shouldn't behave like a proprietary software company like Patreon or Kickstarter, but instead support FOSS development. Generally speaking, all Conservancy's peer organizations (listed above) have been fully dedicated to the idea that any infrastructure developed for fiscal sponsorship should itself be FOSS. LF has deviated here from this community norm by unnecessarily requiring FOSS developers to use proprietary software to receive these services, and also failing to collaborate over a FOSS codebase with the existing community of organizations. LF Executive Director Jim Zemlin has said that he “wants more participation in open source … to advance its sustainability and … wants organizations to share their code for the benefit of their fellow [hu]mankind”; we ask him to apply these principles to his own organization now.
The second difference is that LF is not a charity, but a trade association — designed to serve the common business interest of its paid members, who control its Board of Directors. This means that donations made to projects through their system will not be tax-deductible in the USA, and that the money can be used in ways that do not necessarily benefit the public good. For some projects, this may well be an advantage: not all FOSS projects operate in the public good. We believe charitable commitment remains a huge benefit of joining a fiscal sponsor like Conservancy, FSF, GF, or SPI. While charitable affiliation means there are more constraints on how projects can spend their funds, as the projects must show that their spending serves the public benefit, we believe that such constraints are most valuable. Legal requirements that assure behavior of the organization always benefits the general public are a good thing. However, some projects may indeed prefer to serve the common business interest of LF's member companies rather than the public good, but projects should note such benefit to the common business interest is mandatory on this platform — it's explicitly unauthorized to use LF's platform to engage in activities in conflict with LF’s trade association status). Furthermore, (per the FAQ) only one maintainer can administer a project's account, so the platform currently only supports the “BDFL” FOSS governance model, which has already been widely discredited. No governance check exists to ensure that the project's interests align with spending, or to verify that the maintainer acts with consent of a larger group to implement group decisions. Even worse, (per §2.3 of the Usage Agreement) terminating the relationship means ceasing use of the account; no provision allows transfer of the money somewhere else when projects' needs change.
Finally, the LF offers services that are mainly orthogonal and/or a subset of the services provided by a typical fiscal sponsor. Conservancy, for example, does work to negotiate contracts, assist in active fundraising, deal with legal and licensing issues, and various other hands-on work. LF's system is similar to Patreon and other platforms in that it is a hands-off system that takes a cut of the money and provides minimal financial services. Participants will still need to worry about forming their own organization if they want to sign contracts, have an entity that can engage with lawyers and receive legal advice for the project, work through governance issues, or the many other things that projects often want from a fiscal sponsor.
Historically, fiscal sponsors in FOSS have not treated each other as competitors. Conservancy collaborates often with SPI, FSF, and GF in particular. We refer applicant projects to other entities, including explaining to applicants that a trade association may be a better fit for their project. In some cases, we have even referred such trade-association-appropriate applicants to the LF itself, and the LF then helped them form their own sub-organizations and/or became LF Collaborative Projects. The launch of this platform, as proprietary software, without coordination with the rest of the FOSS organization community, is unnecessarily uncollaborative with our community and we therefore encourage some skepticism here. That said, this new LF system is probably just right for FOSS projects that (a) prefer to use single-point-of-failure, proprietary software rather than FOSS for their infrastructure, (b) do not want to operate in a way that is dedicated to the public good, and (c) have very minimal fiscal sponsorship needs, such as occasional reimbursements of project expenses.
Update on 2019-04-01: Community Bridge was also discussed on episode 0x65 of Free as in Freedom, which is available in mp3 format and ogg format.
Congratulations to Tesla on Their First Public Step Toward GPL Compliance
by on May 18, 2018
Conservancy rarely talks publicly about specifics in its ongoing GNU General Public License (GPL) enforcement and compliance activity, in accordance with our Principles of Community Oriented GPL Enforcement. We usually keep our compliance matters confidential — not for our own sake — but for the sake of violators who request discretion to fix their mistakes without fear of public reprisal. As occurred a few years ago with Samsung, we're thrilled when a GPL violator decides to talk about their violation and works to correct it publicly. This gives us the opportunity to shine light on the real-world work of GPL and copyleft compliance.
We're thus glad that, this week, Tesla has acted publicly regarding its current GPL violations and has announced that they've taken their first steps toward compliance. While Tesla acknowledges that they still have more work to do, their recent actions show progress toward compliance and a commitment to getting all the way there.
Conservancy has been engaging with Tesla on its GPL compliance since June 2013, when we advised Tesla that we had received multiple reports of a GPL violation regarding Tesla's Model S. Customers who purchased Tesla's Model S received on-board system(s) that contained BusyBox and Linux, but did not receive any source code, nor an offer for the source. In parallel, we also asked other entities to advise Tesla about GPL compliance. We know that Tesla received useful GPL compliance advice from multiple organizations, in addition to us, over these years.
For our part, since we first contacted Tesla, we have been working with them collaboratively in various ways to convince their original upstream providers, NVIDIA and Parrot, to disclose complete, corresponding source (CCS) releases for all GPL'd binaries found in Tesla's Model S. During that time, Tesla privately provided Conservancy with multiple rounds of “CCS candidates“. (These are source code releases that are not yet complete and corresponding as required by the GPL.) Conservancy in turn reviewed their CCS candidates and provided technical feedback on how to improve the candidates to reach compliance. In this process, we provide detailed reports explaining how the candidate releases fall short of GPL's requirements. This part of the process is the longest, most difficult part of GPL enforcement. We often wish we could celebrate the triumph of moving from a no-source-or-offer violation to the next step of “incomplete sources provided”1. However, we also can't lose sight of the fact that compliance means meeting all GPL's requirements, so we don't convey false hopes with an incomplete release. We must ultimately remain focused on user freedom in our efforts.
This week, Tesla took a new and different approach. Tesla elected to publish its incomplete CCS candidates, on the online software development collaboration site, GitHub. While our preference is that companies provide adequate CCS immediately, we realize that this can be a challenging process and recognize that Tesla has struggled for years with upstreams to yield proper CCS. We believe Tesla's new approach also has merit, because it allows the entire community to discuss and contribute in public and collaboratively assist Tesla in complying with the GPL. In a case like this, engagement in the community may be an ideal way to transparently assure that compliance is achieved.
We look forward to facilitating Tesla with this new approach to compliance. Toward that end, Conservancy has created a public mailing list to discuss Tesla's source release (and, ideally, to also discuss other CCS candidates if other GPL violators choose to also take this approach.) The first post to this mailing list is our CCS candidate evaluation report 1, written by our Compliance Engineer, Denver Gingerich.
CCS reports have been the standard document of GPL enforcement since 1998. Conservancy has probably produced hundreds of such reports since we began. However, this marks the first time that circumstances have allowed us to share such a report with the public without violating our Principles. We're excited to do that, thanks to Tesla's willingness to engage everyone in their GPL compliance process.
We know many of you, particularly those Linux-savvy folks who bought Tesla vehicles, have reached high levels of frustration with the lengthy time this GPL compliance effort is taking. Nevertheless, this situation shows precisely why patience is essential for successful enforcement work; it gives us the opportunity to welcome violators to become contributors to the copyleft software community. Our community's history is filled with such success stories. To that end, we ask that everyone join us and our coalition in extending Tesla's time to reach full GPL compliance for Linux and BusyBox, not just for the 30 days provided by following GPLv3's termination provisions, but for at least another six months.
We welcome those interested in the CCS evaluation process to join the mailing list, as this marks one of the few opportunities to engage pubilcly in CCS evaluation. Additionally, anyone who holds copyrights in Linux may join our enforcement coalition of Linux Developers by writing to <linux-services@sfconservancy.org>
1 While Tesla partly corrected the violation yesterday by making some offers for source, the source provided is not complete, corresponding source with complete “scripts used to control compilation and installation of the executable”. Denver's email outlines the specific, current compliance failures.
SFLC: Escalation Disguised as “Settlement Offer”
by on December 22, 2017
Conservancy stands by our motion for summary judgment to dismiss Software Freedom Law Center (SFLC)'s petition to cancel our trademark. This remains the most resource-efficient way to dispense with SFLC's unwarranted attacks. We have received their latest escalation, disguised as a “peaceful settlement” offer. Instead of deescalating today, SFLC added inflammatory accusations against Conservancy and its employees. Obviously, we did not commit fraud; our legal counsel, Pam Chestek, has advised us that SFLC's fraud allegation is “unequivocally unfounded”. We will not let them further waste our time.
We cannot accept any settlement offer that includes a trademark license we don't need. Furthermore, any trademark license necessarily gives SFLC perpetual control over how we pursue our charitable mission. SFLC, our former law firm, helped us form and name our independent entity. Changing this arrangement now does not advance software freedom nor our mission. Our community remains best served by SFLC and Conservancy as independent entities.
