Government Open Source Software Policies

Understanding the CSIS Data set

The research team relied on publicly available information to populate the data set. To capture a broad array of policies, the project used unofficial translations. The research took place between January and August 2022, though the research team included some well-documented policies and bills that have been introduced since August 2022. As always, comments, corrections or new data are welcome. You can always reach out to gwood@csis.org .

This data set builds on previous CSIS surveys on OSS policies. (The 2010 update can be accessed here). However, given the developments in the last decade, the researchers found it necessary to adapt the data set to better fit the type of policies found in this iteration. For starters, and as a matter of scope, this data set focuses on those initiatives introduced at the national level. Past iterations included local and regional initiatives since much of the drive for OSS was occurring at those levels. Since then, national governments have increased their interest in OSS policies—CSIS research found a total of 669 policies. After identifying the policies, researchers examined and categorized them according to the following criteria:

1. Title: When a title was not available, the research team included a short description of the action in the title cell. Thus, some titles are not official.
2. Issuing Authority: The research team identified which elements of the national government are working on OSS and divided these entities into five categories:
   • Agency
   • Armed Forces
   • Executive
   • Legislative
   • Ministry
3. Type of Policy/Document: The research team organized the documents according to their type.
   • Bill: This category includes introduced bills or laws.
   • Other: This category includes miscellaneous documents that outline actions or understandings, such as guidelines, studies, and white papers.
   • Directives and Regulations: This category includes regulatory documents not stemming from the legislative branch, such as decrees, executive orders, directives, and memoranda.
   • Support: This category includes documents that do not regulate OSS but convey the issuing authority’s position, such as announcements, statements, programs, and meetings.
   • Strategy: This category includes action plans or strategies that chart a course and objective.
4. OSS Specific: This measure identifies whether OSS is a standalone issue or if it is a pillar or course of action in a broader initiative.
5. Stated Objective: This category examines the reasons governments used to justify the adoption of the policy, split into the following categories:
   • Cost: Governments frequently cited the cost of proprietary software as a reason to study or promote the use of OSS. This category also includes those policies that recognize OSS as an alternative to the use of pirated software by government entities.
   • Sovereignty: Some governments perceived OSS as a way to achieve technology sovereignty and autonomy, easing dependence on third-country technology.
   • Support for National Industry: Some governments advocated for these initiatives as a way to support the development of a national software industry.
   • Modernization: Some governments advocated for OSS as a tool to advance the modernization of government systems and society. This includes, for example, efforts at digitization, e-government, interoperability, and trainings to increase awareness and capacity.
   • Transparency: Some governments viewed OSS as a way to increase transparency on how funds are used by the government and how procurement is arranged. The use of OSS could also increase visibility into the systems themselves.
   • Security: Some governments see OSS as a way to increase security of their systems. This category also includes those policies that address the security of the OSS solutions themselves.
6. Type of Action: This category examined the actions required by each policy and further classified them by purpose, including
   • Cooperation: This includes public-private partnerships between government entities and the OSS community.
   • How to Use: This includes guidelines or instructions for how to develop, implement, or transition to OSS solutions.
   • Procurement (Advisory): This includes when the use of OSS should be considered.
   • Procurement (Mandatory): This includes the mandated use of OSS, when it was given preference over proprietary software, or when it was made a prerequisite for selection of a project.
   • Research and Development (R&D): This category includes studies, white papers, comments, or other initiatives on the viability or feasibility of OSS, as well as requirements for openness (open by default), which would benefit users and other governmental bodies.
   • Repository: This category denotes the development of a repository, not the repository itself.
   • Training: This category includes trainings on OSS development or use for citizens or civil servants.
   • Technology Neutrality (Tech Neutrality): This category denotes explicit endorsement of the principle of technology neutrality —the freedom to choose the technology that is most adequate to one’s needs.
7. Terms: This category identifies what terminology governments use, distinguishing between OSS, free (libre) open source software (FLOSS/FOSS), public software, or if they use some of these terms interchangeably. It is important to note that in some cases, the research team had to make a determination without having access to primary sources or relying on unofficial translations.
8. Status: This category identifies whether a policy has been proposed, approved, or replaced, or if it failed altogether. When the research team found old announcements and no update, they noted the lack of update and kept the categorization as “approved.” When the research team found proposed legislation with no update and more than two years had passed since it was introduced, it was considered “failed.” This category is mostly useful for legislative actions since there is little visibility into proposed or failed ministerial or executive action.

Footnotes

To provide clarification on certain policies, researchers included footnotes in the web version of the data set and entries in the “notes” column in the CSV file.

• Details need to be confirmed. No access to original source, cannot locate it elsewhere. Footnotes were included to flag instances when there was limited access to data on a certain entry.
• Proposed in cited year; no update found. The researchers noted if an entry was proposed but no subsequent updates were found.
• Unclear when it was established. The research team noted when the source did not indicate with clarity when an action was created, announced, or established.
• Link recently broke; not available in Wayback Machine. This note was included in instances when the link to a source is no longer working but was available during the time of data collection.

Tips for Using the Data set

• The web version of the data set can be sorted alphabetically by clicking the header of each column or in reverse alphabetical order by clicking it again. There is also a sort function that allows the user to browse for keywords. For example, to search for Argentina’s strategy on OSS, a user should first sort alphabetically, then type “strategy” into the search bar.
• For sorting by multiple columns, download the CSV file.
• Some links will automatically download a file. The user’s browser should be set to allow for pop-ups.
• For Argentina’s legislation, links might not redirect to the bill but to the parliamentary search function. You can access the bill by searching for the “name” on the “Nro. de Expediente” category.

Acknowledgments

The researchers would like to thank Andrew Braverman and Elizabeth Benke for their research support in the early stages of this project. They would also like to thank the welcoming members of the OSS community who were generous with their time and insights and helped shape this data set.

This work benefited extensively from the work done by the Internet Archive, in particular, the Wayback Machine. This data set would not be as complete without it.

This work was made possible through support from GitHub.

This work is available under a CC-BY license.