decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

Click here to send an email to the editor of this weblog.


To read comments to this article, go here
Publicly Releasing Open Source Software Developed for the U.S. Government by Dr. David A. Wheeler
Wednesday, September 07 2011 @ 08:00 AM EDT

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

by Dr. David A. Wheeler

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 section is intended for non-lawyers, to help them understand the basic rules they must follow.

This article was previously published in the Journal of Software Technology (aka Software Tech News), Vol.14, No.1, February 2011. It is part of “Open Technology Development (OTD): Lessons Learned and Best Practices for Military Software”, and thus is released under the Creative Commons Attribution ShareAlike 3.0 (CC-BY-SA) License. A one-page summary of this paper is available from MIL-OSS, and the MIL-OSS 2011 conference had a presentation on releasing OSS.



Before going further, a few definitions and warnings are necessary. In this section, 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 section 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 questions:

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

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

  3. Do you have the necessary other intellectual rights3 (e.g., patents)?

  4. Do you have permission to release to the public (e.g., classification and export control)?

  5. Do you have the materials (e.g., source code) and are all materials properly marked?

Each of these questions is explained below, followed by a discussion of who can make certain decisions.

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):

Circum-stance

Other Conditions

(if any)

Case

Can government release as OSS?

Can contractor release as OSS?

U.S. federal government employee (including military personnel) develops software as part of his/her official duties. This makes it a “Work of the U.S. government.”

A

Effectively yes. The software is not subject to copyright protection in the U.S. per 17 USC §105, so if released, anyone in the U.S. can read, use, modify, and redistribute it. The government may apply for copyright outside U.S., but still release the software as OSS.

N/A

FAR 52.227-14 contract clause defaults (December 2007), software first produced in performance of contract.

Government has not granted the contractor the right to assert copyright (default).

B

Yes. The government normally has unlimited rights (essentially the same rights as a copyright holder) per (b)(1). In the FAR source code is software, and software is data, so source code is data.

No. The contractor may request permission to assert copyright.

Government has granted the contractor the right to assert copyright (e.g., via specific written permission or via clause alternate IV).

C

No. The government does not have sufficient rights, per (c)(1)(iii); it cannot distribute copies to the public. The government should be wary of granting a request to assert copyright, as it permanently loses many rights to data it paid to develop.

Yes. The contractor may assert copyright.

DFARS 252.227-7014 contract clause defaults (June 1995).

Developed exclusively with government funds.

D

Yes. The government has unlimited rights (essentially the same rights as a copyright holder). Per (b)(2)(ii), the 5-year period from mixed funding can be negotiated to a different length of time, and it starts “upon execution of the contract, subcontract, letter contract (or similar contractual instrument), contract modification, or option exercise that required development of the computer software.”

Yes. Copyright is held by the contractor/​supplier.

Developed by mixed funding (government partly paid for its development) and (sub)contract execution/mod more than 5 years ago.

E

Developed by mixed funding (government partly paid for its development) and (sub)contract execution/mod less than 5 years ago.

F

No. The government does not have sufficient rights. Per (b)(2)(ii), the 5-year period from mixed funding can be negotiated to a different length of time; during this time the government only has “government purpose rights.” If software is developed exclusively at private expense, by default the government only has “restricted rights”; the government should be wary of dependencies on such components. The government can negotiate for greater rights per (b)(3) and (b)(4).

Developed exclusively at private expense.

G

DFARS 252.227-7018 contract clause defaults (June 1995): Small Business Innovation Research (SBIR) Program.

Not developed exclusively at private expense.

Less than five years after completion of the project

H

No. The government does not have sufficient rights, per (b)(4)(i).

Yes. The contractor has copyright.

More than five years after completion of the project and alternate I is not used.

I

Yes. The government has unlimited rights (essentially the same rights as a copyright holder) per (b)(1)(vi). Unfortunately, it is sometimes difficult to determine when the time period has expired.

More than five years after completion of the project and alternate I is used.

J

Sometimes. Under alternate I the Government cannot exercise its rights to release if, within certain time limits, the software is published and the contracting officer is notified. This limitation continues as long as it is reasonably available to the public for purchase (after which the government can release it as OSS). See alternate I for details.

Developed exclusively at private expense.

K

No. The government does not have sufficient rights, per (b)(2).

FAR 52.227-17 “Special works” contract clause defaults (December 2007)

Government has not granted the contractor the right to assert copyright (default), and the software was first produced in performance of the contract.

L

