Government Software Acquisition Policy
The policies governing the US government’s acquisition of commercial software are evolving in an effort to address the challenges of rapid technological advancement and operational complexity. Both DoD and civilian federal agencies are adopting more agile, flexible approaches to software procurement, emphasizing the need for speed, efficiency, and alignment with modern development practices. For DoD, initiatives such as the Adaptive Acquisition Framework and Software Modernization Implementation Plan reflect a shift toward iterative and modular processes tailored to defense requirements. Similarly, civilian agencies are leveraging category management principles, enterprise licenses, and governmentwide acquisition contracts to streamline software procurement. Understanding these policies is critical for negotiating software licensing agreements, as they define the framework within which contracting officers acquire commercial software solutions.
The Defense Acquisition System and Software Modernization Initiatives
The Defense Acquisition System (DAS) plays a pivotal role in ensuring DoD acquires and sustains capabilities to meet national security challenges. Within the DAS, the Adaptive Acquisition Framework (AAF) provides a set of tailored procurement pathways designed to streamline the software acquisition process, allowing for flexibility and speed in awarding acquisition vehicles for complex programs. Among these pathways, the Software Acquisition Pathway (SWP) addresses the unique life-cycle requirements of software systems, recognizing the distinct challenges of acquiring and sustaining software in an era of rapid technological evolution. The SWP focuses on iterative development, continuous integration, and rapid deployment, recognizing that software capabilities must evolve rapidly to maintain operational relevance.
DoD’s Software Modernization Implementation Plan (SMIP) underscores the importance of modernizing software development, deployment, and sustainment processes to support evolving mission requirements. The SMIP is a comprehensive roadmap aimed at driving enterprise-level efficiencies, advancing digital engineering, and ensuring cybersecurity resilience. This plan builds upon the foundation established by the SWP, emphasizing the integration of commercial best practices, automation, and open architecture principles. These elements are crucial for fostering collaboration with industry partners while accelerating the delivery of software solutions to warfighters.
Software procurement policies also have been issued by the individual service branches. For example, the Army has taken a significant step forward in its modernization efforts with the publication of Army Directive 2024-02. This directive outlines the US Army’s framework for adopting agile methodologies like continuous integration/continuous delivery, implementing DevSecOps practices (Development/Security/Operations), and leveraging modular open systems architectures across Army software programs. By prioritizing iterative development cycles and continuous integration, the Army directive seeks to reduce acquisition timelines and enhance the delivery of mission-critical capabilities to warfighters. A core tenet of Army Directive 2024-02 is the alignment of software acquisition processes with the broader objectives of DoD’s Software Acquisition Pathway.
While DoD has taken several steps to modernize its approach to software acquisition, the Department faces persistent challenges in modernizing its software practices, as highlighted by multiple reports from the Government Accountability Office (GAO). Recent GAO reports provide a comprehensive overview of DoD’s software acquisition and modernization challenges, highlighting critical gaps and progress made between 2020 and 2024. In 2021, GAO underscored systemic obstacles faced by DoD in implementing its updated policies to improve its software acquisition processes. Although an increasing number of programs reported using these new methods, GAO found that many DoD programs have yet to implement these practices and that DoD had not consistently collected data or developed metrics to assess adoption and implementation. Similarly, in 2023, GAO emphasized that while DoD had initiated reforms under the AAF, implementation remained stubbornly inconsistent across different programs, especially for acquisitions of weapons systems proceeding outside the normal software acquisition pathway.
The most recent assessment continues to identify ongoing deficiencies in DoD’s ability to measure the performance of software development initiatives, citing inadequate use of metrics and gaps in cybersecurity. This report also discusses how legislative mandates, such as the National Defense Authorization Act for FY 2018, have driven some progress in policy alignment but have not fully addressed operational inefficiencies. Collectively, these findings reveal that while DoD has made strides toward modernizing its software acquisition processes, significant challenges persist. For now, it is safe to assume that policies will continue to evolve, and procedures will undergo additional evolutions as DoD continues to work through these issues and refine its acquisition processes.
Even though DoD policy is far from settled, the overall direction taken by these recent reforms to DoD software acquisition procedures is clear. From a licensing perspective, initiatives like the SWP and SMIP highlight significant shifts away from the traditional acquisition process in how DoD approaches software procurement and life-cycle management. Historically, DoD relied heavily on bespoke software solutions developed under rigid contracts. However, the AAF and SMIP and the services’ further implementation of these initiatives reflect a shift toward acquiring commercial software solutions and rapidly deploying and integrating them into larger defense systems. This increased reliance on and integration of commercial software into platforms and programs that have historically relied on noncommercial solutions raises critical intellectual property (IP) concerns, and the shift means that effective licensing terms must balance the commercial market’s expectations with the government’s needs for transparency, adaptability, and long-term support. Understanding the interplay between these initiatives and commercial practices is essential for negotiating software licenses with DoD customers.
Modernizing Federal Civilian Software Procurement
Federal civilian agencies are increasingly embracing streamlined acquisition processes to modernize their software procurement practices and to keep pace with technological advancements. Reflecting a broader government-wide shift, the General Services Administration (GSA) and the White House’s Office of Management and Budget (OMB) have developed initiatives aimed at improving the acquisition and management of commercial software. These efforts focus on promoting agility, efficiency, and cost-effectiveness in response to longstanding challenges associated with traditional procurement methods. A key development in this area is the implementation of category management principles and the establishment of government-wide acquisition contracts (GWACs) tailored for software and information technology (IT) solutions.
Central to these modernization efforts is the Federal IT Acquisition Reform Act (FITARA), which directs agencies to acquire and manage commercial and COTS software in a more coordinated way. Complementing FITARA, OMB directed agencies to transition to centralized and collaborative software management and develop government-wide strategies to reduce duplication of efforts, such as increasing government-wide software agreements for mandatory use by all agencies. GSA has aimed to improve transparency in software purchasing and reduce duplicative acquisitions. It offers software licenses and software maintenance services on its Multiple Award Schedule (MAS), GWACs, and SmartBUY blanket purchase agreements (BPAs). General Services Administration Acquisition Regulation (GSAR) Case 2015-G512 was published as a final rule on February 22, 2018. The rule, now a mandatory solicitation provision, supplies mandatory language to replace common commercial terms for use of computer software that conflict or are otherwise incompatible with federal law.
The shift toward commercial software procurement raises unique challenges related to licensing terms and vendor relationships. For example, category management principles encourage bulk purchasing agreements and enterprise licenses, which can yield significant cost savings for the government, but also require careful negotiation to ensure compliance with federal laws and policies. Moreover, the rise of cloud-based solutions and software-as-a-service (SaaS) offerings have introduced new complexities, particularly around data sovereignty, cybersecurity, and contract administration. Civilian agencies and contractors must navigate these dynamics to craft license agreements that balance innovation, flexibility, and risk mitigation.
As with DoD, federal civilian agencies also continue to face ongoing challenges in modernizing their software acquisition and management practices. GAO has identified inefficiencies and opportunities for cost savings by concluding that many federal agencies lack comprehensive and accurate inventories of their software licenses or consistent tracking of software usage and purchases, making it difficult to reduce over- or under-purchasing licenses and manage inventory of existing licenses. These observations echo earlier assessments. Vendors providing commercial software and IT solutions to government customers should recognize that while acquisition policies continue to evolve across the federal government, implementation will take time.
License Acquisition Vehicles and License Management
The government employs a variety of acquisition vehicles to streamline the procurement of commercial software and IT solutions. These vehicles enable agencies to leverage pre-negotiated terms, achieve economies of scale, and expedite the acquisition process. For defense and civilian agencies alike, these tools play a critical role in balancing efficiency, compliance, and adaptability while navigating the complexities of software licensing. Notable among these vehicles are DoD’s Enterprise Software Initiative (ESI) and the GSA MAS program.
The ESI, established by DoD, is a strategic sourcing program that provides streamlined access to enterprise-level software and IT products. DoD also has standardized acquisition procedures through the ESI. ESI agreements consolidate demand across DoD components and other federal agencies, allowing for volume discounts and uniform licensing terms. ESI also addresses critical considerations like data rights, cybersecurity compliance, and sustainment, offering a framework that aligns with the unique operational requirements of defense agencies.
For federal civilian agencies, the GSA MAS program remains one of the most widely used acquisition vehicles for software procurement. Specifically, Schedule 70—now integrated into the consolidated MAS—provides access to a broad array of software solutions, including cloud-based platforms and SaaS offerings. The GSA MAS program enables agencies to procure commercial software with pre-negotiated pricing and terms that comply with the Federal Acquisition Regulation (FAR). Additionally, programs like the IT Schedule 70’s Special Item Numbers (SINs) for cloud computing and cybersecurity tools ensure that agencies can access specialized products while meeting emerging technology standards.
These acquisition vehicles highlight the government’s increasing reliance on commercial software solutions to meet operational and mission needs. While these contracting vehicles provide significant advantages in terms of efficiency and standardization, they also introduce complex licensing challenges that require careful legal scrutiny. Contractors and government agencies must navigate a patchwork of regulatory requirements, agency-specific policies, and evolving technology standards to ensure agreements align with both commercial best practices and federal mandates. Understanding the nuances of these acquisition vehicles is essential to crafting contracts that balance innovation, compliance, and mission assurance.
Software license management is intended to manage, control, and protect an organization’s software assets, including management of the risks arising from the use of those software assets. Properly managing software licenses helps to minimize risks by ensuring licenses are deployed cost-effectively and used in compliance with licensing agreements. Software license management also ensures software purchasing and maintenance expenses are properly controlled. This management includes (1) a regular reconciliation review by agencies to ensure they have the appropriate number of licenses for each item of software in use and (2) reviews by vendors to assess the number of licenses in use to ensure the legal agreements that come with procured software licenses are adhered to and that organizations avoid purchasing unnecessary licenses. These reviews—known as “true-up and true-down” reviews—are intended to either “compare[] the current software deployment to the software purchase data to revalidate and reconcile software utilization with historical software procurement data and terms and conditions” (true-up review) or “determine[] if fewer licenses are required” (true-down review). These reviews occur prior to software license renewals or exercising options under a software license agreement.
However, the government often fails to properly manage its purchased licenses by either over- or under-purchasing software licenses. Recent government-wide software license initiatives and, if enacted, proposed legislation are aimed at improving agencies’ management of software licenses to, among other things, consolidate government software purchasing. This includes a government-wide initiative aimed at standardizing software license data to include a vendor assessment initiative, a government-wide IT taxonomy modernization initiative, and a government-wide licensing agreement initiative. In March 2023, legislation was introduced in Congress, titled the “Strengthening Agency Management and Oversight of Software Assets Act” (SAMOSA), to provide Congress improved visibility of federal agency software asset management practices.
Commercial Software Overview
What Is Commercial Software?
Commercial software, in the context of federal procurements, is software that is licensed or offered for license to the general public, typically for purposes other than governmental purposes. The government typically acquires commercial software under the same licenses offered to the public to the extent that such licenses are consistent with federal law. As with any other commercial product, commercial software can include software not yet available in the commercial marketplace but will be in time to satisfy the delivery requirements under a government solicitation, as well as commercial software that has undergone customary or minor modifications to meet government needs. To the extent that commercial software licenses include support services, those services are typically considered commercial services because they support a commercial product.
Many software products are “commercially available off-the-shelf” (COTS) and are designed to be ready to use and integrate with existing systems. COTS software is a narrow subset of commercial software. To be considered COTS, software must be (a) commercial software, (b) licensed in substantial quantities in the commercial marketplace, and (c) offered to the government without modification. COTS software is often developed by third-party vendors and can include operating systems, office suites, productivity applications, email programs, communication protocols, and device drivers.
COTS software is popular because it is convenient and affordable and offers a wide range of features. It can be a good choice for projects with tight schedules and budgets. However, there are some potential drawbacks to using COTS software, including reliance on a third-party vendor to continue to support the software and the software possibly requiring substantial customization. While generally the up-front adoption costs may be lower, COTS software could be more expensive in the long run if the user-base increases or the software requires periodic licensing.
What Is Open-Source Software?
“Open-source software” is defined as “software for which the human-readable source code is available for use, study, re-use, modification, enhancement, and re-distribution by the users of such software.” Open-source software is distributed under licenses that grant users permission to use, modify, and distribute software under certain conditions. These licenses ensure the software’s source code is available to the public. Thus, open-source software generally is licensed under common licenses, such as Apache 2.0, MIT, and GNU General Public License (GPL). If open-source software is already available to the public and is used unchanged, it is usually considered COTS software.
When Are Software Licenses Required?
Software is protected by copyright, and each of the copyright “bundle of rights” can be separately or collectively licensed. These rights include the right to reproduce, distribute, create derivative works, publicly perform, and publicly display the software, allowing the copyright owner to control how their software is used and exploited commercially. As a result, software licenses are required whenever externally acquired software is installed on one or more user computers, installed on a centrally accessed server, or accessed via the Internet.
What Are the Different Types of Cloud-Based Software Distribution Licenses?
Software is distributed in a number of different ways, each of which requires a specific licensing scheme. These include distribution of copies, on media or via the Internet, to be downloaded on individual computers; “Infrastructure-as-a-Service” (IaaS), which refers to a cloud computing model where a provider delivers essential IT infrastructure like servers, storage, and networking capabilities to users on demand; “Platform-as-a-Service” (PaaS), which provides a cloud-based platform that developers can use to create online software; and the more widely adopted “Software-as-a-Service” (SaaS), which is cloud-based software that is hosted online and delivered to licensees via the Internet.
Common Licensing Terms
Identity of Parties
In most instances, the identity of the licensor is simple, assuming all rights to the software are owned by a single entity. Identification of the licensee, however, can be challenging, particularly in the context of the federal government. For example, agencies may have one fulfillment group entering into the contract, while acting on behalf of multiple different entities that will be using the software. This issue can become particularly complex when identifying who the expected authorized users will be and their relationship to the licensing entity.
Duration
An essential term of every software license is its duration. This is particularly important because, depending on the duration of a copyright license, licensees may periodically incur charges in order to continue using the software. These charges must be considered in the acquisition process. Licenses for COTS software are often perpetual, in that once licensed to the end-user, the licensee is not required to renew the license on a periodic basis. This is often seen in connection with operating systems, email clients, and word processing software. More specialized software is often licensed for a specific initial duration followed by automatic extensions until cancelled. The duration can vary from days to years and may or may not include upgrade rights.
Scope of Use
1. Users
Interwoven with the identification of the proper licensee for software is the identification of the users who are expected to have access to the software. The categories of users might include the licensee’s affiliates, contractors, and, sometimes, third parties, if the licensed software is intended to be used in conjunction with other software or services being provided by the licensee.
Historically, software licenses were based on one of two criteria: (1) the number of permitted copies that could be used or (2) the computing capacity of the licensee’s computers. The latter measure has fallen out of favor but is still seen when software is used on mainframe computers—complex, high-performance computers that are used by organizations to process large amounts of data and perform critical applications. These licenses are linked to the speed or power of the server on which they run, or the number of processors.
User-based licenses come in a variety of different configurations. These include (1) per-copy licenses, which may be further delimited by the number of users allowed per license; (2) concurrent use licenses, which allow for a specified number of users to connect simultaneously to a software application; and (3) enterprise or site licenses, which can extend to all users in a particular unit or division or a specific physical site. Many times, user-based licenses are managed using software that tracks when and by whom a particular piece of software is accessed.
2. Territory
Rights in copyright are territorial in nature, meaning that works are protected according to the copyright laws of the country in which the software is used. As a result, care should be taken regarding where licensed software will be accessed and whether that access will be on US territory.
3. Modifications
COTS software generally is distributed as executable code, which does not allow for easy modification by the licensee or end user. Nonetheless, there may be instances where modifications are needed to allow for interoperability with existing platforms or needs. License agreements should account for both permission to modify the software and the ownership of such modifications.
License Fees
As noted, COTS software licenses are typically perpetual and only require an upfront fee. Some commercial software, including some COTS software, include fees for initial and continued use of licenses. These fees may include, as part of the license contract, access to product support (e.g., maintenance, trouble shooting, and training) and/or other services, including upgrades. License fee models differ significantly depending on the software product and vendor.
Other Common Terms
Software licenses, like most contracts, usually include terms that account for indemnity by the licensor for infringement or errors in the software, indemnity by the licensee for certain actions, confidentiality, alternative dispute resolution, choice of law, and other oft-seen terms.
Federal Government Software Licensing
Government’s License Rights in Commercial Software
Companies developing and licensing commercial software are mindful of protecting their valuable intellectual property to maintain their competitive advantage. Although a software developer generally maintains legal ownership of its proprietary software, it provides certain license rights to others for a fee in order for them to use that software. Consider, for example, Microsoft Office, a widely used collection of applications that help with productivity and common computer tasks, including programs for word processing, spreadsheets, presentations, databases, email, and more. While Microsoft always owns its product, the authors of this article are using Microsoft Word pursuant to a license containing certain terms and conditions of use. When Microsoft or similar companies license their software products to the federal government, they want to ensure the government does not obtain greater license rights than ordinarily given to the general public, fearing expanded government rights could weaken their competitive position and limit their ability to profit from their innovations in the market if different from the rights granted in the normal commercial market. On the other hand, the government wants to obtain the necessary rights to use, modify, and distribute the software effectively to support its missions.
Notably, there is virtually no guidance in the FAR regarding negotiating commercial software licenses, with only a passing reference in the Defense Federal Acquisition Regulation Supplement (DFARS) to the “Government’s interest” and negotiating the desired rights “at a fair price.” What the FAR and DFARS do contain, however, is a legal framework for establishing the government’s license rights in software, which in turn informs the negotiation. As such, different rules apply depending on whether the computer software is considered commercial or noncommercial, as prescribed in the FAR and DFARS. When acquiring noncommercial computer software, the government typically seeks specific licensing rights, such as unlimited rights, government purpose rights, and restricted rights in that computer software. When acquiring commercial computer software, the government typically follows standard commercial terms and conditions being offered by the contractor. Indeed, the government has a statutory preference for purchasing commercial products and services. Thus, government agencies often acquire commercial computer software and related services through FAR Part 12 acquisitions for commercial products and services.
As discussed in the outset of the previous section on commercial software, the FAR defines “commercial computer software” as any computer software that is a “commercial product” or “commercial service.” The FAR defines “commercial product” as a product, other than real property, that is typically used by the general public or by nongovernmental entities for purposes other than governmental purposes. It includes products that (1) have been sold, leased, or licensed to the general public or (2) have been offered for sale, lease, or license to the general public. It also includes products that have evolved therefrom, including products that have been modified or adapted from a commercial product to meet specific government requirements, as long as the modifications do not significantly alter the product’s function or essential physical characteristics. The DFARS definition of “commercial computer software” essentially tracks the same elements of the FAR. Thus, if software meets the definition, it is considered “commercial,” even if the government paid for its development.
The FAR and DFARS prescribe the government’s legal rights in a software license. The FAR mandates the government must acquire commercial computer software (and computer software documentation) “under licenses customarily provided to the public to the extent such licenses are consistent with Federal law and otherwise satisfy the government’s needs.” The government has only the rights specified in the license, which must be approved and attached to the contract. Thus, the government’s rights will consist of what is contained in the manufacturer’s end user licensing agreement (EULA), except to the extent such terms either (1) are inconsistent with federal procurement law or (2) do not otherwise satisfy the government end user’s needs. Therefore, contractors are not required to (1) “[f]urnish technical information related to commercial computer software or commercial computer software documentation that is not customarily provided to the public” or (2) “[r]elinquish to, or otherwise provide, the Government rights to use, modify, reproduce, release, perform, display, or disclose commercial computer software or commercial computer software documentation except as mutually agreed to by the parties.”
FAR 52.227-19, Commercial Computer Software License, states that the commercial computer software delivered under the contract may not be used, reproduced, or disclosed by the government except as provided in the clause, which allows the government certain commercial rights including the ability to use the software with the computer for which it was acquired, use with a backup computer, reproduce for safekeeping (archives) or backup purposes, modify the software, and disclose to support contractors.
Similar to the FAR, the DFARS instructs that commercial computer software or commercial computer software documentation “shall be acquired under the licenses customarily provided to the public unless such licenses are inconsistent with Federal procurement law or do not otherwise satisfy user needs.” Thus, the software license specifies the government’s legal rights to use software in accordance with terms and provisions agreed to by the software copyright owner, including any rights to use, modify, reproduce, release, perform, display, or disclose computer software or computer software documentation. Moreover, the government must, to the maximum extent practicable, competitively obtain commercial computer software and commercial computer software documentation using firm-fixed-price contracts or firm-fixed-price orders under available pricing schedules.
There is no DFARS clause for commercial software. This is because, due to DoD’s preference for acquiring commercial products and services, as codified in 10 U.S.C. § 3453 and 41 U.S.C. § 3307, commercial software licenses shall be used rather than a DFARS clause. Notably, DoD issued a final rule on March 22, 2023, implementing a new statutory direction at 10 U.S.C. § 4576 requiring DoD to consider all noncommercial computer software and related materials necessary for the agency’s needs throughout the software’s life cycle during acquisition negotiations in order to improve acquisition planning and ensure fair and reasonable pricing for software deliverables and license rights before contract award. Although DoD acknowledged the statute applies to noncommercial software, it noted that the statute also allows for the consideration of commercial software to meet the government’s life-cycle needs, and directs the government to acquire all necessary software and related materials, regardless of their commercial status, to support the life cycle of noncommercial software. The final rule also allowed for alternative deliverables when software delivery is not feasible. DoD asserts that this approach aligns with its long-standing policies for acquiring commercial software, which permit negotiations for additional deliverables and license rights when standard commercial offerings do not meet the government’s needs. The final rule emphasized consistency with existing policies and allowed contracting officers discretion in considering specific acquisition factors. This alignment with commercial licensing models aims to encourage commercial vendors to work with DoD.
Common Software License Provisions That Conflict with Federal Law
Commercial software licenses, often referred to as EULAs, are typically designed for the general public and may not align with federal legal requirements. When the government acquires software, that software comes with a license that sets forth the terms and conditions of use. That license can take different forms: a standalone document, a clickwrap agreement, or a shrinkwrap agreement. Depending on the form the license takes, the government may inadvertently agree to terms normally provided to the general public but to which the government cannot agree based on fiscal or procurement laws. For instance, if the license takes the form of a clickwrap agreement—where the user must agree to a license’s terms and conditions prior to using the software—government users may unknowingly agree to certain terms that the government may be prohibited by law from accepting.
During the proposal phase of a commercial computer software procurement, the government will typically review and evaluate the license terms and condition. Where award is made, the government is required to insert FAR 52.212-4, Contract Terms and Conditions—Commercial Products and Services, into the awarded contract. Moreover, the government will often incorporate the software license into the contract via exhibit or addendum. Where conflicts arise between terms of the contract and the license agreement, the order of precedence clause will resolve the inconsistencies in a particular order, whereby the software license agreement takes precedence over many of the terms and conditions of the procurement contract. As a result, the government often flags any license terms that (1) are inconsistent with federal procurement law or (2) do not otherwise satisfy the government end user’s needs.
There are certain clauses that are standard to a commercial software license agreement that inherently conflict with federal fiscal or procurement law. For example:
- Assignment Clauses: The Anti-Assignment Act prohibits the assignment of government contracts without the federal government’s express approval. Many commercial licenses include clauses that allow the contractor to assign the agreement to a third party, which is not permitted under federal law.
- Automatic Renewal Clauses: Commercial licenses may include a clause requiring automatic renewal of the license agreement. These clauses can violate the Competition in Contracting Act (CICA), which requires full and open competition for government contracts. Automatic renewals also may conflict with the Anti-Deficiency Act (ADA) if they obligate the government to future payments without guaranteed appropriations. Moreover, any automatic renewal that extends beyond five years does not comply with FAR 17.204, which places a restriction on option periods not to exceed five years (including the base year).
- Choice of Law and Forum Clauses: Commercial license clauses often specify that disputes will be governed by the laws of a particular state and adjudicated in a specific forum. Such provisions conflict with the federal government’s sovereign immunity, which only allows lawsuits against the government under specific conditions, such as those outlined in the Tucker Act and the Federal Tort Claims Act (FTCA). Moreover, while the Tucker Act waives the government’s sovereign immunity for contract claims, the Contract Disputes Act (CDA) governs the requirements for those claims. Thus, contract disputes between the licensor and the government are required to be governed by the CDA and the FTCA, and the government will not agree to be bound by state law, nor can the United States be sued in state or foreign court.
- Confidentiality Clauses: Clauses that require the government to keep the terms of the agreement confidential can conflict with the Freedom of Information Act (FOIA), which mandates public access to government records, including contracts.
- Indemnity Clauses: Both contractor and government indemnity clauses can pose issues. Contractor indemnity clauses—which typically require the contractor to defend the government against third-party infringement claims concerning the product or software—may conflict with the Department of Justice’s (DOJ) exclusive jurisdiction over litigation involving the federal government. In other words, the government cannot hand over the reins of its defense or its settlement authority to a private party. Government indemnity clauses—where the government agrees to compensate the other party (the indemnified party) for costs and expenses arising out of third-party claims—can violate the ADA and exceed the purpose or amount prescribed for the burdened appropriation, as prescribed within the appropriations statute, if the indemnification clause creates open-ended liabilities.
- Limitation of Liability Clauses: These clauses often limit the contractor’s liability for damages, which can conflict with the CDA governing claims involving federal contracts. Under the CDA, a contracting officer does not have authority to settle any claim that involves fraud. Rather, only the DOJ can litigate and settle claims pursuant to the civil False Claims Act.
- Tax Clauses: Commercial license agreements often contain a clause requiring the licensee to pay for taxes associated with the purchase of the software license. However, the federal government is constitutionally immune from paying state taxes, and any clause requiring the government to pay such taxes is invalid.
- Termination Clauses: Commercial license agreements often contain clauses allowing the contractor to unilaterally terminate the agreement for breach or other reasons. However, such clauses conflict with the CDA and the FAR, which provide specific procedures for contract disputes and termination. The government retains the right to terminate the contract for convenience or cause.
- Unilateral Change Clauses: These clauses allow the contractor to unilaterally modify the terms of the agreement, which is not permissible under FAR 43.201, as only contracting officers can execute modifications on behalf of the government.
- Terms That Do Not Satisfy the Government’s Needs: Beyond terms and conditions that are inconsistent with fiscal or federal procurement law, the FAR and DFARS mandate that commercial license terms can be altered where the existing terms do not otherwise satisfy the government end user’s needs. The government sometimes has specific needs that are not always outlined in law and require flexibility in commercial terms and conditions. To account for these unique needs, the government sometimes uses this exemption to contract on more familiar terms and to seek noncommercial rights in commercial software.
Enforcing Contractors’ Rights When the Government Violates the Software License
Enforcement by contractors involves legal actions seeking monetary damages and, if possible, an injunction to stop the government’s infringement. But bringing legal action against the government is complicated. As a general matter, the federal government can only be subject to suit if it has waived sovereign immunity by statute or by contract. There are two common types of lawsuits that can be brought against the government to enforce violations of software license terms: (1) copyright infringement claims under 28 U.S.C. § 1498 and (2) breach of contract claims under the Contract Disputes Act or the Tucker Act.
Copyright Infringement
Liability
The Copyright Act of 1976, as amended, protects “original works of authorship fixed in any tangible medium of expression, now known or later developed, from which they can be perceived, reproduced, or otherwise communicated, either directly or with the aid of a machine or device.” Works of authorship include, among other things, computer software.
The Copyright Act grants a copyright owner “exclusive rights to do and to authorize” certain delineated actions, including reproducing the copyrighted work in copies and distributing those copies to the public. Authorization typically comes in the form of a written license. Thus, the general public can only reproduce copyrighted material through a license or other authorization. This includes the federal government procuring computer software that is published and copyrighted. Anyone who violates an exclusive right of a copyright owner is an “infringer” of the copyright. Thus, to establish a prima facie case of copyright infringement pursuant to 28 U.S.C. § 1498(b), a plaintiff must prove “(1) ownership of a valid copyright, and (2) copying of constituent elements of the work that are original.”
Determining whether breach of a software license gives rise to a claim for copyright infringement is difficult. License agreements typically contemplate some form of permissible copying. Thus, the scope of the license agreement defines what qualifies as unlawful reproduction. For a claim of copyright infringement to arise, the copying must be beyond the scope of the license possessed by the licensee. Thus, copies of computer software subject to a license agreement infringe a copyright if two things are true: (1) the copies include original software code and (2) the copying exceeds the scope of the license agreement. Additionally, whether a licensee acts beyond the scope of the license agreement turns on whether that term in the license is a condition that limits the scope of the license or is merely a covenant. A covenant is a binding promise to do or not do something, while a condition is a future event that must occur before a party is obligated to perform a contract. Terms of a license are presumed to be covenants, rather than conditions, unless it is clear that a condition precedent was intended.
Damages
Congress waived sovereign immunity to allow copyright owners to recover from the federal government their “reasonable and entire compensation” for copyright infringement. The computation of “reasonable and entire compensation” under the statute is essentially identical to “actual damages” under the Copyright Act.
Normally, a copyright owner proves its entitlement to damages through evidence of lost sales or diminished copyright value. However, where copyright infringement has not produced lost sales or opportunities or diminished the copyright’s value, damages are instead calculated based on a reasonable license fee, which is determined using a hypothetical negotiation. In conducting the hypothetical negotiation, courts examine the economic realities using the factors suggested in the seminal patent infringement case of Georgia-Pacific Corp. v. U.S. Plywood Corp. These factors include (1) the infringer’s use of the copyrighted software and its associated value, (2) the established profitability of the copyrighted software, and (3) the rates paid by the government for the use of other similar software. Courts also consider all the relevant facts—not just those known by the parties at the time. The hypothetical negotiation also assumes a willing buyer and seller. Moreover, the court need not assess the license fee with “mathematical exactness,” but rather must be able to make a reasonable approximation. Such an inquiry often involves competing expert witnesses and litigation, can be fact-intensive on both the infringement and the damages owed, and can become expensive for both parties.
Jurisdiction
A copyright is an exclusive right affirmatively granted to an author by the federal government. Thus, the government retains the ability to infringe any copyright without permission, so long as the government pays the copyright owner reasonable compensation. As a result, the government and authorized contractors are not subject to regular infringement suits in US district courts, nor can any court enjoin them from continuing the infringement. Rather, the US Court of Federal Claims (COFC) possesses exclusive jurisdiction to entertain suits against the United States for the infringement of copyrights that occur within the United States.
The COFC’s jurisdiction is subject to three limitations. The statute also provides that no recovery may be had for any copyright infringement by the government committed more than three years before the filing of the complaint. The period during which an administrative claim for compensation is pending is not counted as part of the three-year period unless suit is instituted before the government’s denial of the claim.
Two recent decisions from the COFC, both of which are discussed below, underscore the critical importance of clear and enforceable software licensing agreements in government contracts, and the severe legal and financial repercussions of noncompliance with licensing terms. In Bitmanagement, the US Navy’s unauthorized use of software due to failure to implement tracking software led to significant liabilities, while in 4DD Holdings, the unauthorized copying and use of software by government officials resulted in substantial compensation for infringement. These cases emphasize the necessity for robust license management and adherence to intellectual property rights to avoid costly disputes.
1. Bitmanagement Software GmbH v. United States
In Bitmanagement Software GmbH v. United States, the dispute centered around the US Navy’s unauthorized use of Bitmanagement’s three-dimensional graphics software known as “BS Contact Geo.” Bitmanagement, a German company, developed the three-dimensional visualization software enabling the visualization of geographic information in third-party hardware and software products. Bitmanagement primarily licensed its software via “PC” or “seat” licenses, which allowed one installation of the software onto one computer per license. Each copy of the software included a desktop executable file and a web browser plugin file. The desktop file launched the software as a standalone application, whereas the plugin launched the software within a web browser.
Bitmanagement sold BS Contact Geo licenses to the Navy’s Naval Facilities Engineering Systems Command (NAVFAC) through a reseller, Planet 9 Studios, Inc., on three different occasions. The Navy purchased one copy in 2006, 100 copies in 2008, and 18 copies in 2012. In each instance, Bitmanagement executed a license agreement with Planet 9 indicating how many licenses Planet 9 was authorized to resell to the Navy. Thereafter, the Navy would purchase Bitmanagement’s licenses directly from Planet 9. Thus, although the Navy was bound by the terms of Bitmanagement’s software license, there was no direct contract between Bitmanagement and the Navy.
During the course of the license purchases, Bitmanagement and the Navy discussed moving to a floating license scheme to rectify certain issues the Navy was experiencing managing its individual seat licenses. In particular, the Navy had an existing floating license server tracking application called Flexera that could be used to track BS Contact Geo by limiting the number of simultaneous users of the software based on the number of available licenses. As a result, Bitmanagement agreed to deliver to the Navy a no-cost modification in the form of a new version of BS Contact Geo (version 8.001) “under the same terms of the recently awarded BS Contact Geo license procurement contract with NAVFAC.” Thereafter, the Navy began widespread deployment of BS Contact Geo 8.001 across its Navy Marine Corps Intranet (NMCI) network, where the software resided for more than three years. During that time, Flexera “did not monitor or control the use of the BS Contact Geo plugin, i.e., the OCX component of the software was not Flexera-enabled.” In other words, the Navy deployed the seat licenses across its entire network without implementing Flexera to monitor usage, thereby making it simultaneously available to all of the Navy’s hundreds of thousands of users.
Bitmanagement sued the Navy in the COFC for copyright infringement under 28 U.S.C. § 1498(b). Following trial, the COFC found the government not liable for copyright infringement. Although the COFC found there was no express agreement granting the Navy a license to install BS Contact Geo on all of the Navy’s computers, Bitmanagement had authorized the Navy to copy BS Contact Geo version 8.001 across the Navy’s NMCI network of computers. Thus, although Bitmanagement had established a prima facie case of copyright infringement, the COFC found the Navy had an implied-in-fact license permitting it to make the copies. On appeal, Bitmanagement challenged the COFC’s finding that the Navy had an implied-in-fact license permitting it to make the copies, and even if such an implied license existed, Bitmanagement argued the court failed to address whether the Navy complied with the Flexera condition of the license.
The US Court of Appeals for the Federal Circuit (CAFC) upheld the COFC’s finding that the Navy had an implied-in-fact license that allowed it to deploy BS Contact Geo across its entire network. Moreover, the CAFC held that the implied-in-fact license was not precluded by the existence of express contracts between the Navy and Planet 9, and between Planet 9 and Bitmanagement. However, the CAFC found that even if the Navy established that an implied-in-fact license could have covered the Navy’s actions, the Navy nevertheless committed copyright infringement by failing to comply with a condition of the license—namely that the use of Flexera to track the number of simultaneous users was a condition precedent to the Navy copying BS Contact Geo onto all Navy computers, a condition that the Navy failed to meet. The CAFC applied the legal framework that holds that a copyright owner who grants a license to his copyrighted material waives his right to sue the licensee for copyright infringement and must instead pursue a claim for breach of contract. However, if a license is limited in scope and the licensee acts outside the scope, the licensor can bring an action for copyright infringement under 28 U.S.C. § 1498(b). And whether a licensee acts outside the scope of a contract by failing to comply with a term of the parties’ agreement turns on whether that term is a condition that limits the scope of the license or is merely a covenant. Terms of a license or contract are presumed to be covenants, rather than conditions, unless it is clear that a condition precedent was intended.
The CAFC concluded that Bitmanagement only agreed to the Navy’s proposed licensing scheme based upon the Navy’s promised use of Flexera to limit the number of simultaneous users of BS Contact Geo, regardless of how many copies were installed on Navy computers. Thus, even though Bitmanagement permitted the Navy to allow mass copies of its software at no charge, this was conditioned on the Navy’s use of Flexera at the time of copying the software, thereby making use of Flexera a condition rather than a covenant. The CAFC encapsulated the difference between a condition and a covenant in this context:
Unlike payment, which is typically considered a covenant, the use of Flexera at the time of copying was critical to the basic functioning of the deal. The timing of Flexera was key because the Navy’s tracking of BS Contact Geo users was intended to establish how many additional licenses the Navy would purchase. Without tracking, the Navy would have no basis to purchase more licenses and, consequently, Bitmanagement would have had no reason to enter into the implied-in-fact license. Unlike payment, which can feasibly come at any time after contract performance, Flexera was only useful if it could track, from the beginning, the number of Navy users.
After finding that use of Flexera was a condition rather than a covenant, the CAFC noted that the parties stipulated at trial that Flexera “did not monitor or control the use of the BS Contact Geo plugin,” which included both a desktop executable file (EXE version) and a web browser plugin file (OCX version), and it was not in dispute that “the OCX component of the software was at no point properly monitored by Flexera.” Although the parties disputed whether the Navy monitored the EXE version with Flexera, it made no difference as “[t]hat condition could not have been met by monitoring only half of each copy.” As a result, the Navy’s failure to abide by the Flexera condition of that license rendered its copying of the program copyright infringement. Consequently, the CAFC vacated the previous judgment in favor of the Navy and remanded the case for a calculation of damages to compensate Bitmanagement for the unauthorized copying of its software.
On remand, the COFC awarded Bitmanagement $154,400 in damages based on the Navy’s actual use of the software. Notably, this amount was significantly less than Bitmanagement’s original claim of $155,400,000 (totaling only 0.1%), but the COFC disagreed with Bitmanagement’s damages calculation. Critically, the COFC, as instructed by the CAFC, calculated damages based on the Navy’s actual excess usage of the software rather than the number of excess copies of the software made. Ultimately, the COFC calculated damages based on the number of unique-user licenses that Bitmanagement would have hypothetically negotiated with the Navy to accommodate its excess users, which was one of the three theories briefed by the government. Bitmanagement appealed the COFC’s damages award, which the CAFC affirmed. Although Bitmanagement ultimately prevailed, this decision appears to mainly be a pyrrhic victory due to the paltry legal damages awarded. Had Bitmanagement put forth other damages theories in addition to the number of excess copies made, it may have secured a higher damages award.
2. 4DD Holdings, LLC v. United States
This case highlights the critical importance of adhering to software licensing agreements and the potential legal repercussions of noncompliance. As discussed below, the US Court of Federal Claims found that the government had indeed over-installed the software beyond the licensed terms, resulting in significant copyright violations. For commercial software licensors, it underscores the necessity of clear, enforceable license terms and vigilant monitoring of software usage by licensees. For end users of computer software, it highlights the perils of ignoring license terms.
4DD Holdings, LLC v. United States involved a claim for copyright infringement arising out of the breach of a software license agreement. The software at issue was designed to facilitate the sharing of medical records among government agencies serving servicemembers, veterans, and their families. DoD and the US Department of Veterans Affairs (VA) had long struggled with maintaining comprehensive health care records due to their storage across numerous poorly connected databases. To address this issue, DoD initiated the Defense Health Management System Modernization (DHMSM) program, aimed at creating a single health record for every patient. However, due to the lengthy implementation time, Congress pressured DoD to find a quicker solution, leading to the creation of the Defense Medical Information Exchange (DMIX) program, which sought to federate existing data from various sources into a single format.
DoD selected Systems Made Simple (SMS) as the lead contractor for DMIX and selected “Tetra Healthcare Federator,” a commercial software developed by 4DD Holdings (4DD), as the solution. In order to run, Tetra Healthcare Federator required a separate program called “Tetra Studio,” a graphical interface and programming tool that allows software engineers to “enable and instruct Tetra Healthcare Federator how to function.” 4DD licensed its Tetra software in two ways It licensed its Tetra Healthcare Federator software “per computer core” (where a computer core represents a computer’s processing power, with each Tetra license correlating with one core) and licensed Tetra Studio on a per user or per “seat” basis.
The government initially licensed 64 cores of Tetra Healthcare Federator and 50 seats of Tetra Studio for approximately $1 million. The agreement included an EULA that prohibited copying the software except for a single backup copy. However, only two government employees actually knew of the EULA’s existence, and neither employee was aware that the EULA prohibited copying. In addition, although 4DD—like many software companies—typically invoked a requirement in their license agreement for monitoring license usage (whereby the software alerts the owner when a copy of its software is activated), 4DD could not invoke that feature under this arrangement due to security risks to government networks. As a result, the government bore the burden of tracking license usage and ensuring compliance with the license agreement.
During the software development life cycle, SMS created thousands of unauthorized copies of Tetra Healthcare Federator and Tetra Studio, including backup copies, cloned virtual machines, and new copies released to the Development and Test Center (DTC). 4DD eventually discovered that the government had exceeded its license by at least 68 computer cores. Despite notifying the government and initiating a “true-up” negotiation to address the excess copies, the process was marred by misrepresentations and evidence of destruction by government officials. One government employee ordered the deletion of Tetra copies in the DTC to avoid liability, and both he and the other government employee falsely claimed to have verified the number of Tetra installations.
The true-up negotiations culminated in a meeting where the parties agreed that the government had exceeded the license by 168 cores. 4DD demanded payment at the Solutions for Enterprise-Wide Procurement (SEWP) price of $24,000 per core, but the government negotiated a lower price of approximately $10,000 per core, resulting in a settlement of $1.7 million. As part of the settlement, 4DD released the government from further liability. However, DoD soon abandoned Tetra in favor of the DHMSM project, rendering the government’s Tetra license essentially worthless. The government waited several months to reveal its decision to 4DD. The loss of its customer and doubts regarding the government’s representations of how many Tetra copies actually existed may have motivated 4DD to seek relief in court, while also using the discovery process to uncover the true extent of the government’s infringement.
4DD filed a lawsuit in the COFC for copyright infringement, claiming that the government infringed their copyright by copying and installing the software beyond the scope of the license agreement, which only allowed for a single backup copy. The government argued as an initial matter that 4DD had released the government from liability, thereby barring 4DD’s claim for copyright infringement. However, the COFC found that the government’s misrepresentations during the true-up negotiation invalidated the release of liability and that the government had infringed 4DD’s copyright by making unauthorized copies. The government also argued that even without the release, 4DD’s copyright claim was estopped because 4DD delayed suit until after it knew about the government’s over-installations. However, the COFC refused to apply the equitable estoppel doctrine on the basis that the government had unclean hands as a result of its intentional destruction of evidence and subsequent lying to 4DD about its actions.
Turning to the issue of whether the government was liable for copyright infringement, the COFC held that the government infringed on 4DD’s copyright by making unauthorized copies of its software beyond the scope of the EULA, identifying seven categories of infringing copies, including deployed virtual machine copies, backup copies, and RAM copies. The COFC determined that the government created thousands of infringing copies during the development and testing phases of the program. The COFC rejected the government’s argument that only “runnable” or functional copies should count as infringing, noting that the Copyright Act defines a “copy” as any material object in which a work is fixed and can be perceived or reproduced. The COFC also rejected the government’s claim that copies without associated computer cores should not count against the license. Ultimately, the court found that all categories of copies identified by 4DD’s expert contained infringing copies and that the government exceeded the license’s scope. The court accepted the expert’s count of infringing copies due to the government’s destruction of evidence, which prevented a more precise determination.
In analyzing what a hypothetical negotiation would have produced in the way of a license agreement, the court awarded 4DD a total of $11,159,907.45 in damages.
Breach of Contract
Beyond claims for copyright infringement, as discussed above, if the federal government already has a license, whether express or implied, then any right to relief for violation of the terms of that license will sound in contract and should be pursued as breach of contract claims rather than copyright infringement suits under 28 U.S.C. § 1498. This includes cases where the government exceeds its rights in data such as where the government threatens to release limited rights data or copy-restricted rights software in an unauthorized manner. Contractors frequently attempt to preserve and protect their copyright by incorporating their software licensing into their contract with the government or into their subcontract with a reseller who holds a contract with the government. As discussed in the cases below, tribunals have demonstrated a willingness to enforce these license agreements against the government.
Where such rights are established in a procurement contract, any claim should be filed under the CDA, and may be pursued at the Boards of Contract Appeals or COFC. If the license exists separate and apart from any procurement contracts, a breach of contract claim may be brought in the COFC under its Tucker Act jurisdiction governing general contract disputes with the federal government. In such cases, the aggrieved owner is entitled to its reasonable damages resulting from the breach, which may be measured as lost profits or expectancy damages, or as reliance damages or unjust enrichment, looking at the contractor’s cost of developing the software.
Cases
1. Appeal of CiyaSoft Corp.
The Armed Services Board of Contract Appeals (ASBCA) decision in CiyaSoft Corp. analyzes the intersection between the government’s rights under a contract for commercial software licenses and the seller’s rights preserved by its standard software license terms. This case provides key examples of the critical considerations that contracting officers and software vendors alike must consider when entering into a procurement contract for commercial software licenses under the FAR.
CiyaSoft entered into a contract with the government to provide its proprietary commercial translation software. The contract, awarded through a sole-source justification, involved the purchase of 20 software licenses and included standard terms and conditions for commercial products under FAR Part 12. The contract did not, however, include FAR 52.227-19, Commercial Computer Software License, and did not otherwise address any other conditions or restrictions on the government’s license rights in the software. Rather, the contract merely included a contract line item number (CLIN) stating that it was for 20 single-user licenses.
CiyaSoft’s software was delivered on 20 compact discs (CDs) with copies of written instructions, the single-user license agreement, and a letter addressed to the contracting officer. However, the government had neither reviewed nor negotiated the terms of this license agreement prior to delivery. After receipt, CiyaSoft began to suspect that the government violated the license agreement due to multiple registrations for the same product ID number and technical support inquiries from nonregistered users, including nongovernment personnel. These incidents led CiyaSoft to believe that the government installed copies of the software on multiple devices in apparent contravention of the single-user restrictions, leading CiyaSoft to assert a breach of the license agreement. CiyaSoft filed a certified claim alleging breach of contract and copyright infringement, which, upon denial by the contracting officer, CiyaSoft appealed to the ASBCA.
To prevail on its breach of contract claim, CiyaSoft had to establish that the license agreement was part of its contract with the government. The government argued that the license agreement never became part of the contract because the contracting officer never discussed it with CiyaSoft and never saw a copy of it, the contract did not address licensing agreement terms at all, and the parties never modified the contract to incorporate the license agreement. However, the ASBCA noted that the contract expressly stated it was for 20 single-user software “licenses,” and, in the absence of any other potentially relevant license agreement, concluded that the contract necessarily included CiyaSoft’s license agreement. The ASBCA held that “it does not matter that the licensing agreement was neither negotiated, nor the terms known by the contracting officer. It is the policy of the government, when licensing commercial software to accept the licensing terms customarily provided by the vendor to other purchasers, as long as the license is consistent with federal law and otherwise satisfies the government’s needs.” The ASBCA concluded that at the time the contract was awarded in 2010, the FAR did not address commercial “clickwrap” or “shrinkwrap” forms of licensing agreements, and that CiyaSoft’s software license appeared consistent with those found enforceable by the courts under current commercial law in many jurisdictions. Finally, the ASBCA found that because the contract was expressly for purchasing software licenses, the government had a duty to inquire as to what those license terms were, which the government failed to do here.
The ASBCA ultimately concluded:
Accordingly, based on the fact that it is, and has been, the policy of the federal government prior to the award of the contract to accept the terms of licensing agreements offered by vendors of commercial software that are customarily provided by the vendor to other purchasers and that vendors of commercial software have long included shrinkwrap and clickwrap license agreements with their software, which many courts have found to be valid, enforceable contract terms and the FAR currently also recognizes the validity of clickwrap and shrinkwrap licenses, we find the contract included the licensing agreement appellant shipped with its software. We also hold the government can be bound by the terms of a commercial software license it has neither negotiated nor seen prior to the receipt of the software, so long as the terms are consistent with those customarily provided by the vendor to other purchasers and do not otherwise violate federal law.
The CiyaSoft decision confirms contractors’ rights to enforce the terms of their customary commercial license agreements against the federal government, especially when the government does not include any other software license rights terms. Ultimately, after establishing that the license agreement was part of the contract, the Board concluded that the government breached the contract by violating the license agreement when it permitted the installation of a single copy of the software onto more than one computer and failed to provide CiyaSoft with a list of registered users. The decision, of course, is limited to the factual context before the ASBCA, including the absence of FAR 52.227-19 in the contract. But the decision also serves as a reminder that contracting officers should review any relevant commercial software license in advance to confirm whether the contractor’s customary license provides sufficient rights to satisfy the government’s requirements.
2. Avue Techs. Corps. v. Dep’t of Health and Human Servs.
Many companies that sell software licenses do not contract directly with the federal government, which adds another layer of complexity to attempts by subcontractors or suppliers seeking to enforce their EULAs against the government under the CDA by asserting breach of contract. Recent decisions by the CBCA and the Federal Circuit in Avue Techs. Corps. v. Dep’t of Health and Human Servs. underscore this challenge. In Avue Techs., a company that sold its commercial computer software to the government indirectly through a reseller’s GSA Federal Supply Schedule (FSS) contract sought to enforce its EULA against the government at the CBCA. When GSA added Avue’s software to the prime’s schedule contract, GSA reviewed, approved, and incorporated Avue’s EULA into the schedule contract. Avue alleged the US Food and Drug Administration (FDA) violated its EULA by exceeding authorized usage limits after it purchased the software from the schedule contract in 2015. However, the GSA MAS contract vendor did not sponsor the claim, and the FDA contended that no privity of contract existed between Avue, the software vendor, and the federal government. The CBCA dismissed the appeal for lack of jurisdiction, and Avue appealed to the Federal Circuit.
On appeal, the Federal Circuit vacated the CBCA’s dismissal and held that in certain circumstances, third parties are in privity of contract with the government, becoming a “contractor” within the meaning of the CDA, and therefore may bring a claim under the CDA. The Federal Circuit remanded the appeal to the CBCA to determine whether the EULA constituted a “procurement contract” under the CDA. Specifically, the court wanted the Board to consider whether Avue was a party to a procurement contract with the government by virtue of the incorporation of its EULA into the task order and schedule contract. Since the government did not—and could not—dispute the existence of a “procurement contract,” meaning the task order and schedule contract, the Board was instructed to consider whether Avue had enforceable rights under the procurement contract.
On remand, the CBCA ruled that while the EULA was a legally binding agreement, it did not qualify as a “procurement contract” for CDA purposes. In rejecting Avue’s argument that the EULA created a freestanding enforceable obligation between it and the federal government, the CBCA reiterated that CDA jurisdiction hinges on privity of contract. The Board emphasized that the EULA does not, by its own terms, obligate Avue to perform any services and does not obligate the government to pay Avue directly for its computer software license. Instead, the Board noted that the FSS vendor remained the prime contractor who supplied the subscription to Avue’s software and received payment from the government for that subscription, and that Avue merely conferred conditional permission for the government to use the software it acquired through the prime contractor. In other words, the Board recognized the tiered contracting structure of the transaction, wherein the software vendor acts as a licensor and the FSS prime contractor acts as a reseller of the license to the government via a contract, which places any enforceable rights against the government under the contract exclusively with the FSS prime contractor. As a result, the Board held that the EULA could not sustain a direct CDA claim by Avue.
The Avue decisions reinforce that software licensors selling through agreements with resellers that hold FSS contracts must rely on their prime contractors to sponsor claims for government breaches of incorporated EULAs. While EULAs may be legally binding, they do not constitute “procurement contracts” that independently establish CDA jurisdiction. Software companies should ensure their licensing terms are explicitly incorporated into FSS contracts and collaborate closely with their FSS vendors to pursue sponsored breach of contract claims. This evolving area of procurement law highlights the need for precise drafting and a thorough understanding of the CDA’s jurisdictional framework. Otherwise, software vendors may find their contractual rights unenforceable against the government under the CDA.
Compliance Measures
In the context of government software procurement, compliance measures are essential to ensure software products and services meet stringent security and regulatory standards. These measures are designed to protect sensitive information, maintain the integrity of federal systems, and ensure contractors adhere to best practices in software development and deployment. Key compliance frameworks, such as the National Institute of Standards and Technology (NIST) Secure Software Development Framework and the Federal Risk and Authorization Management Program (FedRAMP), play a crucial role in setting these standards. Additionally, recent legislative and regulatory updates, including requirements for disclosing foreign obligations, further emphasize the importance of transparency and security in government contracts. This section will explore these compliance measures, highlighting their significance and implications for contractors and federal agencies.
NIST Attestation
Federal contractors who sell or license software to US federal agencies will be required to attest that their software products and components are developed using secure practices as outlined in NIST Special Publication 800-218, known as the Secure Software Development Framework (SSDF). This requirement stems from Executive Order 14028, aimed at improving the nation’s cybersecurity, and is supported by two OMB memoranda. The Cybersecurity and Infrastructure Security Agency (CISA) has published a “common form” for this attestation, which federal agencies will use to ensure software security compliance.
Contractors must complete a form confirming their adherence to secure software development practices, providing federal agencies with assurances about the security of the software they use. The new requirement comes amid increasing enforcement actions under the DOJ’s Civil Cyber-Fraud Initiative. Contractors risk not only losing business, but also facing allegations of providing false information if they fail to comply accurately. While CISA has not set a specific deadline, OMB directed agencies to collect attestations within three to six months of the release of CISA’s common form, which happened in March 2024. The FAR Council is expected to incorporate this requirement into new and existing contracts soon. Thus, although agencies will be asking contractors for the common form, the absence of a FAR clause incorporated into the contract requiring submission of the common form creates a bind for contractors—while the agencies may ask for it, there may be no legal requirement to provide it. Contractors need to assess and possibly adjust their software development processes to meet these new standards, which may involve significant diligence and changes to current practices. The goal of these measures is to enhance the security of software used by federal agencies, thereby strengthening the overall cybersecurity posture of the federal government.
FedRAMP
FedRAMP, originally established in 2011, is a government-wide program that aims to streamline the adoption of secure cloud services across federal agencies by providing a standardized authorization process. It is thought of as “the official security stamp of approval to sell cloud computing solutions inside the Washington D.C. beltway.” The GSA FedRAMP Program Management Office (PMO) manages the program. All cloud services offered for sale to the government, such as SaaS, PaaS, and IaaS, are required to obtain a Joint Accreditation Board (JAB) Provisional Authority to Operate (P-ATO) or Agency ATO prior to use by a federal agency.
On July 25, 2024, the OMB issued memorandum M-24-15, which introduces significant updates to the FedRAMP program. The new memorandum rescinds the original 2011 directive and introduces a modernized vision and governance structure for FedRAMP, reflecting advancements in federal cybersecurity and changes in the commercial cloud marketplace.
Among the notable changes in the memorandum is the establishment of a FedRAMP Board. This board is tasked with providing strategic guidance and recommendations to ensure the program remains aligned with the evolving cybersecurity landscape and federal needs. The board will play a crucial role in overseeing the implementation of the updated policies and ensuring that the program’s objectives are met effectively. Another significant update is the introduction of “program authorizations” for cloud service providers (CSPs) that do not have an agency sponsor. This change is designed to expand the FedRAMP marketplace by allowing more CSPs to participate in the program, thereby accelerating the secure adoption of cloud services across federal agencies. By removing the requirement for an agency sponsor, the memorandum aims to reduce barriers to entry for CSPs and foster greater innovation and competition in the cloud services marketplace.
The memorandum also mandates the use of the Open Security Controls Assessment Language (OSCAL). OSCAL is a standardized, machine-readable data format that enhances cybersecurity compliance by enabling automated security assessments and continuous monitoring. By adopting OSCAL, the memorandum seeks to improve the efficiency and effectiveness of the authorization process, making it easier for federal agencies to assess and manage the security of cloud services.
For federal agencies, the updated FedRAMP policy means a more streamlined and efficient process for adopting secure cloud technologies. The introduction of program authorizations and the use of OSCAL are expected to reduce the time and effort required to achieve and maintain compliance with federal security standards. This, in turn, will enable agencies to leverage the benefits of cloud computing more rapidly and consistently, enhancing their ability to deliver services to the public. For cloud service providers, the changes introduced in the memorandum represent new opportunities and challenges. The removal of the agency sponsor requirement opens the door for more CSPs to participate in the FedRAMP program, potentially increasing competition in the marketplace. However, CSPs also will need to adapt to the new requirements, such as the use of OSCAL, to ensure they can meet the updated security and compliance standards.
Overall, OMB memorandum M-24-15 marks a significant step forward in the modernization of the FedRAMP Program. By introducing a new governance structure, expanding the FedRAMP marketplace, and adopting advanced technologies like OSCAL, the memorandum aims to enhance the security, efficiency, and effectiveness of the authorization process. These updates will help ensure that federal agencies can continue to leverage secure cloud services to meet their mission-critical needs in an increasingly digital world.
Disclosure of Information Regarding Foreign Obligations
On November 15, 2024, DoD issued a proposed rule (DFARS Case 2018–D064) to amend the DFARS to implement Section 1655 of the John S. McCain National Defense Authorization Act for Fiscal Year 2019.199 Specifically, Section 1655(a) prohibits DoD from acquiring certain products, services, or systems unless the contractor discloses any sharing of source code and computer code with foreign governments. Additionally, Section 1655(c) mandates that contracts include a clause requiring ongoing disclosures during the contract performance period if new information arises. This rule aims to enhance transparency and security in defense contracts involving information technology, cybersecurity, industrial control systems, and weapon systems.
To implement these requirements, the proposed rule introduces a new subpart, DFARS 239.7X. This new subpart outlines the statutory requirements; defines key terms such as “computer code,” “open-source software,” and “source code”; and details the prohibition on acquiring certain products without the required disclosures. Under the proposed rule, contractors must report any foreign access to source code or object code for noncommercial products developed for DoD, dating back to August 13, 2013. The proposed rule clarifies that the prohibition does not apply to open-source software and establishes procedures for contracting officers to validate disclosures in the Electronic Data Access (EDA) system before awarding contracts. The rule also provides guidelines for a new solicitation provision and contract clause. The pre-award provision, DFARS 252.239-70YY, requires offerors to disclose foreign obligations in the EDA system to be eligible for award. The post-award clause, DFARS 252.239-70ZZ, requires contractors to maintain and update disclosures in the EDA system and ensure subcontractors do the same.
Overall, this proposed rule emphasizes the importance of maintaining accurate and complete disclosures throughout the contract life cycle. By mandating the disclosure of such obligations, DoD aims to identify and address any vulnerabilities that may arise from foreign entities gaining access to critical technological information. This measure is part of a broader effort to safeguard the integrity of defense systems and maintain the technological edge of the US military. Public comments on the proposed rule were due on January 14, 2025.
Conclusion
Licensing commercial software to the federal government requires navigating complex regulations, compliance measures, and evolving procurement policies. Contractors must understand specific licensing terms that align with federal requirements, such as those in the FAR and DFARS, ensuring their software licenses meet federal law and government needs in areas like cybersecurity and intellectual property. Effective license management is crucial to avoid disputes and protect intellectual property. Best practices include thoroughly preparing and negotiating license agreements, staying informed about legislative updates, and leveraging acquisition vehicles like DoD’s Enterprise Software Initiative and the GSA MAS program to streamline procurement and build compliant partnerships with government agencies.
