The United States: federal guidance and state bills
Software policy in the United States operates through federal acquisition rules, agency guidance, state legislation, and requirements for particular public systems. The Center for Strategic and International Studies survey distinguishes federal actions from state and local measures. Its entries record approved guidance alongside bills that failed, expired, or were classified as Proposed. Keeping jurisdiction, action type, and recorded outcome together prevents an unsuccessful state bill from being mistaken for a nationwide software requirement.
The general acquisition framework
Wikipedia's Federal Acquisition Regulation overview describes the FAR as the principal set of rules for federal procurement and the procedures executive agencies use to acquire products and services. The acquisition system pursues best value, fair competition, and reduced administrative costs and time. That general framework is broader than a rule about source code. It covers planning, solicitation, evaluation, and contract administration, so a software acquisition involves procedures as well as a licensing model.
Federal open-source guidance
| Government | Branch or agency | Action | Date | Status |
|---|---|---|---|---|
| U.S. | Department of Defense | Advisory | June 2003 | Approved |
| U.S. | Office of Management and Budget | Advisory | July 2004 | Approved |
| U.S. | Department of Defense | Advisory | 2006 | Approved |
The CSIS Department of Defense entries describe rules for open-source use and, separately, an Open Technology Development roadmap intended to foster broader adoption. They classify these as Advisory, rather than a government-wide mandatory licensing rule. The Office of Management and Budget entry likewise describes technology- and vendor-neutral procurement advice that included ownership and maintenance costs, risks, security, and data privacy. These considerations connect software choice with the wider acquisition process rather than identifying a license as sufficient evidence of fitness for purpose.
State measures had different outcomes
| Government | Branch or agency | Action | Date | Status |
|---|---|---|---|---|
| U.S., California | Performance Review Commission | Advisory | 2004 | Approved |
| U.S., Hawaii | Legislative | Preference | Apr. 2003 | Failed |
| U.S., Hawaii | Legislative | Advisory | 2004 | Approved |
| U.S., Massachusetts | Information Technology Division | Preference | Sept. 2005 | Approved |
| U.S., Oklahoma | Legislative | Mandatory | Feb. 2003 | Proposed |
| U.S., Oregon | Legislative | Preference | May 2003 | Failed |
| U.S., Texas | Legislative | Advisory | May 2003 | Proposed |
| U.S, Texas | Legislative | Mandatory | Feb. 2007 | Expired |
The CSIS state descriptions record a California commission recommendation to use open source where feasible and, separately, a failed mandatory measure. Hawaii's preference bill passed its Senate but remained in House committees; an approved advisory entry concerned an education pilot. Oregon's bills to consider open source remained in committee. Oklahoma's source-code requirement was classified as Proposed, while a later approved research entry concerned studying government use. A recommendation, a pilot, and a proposed acquisition restriction therefore cannot be treated as the same action.
The Texas entries distinguish advisory consideration of open source from expired bills about open document formats. Those subjects overlap but are not identical: access to source code concerns a program, while a document format concerns the information it produces or reads. Massachusetts' approved formats measure and its subsequent expansion of acceptable formats are described in the survey. The office document formats page follows that decision in more detail, including the distinction between a format requirement and a software license.
Voting-system software and testing
Wikipedia's open-source voting system article defines the subject in terms of voting software or hardware with a transparent design that can be examined for problems. Source availability is a design and licensing characteristic. The Election Assistance Commission's Voluntary Voting System Guidelines explanation concerns testing specifications for functionality, accessibility, and security. The commission states that adherence is voluntary except where state law requires it. A source-code description and a testing requirement therefore answer separate questions about a system.
The National Institute of Standards and Technology Voting Program describes technical research supporting voting standards and guidelines. Its work covers accessibility and human factors, cybersecurity, interoperability, and test-laboratory accreditation. NIST also chairs the Technical Guidelines Development Committee. Those roles concern developing and assessing requirements, rather than an endorsement of any vendor or license. They provide institutional context for discussions of voting software without establishing that publishing code alone satisfies every testing requirement.
Government works and publicly funded development
The general rule in 17 U.S. Code § 105, published by the Legal Information Institute, makes copyright protection unavailable for works of the United States Government while permitting the government to hold copyrights transferred to it. The provision and its notes distinguish federal employee works from works produced under contracts or grants. Public funding therefore raises a rights question as well as a procurement question; it does not, by itself, identify the license attached to all software. The publicly funded software page develops those distinctions.
Wikipedia's MITRE account describes a not-for-profit organization managing federally funded research and development centers for government agencies. That institutional description identifies a role in public research; it does not supply a finding about a particular open-source policy or procurement outcome.
The procurement rules overview connects the federal framework with international and European purchasing principles, while retaining the differences between jurisdiction-specific rules and general software selection questions.