Computer Software Copyright Basics 
Robert Kasunic
Assistant General Counsel
United States Copyright Office

The Copyright Act is like a jigsaw puzzle. To understand how a class of works is treated, one needs to pull together and integrate the various sections that apply.

In the 1976 revision of the Copyright Law, Congress left a place marker for computer software pending the CONTU report.  The report recognized alternative forms of protection and that, although these works had primarily functional uses, the form of expression warranted protection as a “literary” work. Explicit copyright protection for computer software was enacted in 1980.  Computer software is defined in Title 17 Section 101 as a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result.

The jigsaw starting point is Section 102.  Two aspects of computer software diverge from other types of copyright protected works.  The first deals with fixation.  In order for computer software to be used, it is necessary to make a “transitory” copy to load into RAM.

The next piece is Section 106.  Not all rights are exclusive for computer software.  See 17 USC Section 117: Limitations of Exclusive Rights:  Computer Programs.
A common characteristic of computer software is that usually there are multiple authors, which would qualify them as “joint works.”  Although, generally they are “works made for hire”; i.e., created within the scope of employment and for which the employer is the “author.”   This is the case of “works of the U.S.” Government” (Section 105) created by federal officers or employees on the job.
Computer programs may also be treated as compilations and derivative works when based on pre-existing work.

A cautionary reminder is that ownership transfer of a tangible physical copy of a computer program is different than a transfer of the intangible copyright in the content.   17 USC Section 202. 

The prevailing test today for software infringement is Computer Associates International v. Altai, Inc. 982 F.21 693(2nd Cir 1992) digital-law-online.info/cases/23PQ2D1241.htm


Open Source Software (OSS or FLOSS) Basics: An Introduction
Dr. David A. Wheeler
Institute for Defense Analyses

The briefing begins with a definition of Free / Open Source Software, i.e., software with its source code available that may be used, copied, and distributed with or without modification and that may be offered either with or without a fee. If the end-user makes any alterations to the software, he can either choose to keep those changes private or return them to the community so that they can potentially be added to future releases.  By definition nearly all OSS are commercial items insofar as they are “any  item, other than real property, that is …sold, leased, or licensed to the general public; or has been offered for sale, lease, or license to the general public..”  OSS is consistent with DoD policy as evidenced in Department of Defense (DoD) memo “Clarifying Guidance Regarding OSS” (Oct 16, 2009); OMB M-04-16 “Software Acquisition” (July 1, 2004); and Dept. of the Navy “OSS Guidance” (June 5, 2007). OSS approaches have the potential to increase functionality, quality, and flexibility, while lowering cost and development time. Include OSS options when acquiring, then evaluate.

The following section of the briefing consisted of a discussion of the types of OSS licenses. These can be categorized as Permissive (proprietary versions can be developed for example, MIT, BSD-new); Strongly protective (cannot distribute proprietary version or directly combine (link) into proprietary work, f or example GPL) and Weakly protective (cannot distribute proprietary version of this component, but can link into larger proprietary work LGPL).

Neither OSS nor proprietary is always better, but there are many cases in which OSS is clearly better.  Be sure to include OSS when evaluating options.



Software Acquisition under the FAR (Federal Acquisition Regulation)
Gary G. Borda
Agency Counsel for Intellectual Property
NASA Headquarters

The briefing began with an overview of rights in data within the Federal Acquisition Regulation, including the applicable definitions and the respective rights and obligations of the Government and the contractor in general (52.227-14), with regard to special works (52.227-17) as well as the SBIR program (52.227-20). The current government policy is to acquire only the data and rights essential to meet Government’s needs and to protect contractor’s proprietary data. In this way the policy strikes a balance between interests of contractors and the Government.

Part 2 of this briefing presented a discussion of software development contracts, and recommended practices in choosing the appropriate clauses for a contract. The following FAR clauses were reviewed in depth: 52.227-14 Rights in Data-General; 52.227-15 Representation of Limited Rights Data and Restricted Computer Software; 52.227-16 Additional Data Requirements; 52.227-17 Rights in Data-Special Works; 52.227-19 Commercial Computer Software-Restricted Rights; and 52.227-20 Rights in Data-SBIR Program.

