Choosing a GPLv3-termination Backport to GPLv2 (KESAP vs. GPLCC)

by Bradley M. Kuhn 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 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.

[permalink]

Tags: conservancy, GPL, law, licensing

Toward Community-Oriented, Public & Transparent Copyleft Policy Planning

by Bradley M. Kuhn on October 16, 2018

More than 15 years ago, Free and Open Source Software (FOSS) community activists successfully argued that licensing proliferation was a serious threat to the viability of FOSS. We convinced companies to end the era of “vanity” licenses. Different charities — from the Open Source Initiative (OSI) to the Free Software Foundation (FSF) to the Apache Software Foundation — all agreed we were better off with fewer FOSS licenses. We de-facto instituted what my colleague Richard Fontana once called the “Rule of Three” — assuring that any potential FOSS license should be met with suspicion unless (a) the OSI declares that it meets their Open Source Definition, (b) the FSF declares that it meets their Free Software Definition, and (c) the Debian Project declares that it meets their Debian Free Software Guidelines. The work for those organizations quelled license proliferation from radioactive threat to safe background noise. Everyone thought the problem was solved. Pointless license drafting had become a rare practice, and updated versions of established licenses were handled with public engagement and close discussion with the OSI and other license evaluation experts.

Sadly, the age of license proliferation has returned. It's harder to stop this time, because this isn't merely about corporate vanity licenses. Companies now have complex FOSS policy agendas, and those agendas are not to guarantee software freedom for all. While it is annoying that our community must again confront an old threat, we are fortunate the problem is not hidden: companies proposing their own licenses are now straightforward about their new FOSS licenses' purposes: to maximize profits.

Open-in-name-only licenses are now common, but seem like FOSS licenses only to the most casual of readers. We've succeeded in convincing everyone to “check the OSI license list before you buy”. We can therefore easily dismiss licenses like Common Clause merely by stating they are non-free/non-open-source and urging the community to avoid them. But, the next stage of tactics have begun, and they are harder to combat. What happens when for-profit companies promulgate their own hyper-aggressive (quasi-)copyleft licenses that seek to pursue the key policy goal of “selling proprietary licenses” over “defending software freedom”? We're about to find out, because, yesterday, MongoDB declared themselves the arbiter of what “strong copyleft” means.

Understanding MongoDB's Business Model

To understand the policy threat inherent in MongoDB's so-called “Server Side Public License, Version 1”, one must first understand the fundamental business model for MongoDB and companies like them. These companies use copyleft for profit-making rather than freedom-protecting. First, they require full control (either via ©AA or CLA) of all copyrights in the work, and second, they offer two independent lines of licensing. Publicly, they provide the software under the strongest copyleft license available. Privately, the same (or secretly improved) versions of the software are available under fully proprietary terms. In theory, this could be merely selling exceptions: a benign manner of funding more Free Software code — giving the proprietary option only to those who request it. In practice — in all examples that have been even mildly successful (such as MongoDB and MySQL) — this mechanism serves as a warped proprietary licensing shake-down: “Gee, it looks like you're violating the copyleft license. That's a shame. I guess you just need to abandon the copyleft version and buy a proprietary license from us to get yourself out of this jam, since we don't plan to reinstate any lost rights and permissions under the copyleft license.” In other words, this structure grants exclusive and dictatorial power to a for-profit company as the arbiter of copyleft compliance. Indeed, we have never seen any of these companies follow or endorse the Principles of Community-Oriented GPL Enforcement. While it has made me unpopular with some, I still make no apologies that I have since 2004 consistently criticized this “proprietary relicensing” business model as “nefarious”, once I started hearing regular reports that MySQL AB (now Oracle) asserts GPL violations against compliant uses merely to scare users into becoming “customers”. Other companies, including MongoDB, have since emulated this activity.

Why Seek Even Stronger Copyleft?

The GNU Affero General Public License (AGPL) has done a wonderful job defending the software freedom of community-developed projects like Mastodon and Mediagoblin. So, we should answer with skepticism a solitary for-profit company coming forward to claim that “Affero GPL has not resulted in sufficient legal incentives for some of the largest users of infrastructure software … to participate in the community. Many open source developers are struggling with a similar reality”. If the last sentence were on Wikipedia, I'd edit it to add a Citation Needed tag, as I know of no multi-copyright-held or charity-based AGPL'd project that has “struggled with this reality”. In fact, it's only a “reality” for those that engage in proprietary relicensing. Eliot Horowitz, co-founder of MongoDB and promulgator of their new license, neglects to mention that.

