• Home
  • Resources
    • Find Resources by Topic Tags
    • Cybersecurity Policy Chart
    • CSIAC Reports
    • Webinars
    • Podcasts
    • Cybersecurity Digest
    • Standards & Reference Docs
    • Journals
    • Certifications
    • Acronym DB
    • Cybersecurity Related Websites
  • Services
    • Free Technical Inquiry
    • Core Analysis Task (CAT) Program
    • Subject Matter Expert (SME) Network
    • Training
    • Contact Us
  • Community
    • Upcoming Events
    • Cybersecurity
    • Modeling & Simulation
    • Knowledge Management
    • Software Engineering
  • About
    • About the CSIAC
    • The CSIAC Team
    • Subject Matter Expert (SME) Support
    • DTIC’s IAC Program
    • DTIC’s R&E Gateway
    • DTIC STI Program
    • FAQs
  • Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Skip to footer
Login / Register

CSIAC

Cyber Security and Information Systems Information Analysis Center

  • Resources
    • Find Resources by Topic Tags
    • Cybersecurity Policy Chart
    • CSIAC Reports
    • Webinars
    • Podcasts
    • Cybersecurity Digest
    • Standards & Reference Docs
    • Journals
    • Certifications
    • Acronym DB
    • Cybersecurity Websites
  • Services
    • Free Technical Inquiry
    • Core Analysis Task (CAT) Program
    • Subject Matter Expert (SME) Network
    • Training
    • Contact
  • Community
    • Upcoming Events
    • Cybersecurity
    • Modeling & Simulation
    • Knowledge Management
    • Software Engineering
  • About
    • About the CSIAC
    • The CSIAC Team
    • Subject Matter Expert (SME) Support
    • DTIC’s IAC Program
    • DTIC’s R&E Gateway
    • DTIC STI Program
    • FAQs
  • Cybersecurity
  • Modeling & Simulation
  • Knowledge Management
  • Software Engineering
/ Journal Issues / DoD and Open Source Software / Publicly Releasing Open Source Software Developed for the U.S. Government

Publicly Releasing Open Source Software Developed for the U.S. Government

Published in Software Tech News
Volume: 14 Number: 1 - DoD and Open Source Software

Author: Dr. David A. Wheeler
Posted: 03/11/2016 | Leave a Comment

This article summarizes when the U.S. federal government or its contractors may publicly release, as open source software (OSS), software developed with government funds.  This article is intended for non-lawyers, to help them understand the basic rules they must follow.

Before going further, a few definitions and warnings are necessary.  In this article, the term “government” means the U.S. federal government.  “You” means the government organization or contractor who wants to release software to the public as OSS.  “Releasing to the public as OSS” means (1) releasing the software source code to the general public (such as through a public website) and (2) giving its users the freedom to use it (for any purpose), study it, modify it, and redistribute it (modified or not)[1].  Note that these freedoms can be given by releasing the software under an OSS license,[2] or by releasing it without any copyright protection.  This article is not legal advice, and variations of specific facts can produce different results.  Also, note that government contracting is very different from commercial practices; do not presume that commercial practices apply.

To determine if you can release to the public some software developed with government funds as OSS, you must answer the following five questions:

1. What contract applies, what are its terms, and what decisions have been made?

First, find the contract and find what terms apply, particularly which data rights clauses apply.  Most contracts use one of a small set of standard data rights clauses, but you need to find out which clauses apply, and if the contract grants exceptions.  If the clause text is different (e.g., older) than the clauses discussed here, or makes an exception, then the contract (if legal) governs.  Also, determine what data rights decisions have been made by the contracting officer.

2. Do you have the necessary copyright-related rights?

The following table shows the default copyright-related rights for common circumstances.  The first row is a special case, where a federal employee develops the software as part of his or her official duties.  Later rows discuss the typical impact of common data rights clauses from the Federal Acquisition Regulation (FAR) or the Department of Defense FAR Supplement (DFARS) (but note the dates):

jsn_dfar1

jsn_dfar2

These are the general rules, but you must examine your specific circumstances to determine exactly what you can do.  There are details in the FAR and DFARS clauses not emphasized here, and the contract can change from these defaults to something very different.  Some contracts will use different versions of the FAR and DFARS clauses, so check to see if there are any relevant differences.  Note that some other agencies (like NASA) have FAR supplements, which are not covered here.

The table above only applies to software that was either (1) developed by a government employee as part of his or her official duties or (2) developed by a government contractor (directly or indirectly) as part of a government contract.  Such software may include or depend on other software, such as commercial software, that does not meet these criteria.  When a system includes commercial software, the commercial license applies to those components, and everyone must comply with their license terms.  Commercial software includes any software that is used for at least one non-governmental use and has been sold, leased, or licensed to the general public (per 41 USC §403 and DFARS 252.227-7014(a)(1)), so nearly all publicly-available OSS is commercial software.  Commercial software with minor modifications is still considered commercial software.

In many cases the contractor receives copyright.  When there are multiple contractors or suppliers (e.g., a lead integrator and subcontractors), the legal arrangements between the organizations determine which contractors/suppliers are legally allowed to assert copyright.  Lead contractors do not necessarily receive copyrights from their subcontractors and suppliers.  Note that the government can receive and hold copyrights transferred to it, per 17 USC §105.

