Data Rights—Marking Sleuths

David A. Frank, Howard Harris, and Wendy Santiago

The Case Begins

We would like to explain a very curious and difficult detective case that we accepted with the Department of Defense (DoD). On one unusually hot and sticky day in San Diego, we received a phone call from a DoD customer asking us to help solve a case regarding data rights markings on noncommercial technical data and computer software source code (henceforth referred to as data). Initially, this case seemed too boring and convoluted, but since business was slow and the offeror was good, we decided to take the case.

First things first, we have resolved a few cases with improper data rights markings in the past. We have even acquired a cool computer software tool to search and identify improper data rights markings. Before we get into the specifics of some of the complicated cases we undertook, we would like to provide some clues regarding data rights markings that result in Legends being placed on data that is delivered to the DoD.

Under copyright law, the author, identified in a simple copyright marking, holds the copyright to the material. If that material was created under a government contract, the copyright would be subject to a government license under that contract.

For DoD contracts, generally the originator (contractor) of the data has sole ownership of that data and protects that intellectual property, since it is the lifeblood of the contractor’s company and a major source of revenue and profit. Contractors protect their intellectual property by placing the proper data rights markings on all data delivered under a procurement contract. These markings thus restrict the ability for the DoD to use or share the data. The Defense Federal Acquisition Regulation Supplement (DFARS) is the authoritative document that provides the exact format and language on how to mark specific types of data.

Authorized markings are provided in the following sections of the Code of Federal Regulations:

48 CFR § 252.227-7013–Rights in technical data–Noncommercial items.

48 CFR § 252.227-7014–Rights in noncommercial computer software and noncommercial computer software documentation.

48 CFR § 252.227-7018–Rights in noncommercial technical data and computer software–Small Business Innovation Research Program.

DFARS defines two types of improper data rights markings—nonconforming and unjustified:

When a contractor places a restrictive data rights marking on noncommercial technical data or noncommercial computer software that it delivers or otherwise furnishes to the DoD, and that is based on a data rights restriction authorized by the contract, but not in the format authorized by the contract, it is deemed to be a “nonconforming” marking. Refer to DFARS 252.227–7013(h) (2) and DFARS 252.227–7014(h) and Table 1.

An “unjustified” data rights marking is a marking that does not accurately depict restrictions applicable to the government’s use, modification, reproduction, release, performance, display, or disclosure of the marked technical data or computer software. Refer to DFARS 227.7103-12(b)(1) and DFARS 227.7203-12(b)(1) and Table 1.

Table 1. Improper Data Rights Markings

The Investigation

A fundamental part of solving any mystery is careful investigation, including gathering and examining clues. In data rights markings cases, clues can include contracts, data rights assertion lists, the marked documents, emails, records of conversations, and licenses.

A key part of conducting any investigation is having the right tools. Part of the reason that we have been able to solve so many data rights markings cases in a relatively short time is our unique software search tool, IpScan. As shown in Figure 1, the tool’s operator prompts it to run a scan through the desired set of files— e.g., a group of source code files. In a matter of minutes the tool can read tens of thousands of software source code files. It can also handle documents in most well-known formats like Word, PDF, and text files. While reading software source code files or documents, it checks for all potential data rights markings and then outlines in a red box any of those that are deemed as cautionary (e.g., “Restricted Rights” or “Proprietary”). Then it organizes the markings for each file or document into an easy-to-read report where the tool operator can preview each potential data rights marking and click on the file in question. It also groups the potential data rights markings so that the operator can see which markings appear together—(e.g., if a particular company copyright always appears with a Restricted Rights marking, the report will group those files together).

Without this tool we could still solve data rights cases, but significantly more time would be required to sift through the various markings using just a traditional file searching tool at the risk of reduced accuracy. In the case at hand, we used IpScan to check the computer software source code files and immediately found the nonconforming (and potentially unjustified) Restricted Rights marking in Table 2 on 229 of the files.