The final section of this briefing reviewed applicable regulations in the acquisition commercial computer software (FAR Part 12). Of particular import are the terms and conditions of the accompanying license. The government will accept a vendor’s standard commercial license unless inconsistent with law or Government’s requirements. Consequently the license must be reviewed by legal counsel as such licenses often include terms inconsistent with the Anti-Deficiency Act, the Contract Disputes Act, the Prompt Payment Act and the Competition in Contracting Act. Open Source Software is considered commercial computer software licensed under a licensing scheme that provides broad rights to modify and redistribute the original source code and modified versions. This can directly affect whether and when the government may be obliged to provide source code to the public. Mandatory source code distribution may not be appropriate for all Government uses, for example software modified for use on, or linked to, classified or other secure computer systems, or where software is export-controlled. In summary, the government should require all contractors developing software for the government to identify fully any uses and planned modifications of OSS they intend during performance of contract and should require approval by the contracting officer before incorporation into software delivered to the government.


U.S. Government Software Acquisition Policies – DFARS and Data Rights
Vicki E. Allums
Office of the General Counsel
Defense Information Systems Agency (DISA)

This briefing begins with a concise summary of copyright basics as enacted by the U.S. Constitution, the U.S. Copyright Act, 28 U.S.C. 1498 (b) and Executive Order 13103. It then proceeds through an overview of DoD data rights policy in the Defense Supplement of the Federal Acquisition Regulation (DFARS) and the companion guidebook, Navigating Through Commercial Waters: Issues and Solutions When Negotiating Intellectual Property With Commercial Companies, issued by the Undersecretary of Defense for Acquisition Technology and Logistics (AT&L). Under DoD policy, contractors are generally permitted to retain ownership of the intellectual property rights governing the technologies/information that they develop or deliver, while the DoD receives a (nonexclusive) license to use the IP.

The following section discusses the differences in policy regarding commercial and noncommercial software. According to the DFARS, DoD’s right to commercial software is determined by standard commercial license “unless such licenses are inconsistent with Federal procurement law or do not satisfy user needs.” Consequently, it is advisable to review the terms and conditions of the license carefully. Data rights for noncommercial software can be any of the following: unlimited, government purpose, restricted, limited, specifically negotiated or SBIR-specific. The scope of the license is determined by the source of funding (e.g. government, mixed or private). Conditions of each category of data rights are defined. The importance of marking the software deliverables is also emphasized. The final section of this briefing presents a useful summary of best practices for software acquisition under the DFARS.


Government Open Source Software Distribution
Hope O’Keeffe
Associate General Counsel
Library of Congress

This briefing summarizes background and best practices for distribution of government authored open source software.

The modes of distribution for government Open Source software include a public repository (e.g. SourceForge), a Government public website (e.g. NASA); a Government nonpublic repository (e.g. Forge.mil) or Individual open source projects (e.g., Drupal). A public repository may be used when there is a standalone segment of software or an extension to other software. When selecting a public repository it is important to examine their Terms of Service. Before distributing open source code, it is important to consider the following questions: What’s the business purpose? Who developed it? What are its building blocks? What’s the cost to distribute? Who developed the code?

Works created by Agency staff should be designated as a U.S. Government work or as a work within the public domain in the source code comments. This allows identification of a particular segment of code as a USGW even if the code is subject to a more restrictive license.

Choice of an Open Source License depends on whether the software is subject to a pre-existing license, whether the use of a specific license is determined by the type of software or whether rights in data are claimed by a contractor, partner or grantee. Custom licenses are strongly disfavored and should be used only in extraordinary circumstances. An Agency ought to adopt a license approved by the Open Source Initiative (OSI) at opensource.org.  Generally, the Agency should apply the most permissive license possible consistent with contract, or any license for incorporated preexisting code. For example, the Agency should not use a GPL or LGPL license (which imposes restrictions on subsequent use) unless required to do so.

It is recommended that an Agency have a written policy or checklist for Open Source Distribution, including a review of the project’s business purpose, data rights issues and signature requirements for the approval process (i.e. the OGC and IT management). Agencies should manage distribution on an institutional level. There should be a single agency account for repositories; all open source projects should be managed under one Agency umbrella. Finally, the release of open code is the beginning of development activity, not the end.


NASA Open Source Software Release
Gary G. Borda
Agency Counsel for Intellectual Property
NASA Headquarters

