December 4, 2020

Open Source Software in Government: The Intersection of Two Public Goods

Exygy’s long time counsel, Joe Morris, and their 2016 article are an oft-referenced primer on open source licensing.

This post is written by Exygy’s long time counsel, Joe Morris. Joe’s 2016 article on choosing an open source license is an oft-referenced primer on open source licensing issues. This post goes more specifically into issues of open source licensing in government.

Over the years, I have often wondered why public funds are not more often spent on publicly-available code. I recently interviewed two experts in open source licensing in government to learn more about the field, from people who are deep in the open source and government space:

Walking away from these two interviews, four key themes stood out to me:

  1. Open source licensing should be the default position for governments.
  2. Projects should be open-source from the start, mostly for pragmatic reasons.
  3. The distinctions among open-source licenses are not so important. Instead, the salient distinction is between open source and proprietary software.
  4. Government policies and standards for open source licensing are very helpful in normalizing and encouraging the adoption of open licensing practices.  

4 Key Takeaways on Open Source Licensing in Government:

1. Open source licensing should be the default standard for all government-funded software.

Matt asserted that, “9 out of 10 times [government should choose] open source,” for its software needs. Even more definitively, John shared that the U.S. government should not be using proprietary software at all. These positions started from a basic place of fairness, or property right. The taxpayers paid for it, so they should have ownership access to the software that was created with their money. As John stated, “I believe that government code is the property of all U.S. people.”

Overall, it’s clear to me that taxpayer funding should lead to an open-source license, by comparing other similar contexts, unless there is some overriding concern, like national security. For example, taxpayer funding for roads almost always leads to publicly-accessible roads, even when a private company is hired by the government to build the road. So, why is it that taxpayer funding for software doesn’t almost always lead to publicly-accessible source code?

2. Make the software open source from the beginning.

Both John and Matt highlighted the importance of making the decision to license software openly at the very beginning of a project. There are three clear advantages to selecting an open-source license from the get-go:

  • It can be difficult to do an open-source release of code that was initially developed in a proprietary, protected environment. A protected environment often results in hard-coded keys or passwords, or other security-through-obscurity design flaws. Over time, those can build up a barrier to an open source release, because of the ever-increasing code cleanup that would be required.  
  • It’ll be more likely to use open source components and data-exchange formats that everyone is familiar with, and therefore avoid “vendor lock” to a particular provider’s unique software and formats.
  • It makes it easier for others with similar problems to find the open-source solution you are working on, so it’s possible to collaborate on a single solution.

3. The choice of a specific open-source license is much less important than the type of license.

In some contexts, software developers feel very strongly that one should use the GPL (or some other copyleft license). Richard Stallman and the FSF are the foremost proponents of this view. But you can also see it in, for example, Automattic’s position that, “If WordPress were a country, our Bill of Rights would be the GPL.” This limits helps to ensure the source code will stay “free.”

On the other hand, there’s been a trend towards adoption of MIT or Apache licenses. This seems to come from two causes:  (a) open-source software has been adopted more widely in enterprise-scale businesses, which are often nervous about the implications of copyleft; and (b) a shift in developers towards a view that easy, widespread adoption of their creations is of primary importance.

John and Matthew both related that, in their work with government, the choice of which specific open source licenses to use was not particularly important. Matt told me that the City of Boston chose a public domain dedication for boston.gov in order to avoid any kind of license compatibility issues. John said that the government CIO’s decision to choose between open-source or proprietary software is most critical, and which open-source license is not nearly as important.

4. Government policies & standards on open source licensing are helpful.

There is a collective problem for actors who decide what software is created, licensed, or used by governments: jurisdictions often have similar software needs, but choose different software solutions. For example, most cities require 311 systems, taxes, fees, registrations, etc., but each uses different software. The same can be said on a federal agency scale. The question of getting different governments or agencies to collaborate on the same open-source project can be somewhat stymieing (John: “if I had an answer to that question, I’d be a millionaire…”).

The federal source code policy, a general mandate to, “…release at least 20 percent of new custom-developed code as open source software,” was described by both technologists as a “soft” influence  —  that is to say, by virtue of its existence, rather than about any hard and fast rule within it. Both Matt and John did find it influential, although in Matt’s case the main policies were the related 18F guidelines as well as the US web design system.

The existence of such policies is important because they set norms for CIOs to look to, and provide a reason to choose an open-source solution when it is feasible. Each individual CIO may not have the bandwidth or other resources to be able to make an extensive evaluation about the pros and cons from a political or pragmatic perspective of proprietary versus open source software. Instead, they’re going to look for the social and political norms that are set by the government they work for as a whole: policies, in other words.

Open Source, GovTech, and You

Why do you think that public funds are not more often spent on publicly-available code? Have you noticed that open source is treated differently in the public vs. private sectors? What can designers and technologists do to improve the quality of public services, for less money? Connect with one of Exygy’s technologists and share your thoughts!

Want to talk more about open source licenses? Contact Joe here:

What’s a Rich Text element?

H1 example

H3 example

The rich text element allows you to create and format headings, paragraphs, blockquotes, images, and video all in one place instead of having to add and format them individually. Just double-click and easily create content.

Static and dynamic content editing

A rich text element can be used with static or dynamic content. For static content, just drop it into any page and begin editing. For dynamic content, add a rich text field to any collection and then connect a rich text element to that field in the settings panel. Voila!

How to customize formatting for each rich text

Headings, paragraphs, blockquotes, figures, images, and figure captions can all be styled after a class is added to the rich text element using the "When inside of" nested selector system.

No items found.

Want to work together?

We are always looking to get in touch with partners to help build healthy and resilient communities together
contact us