This was problematic because our client stored its data in the Department of Defense Information Repository (DoD IR), and the client needed to release those files to authorized users. These Restricted Rights markings would prevent such release. Per DFARS 252.227-7014(b)(3), the terms of Restricted Rights in noncommercial computer software mean that the government has no right to redistribute or share the software source code with other contractors (which does not include covered contractors and subcontractors).

In a perfect world, a copy of the contract and assertion list would correctly clarify exactly from the beginning the government’s data rights in the software source code files. But in an imperfect world, the contracts and assertion lists are not always available to help resolve these issues. In some cases, the contracts are just too old and we cannot locate the Contracting Officers. In other cases, the contracts exist but are extremely difficult to obtain, particularly for clients like the DoD IR that are not part of a program office. In these cases where we must proceed without a copy of the contract or assertion list, the data rights must be deduced from the markings.

Another key part of investigations is that detectives must never lose sight of the big picture. Clues must always be looked at as a piece to a bigger unknown puzzle. In this case, the IpScan also found two contradictory data rights markings on a file named “License.txt” as shown in Table 3: the same nonconforming Restricted Rights marking from Table 2 along with a nonconforming Government Purpose Rights (GPR) marking.

This new clue told us that we needed to further investigate all of those Restricted Rights markings to see if they were also unjustified. Because of that single GPR marking, we went back to the program office, showed them our findings, and asked them to help us get to the bottom of these strange markings. They came back a few weeks later with a memorandum from the prime contractor affirming that the government had GPR to all of the files that the subcontractor had marked as Restricted Rights.

Table 2. Nonconforming Restricted Rights Marking

Table 3. Contradictory Data Rights Markings

Our client will be extremely pleased because this means that they can publish 100 percent of the source code in the DoD IR. Otherwise, they would only have been able to publish only 75 percent of it. And to think that we could have missed this essential clue if it hadn’t been for our trusty scanning tooltool that was able to scan all 829 source code files. Just imagine a case where hundreds of thousands of files need to be manually reviewed!

To close this case, we are still working to get a memorandum from the subcontractor affirming the GPR marking and stating that they incorrectly marked the files as “Restricted Rights.” In addition, we are also still trying to get a copy of the contract to confirm our findings with the assertion list to clear up this mystery once and for all. Stay tuned.

The Case of the MELPe Files

Our customer then directed us to perform the same investigation on the Mixed Excitation Linear Prediction enhanced (MELPe) software source code. Again, as usual, we started with IpScan. This time we scanned a set of 1,711 computer software source code files, measuring 45,135 source lines of code (SLOC) that were part of a reference development platform critical to developing and testing tactical radios and waveforms. The scan revealed four restrictive markings, occurring repeatedly in 119 source code files. Those markings included both DFARS and commercial markings, and one of the good features of the IpScan tool is that it doesn’t just find DFARS data rights markings—it also finds commercial copyright notices (Table 4).

The data rights markings addressed MELPe voice-encoding technology that allows human speech to traverse narrow radio frequency (RF) communications channels used by the military. It was developed from an earlier technology, MELP. Military RF links must deal with signal dropouts induced by noise, weather, and unpredictable motion of radios in helicopters, trucks, and infantry packs, without affecting voice quality. Specified for key tactical waveforms, MELPe aims at near cellphone quality in a military environment.

Reviewing Table 4, the Company X Copyright (Marking 1) and Company Y Copyright (Marking 2) provide a first impression of typical commercial copyright legends, not a technology that had been a product of a government contract. Of course, the files could have been delivered outside of the contract deliverables delivery or could be third-party copyrighted materials inserted into a deliverable. Marking 3 appears to be a DFARS marking, but there was no contract given, and no expiration date. Copyright markings 1 and 2 are acceptable for commercial computer software source code, but not for computer software produced under a government contract, which we had thought was the origin of MELPe.

Values is to protect the data rights of the owner of the data, even if the markings are improper. Absent valid DFARS markings, the case for government rights to the data becomes questionable and the case for company intellectual property becomes plausible. Other developers could not be provided these files and could not be put under contract, possibly locking the government into a sole-source situation.

