The State of the Art

I’ve long held that software being open source¹ is necessary, but not sufficient. Using copyright and contract law to enshrine the freedom to use your software instead of its normal purpose to ensure privatization is a brilliant move, but licenses like the popular Apache, BSD, or MIT licenses are easily abused by large companies to extract value from free labor that they would otherwise have to pay workers for. Further more, when a company chooses to violate the license outright, there is no reasonable mechanism for enforcement in a judicial environment where the license abuser most likely has the resources to bankrupt the software author and continue using their software as they see fit.

The so called “copyleft” licenses that have arisen from the Free Software movement such as the popular GPL license attempt to fix some of these problems by requiring any changes made to the software also be released under the same license. In this way companies that benefit financially from their use of the software must give back to the community in some way, preventing them from using their power to close off the commons and become landlords.

Furthermore, After a recent ruling in a U.S. state court in SFC v. Vizio, groups like the Software Freedom Conservancy are now considered third party beneficiaries to the license, allowing them to enforce license compliance on behalf of the authors. While this does not completely solve the power imbalance between large companies like Vizio who are known to abuse open source software and the authors who have more limited resources, it does level the playing field somewhat since non-profits like the SFC have a bigger platform on which to fundraise and can retain lawyers for much longer than an individual could.

Unfortunately, this still allows companies to make massive profits while not paying anything back to the workers who created the software.

A New Software Commons

A commons is a finite resource that is managed by a group for the collective benefit of the group. In our current society many (maybe even “most”) of us are only familiar with this concept through the “tragedy of the commons” which states that rational actors will act in self interest to exploit the commons for profit, eventually exhausting the limited resource.

Ostrom’s law, named after economist Elinor Ostrom and stated by Lee Anne Fennell, says:

A resource arrangement that works in practice can work in theory.

This rather flippant statement challenges the “tragedy” argument by pointing out that there are many historical examples of sustainable commons. Ostrom studied these examples and argued that the initial economic model behind the “tragedy” concept is flawed. This led to the identification of 8 criteria that should be met in a successfully managed commons.

What would it take to build a software commons that could be sustainably managed by a diverse community of individuals and software projects? And what would it take for that commons to not be exploitable for corporate interests? Let’s go through each of the 8 criteria and find out.

Clear Boundaries

1. Define clear group boundaries.

Who gets to use the finite resource held in common and what are the limits of the group? At first blush software commons fail this rule to an extreme degree by allowing anyone, whether they contribute anything or not, to use the software. However, this makes the fatal assumption that the resource being held in common is the software itself, but software is information that can be copied ad infinitum. To quote Stewart Brand: “information wants to be free”.

The only limit to the software life span is how long it continues to be maintained, updated, and improved: In a software commons the resource isn't the software, it's contributor time and attention.

Most open source software is developed as a hobby—a side project—that takes a back seat the moment something comes up with work, or when the author gets burned out from being asked for things with no one else around to help. One way to do this is by compensating them fairly for their labor, a concept that many large open source consumers seem to struggle with. The goal of building a sustainable software commons then boils down to: how are you going to pay for it?

Local Governance

2. Match rules governing use of common goods to local needs and conditions.

Probably the best known formulation of the “tragedy of the commons” comes from an 1833 pamphlet by economist William Forster Lloyd. In it Lloyd describes cow herders grazing their cattle on common land. Because the land is not privatized, he surmises, herders are incentivized to put more cattle on the land to turn a bigger profit. When one neighbor does this, the others must as well to remain competitive. This cycle will continue until the land has been used up.

What this model fails to consider is that the herders can communicate with one another and come to an agreement about how best to manage the land and that, more importantly, they all have an incentive to do so. Furthermore, external rules may also apply to the system. For example, the communal grazing land in England at the time was governed by a law that no herder could graze more cattle on common land than they had the ability to overwinter, keeping the number of grazing cattle to a sustainable level.

Open source communities have many mechanisms for communication and rule making, but only one way of ensuring that other projects in the ecosystem also meet those needs: the software license. This means that our license should be govern the group boundaries mentioned in the previous section as well as the externalities of how non-contributors and external actors use the software. Software licenses should directly determine how we get paid up front without allowing large companies to take advantage of the output of the workers labor or requiring each project to negotiate (or beg) for donations separately.

Furthermore, because different software products will command different prices, we want to avoid a rush-to-the-bottom where software in the commons must compete on price, lowering the amount for everyone. To avoid this, the price should be set as a general rule across the board for all software that agrees to become part of the commons. If we make this price a percentage of the revenue that companies earn from their products using the software, and that percentage remains fixed no matter how many individual projects they use from the commons, the value of the commons will go up as the number of useful projects in it goes up. This also lets us command a higher than usual cost for our labor because the company is paying for use of the entire commons, not each individual piece of software. This in turn further encourages them to use other software in the commons and spread the payment to those projects as well.

Finally, if a project has no revenue yet: they don’t owe anything to the projects on which they’re building, allowing anyone to get started with your project for free until they do start generating revenue (if that is the intent). This keeps your project open and available for individuals and other commons projects!

Democratic Process

3. Ensure that those affected by the rules can participate in modifying the rules.

Software licenses are mostly fixed and static, but the cost of labor is not. This means that if the license is also to govern how software is paid for we need a mechanism for changing that price. As the commons becomes more valuable (more people contribute software to it), the price of that software should rise to match. However, if one centralized organization that maintains the license were to set the cost of the software it would place them in an extreme position of power over the license users, discouraging them from contributing to the commons.