In many cases the government is not the copyright holder but has unlimited rights (see rows B, D, E, and I).  If the government has unlimited rights, it has essentially the same rights as a copyright holder for purposes of releasing the software as OSS[3].  Thus, it can release the software under any OSS license it chooses, including the GNU General Public License (GPL) and Lesser GPL (LGPL)[4].  When the government has unlimited rights but is not the copyright holder, there are a few actions it cannot take, e.g., the right to transfer or assign rights, and standing to sue in court over copyright infringement[5].  However, for the purposes here these are technicalities; the key point is that the government can release the software as OSS, under any OSS license it chooses, once it receives unlimited rights.

The government should be extremely wary of receiving less than unlimited rights for software or systems it paid to develop.  For example, some contractors will intentionally embed components over which they have exclusive control, and then design the rest of the system to depend on those components.  When the government has less than unlimited rights, it risks creating a dependency on a contractor, rendering competition for that system meaningless[6] and in some cases putting military capability at risk.[7] [8]

Some have misunderstood U.S. law and policy as requiring the government to mindlessly accept proposals which give less than unlimited rights for systems developed though government funding.  It is true that 10 U.S.C. §2320(a)(2)(F) states that “a contractor or subcontractor (or a prospective contractor or subcontractor) may not be required, as a condition of being responsive to a solicitation or as a condition for the award of a contract, to … sell or otherwise relinquish to the United States any rights in technical data [except in certain cases, and may not be required to ] refrain from offering to use, or from using, an item or process to which the contractor is entitled to restrict rights in data”[9].  However, this is not the whole story.  “If the Government has properly required certain data or software in a solicitation, it is entitled to certain rights in accordance with the statute and an offer failing to propose at least those rights could be held unacceptable.”  What is more, the government may (and should) evaluate proposals “on the basis of data rights and giving higher ratings to offerors willing to provide more than the bare minimum rights”[10]

Under many of the FAR (but not DFARS) clauses, if the government agrees to allow contractors to assert copyright, the government loses many of its rights, forever, to software that the government paid to develop (see rows B, C, L, and M).  This loss of rights can be quite detrimental to the government.  What’s more, it creates a difficult decision for a contracting officer to make, as the contracting officer must anticipate all possible future uses to make a good decision (something that is difficult in practice).  The usual DFARS clause (252.227-7014) avoids this problem; in this clause, typically the government ends up with unlimited rights to software it paid to develop (in some cases after a delay), and the contractor has copyright, enabling both parties to take actions such as releasing the software as OSS.

Here are a few notes about specific clauses:

  • Under FAR 52.227-14 (rows B and C), the government can grant a contractor the right to assert copyright, at which point the contractor gains rights but the government permanently loses rights.  Per FAR 27.404-3(a)(2), the government should grant this request only “when [that] will enhance appropriate dissemination or use.”  Government officials should not grant this automatically, as doing so dramatically reduces the government’s rights to software that the government paid to develop.  The government could choose to grant this permission on condition that the software be immediately released to the public under some specific OSS licenses (with the license agreed upon as part of the condition for release).  In such a case, public release as OSS would be used as a method to enhance dissemination and use.  Deliverables can include data not first produced in the performance of the contract, per (c)(2), but in this case it is not clear to this author if the government can release software as OSS.
  • Under DFARS 252.227-7014 (rows D-G), the contractor normally gets copyright.  The government gets the same rights as a copyright holder (via unlimited rights) if (1) the software was developed exclusively with government funding or (2) the funding was mixed and five years have passed after the relevant contract or contract modification that caused its development was signed.  The government should beware of situations where the contractor attempts to deliver software that vitally depends on some component that they developed entirely at private expense.  Such a dependency can inhibit any future competition for maintenance, as by default the government only has restricted rights to such components.
  • Under DFARS 252.227-7018 (rows H-J), the government typically gets unlimited rights to software not exclusively developed at private expense, but only after five years after the project has completed (note that this is a different starting time than DFARS 252.227-7014).  Amendment I can remove this right as long as the product is “reasonably available to the public for purchase.”
  • FAR 52.227-17 (rows L-N) is, according to FAR 27.409(e), to be used for software for the “government’s internal use” or where “there is a need to limit distribution” or to “obtain indemnities for liabilities.”  However, purposes change; software originally developed for the “government’s internal use” may become software that should be publicly released as OSS.  This document simply describes what is allowed, rather than the expectations of the original contract authors.
  • DFARS 252.227-7020 (rows O-P, the special works clause) is discussed in DFARS 227.7106.  That discussion does not specifically mention software, but the -7020 clause can be used for software.  DFARS 227.7106(2) says it can be used for “a work” and is not just limited to “technical data.”  This clause should be used if the government must own or control copyright.  For example, it might be appropriate if the government wishes publicly release OSS and be able to (1) directly enforce copyright in court, and/or (2) provide indemnification.
Pages: Page 1 Page 2 Page 3