NASA has a well developed policy and procedure for releasing NASA software available at http://nodis3.gsfc.nasa.gov/displayDir.cfm?t=NPR&c=2210&s=1C. As part of the NASA Software Release Policy, NASA has developed an Open Source option for the release of NASA-developed software. Open Source means that software is distributed with source code and a usage agreement that grants specific rights regarding use and reuse of the code. Within the Software Release Policy, “Open Source Software Development" means either: (1) the incorporation of external Open Source Software into software developed by or for NASA; or (2) the original development by or for NASA of software intended for Open Source release..

The NASA Software Release Policy was developed to protect the government interests and public investment in valuable intellectual property, to prevent violation of non-federal owner’s rights, and to comply with export control laws and IT security requirements. Each NASA Center has a Software Release Authority (SRA) that coordinates software reporting, information collection, and all required review and approval under the NASA policy. NASA software can be release under one of the following terms: government purpose only release; U.S. general release; U.S. academic release; public release and open source release.

In 2003 NASA researchers requested that NASA consider an open source release option. Subsequently, an Open Source Legal Team was formed which produced NASA Open Source Agreement (NOSA). The agreement grants rights to use, reproduce, distribute, display, and modify original NASA software without royalty, and  the right to create a ‘larger work’ by combining separate software not covered by NOSA. The current software release policy was developed to release software originally developed by NASA that is at the end of NASA development lifecycle. However, NASA has begun participating in established external open source development projects. This will require enhancements to the policy to support NASA participation in existing OSS development projects, and contribution of revisions to existing OS projects.


Using OSS Software for Government Purposes Forge.mil
Tom Morton
Chief Engineer – Forge.mil
Defense Information Systems Agency

The rationale for establishment of Forge.mil is found in the National Defense Authorization Act FY 2010 which mandates a new acquisition process for information technology systems.

 Forge.mil was launched to help developers work on open-source software projects for DoD by using shared tools and a development environment hosted by the Defense Information Systems Agency (DISA). The site allows Defense agencies, as well as Defense personnel and contracts, to minimize duplication of effort by providing access to software components that already have been created and by offering a common set of development tools. Forge.mil’s first component, SoftwareForge, includes tools for version control, bug tracking, wikis, discussion forums and document storage. The DoD effort is similar to SourceForge, the leading open-source software development and distribution site for civilian projects, but with additional security measures.

Software Distribution policy directs use of Open Source Initiative approved licenses whenever possible. Otherwise, components are directed to use DoD Community Source (DCS) Usage Agreement. The DCS Usage Agreement allows DoD to take maximum advantage of its software assets including software acquired with (i) Unlimited Rights or (ii) Government Purpose Rights (GPR) under a Government contract. Software and documentation that requires stricter distribution control or where the DoD has acquired only limited rights under the DFARS is not released as DoD Community Source. Under the present construct contributors are responsible for determining whether software can be reproduced and distributed on forge.mil.

Forge.mil – today provides collaborative Application Lifecycle Management infrastructure on the NIPRnet and SIPRnet. There are more than 350 projects (open & controlled) utilized by over 6,000 users.


caBIG® The Cancer Biomedical Informatics Grid® Initiative: Open Source Software Licensing Approach
Wendy E. Patterson, Esq.
Senior Advisor, Technology Transfer Center
National Cancer Institute, NIH/DHHS

The goal of caBIG® is to build a virtual web of interconnected data, individuals, and organizations that redefines how research is conducted, care is provided, and patients/participants interact with the biomedical enterprise.  caBIG® will connect the cancer research community through a shareable, interoperable infrastructure; deploy and extend standard rules and a common language to more easily share information; and build or adapt tools for collecting, analyzing, integrating and disseminating information associated with cancer research and care.
All caBIG® tools and information are released under a "non-viral" open-source license that allows commercial reuse of caBIG® technology, so that vendors may become caBIG®-compatible.


Daniel Risacher
Associate Director for Information Policy and Integration
Office of the Deputy CIO
Department of Defense

This presentation took the form of an open dialog regarding miscellaneous topics on open source software, and since it was the final presentation of the day, served as an excellent opportunity to consider the various issues addressed in the preceding briefings.

