How to win the copyleft fight—without litigation

No readers like this yet.
A diagram of a branching process

Opensource.com

The Software Freedom Conservancy's Bradley Kuhn is probably best known for his work in enforcing the GNU General Public License (GPL). Enforcement-by-litigation might get the headlines, but Kuhn treats the courts as a last resort.

A regular OSCON speaker, he returns this year to share the story of a project that avoided the courtroom. I recently spoke to Kuhn about his talk and the free software landscape at large.

When did you first get involved with free software and what makes it a passion for you?

I often say that "I came for the free-as-in-price and stayed for the free-as-in-freedom." I needed a Unix-like system for my laptop as a student in 1991. I subscribed to all the Usenet news groups about cheap or free-as-in-price Unix-like systems, such as comp.os.minix. Thus, I read Linus' original post announcing Linux a few days after he posted it. Meanwhile, I was already using GNU replacements for most of the other pieces of Unix-like systems at my job, and I was pretty excited that there might be a way to run a free-as-in-price Unix-like system on my laptop, and followed the growing distribution community.

Once "Soft Landing System" (SLS) came out in summer 1992, I could get GNU/Linux running on my laptop. It was then I started to understand software freedom was more than just zero-cost software for financially strapped people like me, but rather, everyone actually got the source code and could make changes to the software.

I continued on in my professional career, which included developing and supporting proprietary software, but I found that the lack of source code and/or the ability to rebuild it myself constantly hampered my ability to do my job. Proprietary software companies today are more careful to give "some open source"; thus, many technology professionals don't realize until it's too late how crippling proprietary software can be when you rely on it every day. In the mid 1990s, hardly any business software license gave us software freedom, so denying our rights to practice our profession (i.e, fix software) made many of us hate our jobs. I considered leaving the field of software entirely because I disliked working with proprietary software so much.

Those experiences made me a software freedom zealot. I made a vow that I never wanted any developer or sysadmin to feel the constraints of proprietary software licensing, which limits technologists by what legal agreements their company's lawyers can negotiate rather than their technical skill.

So, what day job do you do to help software freedom in this regard?

My primary daily work is as President and Distinguished Technologist at a non-profit organization called Software Freedom Conservancy (Conservancy). Unlike many other non-profits in the technology field, Conservancy is a charity, not a trade association. As such, Conservancy is legally required to serve the general public, not merely for-profit companies.

Conservancy's primary charitable work provides non-profit infrastructure for its various member projects. Conservancy acts as the formal organizational agent of its projects, handling everything as mundane as bookkeeping and reimbursing developers for their travel to speak at conferences, to enforcing Free Software licenses on behalf of our projects.

A common perception of license enforcement is that it requires at least the threat of a lawsuit. Indeed, Conservancy announced earlier this year that you're funding Christoph Hellwig's lawsuit against VMware in Germany. Tell us more about that.

As far as the actual details of that case, the lawyers always tell us not to comment in detail on ongoing litigation, so for that part, I have to simply refer readers to Conservancy's FAQ on the lawsuit.

However, I can expound on how and why we need these sorts of lawsuits. Your readers might be surprised to read that I hate GPL litigation more than anyone. It's a costly undertaking, and when your paramount goal (as Conservancy's is) is compliance with the license (i.e., proper and fair treatment of users and developers), the litigation isn't usually self-funding (particularly when you factor in the enormous amount of staff time necessary to litigate).

Simply put, Conservancy engages in GPL litigation because companies too often refuse to comply. As people can read in the aforementioned FAQ, Conservancy worked with VMware for many years, politely asking them to do the simple things that the GPL requires. VMware simply refused. We always offer hours and hours of our time to these companies to discuss and review their source releases, and explain why they don't comply with GPL. But some companies simply refuse to correct the problems. (They figure they can outspend us.) When companies become intransigent, a lawsuit is the only option remaining to achieve compliance with the GPL.

Of course, we always exhaust every option available before seeking remedy in the courts. For example, with regard to VMware, I sought assistance from a number of key trade association and for-profit company executives—including three top executives of the Linux Foundation—back in 2012 about VMware's violations. I repeatedly asked for their assistance to convince VMware to comply with the GPL, but seeking out-of-Court mediators is just futile in these situations. I warned all of these would-be mediators in 2012 that a lawsuit was imminent, but no one helped us. Ultimately, Conservancy funded Hellwig's suit in 2015.