Previous Article:
« Application Specific Abstractions: A Research
Next Article:
Open Source Software Is Commercial »

Author

Dr. David A. Wheeler
Dr. David A. Wheeler
My professional interests are in improving software development practices for higher-risk software systems (i.e., ones which must be secure, large, and/or safety-critical). My specialties include writing secure programs, vulnerability assessment, open standards, open source software / free software (OSS/FS), Internet/web standards and technologies, and POSIX.

Reader Interactions

Leave a Comment Cancel

You must be logged in to post a comment.

sidebar

Blog Sidebar

Featured Content

The DoD Cybersecurity Policy Chart

The DoD Cybersecurity Policy Chart

This chart captures the tremendous breadth of applicable policies, some of which many cybersecurity professionals may not even be aware, in a helpful organizational scheme.

View the Policy Chart

Featured Subject Matter Expert (SME): Daksha Bhasker

A dynamic CSIAC SME, Senior Principal Cybersecurity Architect, Daksha Bhasker has 20 years of experience in the telecommunications services provider industry. She has worked in systems security design and architecture in production environments of carriers, often leading multidisciplinary teams for cybersecurity integration, from conception to delivery of complex technical solutions. As a CSIAC SME, Daksha's contributions include several published CSIAC Journal articles and a webinar presentation on the sophiscated architectures that phone carriers use to stop robocalls.

View SME's Contributed Content

CSIAC Report - Smart Cities, Smart Bases and Secure Cloud Architecture for Resiliency by Design

Integration of Smart City Technologies to create Smart Bases for DoD will require due diligence with respect to the security of the data produced by Internet of Things (IOT) and Industrial Internet of Things (IIOT). This will increase more so with the rollout of 5G and increased automation "at the edge". Commercially, data will be moving to the cloud first, and then stored for process improvement analysis by end-users. As such, implementation of Secure Cloud Architectures is a must. This report provides some use cases and a description of a risk based approach to cloud data security. Clear understanding, adaptation, and implementation of a secure cloud framework will provide the military the means to make progress in becoming a smart military.

Read the Report

CSIAC Journal - Data-Centric Environment: Rise of Internet-Based Modern Warfare “iWar”

CSIAC Journal Cover Volume 7 Number 4

This journal addresses a collection of modern security concerns that range from social media attacks and internet-connected devices to a hypothetical defense strategy for private sector entities.

Read the Journal

CSIAC Journal M&S Special Edition - M&S Applied Across Broad Spectrum Defense and Federal Endeavors

CSIAC Journal Cover Volume 7 Number 3

This Special Edition of the CSIAC Journal highlights a broad array of modeling and simulation contributions – whether in training, testing, experimentation, research, engineering, or other endeavors.

Read the Journal

CSIAC Journal - Resilient Industrial Control Systems (ICS) & Cyber Physical Systems (CPS)

CSIAC Journal Cover Volume 7 Number 2

This edition of the CSIAC Journal focuses on the topic of cybersecurity of Cyber-Physical Systems (CPS), particularly those that make up Critical Infrastructure (CI).

Read the Journal

Recent Video Podcasts

  • A Brief Side-by-Side Comparison Between C++ and Rust – Part 3 Series: Programming Language Comparisons
  • A Brief Side-by-Side Comparison Between C++ and Rust – Part 2 Series: Programming Language Comparisons
  • A Brief Side-by-Side Comparison Between C++ and Rust – Part 1 Series: Programming Language Comparisons
  • Digital Engineering Implementation Progress and Plans Series: CSIAC Webinars
  • Assessing the Operational Risk Imposed by the Infrastructure Deployment Pipeline Series: The CSIAC Podcast
View all Podcasts

Upcoming Events

Jan 28

Data Privacy Day

January 28, 2022
Jan 28

Data Privacy Day

January 28, 2023
View all Events

Footer

CSIAC Products & Services

  • Free Technical Inquiry
  • Core Analysis Tasks (CATs)
  • Resources
  • Events Calendar
  • Frequently Asked Questions
  • Product Feedback Form

About CSIAC

The CSIAC is a DoD-sponsored Center of Excellence in the fields of Cybersecurity, Software Engineering, Modeling & Simulation, and Knowledge Management & Information Sharing.Learn More

Contact Us

Phone:800-214-7921
Email:info@csiac.org
Address:   266 Genesee St.
Utica, NY 13502
Send us a Message
US Department of Defense Logo USD(R&E) Logo DTIC Logo DoD IACs Logo

Copyright 2012-2021, Quanterion Solutions Incorporated

Sitemap | Privacy Policy | Terms of Use | Accessibility Information
Accessibility / Section 508 | FOIA | Link Disclaimer | No Fear Act | Policy Memoranda | Privacy, Security & Copyright | Recovery Act | USA.Gov

This website uses cookies to provide our services and to improve your experience. By using this site, you consent to the use of our cookies. To read more about the use of our site, please click "Read More". Otherwise, click "Dismiss" to hide this notice. Dismiss Read More
Privacy & Cookies Policy

Privacy Overview

This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary
Always Enabled

Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.

Non-necessary

Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.

SAVE & ACCEPT