Normally, when unjustified or nonconforming markings are found, the standard DFARS procedure is for the contracting officer to require the contractor to correct the markings. In this case, we had expected to see a government contract identified, but it wasn’t there. There was no contracting officer to contact in order to challenge the marking.

This set of data rights markings provided no assurance that the government obtained GPR or equivalent data rights to the newer MELPe computer software, and this did not align with expectations for a technology developed for widespread government use.

To help determine whether the government had data rights in the newer MELPe software, we contacted government and industry experts in the fields of tactical waveforms and speech coding. In most data rights cases, the contracting officer will determine the course of action, and in all cases we recommend that legal counsel be fully engaged. The actions shown in Table 5 were taken over seven arduous months of sleuthing, and they revealed a series of clues concerning the timelines and circumstances behind development of the MELPe technology.

Table 4. Markings in MELPe Source Code

Table 5. Intellectual Property/Data Rights Detective Checklist

After figuring out the circumstances around development of the MELPe technology, the markings on the 119 files could be addressed (Table 6).

Since we discovered that the patents declare government rights in the MELPe invention, DoD Legal Counsel phoned Company X and presented the problem—that although there is ample evidence that MELPe was developed under contract, the markings neither reference the contract nor the government’s rights to the files. The inference is that proper data rights markings were never put into files developed under a government contract. The GPR marking we expected to be with Marking 1 (Company X Copyright) was simply missing.

Table 6. Addressing Markings

Seven months from the arrival and scanning of the files, Company X responded to us with an email acknowledging that the government may use, modify, and release the source code for government purposes. This was a major break in the case. Because the contractor did not put the proper data rights markings into the source code, it took us seven months to obtain evidence sufficient to allow government use of the files. Based on our findings, the government signed an Intellectual Property Rights memo, now included with the MELPe source code, to let authorized companies know that they may use it for government purposes. Due to our successful efforts, our customer can now allow authorized contractors to use, modify, and upgrade the source code for MELPe, removing barriers to competition and reducing sustainment costs for this important military technology, but the case illustrates that markings for contract deliverables should comply with DFARS clauses prior to their acceptance.

Case Closed

Once again, our trusty IpScan helped us to close another case. Even though this last case took us nearly seven months to wrap up, it could have taken a great deal longer without our tool to search through the 45,135 SLOC to reveal the data rights markings discussed above. Without this tool, a lot more effort would be spent simply obtaining the markings, and less time would be available to devote to the investigation. As illustrated, to be an effective data rights marking sleuth, you need both the right tools and the right knowledge skill set, including a comprehensive understanding of the DFARS and the ability to conduct a proper investigation. Both of the cases demonstrated how the combination of an effective data rights searching tool and skillset can be used to resolve data rights marking mysteries.

While we wrote this article as “independent detectives,” we actually work for the Joint Tactical Network Center (JTNC) in San Diego, California. We do this type of detective work every day in our work on data rights markings. We have an experienced team and the tools that can assist your program with data rights markings and ensure the proper resolution.

For more information on obtaining a copy of the (IpScan) tool, contact the JTNC at [email protected]. This JTNC-developed tool is freely available from the DoD IR and can be used by DoD personnel and contractors.

Read the full issue of
Defense Acquisition magazine

FRANK is a computer engineer in San Diego at the JTNC with 30 years’ experience in software development and operations, information assurance and radio frequency communications. He has a Bachelor of Science degree in Electrical Engineering from the University of Kansas.

HARRIS is a professor of Program Management at DAU in San Diego, California. He has more than 20 years of experience in defense acquisition. He holds a Master of Science degree in Systems Engineering from Johns Hopkins University as well as a Master’s in Business from the Florida Institute of Technology.

SANTIAGO is a Data Rights Analyst in San Diego for the JTNC. She is experienced in the practice of law and data rights. She has a Bachelor of Arts in English from the University of San Diego and a Juris Doctorate from the Thomas Jefferson School of Law in San Diego.

The authors can be contacted at [email protected], [email protected], and [email protected].

The views expressed in this article are those of the authors alone and not the Department of Defense. Reproduction or reposting of articles from Defense Acquisition magazine should credit the authors and the magazine.