There was a lengthy discussion on the ramifications of open source licenses within sensitive and/or classified programs. Various scenarios were considered. Ultimately, program managers must rely on regulation, classification guides, legal and public affairs reviews before embarking on an OSS project within a classified environment.

Various clauses within the FAR were discussed, with the notion that some revisions are necessary to render the regulations germane not only to OSS issues but to analogous unconventional deliverables.

There was an interesting discussion on data rights clauses on IDIQ and multiple award contracts. While these contracting vehicles are meant to streamline acquisition, there is a tendency to overlook the data rights within the base contract. The consequences can be legally perilous and antithetical to the original intent of the task order.

Another topic of discussion concerned the expiration of government purpose rights. The default is five years after the execution of the contract, although other negotiations are possible. Under a SBIR award, it is important to consider consecutive phases of the work, as the protection of rights continues through five years after the completion of phase II.

Comments from the audience included testimony that the local IT infrastructure is frequently averse to using Open Source Software.

A participant asked whether state and local governments were eligible for items protected by government purpose rights. The consensus was that federal rights do not transfer to local governments.

Q and A

The following is a record of questions and comments from the audience.

Q: Why is the GNU General Public License (GPL) license the most commonly used?
A: The GPL was one of the earliest Open Source Licenses and it requires all derivative works of software licensed under the GPL and any software linked to software licensed under the GPL to be redistributed under the GPL. Thus, once software originally licensed under the GPL is used in an open source project, that the redistribution of software developed under that project is normally locked into the GPL.

Q: Why are the terms of GPL unfavorable to the government?
A: Under GPL, if the government re-distributes modifications to the GPL licensed software as well as any code linked to the GPL licensed software, the source code must be made publicly available. In some circumstances distribution of source code may not be appropriate. Particularly where the software will be modified for use on, or linked to, classified or other secure computer systems, or where such software is export-controlled. Further, source code distribution of linked software may adversely implicate third-party proprietary code or information, depending on computer system and software architecture..

Q: Difference between “public release” and “open source”
A: Open source release requires access to the source code. Public release does not require access to the source code but may be accomplished through release of executable code only.

Q: FAR says the government may not distribute software to the public.
FAR 27.404-3 (a) (4) Pursuant to paragraph (c)(1) of the clause at 52.227-14, the contractor grants the Government a paid-up nonexclusive, irrevocable, worldwide license to reproduce, prepare derivative works, distribute to the public, perform publicly and display publicly by or on behalf of the Government, for all data (other than computer software ) first produced in the performance of a contract. For computer software, the scope of the Government's license includes all of the above rights except the right to distribute to the public.
A: This is a misunderstanding of the language of the FAR Rights in Data clause (52.227-14). Under 52.227-14(c)(1)(i), the contractor must obtain the permission of the contracting officer prior to asserting copyright in any copyrighted work containing data, including software, first produced in the performance of a contract. The copyright license of paragraph (c)(1)(iii) applied to data only if the contracting officer grants such permission. Thus, the prohibition on release to the public applies only if the contracting officer has granted the contractor’s request to assert copyright. Otherwise the government has unlimited rights. If the contracting officer grants such permission, the contractor must include the applicable copyright notices of 17 U.S.C. 401 or 402, and an acknowledgment of Government sponsorship (including contract number). Failure to do so could result in software being treated as unlimited rights data (see FAR 27.404(a)(5)).

Q: Copyrights on scientific and technical literature published in third party publications.
A: The Government has government purpose rights in scientific and technical articles based on or containing data first produced in the performance of this contract and published in academic, technical or professional journals, symposia proceedings, or similar works (see 52.227-14(c)(1)). This license is a pre-existing right to distribute the article as submitted by the contractor even if the article is published later.

Q: Comment: NASA open source agreement prescribes an unusual condition that 2 licenses cannot be merged in one application.
NASA Open Source Agreement Version 1.3 paragraph 2. D. The rights granted in Paragraphs A and B allow the Recipient to sublicense those same rights. Such sublicense must be under the same terms and conditions of this Agreement.
A: Will be revised in the new version of the policy.

Q: Can other agencies use NOSA?
A: Yes

Q: Comment: Forge.mil contributions are submitted without viral aspect.
A: Forge.mil does not require contributions. These are submitted by a different mechanism where they undergo a QC review.

Previous Page