Fortunately, the community has given a wonderfully positive response to this lawsuit. Conservancy raised just over $50,000 from the general public in response to this action, which will likely help fund this very expensive litigation. (Yes, sadly, lawsuits like this can ultimately cost that much and more!) More importantly, many Linux developers who don't even participate in Conservancy's GPL Compliance program for Linux developers have either publicly or privately given statements of support. For example, Grant Likely provided a quote in our press release, and a very high ranking Linux developer told me privately before we filed the lawsuit: "What VMware is doing is in very poor taste, and someone should really do something about it." Another high ranking Linux developer told me: "I support what you're doing, even though I can't say it publicly". Steve Hemminger even asked his former employer (who required copyright assignment to them on Steve's code) to enforce against VMware, but sadly they refused.

I thus think we have consensus in the Linux community and the broader copyleft community that litigation over GPL is an unfortunate but absolutely essential and necessary step, particularly with regard to issues where combined works are created and not released under the GPL.

Let's turn to the topic for your talk at OSCON this year. You're actually speaking about how to resolve a GPL violation without litigation. How can projects resolve violations in without litigation?

Since litigation is so time-consuming and ridiculously expensive, an underfunded charity like Conservancy must seek new ways to resolve GPL violations. Throughout my nearly 20 years of enforcing the GPL on behalf of charities and individual developers, I've constantly sought and, in some cases, devised novel ways to resolve hopelessly deadlocked GPL violations without a single document filed in a court.

(I suppose I should say "spoiler alert" here for my OSCON 2015 talk; I'll now give everyone the punchline of my talk, since I know many of your readers may not make it to OSCON this year.)

In the case I'm discussing in my talk, a company called RhodeCode developed a project initially under GPLv3. Later, RhodeCode attempted to add additional restrictions on the GPLv3. GPLv3 absolutely forbids that behavior, and RhodeCode of course violated that section (and probably others) of GPLv3.

Yet, when I discussed this with the then-burgeoning Kallithea (and existing Mercurial) community, both I and the developers were aghast when we considered options. Litigation would probably take two to three years at the least, and RhodeCode might appeal. It would also probably cost hundreds of thousands of dollars, merely to get the Court to declare more recent version of RhodeCode's software unequivocally GPLv3'd. While we were sure that we were right (and GPLv3 §7¶4 is frankly pretty plain in its requirements), we knew that RhodeCode would dispute that. Thus, for the years during litigation, adopters would wonder whether or not they really had permissions under the GPLv3.

With help of the community, we came up with a innovative solution that worked well in this case: we simply forked RhodeCode at the last GPLv3 version without this additional restriction listed, and rebranded the whole codebase "Kallithea." We now have a vibrant Free Software community, operating under a copyleft license.

Admittedly, the work, while much easier than litigation, was still substantial. We vetted almost every commit to ensure that we could, beyond any doubts, affirm that every line of code in Kallithea was licensed under GPLv3. If folks will be at OSCON, they should come to my talk to hear about all the details of that to understand what work like that entails. (I think release engineers in particular will find the material illuminating.)

A recent industry survey reported 78% of companies now use open source software. Even traditionally hostile companies like Microsoft and Apple are opening some products. Now that open source has "won," is it time for the focus to be on free software, not merely open source?

Your question reminds me of one of OSI's co-founders shouting on a conference panel in 2001: "The time for open source is over. We should start shouting freedom from the rooftops!" I took his point to heart. The only societal value of our community's activity is the that we guarantee users and developers freedom to copy, modify, redistribute, and share software. Sadly, in my experience, "open source" has never been about that. Rather, "open source" co-opts the message of software freedom.

Like most software freedom advocates, I initially thought "open source" was more or less benign. If that framing of issues and terminology helped proprietary software companies release a little bit more of their code under Free Software licenses, then I figured it was worth trying any tactic the community could devise.

However, what I've seen, particularly in the last decade, is that companies carefully developed methodologies to avoid sharing most of their software with the community, while giving lip service and occasionally allow their developers to "work upstream." I think devleopers' lives are certainly better under this regime than they were two decades ago, but "open source" has brought about only a small piece of the universal software freedom that many of us seek.

I don't think we'll convince companies to care about software freedom; they will "open source" when it behooves their business interests, and keep software proprietary when it doesn't. The real advantage we have is that developers have a lot more power than they think. I encourage developers to simply demand that they not work on any software that's proprietary: the industry has so many jobs now that it's actually possible for many to succeed in this demand. I've long said that we'd win software freedom overnight if every software developer just woke up tomorrow morning and said: "I'll never write proprietary software again."

The rise of hosted web services has changed how we interact with software, which lead to the AGPL. What new changes do you see coming that might necessitate a new paradigm?

Given that I was so directly involved with the creation of the Affero GPL (along with Henry Poole), I'm personally proud that Affero GPL addressed a need and was available early and ahead of that curve. But its history gives an interesting example of how the real challenge isn't assuring that copyleft addresses technological changes; it's that copyleft receives interest from developers and enforcement activity.

Ultimately, due to limited advocacy of the Affero GPL by myself and others, as the next generation of developers came of age in the early 2000s, they didn't even know there was a copyleft license they could use. There was never a concerted education effort to explain to the next generation of developers why copyleft mattered. I regret this as a personal mistake, but all of us should have put more work into it.

Meanwhile on grounds where copyleft does have the legal means to adequately defend software freedom, it fails to do so because so many industry parties oppose and seek to curtail community GPL enforcement. Conservancy is standing up for the GPL, but more people need to do so. An unenforced GPL is the moral equivalent to a non-copyleft license, from the point of view of the users who receive GPL-violating products.

Thus, there's not some new technological paradigm that I see coming that will demand needed changes to copyleft drafting, but rather, we need more people to chose copyleft licenses (AGPL in particular), and altruistically enforce them when they're violated. The new paradigm of companies insisting on non-copyleft licenses and opposing GPL enforcement is the key threat to software freedom today.

All of the major project hosting sites (GitHub, BitBucket, etc) now have at least some degree of proprietary components in their service. How can a purely-libre offering succeed in this space?

Online application are complex. Such applications typically combine server-side code with browser-installed Javascript—all along with certain types of data aggregation into a centralized server. The software freedom implications of such applications are certainly not identical to software copied onto one's own computer, but it's now clear that these companies like Facebook, Twitter, GitHub, Atlassian and others curtail software freedom by convincing people to centralize control of their computing through proprietary online applications.

However, mere release of code as Free Software will not solve this problem—it'd just be a first step. I'm now convinced that while licensing all online application software under Affero GPL is a necessary condition to achieve software freedom, it's not by itself a sufficient condition to achieve software freedom. The recent Gitorious Apocalypse was ultimately the litmus test: all the code that ran Gitorious is AGPL'd Free Software, yet there is no functionality to export merge requests and other meta-data. I literally had to cut and paste merge requests from Gitorious into the Copyleft.org Kallithea instance to import the data.

I believe the fundamental problem here is lack of truly distributed software systems; we've not come very far on this issue. Consider Git: while the VCS itself is distributed, most people use a centralized site to host the canonical repository, handle bug tracking and pull requests, and other such activity. While the Internet itself was initially designed for true decentralization where everyone is a first-class citizen, user apathy has allowed for-profit companies to impose centralization on us to meet their own ends (mostly to sell advertising). I suspect only software development volunteerism, focused on implementing truly decentralized, federated systems under the Affero GPL will solve this problem.

You've identified two important issues here: copyleft enforcement and development of copylefted decentralized software. Are there any other issues that you see as essential and urgent to software freedom?

We must stop ignoring the abysmal lack of diversity in the Free Software developer community. I admit that I'm a latecomer to this issue, as it wasn't until the mid-2000's when I first heard Marina Zhurakhinskaya speak about the Outreach Program for Women that I understood how insular and (frankly) sexist, heteronormative, and racially insensitive our community is. As a privileged, middle-class, Caucasian male, I have an obligation to make use of my privilege to undo that privilege. We need programs to increase diversity in the software freedom community. I was delighted that the Outreach Program for Women sought to expand, re-brand as Outreachy, and join Software Freedom Conservancy. I spent a lot of my staff time at Conservancy helping Outreachy succeed.

With the addition of Outreachy in our member project list, Conservancy truly becomes the software freedom charity with a conscience. We take on the jobs that some consider controversial but we believe are the moral and ethically correct urgent issues to advance software freedom.

OSCON
Speaker Interview

This article is part of the Speaker Interview Series for OSCON 2015. OSCON is everything open source—the full stack, with all of the languages, tools, frameworks, and best practices that you use in your work every day. OSCON 2015 will be held July 20-24 in Portland, Oregon..

User profile image.
Ben Cotton is a meteorologist by training, but weather makes a great hobby. Ben works as the Fedora Program Manager at Red Hat. He is the author of Program Management for Open Source Projects. Find him on Twitter (@FunnelFiasco) or at FunnelFiasco.com.

1 Comment

Really great questions and answers.

Thank you!

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.