Yes, either through unlimited rights or by holding copyright. By default, the government has unlimited rights in all data delivered under the contract, and in all data first produced in the performance of the contract, per (b)(1)(i). Per (c)(ii), if the contractor has not been granted permission to assert copyright rights, the contracting officer can direct the contractor to assign copyright to the government.

No. Contractor cannot assert copyright rights per (c)(1)(i). The contractor may request permission to assert copyright; if granted see below.

Government has granted the contractor the right to assert copyright, and the software was first produced in performance of the contract.

M

No. The government only has the more limited rights listed at the end of (c)(1)(i), and these rights are limited to uses “by or on behalf of the Government.”

Yes. Contractor has copyright.

Software not first produced in the performance of this contract.

N

It depends. Note that a contractor cannot include copyrighted software into a deliverable without written permission of the contracting officer, see (c)(2) for more.

It depends.

DFARS 252.227-7020 “Special works” contract clause defaults (June 1995).

Work first produced, created, or generated and required to be delivered under the contract.

O

Yes. The government receives the copyright, per (c)(2).

No. The government has copyright.

Other copyrighted works incorporated into a required deliverable (unless written approval granted for an exception).

P

Normally yes. Per (c)(3) and (d), the contractor must normally grant to the government a long list of data rights when incorporating other copyrighted works, and these rights permit OSS release. The contractor may only incorporate software without those rights into a deliverable if the government contracting officer gives written approval, per (d).

Normally yes. The contractor must already have the rights for OSS release to incorporate it, unless given written approval.



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 OSS4. Thus, it can release the software under any OSS license it chooses, including the GNU General Public License (GPL) and Lesser GPL (LGPL)5. 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 infringement6. 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 meaningless7 and in some cases putting military capability at risk.8 9

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”10. 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”11

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.

3. Do you have the necessary other intellectual rights (e.g., patents)?

You need to make sure that you have any other necessary intellectual rights. Most importantly, determine if there are any relevant patents, and if so, what the rights to them are.

Other potential issues are trademark, trade dress, government seals, and trade secrets. Trademark issues, if relevant, can often be easily addressed by simply removing the trademark marking. If the contractor has granted copyright or unlimited rights to the government, then the government already has the rights to release that information to the public and is thus not barred from public release by trade secret law.

4. Do you have permission to release to the public?

In particular, for public release the material must not be restricted by:

  • Classification. Classified data cannot be legally released to the public. Where this is not obvious, a classification review may be required.

  • Distribution statements. A government contracting officer may require certain clauses be included in data (including software) to limit its release; contractors must obey these clauses or cause them to be rescinded.

  • Export controls. The Export Administration Regulations (EAR) are issued by the Department of Commerce), and the International Traffic in Arms Regulations (ITAR) are issued by the Department of State. These prohibit the unlicensed export of specific technologies for reasons of national security or protection of trade. Note that cryptography can invoke export control issues.

