DEV Community: Luis Villa

Will the new judicial ruling in the Vizio lawsuit strengthen the GPL?

Luis Villa — Mon, 15 Apr 2024 20:16:00 +0000

Last week an important judicial ruling came down on a very intriguing case about open source license compliance. In this post, I'll talk about what makes it so interesting and potentially impactful across our industry.

Legal background

Traditionally, open source licenses have been enforced through the law of copyright. In other words, the key question has been did copying occur, and if so, were the rights of the author violated? This has a subtle, but very important effect: only the author can initiate the lawsuit. In addition in the United States, such lawsuits must be filed in federal court, rather than in state courts, and the remedies available are primarily financial.

However, arguably, open source licenses could also be enforced through the law of contracts. Contracts can be about copyright, but in general they are a different beast. In the United States, remedies for contracts can include what is called "specific performance”—in other words, a judge can order someone who has broken a contract to do a specific act. Contracts also are typically enforced through state courts, not federal courts.

Finally, and most importantly for our discussion today, contracts can—under certain conditions—be enforced by third parties. These parties are known as third-party beneficiaries. Because they benefit from the contract, they can sometimes enforce the contract. For example, if I signed a contract with a baker to deliver a cake to my mother, my mother would be able to sue the baker if the cake did not arrive.

The Vizio case

In October of 2021 the Software Freedom Conservancy (SFC) decided to launch what is believed to be the first significant open source lawsuit based in contract rather than in copyright. Critically, the SFC’s case argued that anyone who benefits from the General Public License (GPL), not just the authors of the software, should be able to bring a lawsuit to enforce the terms of the GPL.

This case was brought in Orange County, California against Vizio, a large TV manufacturer. Like most TVs these days, Vizio TVs include Linux and a lot of other open source software that is under the GPL. The GPL says that buyers of those TVs should be able to get copies of that source code, so SFC walked into a store in Orange County, bought a TV, and requested copies of the source code. Vizio did not comply with the request, and so SFC brought suit.

To win their case, SFC knew that they would have to jump through several hoops. The most obvious one was the imbalance in resources—Vizio’s law firm makes about as much in a day as SFC makes from donations in a year. (You can buy a t-shirt if you want to help.) But there are a lot of legal barriers too.

Under U.S. law, the first hoop was that they had to prove that the case was not a copyright case. This is because, under a doctrine known as preemption, state courts generally cannot rule on questions of federal law, like copyright. They won that in May of 2022, and then the case turned to the next question.

(I realize it sounds odd to say that a case about software licenses is not a copyright case. The legal issue there is shockingly complex, so I won’t go into it much here. The short version is that, by asking for specific performance (a contract remedy) rather than financial penalties (a copyright remedy), and by claiming violations of rights granted by the contract (the license) rather than rights granted by copyright, the federal court found that this was a contract case and not a copyright case.)

The question in last week’s ruling

Last week’s ruling was primarily about the next important question in the case, what’s known as “standing.” Courts, for fairly obvious reasons, don't like to have random people in the courtroom. So they have developed the question of standing: do you have the right to even launch the lawsuit at all? In contracts, the question of standing is usually easy: are you one of the parties named in the contract or not?

Third-party beneficiaries add a small wrinkle to this: if a third-party is named in the contract, and the parties who signed the contract intended for that third-party to benefit from the contract, then the third party might have standing.

Here, Vizio attempted to argue that the state court should end the case because SFC was not a third-party beneficiary, and so had no standing. This question is, for open source license enforcement, a truly revolutionary one. Depending on how the court answered, the tradition that only software authors could enforce open source licenses would be maintained, or the dam would break open—and anyone who buys hardware with the Linux kernel in it would have the right to sue.

It is important to note that at this stage, Vizio was (in essence) arguing that SFC’s case had “no merit” and so no reasonable person could find SFC to be a third-party beneficiary. If the court agreed, the case would then end. But if the court found reasonable people could disagree then the case would proceed.

The court’s ruling

For such a potentially revolutionary holding, the court’s argument is quite short and to the point. First, the court rehashed the question of whether this is a contract claim or a copyright claim. Ultimately, it agreed with the federal court last May that despite being about a copyrighted work, the claims made fall into the category of contract rather than the rights and remedies of the Copyright Act.

That left the question of standing—since the California court is going to treat this like a contract, is SFC a third-party beneficiary who can bring a claim? Quoting an earlier California case, the court said that the third party must show three things:

the third party would in fact benefit from the contract;
a motivating purpose of the contracting parties was to provide a benefit to the third party; and
permitting the third party to enforce the contract is consistent with the objectives of the contract and the reasonable expectations of the contracting parties.

Vizio “did not dispute” the first two questions, focusing instead on the “expectations” of the contracting parties. Relying on the Free Software Foundation’s (FSF) GPL FAQs, it argued that the FSF never intended for third parties to enforce the contract, and therefore the parties to the contract could not have intended it. The court was harsh here:

“much of Defendant Vizio’s argument is based on inadmissible evidence, and there is no competent evidence that suggests that the intent of FSF was to preclude recipients of the source code as beneficiaries to the GPLs.”

To divine the objective of the contract, the court used the sophisticated technique of “read it.” And so we end up with the judge quoting the GPL directly, including

“you must give the recipients all the rights that you have”

and that distributors must provide

“a written offer … to give any third party … a complete machine-readable copy of the corresponding source code”

Not surprisingly, in an argument about third party benefits, the court found that last point particularly persuasive, since it spells out the benefits that must be provided to “any third party.”

The court, then, did not mince words:

“Allowing third parties such as SFC to enforce their rights to receive source code is not only consistent with the GPLs’ objectives; it is both essential and necessary to achieve these objectives. Recipients of GPL-licensed software will be assured of their right to receive source code only if they have standing to enforce that right.”

At this stage of a case, judges are generally inclined to insert phrases like “giving the benefit of the doubt.” Because they are talking about what reasonable people might believe, they also often say “may” and “might.” In that context, the statement that third party enforcement is “essential and necessary” jumps off the page.

The judge follows this up with an economic analysis based on California case law. Again, they find this supports SFC, saying that if only copyright holders could enforce, they “would have no economic incentive to enforce ... because they would bear all the enforcement costs with no real benefit themselves.” This is again quite strikingly strong language—no “arguably” or “maybe” to be found.

The court ultimately concludes that the question of whether SFC is a third-party beneficiary is a “triable issue of material fact,” which is lawyer-speak for “reasonable people might disagree about what happened, so we should go to trial to figure it out.”

What is next?

The judge’s simple and straightforward ruling suggests that changing the judge’s mind on this point will be an uphill battle for Vizio. In this light, the judge’s note about how much of the evidence was “inadmissible” and not “competent” is particularly harsh. The evidence in this brief was presumably the best written evidence that extremely good lawyers could find, so Vizio will have to try other routes to show the judge what the “reasonable expectations” of the “parties” were. Since Vizio presumably relied on the best public documents they could find, it wouldn’t surprise me if they ask Linus to talk about his expectations when he put the kernel under the GPL.

Before we get there, though, SFC has asked the court to rule on whether the contract (the GPL) creates a “legal duty” for Vizio to “share source code with SFC as provided by the GPLs.” In essence, SFC is saying that (given the text of the GPL) the court already has all it needs to know about the nature of the duty, and so if there is a trial, it should be merely about the scope of the duty, not its existence. Here, the benefit of the doubt will go the other way, with Vizio only needing to prove that there are questions about that duty best settled in a full trial. I suspect the court will find that there is a duty to provide source code, but allow the trial to settle the important question of how much source code.

Possible impacts

In some sense, not much has changed: if you were obligated to comply with the GPL two weeks ago, you have the same obligations today. If you didn’t have obligations then, you don’t have them now.

What has changed is who can enforce those obligations. Two weeks ago, we mostly believed that enforcement could only come from the authors of the code. Those folks rarely had time, money, or interest for litigation, and they might also face a lot of pressure from their peers and employers to avoid litigation.

If this ruling holds up at the end of the case, the number of potential enforcers just went way up. The limitations on financial claims will (probably) not make this a lucrative line of mass litigation, but a threat letter from the SFC or similar groups will carry much more weight. One could easily imagine other activist groups using similar arguments to free source code to systems they oppose, like surveillance systems or locked up trains. I’ll continue to watch this case closely, but for now we should see this recent ruling as welcome news for those who believe in the importance of staying true to the original principles that led to the creation of the GPL in the first place.

Upstream is June 5, 2024

Luis Villa — Wed, 10 Apr 2024 09:08:00 +0000

Improving the health and security of open source is an old problem. In the past 25 years companies have been formed, foundations have been funded, treatises have been written, and standards have been created, all in the name of making open source software more secure and resilient.

Yet, here we are in 2024 and the security and resilience of open source is still not a solved problem.

In fact, one might argue that, despite all of the sound and fury invested in improving open source security, that the situation is more dire than ever. Rising consumption of open source further stresses an already strained system that sees large enterprise users relying heavily on open source projects created and maintained by volunteers. The increasing popularity of open source has also made it an even more tempting target for those who seek to exploit it, and highly visible vulnerabilities like Log4Shell have only added to the pressure.

For Upstream 2024, we’ve chosen the theme “unusual ideas to solve the usual problems.” This year’s event will be fully virtual again, taking place Wednesday, June 5, from 11 a.m. ET to 5 p.m. ET. You can RSVP now!

Our goal for this year’s event is to curate a set of presentations and conversations featuring those who are pursuing exciting new approaches to improving open source health and security, those who are attacking a very old problem in very new ways.

We’ll bring together open source maintainers and those who use their creations alongside government leaders, thought leaders, while also gaining inspiration from visionaries tackling parallel challenges in other fields.

Our hope is that those who attend come away refreshed, rejuvenated, and with new energy to tackle ensuring the security and resilience of the open source software we all depend on in new, unusual, and exciting ways.

We look forward to seeing you there!

Announcing the Upstream podcast

Luis Villa — Tue, 16 May 2023 21:23:47 +0000

Open is 1️⃣ all over and 2️⃣ really interesting and yet 3️⃣ there’s not enough media that takes it seriously as a cultural phenomenon, growing out of software but now going well beyond that.

And so, announcement: I’m trying to fill that hole a little bit myself. Tidelift's new Upstream podcast, which I’m hosting, will:

Pull from across open, not just from software. That’s not because software is bad or uninteresting, but because it’s the best-covered and best-networked of the many opens. So I hope to help create some bridges with the podcast. Tech will definitely come up—but it’ll be in service to the people and communities building things.
Bring interesting people together. I like interview-style podcasts with guests who have related but distinct interests—and the magic is their interaction. So that’s what we’ll be aiming for here. Personal goal: two guests who find each other so interesting that they schedule coffee after the recording. Happened once so far!
Be, ultimately, optimistic. It’s very easy, especially for experienced open folks, to get cynical or burnt out. I hope that this podcast can talk frankly about those challenges—but also be a recharge for those who’ve forgotten why open can be so full of hope and joy for the future.

So far I’ve recorded on:

The near past (crypto?) and near future (machine learning?) of open, with Molly White of Web 3 Is Going Great and Stefano Maffuli of the Open Source Initiative. Get it here! (Transcripts coming soon...)
The joy of open. At Tidelift, we often focus on the frustrating parts of open, like maintainer burnout, so I wanted to refresh with a talk about how open can be fun. Guests are Annie Rauwerda of the amazing Depths of Wikipedia, and Sumana Harihareswara—who among many other things, has performed plays and done standup about open software. Will release this tomorrow!
The impact of open on engineering culture, particularly at the intersection of our massively complex technology stacks, our tools, and our people. But we are often so focused on how culture impacts tech (the other way around) that we overlook this. I brought on Kellan Elliot-McCrea of Flickr, Etsy, and Adobe, and Adam Jacob of Chef and the forthcoming System Initiative to talk about those challenges—and opportunities.
The relationship of open to climate and disasters. To talk about how open intersects with some of the most pressing challenges of our time, I talked with Monica Granados, who works on climate at Creative Commons, and Heather Leson, who does digital innovation — including open — at the IFRC’s Solferino Academy. I learned a ton from this one—so excited to share it out in a few weeks.

Future episodes are still in the works, but some topics I’m hoping to cover include:

open and regulation: what is happening in Brussels and DC, anyway? Think of this as a follow-up to Tidelift’s posts on the Cyber Resilience Act.
open and water: how does open’s thinking on the commons help us think about water, and vice-versa?
open and ethics: if we’re not technolibertarians, what are we anyway?

I’m very open to suggestions! Let me know if there’s anyone interesting I should be talking to, or topics you want to learn more about.

We’ll be announcing future episodes here and through the normal Places Where You Get Your Podcasts.

Tidelift can help with legal support for lifters

Luis Villa — Tue, 07 Mar 2023 17:53:54 +0000

Hi, all! A lifter recently received a DMCA notice, asking that they take their package down. We reached out to offer support. Thankfully, our support was not needed. It did remind me, though, that it's been a long time since we mentioned to you that—just like we help you with security—we can also help if your package receives a legal question of some sort.

Why?

This is probably obvious, but part of why our customers pay us is to make sure your package stays available, and ensure that they can use it legally. Both Tidelift and our customers are happy to help if you get legally challenged!

Examples, including how we can help

Here are a few situations where we can help you out.

Licensing: Don't understand how a copyleft dependency impacts you? Need to know how multiple permissive licenses work together? Or why GitHub's scanner isn't seeing your license information? Let us know and we can help you promptly.
DMCA: The Digital Millennium Copyright Act provides a way for copyright owners to get infringing materials taken off hosting services, often called "takedown notices". It isn't common, but these notices can be directed at package hosting services like PyPi. If you get one of these, let us know—we may be able to help directly, or to put you in touch with other attorneys or with the package ecosystem's legal team.
Patents: Claims of patent infringement by open source projects are thankfully quite rare, but are impactful when they do happen—for both you and customers who use your software. Please let us know when and if this happens to you. Among other things, we are a member of the Open Invention Network and can help you connect with them or other community resources.

If you get other legal questions about your package that don't fall into one of these buckets, reach out and we’ll do our best to assist you.

Limitations

Tidelift can't be your attorney, so that may sometimes limit how we can work with you. If we need, we can always help you match up with other attorneys, and we may be able to help support your costs in a legal defense as well.

How to reach out?

If you do find yourself in a legal situation, the best way to reach out is to simply tell lifter@tidelift.com that you’d like to check in with Tidelift about a legal question. (If the issue is public, like many licensing issues are, feel free to include a link!) The team will figure out the best way for you to talk to us, making sure we do our best to protect your confidentiality.

Washington, DC, and open—for maintainers

Luis Villa — Fri, 14 Oct 2022 17:20:01 +0000

Some of you may have seen that open source has been in the news coming out of Washington, DC lately, with open source security in particular getting increasing attention from the White House and (two weeks ago) the US Senate.

In this post, I'm going to try to briefly run down what this news means for maintainers.

Why is this happening?

After the Log4Shell and SolarWinds software supply chain vulnerabilities, the US Government has begun to grapple with the fact that it is one of the world's biggest consumers of software. This makes it a big target for hackers. So it's been rapidly trying to figure out what it should do to protect its software infrastructure.

What's the focus, so far?

To date, the primary thrust of the various US Government activities has been understanding the scope and scale of this problem. You can see this, for example, in a recent White House memo, which calls for (within 180 days!) a creation of a registry of what open source is being used within the government. Similarly, the recent US Senate bill is very focused on creating standards to help understand how secure (or insecure) the most important software is.

What's not the focus, so far?

No one, yet, is talking about imposing specific solutions, or forcing open source developers to do anything. The NIST is not going to be calling you up and telling you to enable two-factor auth, and the CIA is not going to demand you use Rust. So don't lose sleep over that. But governments often gather data as the first steps towards creating regulation. So it's important for us not to panic, but also to get this data gathering right as early as possible, before regulations are drafted.

What's good here?

I think there are a few very important and positive things here, even if you're skeptical of the current state of the US government:

The US government is getting real about security: Software (not just open source!) really does have a security problem; we have often traded security for convenience or efficiency. The best time for that discussion was twenty years ago and the second-best time for it is now.
The US government is getting real about resourcing: Open source software in particular really does have a resourcing problem—the non-profit package managers, for example, have limited resources to improve their own security scanning or other metadata. Bringing federal government resources to bear may help, especially in areas that traditionally have free-rider or collective action problems. Solving those sorts of problems is literally what government is for!

This is only two bullet points, so this seems like a short list of "good", but each of these are huge for the future of open source. So please take my concerns, below, in this extremely positive context.

What concerns are there?

While overall I'm optimistic about this activity, I have a few concerns.

In particular:

Is the problem open software, or all software? The recent US Senate bill talks about the problems "unique to open source" but then prescribes standards that should apply to all software, like use of multi-factor auth and memory-safe languages. It would be a very bad outcome if open source is held to a higher standard than proprietary software---these efforts should be careful to distinguish between the deep problems of all software, and those problems specific to open source.
Tradeoff of speed and flexibility/nuance: The government is moving quickly here, as it probably should, but it must do that while retaining flexibility to adapt as the underlying open source communities evolve. It must also avoid a one-size-fits-all approach, since different communities have different security requirements and practices, often well-adapted to their languages and use cases. A government (or business!) policy that doesn't recognize those nuances will fail to improve security.
Balance of spending: Traditional open source security techniques have emphasized scanning tools, and often not emphasized supporting developers to fix the issues uncovered by those tools. The US Government is in a unique position to fund a transition from "find the problems" to "find and remedy the problems"! There are promising signs of this, but more awareness needs to be built and the open source community can help. (And the current bill is a purely 'unfunded mandate'—rules, with no money attached.)
Listening to communities: The recent US Senate bill is very specific that communities should be consulted, which is great, but it should specifically call out the important and unique role of 501(c)3 (public benefit) non-profits in our space. I hope those organizations can step up in this important moment (and I'm particularly proud that Tidelift partners with several of them!)

It's worth noting that all of these have clear paths for improvement! So work needs to be done. But it can be done.

What about other governments?

Since maintainers (and Tidelift-partnered lifters) are all over the world, this is a very fair question! I'll be writing more about this soon—there's definitely work underway that we're keeping an eye on, including EU announcements last year on supply chains and last week on software
liability.

What is Tidelift doing?

We're doing a couple of things.

Monitoring: We're keeping an eye on, well, everything. And trying to write about it as much as we can! Here, for example, is a recent post I wrote about the new proposed legislation. And here is one our CEO Donald Fischer wrote about [the new Office of Management and Budget guidance for organizations building applications with open source.
Advising: Last year, we filed a response to a US Department of Commerce request for comment, pointing out that uptake will be slow if maintainers aren't compensated. We will continue to look for opportunities to present the interests of maintainers, both formally and informally.
Standards-building: To their credit, the US government does seem dedicated to learning from work the open source community has already done. So we are working hard with our maintainer partners to adopt and improve these industry standards, making them a better basis for future government action. In particular, we are working directly with maintainers to validate which of the new proposed industry standards will have the most direct and immediate impact on improving open source software security and resilience, and paying maintainers to implement these standards first. If you're already a Tidelift maintainer partner and want to participate, keep an eye out for more details on that; if you're not, apply now!

What can you do?

I hate to ask maintainers to do more work, but there are a few things
that might be helpful.

Contact your 501(c)3s: If you're a member of a software community 501(c)3, reach out to them about this and ask what they're doing. Obviously they're all stretched thin---but they need to have an eye on these new government initiatives.
Give feedback on new security standards: The various security standards like OpenSSF Scorecard and SLSA.dev can be a lot to digest, but they are likely going to be very influential in developing government standards. Take a peek at them, and if you have concerns or questions, file issues. The people behind them want to hear from a broad range of maintainers, so your feedback really does matter. (If you're a Tidelift maintainer partner, you can also bring the feedback to us—we are participating in these discussions, and may be able to either point to existing discussions, explain them more deeply, or bring your feedback to the appropriate places.)

And of course feel free to ask questions here on our forum or via dev.to—I'm busy but would love to chat more about this with maintainers.

What I learned from the Server Side Public License

Luis Villa — Wed, 17 Mar 2021 14:23:10 +0000

When the Server Side Public License (SSPL) was submitted to the Open Source Initiative (OSI), many people criticized it, and the license was eventually withdrawn. A key cause of the criticism was that it was drafted by a for-profit company (MongoDB). I, and others, pushed back—arguing that the nature of the company should be mostly irrelevant to the evaluation of the license.

Now, in the wake of SSPL’s adoption by Elastic, I realize I was partially wrong. In this post, I’ll cover why many aspects of the “living license” outside the plain text, including company engagement, should be considered by OSI, and give some recommendations that I hope will be useful to both OSI and future license authors.

OSI’s standards—in writing and in practice

You won’t find “who wrote the license” anywhere in the Open Source Definition. When the Open Source Initiative evaluates a license, the license should, in theory, stand on its own. If it is good, it gets approved; if not, it doesn’t. The OSI also has a long history with important licenses sponsored by large for-profits, including Netscape, Sun, IBM, and even Microsoft. And the current license submission process (which I significantly revised while I was on the OSI Board of Directors) does not ask license submitters about their corporate form or governance.

Despite these rules and history, when SSPL was originally submitted to the OSI in 2018, there were several important concerns raised. But the loudest critique (or at least the one I found the most frustrating at the time) was a claim that, regardless of the text, MongoDB should be distrusted as a license steward.

I’ve now realized that my frustration at this was subtly, but importantly, wrong. It’s still true that “was this written by a for-profit company?” is a bad test, and OSI should rarely, if ever, consider this factor. But as I wrote about in my last post, a written license (especially one that seeks to push the boundaries of what we do with licenses) is part of something broader, analogous to a movement or product launch. Since the license is, in this sense, a “living document,” I was wrong to say that OSI should only focus on the text. Instead, I now believe that, especially for new or innovative licenses, OSI should (carefully!) consider factors outside the text. Here’s how that could have applied to SSPL.

Non-license factors OSI could and should have considered

So what should OSI have thought about when SSPL was submitted? If we take the OSI’s proper focus as the living license ecosystem, not just the static license text, here are a few things we can learn. In the interests of brevity, I won’t address every topic from my last post (on “writing a successful license”), but here are a few that particularly jump out:

Dual-licensing’s warped incentives for license stewards: A good license steward has strong incentives to clarify and enhance the license over time, through investments in things like education, training, etc. In contrast, a license steward who plans to use a license as part of a dual-licensing scheme has every incentive to make the license worse, by having sales teams who create fear about their own license, and having a disincentive to create educational material that improves the understanding of the license over time.
"There are many AGPL projects where you literally can't pay someone money to avoid the AGPL. There are zero SSPL projects in the same position."
— Matthew Garrett (@mjg59) January 28, 2021
So it could be appropriate for OSI to inquire about dual-licensing plans, and reject a steward who has no plans to single-license under the proposed license.
Developer evangelism: If the purpose of an innovative license is to make a particular change in the world, people have to use it. And that means the license author has to do work to reach out to potential users! OSI could have asked MongoDB about their plans to encourage developer adoption, and the answers might have been revealing. (For example, outreach exclusively to other AWS competitors using a dual-licensing model might have said one thing; good-faith outreach to the FSF or other community-backed SaaS projects, like Mediawiki, might have said another.)
Iteration and improvement: When the Cryptographic Autonomy License was first submitted to the OSI, it was explicitly as a beta, with clear expectations that OSI’s input would be considered before the license reached 1.0. This demonstrated a good-faith intent to iterate the license in a manner consistent with the goals and purpose of the Open Source Initiative. In contrast, the SSPL was submitted as “1.0” and, to the best of my knowledge, neither MongoDB nor anyone else has adopted the subsequent versions of the SSPL.
Lawyer education: How seriously you take lawyer education is a good signal of how seriously you take your license, since lawyers are a key audience for use and deployment of the license. If lawyers understand the license, developers and organizations will be able to use it in the way you intend; if they don’t understand it, the license will be shrouded in uncertainty and doubt—or worse, it just won’t be used at all. It’s hard to do this before a license is finalized, but certainly not impossible.

Doing it better next time

At the end of the day, a standardized license text cannot prevent a malicious copyright holder from forking a project into a proprietary license. This is true regardless of the scope of copyleft (as long as there is a CLA in place), and indeed happens all the time with non-copyleft permissive licenses like Apache! OSI also can’t see into the future, or read into the hearts and minds of a corporation. These facts make it very hard to say “OSI should not approve licenses that support dual-licensing."

So instead of trying to divine what lies inside the secret heart of a company, or enforcing an unwritten rule that only the FSF can expand the scope of copyleft, what reasonably objective standards could OSI fairly use to assess the potential future stewardship of a strong copyleft license? I’ll suggest the following standards:

Pre-OSI public discussion and iteration: I’ve previously proposed that, as a matter of good drafting, OSI should require that the author solicit public feedback on a license for some time before submitting it to OSI. I still think this would be good for drafting quality, and I now also think it would also be good for assessing how seriously committed a license author is to the hard work that goes with a good-faith strong copyleft license—including education, network-building, and drafting.
Adoption from non-author projects: Imagine if a license’s submission contained the phrase “We, project X, support the expressed purpose of this new license, and would strongly consider switching our project to it if OSI approves it.” The hard work of convincing another existing project to make a statement like that is a good sign that the steward intends to be a steward and not just a dual-license troll. (It’s possible that, as a practical matter, this would be the death knell for for-profit-sponsored licenses, since few communities would be excited to place their future in the hands of a for-profit. But by asking it in this way, the question is asked of projects that have their own code and reputation on the line, instead of asking OSI to guess whether it will be adopted or not.)
Evaluating other governance components: Simon Phipps aptly calls the “give lots of rights early, and then remove rights later” model the “rights ratchet.” In a complementary Twitter thread Tobie Langel noted that for the rights ratchet to work, there must be (among other things) a weak community and centralized trademark control. It’s possible that, where there is a plausible case that the license is a bad-faith attempt to execute a rights ratchet on a particular project or group of projects, OSI could evaluate the overall state of those projects and attempt to understand what other structures have been put in place to reduce the risk. For example, if a project has a strong community of contributors from other companies (perhaps supported through Tidelift!), or has trademark policies in place that would protect the existing community’s ability to fork, this might reduce concerns about whether a shift to an innovative license is legitimately intended to increase openness.

Some of these tests would be easy for OSI to check for (in fact, in some ways easier than existing unwritten rules around drafting quality!), while the last would be a lot of work. At the same time, it’s also something that a good-faith license submitter could consider beforehand—and I suspect would eliminate a lot of bad-faith argument on all sides.

SSPL version 1, as submitted, would likely still have failed these tests. In particular, the controversial language it used that could have extended even to an entire operating system would likely not have made it through any genuine community-based pre-OSI review process. And to date the only projects adopting it have also been via companies executing a “rights ratchet,” rather than any non-corporate communities.

The bottom line: licenses are living documents, and we should evaluate them that way

I was wrong that the open source license review process can’t look at the author, because the success or abuse of a license is predicated on a broad set of factors outside of the license text. At the same time, by looking at these broad factors thoughtfully, we can create better tests than the ones we’ve got—and hopefully encourage future license authors to respect them!

So you want to write a successful license

Luis Villa — Wed, 24 Feb 2021 18:09:45 +0000

In early 2020, when international travel was still a responsible thing one could do, I gave a talk on "what makes a license successful" at FOSDEM in Brussels. I then wrote a blog post about it, got some writer's block, and never finished it. But recent interest in the topic, and specifically on what lawyers can (or can’t) contribute to the success of a license, made me decide to dust it off and hit publish. You can think of this post as the questions I would ask, and the advice I would give, to anyone seeking to promote new, innovative licenses, of any sort.

Tidelift disclaimer

Tidelift believes that the best way to increase the use (and profitability) of open source is to minimize points of friction and so, when appropriate, we’ve criticized new licenses. At the same time, we want to empower developers to support themselves in a way that works for them.

So this blog post (and the talk before it) are neither an endorsement nor a rejection of new licenses. Rather, I hope it’s a useful reference checklist that will help some folks new to the licensing space realize how big a challenge they face, while constructively helping the most dedicated reach their goals effectively.

What is license success?

In my mind, outcomes for a license that seeks to change developer behavior (as copyleft did and ethical licensing seeks to do again) can range from:

vanishing into the giant battlefield of information overload without a sound
stimulating discussion, without actually seeing much adoption
getting adopted by enough software to actually have an impact at the margins
actually changing an industry

It's entirely likely that the GPL’s trick of doing #4 is no longer possible, because the industry is too vast. ("It is easier to imagine the end of the world than the end of capitalism," but for software...) I am perhaps naive enough to think #3 might still be possible, and this post is written with that in mind. (If you’re going for #2—stimulate discussion—at least some of what is below will apply, but some will not, so be realistic if that’s where you think you want to be.)

TL;DR: Movement building, or product marketing—take your pick

Here's the thing: Public-use licenses are not like other legal documents, which tend to be drafted by clients who badly need the document, memorialized, and then forgotten about until something goes very wrong.

Instead, public-use licenses are like a product: they must find (or sometimes create) a market, often with “customers” who don't know the product exists; they must evolve as the “customer” and market evolves; they must find advocates and mollify doubters (or sometimes even actively fight enemies).

These things (and more) are not qualities a legal document, by itself, can have. They're qualities of movements, or, if that word scares you, qualities of good product management. So, the question you have to ask yourself, if you’re thinking about writing an innovative license, is “do I want to do the hard work of building a long-term movement?”

Drafting the document itself

Let's get this one out of the way. There have been a lot of words written (ironically!) about clarity in license and contract drafting, including by me. I do love great, clear writing! But here's the thing: drafting almost certainly doesn't matter. Or at least, "perfect" drafting is unnecessary.

GPL v2: When introduced, it was widely considered by attorneys to be badly drafted and possibly unenforceable. And yet it was hugely successful.
GPL v3 and MPL v2 were much better drafted than GPL v2, and yet have seen relatively slower adoption, each about a decade in.
There are a variety of new, better-drafted permissive licenses (Intel’s BSD+Patent, Oracle’s Universal Public License, Blue Oak Model License, etc.). Yet, they have poor adoption relative to the literally comically drafted WTFPL, much less "antique" licenses like BSD and MIT.

It is true that there is probably a minimum competence level that must be met when drafting new licenses. A license can't have glaring, total failures (though I have publicly written that open data licenses are borderline unworkable, and they are nevertheless powering a multi-billion-dollar industry). Despite that, I now suspect that the optimal level of time spent on drafting is closer to 1-3 intensive months than the 1-3 intensive years some recent licenses have taken.

Unfortunately, "work less on drafting" is about the only time-saving advice I'll offer in this post—the rest is a long, hard slog that will be familiar to movement (and product) builders.

Documentation and education (for lawyers)

Here's what takes the place of perfect drafting: good documentation and education. Unfortunately, this is not something you can write once and drop somewhere—it is an ongoing process, over a period of years.

The challenge here is that lawyers essentially have veto power over widespread license adoption, because of their role in corporate approval of new licenses. If they don't like or understand your license, it will go nowhere in corporate usage, and even the most firmly anti-corporate licenses typically require at least some corporate adoption to spur investment and influence for your license and the ideals it espouses.

Lawyers don't have to like the license; like a lion tamer, they're willing to take their chances if they have the right tools and the right reasons to be in the cage with the lion. But they must know the lion they're getting in the cage with, and have reason to believe they can work with the beast on its terms.

So consider:

How will lawyers learn about your license, once their developers come to them with a leading app released under your license (about which, more later)? Will it be just by reading the license, or will there be supplemental material that explains intent, context, etc.?
How will you revise and supplement that learning as your understanding of the license evolves? In other words, your drafting will have mistakes, because you're human. How will you address that once your mistakes are found?
How will you actively oppose lawyer-focused FUD about your license? Because, if you're trying to change the world, well-paid lawyers will come after your license. You will need to have time and resources committed to fight back, lawyer-to-lawyer.

GPL v2’s 22,000 word FAQ, while imperfect, is the pre-eminent example of how ongoing education and explanation can work to assuage legal concerns. And it’s a great reminder that a license is an ongoing, contextual work: as corner cases are discovered, and as the underlying technology changes, communicating how the sponsor thinks about the license is important.

(This speaks directly to the question of movement-building. If you can’t say who will be maintaining this sort of documentation in 5-10 years, and aren’t ready to make that commitment yourself, you might not be the right person or organization to be writing a license.)

Vision and evangelism (non-lawyers)

But let's be real—lawyers aren't what make or break a license, either. You're doing this because you have a vision of a better world, and you think licensing is a useful tool to help work towards that vision.

You need to ask yourself —which developers are motivated by your vision? What are they motivated to do? Adoption of innovative licenses requires individual developers to be motivated to do some work, and take some risks. Is the vision of your license speaking to the people who can do that work and take those risks? How are you teaching them about the size and nature of the risk (which may be a lot smaller than they think)? Are these developers already at known watering holes? How are you preaching to those not yet converted?

GPL v2 was backed with very effective messaging and evangelism by Richard Stallman and the Free Software Foundation. In contrast, Stallman all but actively campaigned against AGPL v3, repeatedly stating that all network services (regardless of license) were a bad idea, and keeping network/SaaS terms out of the “main” GPL v3 despite the sea change in the industry between the release of GPL v2 and v3. Given that stark contrast, it is no surprise that AGPL v3 has mostly failed to attract any organic adoption.

This is essentially a movement-building challenge (or, if you prefer, a marketing challenge). When you go to a lawyer to help you write a license, you should already have a pretty clear strategy in mind for this.

App that drives understanding

For a license to really have an impact, you probably need an application released under that license that will be unavoidable, and therefore force lawyers, businesses, and developers to understand the license.

Linux and MySQL were of course those unavoidable apps for GPL v2. To the extent MPL v2 has been successful at all, it is almost completely because Firefox forced a huge community of people to get comfortable with it—and some became fans and evangelists themselves.

For a long time, I thought Mongo was such an app for AGPL v3, and would cause more people to learn about (and therefore eventually become comfortable with) that license. But in writing the Brussels talk that gave birth to this blog post, I realized why this apparent contradiction was not a contradiction at all: Mongo drove lots of awareness of AGPL, but very little understanding, because Mongo preferred uncertainty and lack of understanding. As a result, despite being leading users, they were not leading advocates. (This suggests that an org that wants to publish an innovative license should consider what happens when the leading app is actually hostile to the license.)

That said, it is useful to keep in mind that an unavoidable app may not be enough. The Open Database License is a useful counter-example. Open Street Map is the second-biggest open culture project, after Wikipedia, and has caused many lawyers to read the Open Database License. But the license is nevertheless not widely liked or adopted, and arguably not particularly impactful overall. This is a good reminder that even extremely successful products can only do so much if other pieces of the puzzle aren’t in place.

Partnerships

If you’re innovating to act on a moral and ethical vision of some sort, presumably you’re not the first person to have that vision—or at least something like it.

What is your strategy, as a license innovator, to find and use those partnerships?

The GPL succeeded in large part because IBM made a conscious choice to use the Linux kernel, and invested in many things around the GPL as a result. Perhaps, in writing the next generation copyleft, or a new ethical license, you don't trust IBM, but consider who will be the big partner who publicizes your license (or just as likely, the leading apps under those licenses).

For example, I suspect we'll all have to take the various carbon licenses (like the Atmospheric License) more seriously when they’re able to partner with one of the existing carbon divestment initiatives to help them properly define the problem, and work with existing communities (which likely include some programmers!) to drive developer engagement. In your ethical challenges, who are those partners? What knowledge can you gain from them? What existing communities can you lean on?

Governance

In a topic I can’t believe I didn’t have in the original talk, it’s important to mention license governance. If you’re just throwing a permissive license over the fence, governance matters less. If you’re trying to innovate, odds are high you’re going to have to make judgment calls—including possibly publishing new versions. And that requires reassuring potential users about how those decisions are going to be made, not just before the license is published but for a long time afterwards.

The governance model for a license need not be particularly complex; the reality of movements, including some of the most successful open source licenses, is that “charismatic authoritarian decision-maker” has a relatively long history of success. But in this day and age one likely has a better chance of success if one can at least explain what governance infrastructure is in place for the long run.

Scope of, and incentives for, enforcement

As I mentioned earlier, for a corporate lawyer (or even for many developers), getting involved with a new license is a bit like getting in the cage with a lion. The more assurances you have that the lion won't eat you, the better!

In license design and drafting, this speaks to clarity for the scope of enforcement. For example, if a carbon license asks "do you have $10,000 invested in oil companies?", I'm not even sure that I would know how to figure that out (since my retirement money is largely in mutual funds). So that language creates costs for me, without much impact on carbon emissions, since my investments are nowhere near large enough to impact corporate decision-making.

In contrast, imagine a license that was very specific—“the top 100 carbon-reserve-owning companies cannot use this software.” That frees virtually everyone else to use the software without worry, while giving you a clear set of target, risk-averse organizations to go after.

Narrowing the scope of enforcement in that way may not be appropriate for every cause, but it’s something to always consider.

Similarly, a license-based movement should also have a clear (or at least aspirational!) strategy for enforcement. If your theory is “the mass-murderers of the world have ignored justice for too long, but surely copyright licensing will bring them to their knees” … maybe you need a different theory. 😃 That theory could be, for example, targeting the type of company that is somehow related to your problem and who are known to have large, risk-averse legal teams. It could also involve movement partners (as I mentioned above), who may already have impact litigation teams. It could involve particularly targeting pieces of software that are web-exposed, so that you can scan the world for violations. Whatever the strategy is (and there may be many different strategies for many different movements!), it must be something, and it must be something more than just “bad people will read the license and see the error of their ways.”

Time

Which brings us to the last question: are you in this for the long run? Because you need to be.

The first versions of Apache and GPL were each rewritten before they saw truly mass adoption. Many other licenses that tried to change the world never saw mass success at all. If you’re thinking of this as a one-year project, strongly consider not doing it.

TL;DR: again

If you haven’t planned a movement, strongly consider not writing a license. Or perhaps the more positive version: if you build a movement, maybe you won’t need a license! In either case, think long and hard before choosing licensing as the lever to change the world.

Ask me your toughest licensing questions for our live AMA this week

Luis Villa — Mon, 24 Aug 2020 19:38:20 +0000

I’m going to be doing one (and possibly more) AMAs on the worst(?) topic in open source. That’s right... licensing!

You are immediately saying WHHHYYYYY. And let’s be honest, some days I have the same response.

Indeed, in other contexts, such as an upcoming training for lawyers, these days I’m rarely talking about licensing, instead focusing on diversity, inclusion, and sustainability. So why a licensing AMA, now?

So why a licensing AMA?

The short summary is that licenses are dull—but also irreplaceable governance infrastructure for the FOSS ecosystem. And many people (both bizfolks and developers) still know very little about them, causing all sorts of pains, mostly small—but sometimes very, very big.

Let’s unpack that in a little more depth.

First, not everyone is bored! If you’re an old hand, and have been doing this for a decade or two, it can be easy to forget that there are millions of open source newbies who are genuinely intrigued by how this all works. In part because some of us find this tedious, the inner working can be obscure sometimes. (I almost derailed a sales call last week because of curious questions from engineers—they really were excited to pick my brain on legal concepts that most lawyers find elementary or just plain full.)

Second, even when it genuinely is dull, it still matters. For better or for worse (often for worse!) it is hard for companies to be involved in FOSS without licenses. Having a basic understanding of why the licenses are important is useful to grokking the broader non-licensing world of open source.

You can also Google a lot of licensing rules of thumb. They’re helpful, economically rational (perfection is expensive!) and often accurate enough for most businesses and developers. But with a deeper understanding of open source licenses, one can apply them more confidently and effectively, and I hope to start getting into those rules of thumb (either in this seminary or in a future one!).

Finally, knowing why the “experts” generally find licenses tedious can help FOSS contributors understand what non-licensing tools are appropriate, and why; and perhaps even help us understand when licenses might still be the right tool.

Anyway, that’s enough to have convinced me that it’s still a good idea to talk about and educate people on licensing, andI suspect once I get in the groove there will be more.

I hope to make this AMA accessible and interesting (despite the title!) so, again, feel free to sign up here.

Evaluating an ethical license for corporate use

Luis Villa — Tue, 25 Feb 2020 17:27:00 +0000

In my 2019 open source licenses year in review, I suggested that 2020 would see more adoption of licenses with a strong ethical focus. Just on schedule, last week the authors of the Hippocratic License (a license that prohibits usage in situations that violate human rights) released version 2.0, and the vcr project adopted it. Kurtis Rainbolt-Greene, the lead author of vcr, gave the following straightforward explanation for the change: before the license change “anyone ... could start using our collected works for things that should be opposed on an ethical level.”

Since vcr has over 15,000 dependent repositories, and is in our dependency stack at Tidelift, I thought it would be timely to share how an attorney (like myself) might assess this license change and advise clients.

Will it get evaluated at all?

The most common way in which the license will get evaluated is “not at all.” The vast majority of users won’t notice this library’s new license, and will continue using it just as they have in the past. This is probably not ideal for anyone. For the authors of vcr, of course, it means their ethical goals likely are not going to be met. For the corporations using vcr and unaware of the license change, it’ll mean an ongoing potential copyright license violation.

Will the evaluation be just a checklist?

The next most common evaluation will be a simple check against a list of accepted licenses, usually the list from the Open Source Initiative, a license-scanner vendor, or from counsel. Organizations using this approach are sophisticated enough to know what code they’re using, but prefer to take a risk-averse approach to what they accept.

In this case, the license will be rejected immediately, because the license isn’t on any of these lists yet (and may never be). These organizations will likely stick with vcr 5.0.0 (the last version under the old license) as long as they can, in the hopes either that newer versions will switch back to the old license, or that someone else will write a viable replacement, under a more permissive license, that they can use instead.

A more sophisticated evaluation

A very small number of organizations will go to the trouble of reading the license and figuring out if they can comply with its terms. This will be rare, because few organizations have the right kind of legal skills (or the time!) to analyze this. But for those that do analyze it, the first pass will be a simple search for any egregious flaw that would cause the document to be rejected immediately; only if there is a really compelling business reason to use the software will the lawyer dig further (say, by doing more research or looking for ways to work around problems).

Version 1.3 of the license, used (as of this writing) by vcr, has a number of these showstoppers; perhaps most importantly for most businesses, it prohibited harm to the “economic well-being” of others—which is a tough ask for businesses who see themselves as being in economic competition! So license compliance would have been very difficult for many businesses, unless they wanted to use loopholes to avoid the plain language of the license.

The new version 2.0 of the license removes some of the most obvious flaws of this sort, probably in part because it was the first version drafted with help from attorneys. These changes will force any counsel grappling with vcr and the Hippocratic License more generally to answer some fundamental questions about their business and their tolerance for risk—never fun or easy exercises!

In particular, four of the tough questions forced by the license include:

Legal compliance: the license says, in essence, “you have to comply with relevant laws.” On its face, this is easy: all businesses of course agree to comply with the law. The trickier question is, who enforces the law? And what are the penalties? Accepting this license signs a company up for third-party monitoring of your legal compliance, with the stick now being copyright law penalties rather than other, potentially milder, penalties the law may call for. This probably isn’t a deal-breaker for most companies, but might be in some situations.

For example, if the Linux kernel adopted this, then for SaaS companies even the smallest, most inadvertent violations of labor law could turn from something resolvable with payment of a governmentally determined reasonable fine into a huge, potentially extinction-level problem.

Human rights compliance: The clause of the license that references the UN Universal Declaration on Human Rights allows the licensor to terminate a license based on any allegation (even self-made) of a violation. This makes the licensor judge, jury, and executioner, because there is no requirement that the allegation be supported or proven. This invests a lot of power in the licensor. As we’ve been reminded in several GPL copyright troll cases, one can’t always count on good-faith behavior from licensors, and so businesses will look on provisions of this sort with some skepticism since it could mean that even a bad-faith licensor could cancel the license without much warning. (Coraline Ada Ehmke, the creator of the Hippocratic license, has indicated on Twitter that the drafting team is trying to figure how to address this in version 2.1 of the license, perhaps through arbitration.)
Failure modes: A key question to ask of any legal agreement is “what happens if a court finds it invalid or unenforceable?” In the case of most open source copyright licenses, the answer is “then no one can use the work.” This sounds bad, but works out great, because it dissuades people who are violating the license from attacking its validity. In other words, you might argue with nuances of the license, but you aren’t going to claim that the license itself is invalid, because if it is invalid, then you still can’t use the work. The Hippocratic License puts in some language in 2.0 to attempt to address this, but I suspect it needs some work and will be revised in future versions.
Governance and new versions: Companies that use software licensed under version 2.0 of the license now may comply with version 2.0, or “any subsequent version published on the Hippocratic License Website.” This is not a showstopper for a business (since they can ignore later versions if those terms are unfavorable) but should lead any project developer who wants to use the license to push for robust, shared governance of the website.

Best-faith interpretation

Alternatively, consider the case of an upstanding nonprofit, whose own motives (and legal team) are unimpeachable.

For such an organization, some of the same concerns about the license will still apply. For example, most practicing nonprofit lawyers will still not be familiar with the UN UDHR. (They’re also, sadly, even more likely to be crunched for time.) So the license is still likely to face legal hurdles to adoption because they won’t have time to do that sort of research.

In fact, in some ways the license may be more difficult for a nonprofit to use. Where a hostile or risk tolerant for-profit will feel comfortable taking advantage of any ambiguity, and ignore the spirit of the license, a nonprofit will likely respect the spirit and reject attempts to use loopholes or ambiguity. They may also still have obligations (to funders or existing communities) that prevent them from following every detail of the license, just like for-profits do.

The lawyer assessment

Despite my personal sympathy towards the goals of the license, I’ve asked the Tidelift team to keep us on the MIT-licensed version of vcr—for now.

To Coraline’s credit, the Hippocratic License is adopting a very open-source-y release-early, release-often model. This leads to some uncertainty (never ideal in a license) but also seems likely to help the license iterate more quickly. She has also engaged pro bono legal help, which is a great sign. So even though they aren’t there yet, that combination makes me optimistic that the project can move towards a license that can meet the moral goals of projects like vcr and pragmatic needs of the many businesses (like ours) that rely on them.

Open source licenses: 2019 year in review

Luis Villa — Thu, 23 Jan 2020 17:39:03 +0000

2019 was the most active year in open source licenses in a very, very long time, with news from China to Silicon Valley, from rawest capitalism to most thoughtful ethics. Given all that, I thought it would be worth summarizing the most interesting events, and sharing some reflections on them.

Growth in China

China has been a slowly, but steadily growing factor in open source for quite some time. Last year saw one of the first GPL enforcement lawsuits in China, and 2019 saw two more important steps.

The first was the publication of the 996.icu license in late March. It is now the second-most starred repo in all of GitHub. More about it below (including why it isn’t open source per se), but for a new license like 996.icu to have one-quarter million stars, much less a Chinese one, is a significant cultural milestone for open source.

The other big milestone in 2019 was the first formal submission of a Chinese-language license by a Chinese entity to the Open Source Initiative. Putting aside whether translated licenses are a good idea, this license submission is a sign that China continues to integrate itself very fully into the open source community—not just in development work (which has been going on for many years now) but on the legal side as well.

Organizations changing

The Open Source Initiative and Free Software Foundation remain the two most important organizations in the licensing space, and both had notable years.

OSI’s evolving process

The Open Source Initiative’s license-review process has been, for a long time, fairly informal. When I chaired the process some years ago, I introduced a few procedural reforms, but they were ultimately fairly minor—and published at a time when few genuinely controversial licenses were reaching the OSI.

In the midst of a challenging wave of new licenses and critiques of the OSI (more later on this), board members have been pushing the organization towards a more structured licensing process (January, May). This work should be celebrated, both because it will make the process more fair, and because the additional transparency may help the OSI effectively grapple with some difficult issues.

OSI’s new board

In related news, March 2019’s board election led to an OSI board that is much more inclusive of a new generational wave of open source than ever before, with representatives from big companies and the first publicly elected candidate from outside the US and Europe. The membership’s election of an entirely female slate of candidates was also a clear repudiation of the sexist harassment some of the candidates faced.

The FSF’s rough year

Unfortunately, these improvements at OSI come at a time when the Free Software Foundation is undergoing extreme challenges. Richard Stallman resigned from the FSF in September, but the board remains mostly comprised of long-time associates of Stallman’s—a stark contrast to the fresh, publicly elected OSI board. Indeed, instead of bringing in new blood, the board has almost completely lost its younger board members, with Bradley Kuhn and Mako Hill resigning in October, following Matthew Garrett (who left before this latest crisis).

This leadership problem is not incidental to licensing. When GPL v3 was released in 2007, the FSF had a commanding position in the licensing landscape, stewarding the most popular license in FOSS. In the decade-plus since then, that position has been lost—GPL v3 has not seen adoption by significant projects, nor had a substantial impact in preventing widespread adoption of DRM (arguably the most significant policy goal of GPL v3).

During that same period, under Richard’s direction, the organization failed to effectively address the rise of network services, the creation of entire new toolchains like Kubernetes, or important social questions like contributor diversity and financial sustainability. Given these significant failures, Richard should have stepped aside—even if he hadn’t been a serial harasser of women.

This vacuum left by FSF’s lost decade is in large part responsible for many of 2019’s other licensing trends—as I’ll discuss next.

Challenges for the OSI

It’s worth noting that, despite the positive progress made by the OSI, the year has also seen several explicit rejections of the OSI’s work.

One of these has been the “Commercial Open Source Software” coinage and event. More on it below, but the core of the challenge is based on the notion that the OSI is no longer representative of the broader open source movement, and licenses that explicitly prohibit competition should still be welcome in some definition of “open source.”

Relatedly, Kyle Mitchell, perhaps the lawyer who has most embraced the open source ethos of “release early, release often,” has explicitly rejected the OSI process for his (many) new licenses and licensing-related experiments. The list of licenses and licensing-related projects he’s written or contributed to in the meantime is lengthy.

(I should disclose here that Kyle and I work together quite a bit, and I co-authored a license with him in 2019—the Blue Oak Model License—that I volunteered to submit to the OSI as a guinea pig to test any improved processes.)

To some extent, these challenges are inevitable—there’s never been a large, growing movement of human beings that has not eventually fought over definitions and structures. So while this fragmentation may not be ideal, it is also a sign of growth and evolution—much better than a movement that is dying!

An open question for the leadership of both FSF and the OSI is how they react to this growth. Do they demand respect on the basis of things that were written and created a literal generation ago? Or do they see these changes as an opportunity to respond with persuasion, education, and activity? I hope for the latter, of course, but particularly for FSF, 2019’s leadership challenges may be too great to overcome.

This question isn’t just important for these organizations. Everyone in software (especially the movement’s corporate beneficiaries) should be asking whether they benefited from the licensing stability of the past fifteen years, and if so, what they can do to extend it. As the events of 2019 made clear, this situation can’t just be taken for granted—we will need active work to maintain it (or conscious, careful work to reassemble it constructively).

The rise(?) of “ethical” licenses

The question of how “political” open source licenses should be is one that flares up every once in a while. For example, I wrote about a backlash against GPL v3 for being “too political” in 2007, and Kyle Mitchell wrote something similar in September. In 2019 though, the push for increased ethics in licensing was active and sustained in a way that I don’t think we’ve ever seen before.

Lerna and ICE

This discussion was (re)started in late 2018, when the Lerna project briefly blocked use by ICE and other US government agencies. While that particular license change was quickly revoked, it set the stage for a larger discussion in 2019 (including discussions that spilled over from licensing into corporate behavior).

996.icu

The first big news item of the year in this area was the 996.icu license, in which Chinese developers attempted to use licensing to combat rampant violation of Chinese labor law. Putting aside for a moment whether or not this was effective, or even a good idea, there are several important takeaways:

This was perhaps the first example of a huge, bottom-up developer-led licensing movement in quite some time—and it came from China, not the WEIRD countries.
The leaders of the movement explicitly said they were inspired by free and open source’s history of “programmers fighting for rights” and said that they felt the license was ”exactly the embodiment of the spirit of free and open source software.”
One-quarter of a million people supported it on GitHub.

Unfortunately, the formal leadership of the free and open source movements gave, at best, tepid support to this literally unprecedented show of interest—a squandered opportunity to build bridges and interest, in my opinion.

Hippocrates and beyond

Another significant moment in the year’s discussion of ethics in licensing was when Coraline Ada Ehmke (author of the extremely popular and useful Contributor Covenant) published the Hippocratic (aka Do No Harm) License. Coraline is also actively organizing a group of people interested in the ethics problem, outside of the OSI and FSF. My take is that it is very complicated to write this sort of license, but Coraline’s work is the most serious (non-996) attempt to challenge FSF/OSI’s hegemony that I can recall in a very long time.

Other licenses have taken up this torch as well. During the year, the OSI saw requests for comments on the Working Class License and a license “respecting European values” like privacy, both of which are roughly what they sound like on the label. There is also now an anti-carbon license, and I’m sure others I have not yet seen. We should expect to see more of the same in 2020.

Responses from the OSI and FSF

It’s perhaps not surprising that OSI and FSF have responded coolly to these new licenses. As Christie Koehler pointed out in a summary of the situation, the OSI and FSF have an unambiguous history of arguing that source should be usable by everyone, even the “bad guys,” and she shared some pretty good (though not iron-clad) reasons why that still makes sense.

At the same time, many of those discussions happened two decades ago—and since then the OSI and FSF have not done a particularly good job (re-)articulating why those libertarian principles should apply in a world where ethical and political questions have become more salient on a daily basis for many of us.

One ethical license written in 2019 appears to have been specifically created to force the OSI to reckon with this history. The anti-vaccine license submitted to the OSI was relatively carefully drafted, and then submitted pseudonymously by someone who appears to have enough experience to know it would be forcefully rejected.

So why write it, knowing it would be rejected? The author says that “[t]here is a rising sentiment in the Open Source community that we give too much and ask for much too little”, and then asks the OSI to come to terms with that. The OSI can view this as an opportunity, using its improved process to make clear why the organization feels these rules are still important and relevant, and perhaps even elaborating constructively on OSI’s mid-year statement on morality in software. But whether or not OSI takes advantage of the opportunity remains to be seen.

Money, money, money

Inevitably, as open source has “won,” money has become ever more central to how it functions. It turns out it is hard to sustain the entire software industry on a part time basis! Licensing has not played a central role in this discussion, but 2019 gave several examples of how licensing and money are entangled.

Explicitly commercial standardized licenses

Part of the Kyle Mitchell License Avalanche of 2019 was an uptick in adoption of his License Zero, an explicitly commercial (not open) licensing system with built-in payment mechanisms. (Kat Marchán has written about her adoption of it, as has Tidelift participant Feross Aboukhadijeh.)

A group of attorneys also published a set of standard, but again very explicitly commercial/not-open, licenses as the Polyform Project.

While the lawyers involved in these (including Kyle, Heather Meeker, and me) would be the first to tell you that these licenses aren’t open source, I include them here because they bear two key similarities to open source licenses.

First, they explicitly aim to simplify and reduce the cost of licensing by standardizing it. This standardization is, in a very real sense, a legal technology pioneered by open source, and in 2019 finally being systematically made available to other parts of the legal-tech industry. Secondly, particularly for License Zero, the audience of these licenses is developers and small shops—groups traditionally well-served by open source and ill-served by the legal industry. It’s possible that this approach will appeal to them.

Commercial “open source”

In late 2018, Mongo submitted the Server Side Public License to the OSI, intended to replace the AGPL with a license that was more aggressive and protected their business from cloud vendors. In 2019, this trend accelerated and turned into a movement of a sort, with Redis using a new source available license. These discussions eventually snowballed into something calling itself Commercial Open Source Software, centered around an Open Core Summit.

The entire thing was a little odd, given that open source has (from literally the time the phrase was coined!) been pro-commerce, and that also since the nominally pro-commerce COSS folks appeared to be arguing primarily for licenses that...oppose commercial use.

While I think some of the readings of this have been uncharitable, suffice to say that this messaging has been at best very confusing and at worst perceived as an active attack on the definition of open source by venture capitalists who want Red Hat-like returns without putting in the effort.

Regardless of the confused messaging, I expect we’ll see more of this in 2020—in both good and bad faith.

New network copyleft, and going beyond copyright

Over the past decade, the FOSS movement has not had a particularly coherent response to the industry’s shift from self-hosted services to the corporate-hosted clouds. FSF’s AGPL v3 was the last major attempt to address this, but FSF has failed to advocate for (or improve) the license in a sustained, systematic way.

2019 saw three serious attempts to address this gap.

CopyleftConf

In February 2019, following the annual FOSDEM conference in Brussels, the Software Freedom Conservancy hosted the first “CopyleftConf.” This was an attempt to reinvigorate copyleft by getting advocates for it together in one place and share ideas for the future.

Meetings can only do so much, of course. But the existence of the event is a good sign that many people realize that copyleft is not a self-fulfilling prophecy, and must (like any software product!) be constantly refined and promoted. I look forward to attending the next one.

Cryptographic Autonomy License

Shortly after presenting at CopyleftConf on the “maximum allowable scope of copyleft,” Van Lindberg published the first draft of the Cryptographic Autonomy License, with the stated goal of “protect[ing] people’s rights to their data.”

There’s a lot of interesting innovations in the CAL, but the one that is perhaps most interesting is exactly that up-front goal: the expansion of copyleft to data. In this vision of copyleft licensing, data is nearly as important to users as source code—if one can’t export data from a service, then full source code access is arguably useless.

This clause is both a very modern issue, given the proliferation of software-as-a-service, and a very old one. GPL has long recognized that source code that can’t be installed is not very useful, requiring installation scripts in GPL v2 and potentially cryptographic keys in GPL v3. CAL takes that to the next logical step, understanding that for many users a service with source but no data is useless.

CAL has faced a lengthy approval process, which is still underway and controversial as I write this (nine months after the initial submission). This is not surprising, given how aggressive the license is, but still somewhat disappointing. In particular, Van’s motives have been repeatedly questioned, and at least some discussants of the license have essentially proposed conditions that would block any extension of copyleft unless done by the FSF—which can’t be healthy for the future of copyleft.

Parity

CAL is a lawyer’s license, similar in complexity to other existing strong copyleft licenses. Parity, from Kyle Mitchell, is an attempt to go in the other direction: an extremely broad copyleft, in extremely straightforward language, designed to appeal to developers rather than attorneys. It saw two releases in 2019 (6.0.0 and 7.0.0). I’ve long been an advocate of simplified drafting, so it will be interesting to see whether this path yields significant adoption in 2020.

2020 will be more of the same

Open source has, in many important ways, won. Virtually everyone who writes software uses it. But that also means that everyone who writes software has a stake in what open source is and can mean.

In a politically charged moment (spanning the gamut from Chinese labor to global carbon extraction to Silicon Valley VC), that growth in open source is inevitably going to lead to contestation of what the term should mean—and what our licenses should do. So expect more of the same in the year to come, as we continue to argue about what our legal tools can and should do.