The most glaring problem with this license, which Horowitz admits in his OSI license-review list post, is that there was no community drafting process. Instead, a for-profit company, whose primary goal is to use copyleft as a weapon against the software-sharing community for the purpose of converting that “community” into paying customers, published this license as a fait accompli without prior public discussion of the license text.

If this action were an isolated incident by one company, ignoring it is surely the best response. Indeed, I urged everyone to simply ignore the Commons Clause. Now, we see a repackaging of the Commons Clause into a copyleft-like box (with reuse of Commons Clause's text such as “whose value derives, entirely or substantially, from the functionality of the Software”). Since both licenses were drafted in secret, we cannot know if the reuse of text was simply because the same lawyer was employed to write both, or if MongoDB has joined a broader and more significant industry-wide strategy to replace existing FOSS licensing with alternatives that favor businesses over individuals.

The Community Creation Process Matters

Admittedly, the history of copyleft has been one of slowly evolving community-orientation. GPLv1 and GPLv2 were drafted in private, too, by Richard Stallman and FSF's (then) law firm lawyer, Jerry Cohen. However, from the start, the license steward was not Stallman himself, nor the law firm, but the FSF, a 501(c)(3) charity dedicated to serve the public good. As such, the FSF made substantial efforts in the GPLv3 process to reorient the drafting of copyleft licenses as a public policy and legislative process. Like all legislative processes, GPLv3 was not ideal — and I was even personally miffed to be relegated to the oft-ignored “GPLv3 Discussion Committee D” — but the GPLv3 process was undoubtedly a step forward in FOSS community license drafting. Mozilla Corporation made efforts for community collaboration in redrafting the MPL, and specifically included the OSI and the FSF (arbiters of the Open Source Definition and Free Software Definition (respectively)) in MPL's drafting deliberations. The modern acceptable standard is a leap rather than a step forward: a fully public, transparent drafting process with a fully public draft repository, as the copyleft-next project has done. I think we should now meet with utmost suspicion any license that does not use copyleft-next's approach of “running licensing drafting as a Free Software project”.

I was admittedly skeptical of that approach at first. What I have seen six years since Richard Fontana started copyleft-next is that, simply put, the key people who are impacted most fundamentally by a software license are mostly likely to be aware of, and engage in, a process if it is fully public, community-oriented, and uses community tools, like Git.

Like legislation, the policies outlined in copyleft licenses impact the general public, so the general public should be welcomed to the drafting. At Conservancy, we don't draft our own licenses⁰, so our contracts with software developers and agreements with member projects state that the licenses be both “OSI-approved Open Source” and “FSF-approved GPL-compatible Free Software”. However, you can imagine that Conservancy has a serious vested interest in what licenses are ultimately approved by the OSI and the FSF. Indeed, with so much money flowing to software developers bound by those licenses, our very charitable mission could be at stake if OSI and the FSF began approving proprietary licenses as Open, Free, and/or GPL-compatible. I want to therefore see license stewards work, as Mozilla did, to make the vetting process easier, not harder, for these organizations.

A community drafting process allows everyone to vet the license text early and often, to investigate the community and industry impact of the license, and to probe the license drafter's intent through the acceptance and rejection of proposed modified text (ideally through a DVCS). With for-profit actors seeking to gain policy control of fundamental questions such as “what is strong copyleft?”, we must demand full drafting transparency and frank public discourse.

The Challenge Licensing Arbiters Face

OSI, FSF, and Debian have a huge challenge before them. Historically, the FSF was the only organization who sought to push the boundary of strong copyleft. (Full disclosure: I created the Affero clause while working for the FSF in 2002, inspired by Henry Poole's useful and timely demands for a true network services copyleft.) Yet, the Affero clause was itself controversial. Many complained that it changed the fundamental rules of copyleft. While “triggered only on distribution, not modification” was a fundamental rule of the regular GPL, we as a community — over time and much public debate — decided the Affero clause is a legitimate copyleft, and AGPL was declared Open Source by OSI and DFSG-free by Debian.

That debate was obviously framed by the FSF. The FSF, due to public pressure, compromised by leaving the AGPL as an indefinite fork of the GPL (i.e., the FSF did not include the Affero clause in plain GPL. While I personally lobbied (from GPLv3 Discussion Committee D and elsewhere) for the merger of AGPL and GPL during the GPLv3 drafting process, I respect the decision of the FSF, which was informed not by my one voice, but the voices of the entire community.

Furthermore, the FSF is a charity, chartered to serve the public good and the advancement of software freedom for users and developers. MongoDB is a for-profit company, chartered to serve the wallets of its owners. While MongoDB employees¹ (like those of any other company) should be welcomed on equal footing to the other unaffiliated individuals, and representatives of companies, charities, and trade-associations to the debate about the future of copyleft, we should not accept their active framing of that debate. By submitting this license to OSI for approval without any public community discussion, and without any discussion whatsoever with the key charities in the community, is unacceptable. The OSI should now adopt a new requirement for license approval — namely, that licenses without a community-oriented drafting process should be rejected for the meta-reason of “non-transparent drafting”, regardless of their actual text. This will have the added benefit of forcing future license drafters to come to OSI, on their public mailing lists, before the license is finalized. That will save OSI the painstaking work of walking back bad license drafts, which has in recent years consumed much expert time by OSI's volunteers.

Welcoming All To Public Discussion

Earlier this year, Conservancy announced our plans to host and organize the first annual CopyleftConf. We decided to do this because we seek to create a truly neutral, open, friendly, and welcoming forum for discussion about the past and future of copyleft as a strategy for defending software freedom. We had no idea when we first mentioned the possibility of running CopyleftConf (during the Organizers' Panel at the end of the Legal and Policy DevRoom at FOSDEM 2018 in February 2018) that multiple companies would come forward and seek to control the microphone on the future of copyleft. Now that MongoDB has done so, I'm very glad that the conference is already organized and on the calendar before they did so.

Despite my criticisms of MongoDB, I welcome Eliot Horowitz, Heather Meeker (the law firm lawyer who drafted MongoDB's new license and the Commons Clause), or anyone else who was involved in the creation of MongoDB's new license to submit a talk. Conservancy will be announcing soon the independent group of copyleft experts (and critics!) who will make up the Program Committee and will independently evaluate the submissions. Even if a talk is rejected, I welcome rejected proposers to attend and speak about their views in the hallway track and the breakout sessions.

One of the most important principles in copyleft policy that our community has learned is that commercial, non-commercial, and hobbyist activity³ should have equal footing with regard to rights assured by the copyleft licenses themselves. There is no debate about that; we all agree that copyleft codebases become meeting places for hobbyists, companies, charities, and trade associations to work together toward common goals and in harmony and software freedom. With this blog post, I call on everyone to continue on the long road to applying that same principle to the meta-level of how these licenses are drafted and how they are enforced. While we have done some work recently on the latter, not enough has been done on the former. MongoDB's actions today give us an opportunity to begin that work anew.

---

⁰ While Conservancy does not draft any main FOSS license texts, Conservancy does help with the drafting of additional permissions upon the request of our member projects. Note that additional permissions (sometimes called license exceptions) grant permission to engage in activities that the main license would otherwise prohibit. As such, by default, additional permissions can only make a copyleft license weaker, never stronger.

¹, ³ I originally had “individual actors” here instead of “hobbyist activity”, and additionally had expressed poorly the idea of welcoming individuals representing all types of entities to the discussion. The miscommunication in my earlier text gave one person the wrong impression that I believe the rights of companies should be equal to the rights of individuals. I fundamentally believe that companies and organizations should not have rights of personhood and I've updated the text in an effort to avoid such confusions.

[permalink]

Tags: conservancy, GPL, CLA, conferences, law, licensing, Copyleft Conf

Challenges in Maintaining A Big Tent for Software Freedom

by Bradley M. Kuhn on August 30, 2018

In recent weeks, I've been involved with a complex internal discussion by a major software freedom project about a desire to take a stance on social justice issues other than software freedom. In the discussion, many different people came forward with various issues that matter to them, including vegetarianism, diversity, and speech censorship, wondering how that software freedom project should handle other social justices causes that are not software freedom. This week, (separate and fully unrelated) another project, called Lerna, publicly had a similar debate. The issues involved are challenging, and it deserves careful consideration regardless of how the issue is raised.

One of the first licensing discussions that I was ever involved in the mid 1990s was with a developer, who was a lifelong global peace activist, objecting to the GPL because it allowed the USA Department of Defense and the wider military industrial complex to incorporate software into their destructive killing machines. As a lifelong pacifist myself, I sympathized with his objection, and since then, I have regularly considered the question of “do those who perpetrate other social injustices deserve software freedom?”

I ultimately drew much of my conclusion about this from activists for free speech, who have a longer history and have therefore had longer time to consider the philosophical question. I remember in the late 1980s when I first learned of the ACLU, and hearing that they assisted the Klu-Klux Klan in their right to march. I was flabbergasted; the Klan is historically well-documented as an organization that was party to horrific murder. Why would the ACLU defend their free speech rights? Recently, many people had a similar reaction when, in defense of the freedom of association and free speech of the National Rifle Association (NRA), the ACLU filed an amicus brief in a case involving the NRA, an organization that I and many others oppose politically. Again, we're left wondering: why should we act to defend the free speech and association rights of political causes we oppose — particularly for those like the NRA and big software companies who have adequate resources to defend themselves?

A few weeks ago, I heard a good explanation of this in an interview with ACLU's Executive Director, whom I'll directly quote, as he stated succinctly the reason why ACLU has a long history of defending everyone's free speech and free association rights:

[Our decision] to give legal representation to Nazis [was controversial].… It is not for the government's role to decide who gets a permit to march based on the content of their speech. We got lots of criticism, both internally and externally. … We believe these rights are for everyone, and we truly mean it — even for people we hate and whose ideology is loathsome, disgusting, and hurtful. [The ACLU can't be] just a liberal/left advocacy group; no liberal/left advocacy group would take on these kinds of cases. … It is important for us to forge a path that talks about this being about the rights of everyone.

Ultimately, fighting for software freedom is a social justice cause similar to that of fighting for free speech and other causes that require equal rights for all. We will always find groups exploiting those freedoms for ill rather than good. We, as software freedom activists, will have to sometimes grit our teeth and defend the rights to modify and improve software for those we otherwise oppose. Indeed, they may even utilize that software for those objectionable activities. It's particularly annoying to do that for companies that otherwise produce proprietary software: after all, in another realm, they are actively working against our cause. Nevertheless, either we believe the Four Software Freedoms are universal, or we don't. If we do, even our active political opponents deserve them, too.

I think we can take a good example from the ACLU on this matter. The ACLU, by standing firm on its core principles, now has, after two generations of work, developed the power to make impact on related causes. The ACLU is the primary organization defending immigrants who have been forcibly separated from their children by the USA government. I'd posit that only an organization with a long history of principled activity can have both the gravitas and adequate resources to take on that issue.

Fortunately, software freedom is already successful enough that we can do at least a little bit of that now. For example, Conservancy already took a public position, early, in opposition of Trump's immigration policy because of its negative impact on software freedom, whose advancement depends on the free flow of movement by technologists around the world. Speaking out from our microphone built from our principled stand on software freedom, we can make an impact that denying software freedom to others never could. Specifically, rather than proprietarizing the license of projects to fight USA's Immigration and Customs Enforcement (ICE) and its software providers, I'd encourage us to figure out a specific FOSS package that we can prove is deployed for use at ICE, and use that fact as a rhetorical lever to criticize their bad behavior. For example, has anyone investigated if ICE uses Linux-based servers to host their otherwise proprietary software systems? If so, the Linux community is already large and powerful enough that if a group of Linux contributors made a public statement in political opposition to the use of Linux in ICE's activities, it would get national news attention here in the USA. We could even ally with the ACLU to assure the message is heard. No license change is needed to do that, and it will surely be more effective.

Again, this is how software freedom is so much like free speech. We give software freedom to all, which allows them to freely use and deploy the software for any purpose, just like hate groups can use the free speech microphone to share their ideas. However, like the ACLU, software freedom activists, who simultaneously defend all users equal rights in copying, sharing and modifying the software, can use their platform — already standing on the moral high ground that was generated by that long time principled support of equal rights — to speak out against those who bring harm to society in other ways.

Finally, note that the Four Software Freedoms obviously should never be the only laws and/or rules of conduct of our society. Just like you should be prevented from (proverbially) falsely yelling Fire! in a crowded movie theater, you still should be stopped when you deploy Free Software in a manner that violates some other law, or commits human rights violations. However, taking away software freedom from bad actors, while it seems like a panacea to other societal ills, will simply backfire. The simplicity and beauty of copyleft is that it takes away someone's software freedom only at the moment when they take away someone else's software freedom; copyleft ensures that is the only reason your software freedom should be lost. Simple tools work best when your social justice cause is an underdog, and we risk obscurity of our software if we seek to change the fundamental simple design of copyleft licensing to include licensing penalties for other social justice grievances (— even if we could agree on which other non-FOSS causes warrant “copyleft protection”). It means we have a big tent for software freedom, and we sometimes stand under it with people whose behavior we despise. The value we have is our ability to stand with them under the tent, and tell them: “while I respect your right to share and improve that software, I find the task you're doing with the software deplorable.”. That's the message I deliver to any ICE agent who used Free Software while forcibly separating parents from their children.

[permalink]

Tags: conservancy, law, licensing

Software Freedom Ensures the True Software Commons

by Bradley M. Kuhn on August 22, 2018

Update (2023-11-14): Not long after publication of the post below about the so-called “Commons Clause”, Neo4j utilized that Clause to add a “further restriction” to the Affero General Public License, Version 3 (“AGPLv3”). When John Mark Suhy tried to remove it, as permitted and encouraged by AGPLv3 itself, Neo4j sued John Mark and his small company (PureThink). That case sadly resulted in multiple ill-informed judgments forbidding such removal. As SFC's Policy Fellow, I filed an expert report on the case — explaining my first-hand knowledge about the drafting of the relevant “further restriction” removal clause, but, alas, the Court has not changed its view. The case is, however, ongoing, so please watch SFC's website for updates.

The SFC remains dismayed that the proprietary “AGPLv3-only WITH Commons-Clause” has been allowed to stand as valid since 2018. If the SFC were the copyright holder of the text of the AGPLv3, or the trademark holder of the license's name, we would have intervened in this case to clarify these matters for the Court. Since the SFC did not create the AGPLv3 (my personal involvement with AGPLv3 drafting was not as an SFC employee), filing the expert report was the only action that SFC could take to assist in this matter. However, going forward, we do encourage anyone facing a “further restrictions” issue with copyleft license to contact us for support — so that those who care about the future of copyleft can coordinate a response together.

(Original post follows:)

---

Proprietary software has always been about a power relationship. Copyright and other legal systems give authors the power to decide what license to choose, and usually, they choose a license that favors themselves and takes rights and permissions away from others.

The so-called “Commons Clause” purposely confuses and conflates many issues. The initiative is backed by FOSSA, a company that sells materiel in the proprietary compliance industrial complex. This clause recently made news again since other parties have now adopted this same license.

This proprietary software license, which is not Open Source and does not respect the four freedoms of Free Software, seeks to hide a power imbalance ironically behind the guise “Open Source sustainability”. Their argument, once you look past their assertion that the only way to save Open Source is to not do open source, is quite plain: If we can't make money as quickly and as easily as we'd like with this software, then we have to make sure no one else can as well.

These observations are not new. Software freedom advocates have always admitted that if your primary goal is to make money, proprietary software is a better option. It's not that you can't earn a living writing only Free Software; it's that proprietary software makes it easier because you have monopolistic power, granted to you by a legal system ill-equipped to deal with modern technology. In my view, it's a power which you don't deserve — that allows you to restrict others.

Of course, we all want software freedom to exist and survive sustainably. But the environmental movement has already taught us that unbridled commerce and conspicuous consumption is not sustainable. Yet, companies still adopt strategies like this Commons Clause to prioritize rapid growth and revenue that the proprietary software industry expects, claiming these strategies bolster the Commons (even if it is a “partial commons in name only”). The two goals are often just incompatible.

Here at Conservancy, we ask our projects to be realistic about revenue. We don't typically see Conservancy projects grow at rapid rates. They grow at slow and steady rates, but they grow better, stronger, and more diverse because they take the time to invite everyone to get involved. The software takes longer to mature, but when it does it's more robust and survives longer.

I'll take a bet with anyone who'd like. Let's pick five projects under the Affero GPL and five projects under the Commons Clause, and then let's see which ones survive longer as vibrant communities with active codebases and diverse contributors.

Finally, it's not surprising that the authors chose the name “Commons”. Sadly, “commons” has for many years been a compromised term, often used by those who want to promote licenses or organizational models that do not guarantee all four freedoms inherent in software freedom. Proprietary software is the ultimate tragedy of the software commons, and while it's clever rhetoric for our opposition to claim that they can make FOSS sustainable by proprietarizing it, such an argument is also sophistry.

[permalink]

Tags: conservancy, GPL, CLA, law