Export controls can be particularly confusing, and the penalties for failing to comply with them can be stiff (including large fees and jail time). Thus, here are some basics about export control:

  • More information about export control regulations under the EAR are provided by the U.S. Department of Commerce Bureau of Industry and Security (BIS) (http://www.bis.doc.gov/ licensing/). In particular, see their pages on “Export Control Basics” and “Licensing Guidance.” Any item (including software) that is sent from the US to a foreign destination, including to any foreign national, is an export – even if the item originally came from outside the US. Certain U.S. exports/re- exports require a license from BIS. A key is knowing whether the item you are intending to export has a specific Export Control Classification Number (ECCN) as listed in the Commerce Control List (CCL), available on the EAR website. In addition, a license is required for virtually all exports and many re-exports to embargoed destinations and countries designated as supporting terrorist activities.

  • Similarly, more information about the export control regulations under the ITAR, which implements the Arms Export Control Act (AECA), are provided by the U.S. Department of State Directorate of Defense Trade Controls (DDTC) (http://www.pmddtc.state.gov). In particular, see their page on “Getting Started.” The US regulates exports and re-exports of defense items and technologies, so if what you wish to export is covered by the U.S. Munitions List (USML), a license from DDTC is required. You may file a commodity jurisdiction request (CJ) to determine whether an item or service is covered by the U.S. Munitions List (USML) and therefore subject to export controls related to AECA and ITAR.

The Department of Defense (DoD) does not have authority to grant export control licenses. A contractor may be liable if he or she relies on a DoD official’s permission for export control, because in most cases the DoD does not have this authority. Note that even when an export-controlled release of software is granted, it is often contingent on not releasing the source code, making such “releases” useless for open technology development among all parties.

However, if the DoD determines that something it has purview over is releasable to the public, it is no longer subject to export control. This is because 15 C.F.R. 734.3(b)(3) says that “The following items are not subject to the EAR . . . Publicly available technology and software....” Similarly, 22 CFR 125.4 (13) notes that technical data is exempt from ITAR export controls if it is “approved for public release (i.e., unlimited distribution) by the cognizant U.S. government department or agency or Office of Freedom of Information and Security Review.” Thus, if software is intended to be released to the public, having the cognizant U.S. government department or agency (such as the DoD) approve its public release is often the best way to fully comply with export control regulations.

5. Do you have the materials (e.g., source code) and are all materials properly marked?

The government and upper-tier contractors should ensure that they receive all material, including source code, that they are entitled to. It is all too common to have the right to the source code or related materials, yet not have it and thus be unable to exercise your rights. Source code is necessary for potential OSS release, and it is also necessary to enable competition for future software maintenance bids. Both the government and contractors should make sure that they do not lose the source code, but instead treat it as valuable data (e.g., by creating multiple backup copies in different locations).

Under DFARS 252.227-7014, the definition of “computer software” includes not only “computer programs” but also “source code, source code listings... and related material that would enable the software to be reproduced, recreated, or recompiled.” Thus, a delivery of developed software is supposed to include source code by default. Also, (b)(1)(i) and (b)(2)(i) state that the government has rights to software (whether it was a deliverable or not) if its funds were used.

Source code should only be accepted if is ready for use. Material should only be considered acceptable as source code if it is the preferred form of the work for making modifications to it. Source code should not be accepted if it is just a printout or electronic images of a printout. It should not be accepted unless it is easy to automatically rebuild, e.g., a “make” or similar simple command should be sufficient to recreate an executable. Build documentation should be included with any deliverable, including information on what is required to rebuild it.

It would be best if the source code also included the historical record (e.g., a complete record of each change, who made it, and when), in an electronic form adequate for transfer to another configuration management system. Ideally, the government should have sufficient access to the software engineering environment (SEE) of the contractor, so that the government could monitor changes as they are made.

Ensure that the source code and other materials are marked appropriately. Companies may include restrictive markings on materials, and if those markings are inappropriate, then the markings need to be fixed. Government contract clauses include processes for fixing incorrect markings; follow them. Government and upper-tier contractors need to promptly challenge improperly marked materials due to time limits. For example, contracts using DFARS 227.7203-13 include, in item (d)(3)(i), a challenge time limit of three years after either the final payment or the delivery of software, whichever is later. Also, improper markings tend to be copied into other materials; fixing markings early greatly reduces the effort to fix them later.

Who has authority?

Unfortunately, it is not always obvious who in government or the various contractors can make these decisions. It would be best if the government and contractors could clarify roles, policies, and procedures. In the meantime, the following may be helpful:

  • As noted above, when there are multiple contractors or suppliers, 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. By U.S. law (17 USC §201), “Copyright... vests initially in the author or authors of the work... In the case of a work made for hire, the employer or other person for whom the work was prepared is considered the author [and holds the copyright] unless the parties have expressly agreed otherwise in a written instrument signed by them.”

  • The 2009 DoD OSS memo does clarify who in the DoD can determine when it should release software as OSS, and under what conditions. It says that “Software items, including code fixes and enhancements, developed for the Government should be released to the public (such as under an open source license) when all of the following conditions are met:

    (1) The project manager, program manager, or other comparable official determines that it is in the Government’s interest to do so, such as through the expectation of future enhancements by others.

    (2) The Government has the rights to reproduce and release the item, and to authorize others to do so. For example, the Government has public release rights when the software is developed by Government personnel, when the Government receives "unlimited rights" in software developed by a contractor at Government expense, or when pre-existing OSS is modified by or for the Government.

    (3) The public release of the item is not restricted by other law or regulation, such as the Export Administration Regulations or the International Traffic in Arms Regulation, and the item qualifies for Distribution Statement A, per DoD Directive 5230.24 (reference (i)).”

  • Some organizations do not have a review process for software source code but do have a process for reviewing documents. In these cases, it may be appropriate to submit the source code to the document review process. This is especially relevant for classification review.

Final notes

If the government and relevant contractors intend to release software as OSS, it’s best if that is explicitly stated ahead of time. For example, OSS could be identified as the planned software maintenance philosophy per DFARS 227.7203-2(b)(1). However, since many contracts do not discuss releasing software as OSS, it’s important to understand the default rules for commonly-encountered cases.

If software is released to the public as OSS and it becomes “customarily used by the general public or by nongovernmental entities for purposes other than governmental purposes,” then that software becomes commercial software. This is by both law (41 USC §403) and regulation (e.g., DFARS 252.227-7014(a)(1)). It does not matter if the software was originally developed with government funds, or not. Thus, releasing software as OSS can be a commercialization approach.

The U.S. government and its contractors have released many programs as OSS. I hope that this material helps you understand how you can release software as OSS in a manner consistent with laws, regulations, and contracts.

The publication of this paper does not indicate endorsement by the Department of Defense or IDA, nor should the contents be construed as reflecting the official positions of those organizations.



Footnotes

1 This is, in summarized form, the Free Software Definition (http://www.gnu.org/philosophy/free-sw.html) from the Free Software Foundation. A similar definition is in the DoD’s “Clarifying Guidance Regarding Open Source Software (OSS)” (http://cio-nii.defense.gov/sites/oss/2009OSS.pdf). A more detailed definition of OSS is the Open Source Definition (http://www.opensource.org/osd.html) from the Open Source Initiative.

2 To release under an OSS license you must have the copyright-related rights (listed in 17 USC §106) to reproduce the work, to prepare derivative works, to distribute copies, and to permit others to perform those actions.

3 Some lawyers use the term “intellectual property rights,” but many believe this term is misleading. Intellectual works (like software) are fundamentally different from physical property, because someone can receive an intellectual work (or rights to it) without its first possessor losing the work or their rights. The authors recommend using the term “intellectual rights” instead.

4 The Council on Governmental Relations (CAGR)’s “Technical Data and Computer Software: A Guide to Rights and Responsibilities Under Federal Contracts, Grants and Cooperative Agreements” states that “This unlimited license enables the government to act on its own behalf and to authorize others to do the same things that it can do, thus giving the government essentially the same rights as the copyright owner.”

5 CENDI’s “Frequently Asked Questions about Copyright and Computer Software” at http://cendi.gov/publications/09-1FAQ_OpenSourceSoftware_FINAL_110109.pdf question 4.3 says: “an agency may distribute software created by a vendor to all users under an open source licensing scheme if it acquired sufficient rights from the vendor to do so in the software. For example, an “unlimited rights license” acquired under a DFARS procurement-type contract...” Similarly, the “DoD Open Source Software (OSS) FAQ” says that once the government has unlimited rights, it can “use those rights to release that software under a variety of conditions (including an open source software license), because it has the use and modify the software at will, and has the right to authorize others to do so.”

6 The government can probably take other measures against someone who does not comply with the license, though. For example, the government may be able to sue for breach of license. Also, an infringer may lose any ability to enforce rights over the resulting work in U.S. court due to the doctrine of unclean hands.

7 Ashton B. Carter, “Memorandum to Acquisition Professionals Subject: Better Buying Power: Mandate for Restoring Affordability and Productivity in Defense Spending” https://dap.dau.mil/policy/Documents/Policy/Carter%20Memo%20on%20Defense%20Spending%2028%20Jun%202010.pdf - His first point on providing incentives is to “Avoid directed buys and other substitutes for real competition. Use technical data packages and open systems architectures to support a continuous competitive environment.”

8 GAO GAO-06-839 “WEAPONS ACQUISITION: DOD Should Strengthen Policies for Assessing Technical Data Needs to Support Weapon Systems” (July 2006) http://www.gao.gov/new.items/d06839.pdf reported that “The lack of technical data rights has limited the services’ flexibility to make changes to sustainment plans that are aimed at achieving cost savings and meeting legislative requirements regarding depot maintenance capabilities... Unless DOD assesses and secures its rights for the use of technical data early in the weapon system acquisition process when it has the greatest leverage to negotiate, DOD may face later challenges in sustaining weapon systems over their life cycle.”

9 See, for example, “Fire support’s dependence on contractors,” Sgt Timothy Caucutt, http://www.mca-marines.org/gazette/article/paying-pirates

10 This U.S. law does not cover software, but the DoD also applies this to software per DFARS 227.7203-1(c) and (d).

11 George O. Winborne, Jr., “Who’s Killing the Goose?” American Bar Association Section of Public Contract Law Program Intellectual Property in Government Contracts—What You Didn‘t Learn in Kindergarten, November 11-12, 2010, Seaport Hotel, Boston, Massachusetts. https://acc.dau.mil/adl/en-US/401584/file/54029/Winborne_ABAPCL_paper_Who%27s_Killing_the_Goose_For%20_Release.pdf


  View Printable Version


Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )