The licensing discourse in the last few weeks has highlighted a difference between what “open source” means and what we’re talking about when we use the term. Strictly speaking, open source software is software released under a license approved by the Open Source Initiative. In most practical usage, we’re talking about software developed in a particular way. When we talk about open source, we talk about the communities of users and developers, (generally) not the license. “Open source” has come to define an ethos that was all have our own definition of.

A better vocabulary

As I’ve written before, we need to consider the inputs and outputs. We’re frequently talking about the inputs when we talk about open source, but in reality, the term only applies to the outputs. Perhaps we need a better vocabulary.

I think Tobie Langel represented it well in a recent Twitter thread. “The problem we’re facing,” he wrote, “is a mixup between, on one side, open source practices and norms, and on the other, open source licenses.” Tobie put the problem on two axes: licenses and norms. Each quadrant can then be named appropriately.

Tobie’s model—particularly the quadrant names—could probably use some refinement (as I’m sure he’d agree), but it provides an excellent starting point for developing a shared vocabulary. I suspect that most people are talking about the right half of this diagram when they say “open source”, even though that term only applies to the top half.

His example of Android in the “nominally open source” upper-left quadrant is excellent. Android primarily uses the Apache License 2.0, but there is no doubt that Google drives the project entirely. Fedora Linux would fit in the upper-right quadrant. Although Red Hat owns the trademarks, etc and hires people into leadership roles (full disclosure: including yours truly), the community drives the project. oysttyer, the Twitter client I still nominally maintain, falls into the “broader ecosystem”. It uses the Floodgap Free Software License, which ironically is non-free (libre) because it requires the software to always be free (gratis), but has (had) community participating and contribution.

Read my lips: no new licenses

What we don’t need is to try to license our way out of the problem. We don’t need, as Matt Asay mused, a “new class of license“. Writing new licenses is what brought us here in the first place. Asay said a few days later that we spend too much time on licenses and not enough on governance. Governance is hard, so it’s understandable that we’d focus on the (relatively) easy part. And the norms around governance have enough components that we could probably fractally zoom in on the upper-right quadrant of Tobie’s diagram.

Like the dated political reference in this section’s header, I’m going to backtrack on this position. We have not achieved the Platonic ideal license. This is, in part, because we do not have a uniform option on what rights a license should grant—or restrict. And the world of technology has changed pretty dramatically since the most popular licenses were drafted. Computing is more pervasive and powerful. The delivery model has shifted from installed software to software-as-a-service, which brings along new data and privacy considerations.

The software license, being a part of copyright law, is not necessarily the place to address all of the concerns we have about the state of the industry (and our effects on the broader world). But I applaud attempts to explore the space.

Where do we go from here?

In the “We won: now what?” talk I delivered at DevConf.CZ (25 minutes) and DevConf.US (40 minutes), I said that some of the recent licensing wars was due to having “defeated” proprietary software. We had set aside some of our differences to fight the bigger common enemy. Now that the fight is over, we’re free to resume our internal (within the open source world) fights. I hold that this is more true than ever.

As a community and an industry, we need to move our focus beyond the licenses. Licenses will always be important, but the license is not enough. We have to pay attention to our inputs and our outputs. That means we have to do better about being inclusive and welcoming to new contributors—particularly those that aren’t like us. We have to consider the effects of what we produce and mitigate the harm.

We need to be aware of our principles (in the understanding principles are not universally-held) and make sure we’re governing our projects in a way that’s compatible. Not only in the micro-effects, but in the macro-effects. And we need to develop a vocabulary that expresses our shared understanding and our difference.