Open Source Usage Policies
Category:Open Source Category:Policy See also Open Source Release Policies
List of government policies about using open source software – i.e., policies about when open source solutions should be considered, either through in-house deployment or deployed by a contractor. We appreciate any help in updating this list, and of course we do not represent it to be complete.
'’For policies about creating new open source software, either by procurement from a contractor or by government developers writing the code themselves, see Open Source Release Policies.
Surveys
- Comprehensive 2010 Study of Government Open Source Policies (PDF)
- Gunnar Hellekson’s “Open Source in Government: Who was first?”, a chronology of policies.
- http://openplans.org/2010/01/29/cities-powered-by-open-source-2/
Case Studies
North America
- Massachusetts Enterprise Information Technology Acquisition Policy
- Vancouver (PDF)
- Portland (PDF)
- San Francisco (Press Release) (PDF)
- California Open Source Software Policy (PDF)
- Vermont Open Source Software and Open Standards Policy and Guidelines (PDF)
- United States Technology Neutrality Policy PDF (White House Office of Management & Budget)
- City of Raleigh
- New Hampshire House Bill 418-FN
- Austin, Texas Res 20111208-074
- Oklahoma House Bill 2197 (view online) - this is based on New Hampshire’s HB418
Eurasia
- Government of the Russian Federation (auto translated to English)
- UK Open Source & Open Data Licensing
- UK Open Source & Open Standards Policy (PDF)
- Iceland - see more background on Joinup
- See more on Joinup
Definition
The Open Source Initiative
Both California and Vermont cite the Open Source Initiative (Bruce Perens’) Open Source definition: http://opensource.org/docs/osd
Procurement
Two points to notice here are based on the words “equal” and “commercial.” The word “equal” gives these policies some measurable way of ensuring and benchmarking open source as part of the procurement process. The use of the word “commercial” as the opposite of “open source” is misleading since it implies that open source software is by definition non-commercial. A more accurate term to serve as the opposite of “open source” would be “proprietary” but terminology should really be defined as part of the policy (“closed source” isn’t quite right, because it implies that the source code is inaccessible, which is not always the case even with proprietary software; “proprietary” is the most precise antonym for “open source”).
- EU Guidelines on Procuring Open Source from OSOR
- UK Open Source & Open Standards Policy (PDF) (This link appears to be stale. Does anyone know where a recent copy lives?)
- Commonwealth of Massachusetts, IT Division: Nine Ways to Protect Your State From the Legal Risks Posed by the Use of Open Source Software
Vancouver
The City of Vancouver, when replacing existing software or considering new applications, will place open source software on an equal footing with commercial systems during procurement cycles. (Citation needed.)
Portland
Establish best practices for analysis of business requirements in software review and selection processes, identify existing commercial software systems with licenses that are scheduled to expire in the near future, and encourage the consideration of Open Source Software in the review, replacement and continual improvement of business solutions; (Citation needed.)
San Francisco
The Software Evaluation Policy will require departments to consider open source alternatives, when available, on an equal basis to commercial software, as these may reduce cost and speed the time needed to bring software applications to production. San Francisco COIT Software Evaluation Policy