Instead the software projects themselves must set the price and exceptions to that price collaboratively.

Self-governance

4. Make sure the rule-making rights of community members are respected by outside authorities.

The license is already part of an external legal framework enforced by outside authorities. It acts as a contract between the software community, the users, and any third party developers who are not active in the main project community.

Most licenses only cover how others can use and modify the software, but do not make mention of internal project governance. Projects may make use of some form of democracy or they may use the controversial “Beneficial Dictator for Life” (BDFL) model in which a single individual controls all decisions about money, development, etc. Either way there are generally no provisions to stop one or more strong personalities from coming in and changing how the project is governed.

Baking democratic decision making into the license itself allows projects that are not large enough to have other legal frameworks such as a business vehicle with articles of incorporation and bylaws to legally enforce that the rights of community members are respected.

Other projects such as the experimental Cross License Collaborative model take a similar approach to mixing the license with governance. It may be possible to write a license that indicates the right to some form of democratic decision making so that existing models like the cross license model can be used in conjunction with the fiscal parts of the license.

Monitoring

5. Develop a system, carried out by community members, for monitoring members’ behavior.

You may have noticed that in the previous section we started discussing democracy among individual project members whereas previously we had been discussing a confederation of projects as a group making decisions about a shared license together.

The fact of the matter is that the commons must be maintained at every level. Individual software communities must make their own decisions as they see fit, but projects must also manage shared resources and infrastructure democratically.

At both levels we need a way to make sure that everyone else is playing by the agreed upon rules. Putting such a system in the license gives it legal teeth and creates a contract between individual projects that use the license whether they depend on each other or not, ensuring that everyone both has a say in the rules, and in enforcing them.

Graduated Sanctions

6. Use graduated sanctions for rule violators.

Sanctions are always tough. No one wants to be a cop — or, if they do, you probably don’t want them as a member of your project. Jumping straight to the nuclear option of banning or taking legal action against those who make minor license violations is bad for the commons as whole, because this means less chance for generating revenue and fewer contributors. Taking legal action is also expensive and, for smaller violations that don’t involve recuperating lost revenue, is likely not worth pursuing. Instead we want to try and bring people back into the fold by deciding on a set of rules and sanctions collectively that gradually increase with the level of the offence.

As with the previous sections, the license should reference these sanctions so that, in the worst case, there are legal protections for everyone involved.

Conflict Resolution

7. Provide accessible, low-cost means for dispute resolution.

This is one of the hardest but most important rules to meet. With most software licenses it’s up to the software author or copyright holder to sue in a court of law for license enforcement, but this is beyond the means of most authors, making the license effectively useless against bad actors. The previously mentioned SFC v. Vizio case has made this somewhat better for the GPL specifically, but non-profits like the SFC still don’t have the same resources as the big companies and can’t take every single license enforcement case. This means that we need to cast a wide net in terms of license beneficiaries (those who have standing to sue), and try to build in other mechanisms for enforcement that are easier as mentioned in the previous section.

Almost all software EULAs provided with proprietary software include a forced arbitration clause in which you waive your right to sue. Disputes are then resolved by a less expensive process known as arbitration. In EULAs these clauses exist because arbitration is almost always more friendly to the big business trying to make you give up your rights, but we can borrow aspects of this strategy and use them for good as well.

A software commons should use forced arbitration to its advantage. This could be by performing arbitration with specific organizations that have agreed to act as the arbiters and allowing the commons community to vote on adding or removing those organizations from the list of acceptable ones, or by creating a jury of other projects in the commons that have no connection or dependency on the disputed project to arbitrate disputes. By joining the commons and becoming a beneficiary of the license each project could agree to a sortition system whereby they may be selected to help arbitrate disputes at any time. If, at a later date, they wind up in a dispute with another project or an external entity they would also have the benefit of the decision of a jury chosen by sortition and who’s decision has legal legitimacy thanks to the license.

Confederation and Community

8. Build responsibility for governing the common resource in nested tiers from the lowest level up to the entire interconnected system.

This is one of the easiest rules to apply to software because so much software works this way already. Unfortunately, many people interpret this rule to mean “form hierarchies of power,” but nothing could be further from the truth.

Instead each individual project is a tier that governs its own internal affairs as it sees fit: though hopefully that includes some form of democracy and consent based decision making. These projects are then confederated into a higher tier bound together by the license. Within the larger tier otherwise separate projects may decide to work together as one larger body, maybe as members of the same fiscal host or support organizations. Across these organizations and individual projects unions of otherwise unrelated projects might form where shared interests overlap. These tiers generally resemble the circles of sociocracy, but the exact governance method isn’t important so long as the projects decide together how they will make decisions without coercion or hierarchy.

Putting it all together

To summarize, a sustainable software commons would require a new license or license addendum that provides (at a minimum) the following guarantees:

• A percentage of revenue from dependent projects must be set aside and paid out to its dependencies
• Decisions about payments, sanctions, and inter-project communication must be made democratically
• All members and users of the software must have standing to enforce compliance according to graduated sanctions
• Projects must have the right to self-determination, but may also confederate with other projects to receive the benefits of the commons and help determine the direction of the commons as a whole

I’m aware that most companies would simply refuse to use any software that adopted such a license, and that this is all a bit abstract and may be difficult to do across legal jurisdictions. There are also a huge number of open questions about how exactly such a license would function across projects with a near infinite variety of governance structures, sizes, and tooling. Regardless, as an experiment I think the general idea is worth pursuing.

Want to explore these ideas further? Reach out and let’s collaborate!