Recent Developments in Intellectual Property in Government Contracts: Five Things Every Prime and...
-
Upload
marylou-newton -
Category
Documents
-
view
215 -
download
0
Transcript of Recent Developments in Intellectual Property in Government Contracts: Five Things Every Prime and...
Recent Developments in Intellectual Property in
Government Contracts: Five Things Every Prime and Sub
Needs to Know
Fernand Lavallee, Partner
DLA Piper LLP (US)
O: (202) 799-4401 November 13, 2013
Email: [email protected]
November 13, 2013 NCMA 2
It’s All About the Rights
The Government regulations governing IP are complex and counter-intuitive
Funding test for technical data and software
Event test (conception or first actual reduction to practice) without regard to funding for patents
Non-compliance with the Government regulations can have catastrophic consequences:
Failure to follow reporting rules can result in forfeiture of title in a patent and loss of all rights. Campbell Plastics, ASBCA No. 53319, 2003 WL 1518313 (March 18, 2003)
Failure to follow marking rules (use of restrictive legends) can result in third parties obtaining broad use rights for free (i.e., a royalty-free, unlimited license). General Atronics, ASBCA No. 49196, 02-01 BCA ¶ 31,798
November 13, 2013 NCMA 3
Can You Prove It? Burden Shift to Contractor
1. Commercial Items: Change in Presumption
If technical data is to be delivered to the Government for a commercial item that has been developed in any part at Government expense, the Government’s rights in that technical data will be governed by both DFARS 252.227-7013 (Rights in technical data—Noncommercial items) and DFARS 252.227-7015 (Technical data—Commercial items). In those circumstances, DFARS 252.227-7015 will apply to the portions
of the commercial item technical data developed exclusively at private expense.
DFARS 252.227-7013 will apply to the portions of the technical data developed at Government expense.
In a validation challenge, the presumption of developed at private expense remains. The Government must have evidence of development at government expense in order to challenge. A contractor’s failure to respond to a formal validation request alone is not sufficient basis for a final decision against the contractor.
Commercially available off-the-shelf (COTS) items (defined at 41 U.S.C. 431(c)(104)) are exempt from these requirements and will retain the presumption of development exclusively at private expense.
November 13, 2013 NCMA 4
Burden Shift to Contractor (Cont’d)
1. Commercial Items: DoD Change in Presumption The Commercial Rule: If technical data is to be delivered to the Government for a
commercial item that has been developed in any part at Government expense, the Government’s rights in that technical data will be governed by both DFARS 252.227-7013 (Rights in technical data—Noncommercial items) and DFARS 252.227-7015 (Technical data—Commercial items). In those circumstances, DFARS 252.227-7015 will apply to the portions of the commercial
item technical data developed exclusively at private expense. DFARS 252.227-7013 will apply to the portions of the technical data developed at
Government expense.
In a validation challenge, the presumption of developed at private expense remains. The Government must have evidence of development at government expense in order to challenge. A contractor’s failure to respond to a formal validation request alone is not sufficient basis for a final decision against the contractor.
Commercially available off-the-shelf (COTS) items (defined at 41 U.S.C. 431(c)(104)) are exempt from these requirements and will retain the presumption of development exclusively at private expense. When either DFARS 252.227-7013 or 252.227-7015 is applicable, then DFARS 252.227-
7037, Validation of Restrictive Markings on Technical Data, is also applicable and requires these clauses be flowed down to subcontractors.
The presumption of developed at private expense remains unchanged.
November 13, 2013 NCMA 5
But Wait, There’s More: The Burden Shift to Contractor
1. Commercial Items: Change in Presumption
Major Systems, as defined by statute and in the FAR, refers to a combination of elements that function together to produce the capabilities required to fulfill a mission need.
The elements may include hardware, equipment, software, or any combination thereof, but exclude construction or other improvements to real property.
For the DoD, it refers to systems where the total expenditures for research, development, test and evaluation are estimated to be more than $189.5 million or the eventual total expenditure for the acquisition exceeds $890 million.
Or, a system can be designated a “Major System” by the head of the agency responsible for it. (10 USC § 2302).
November 13, 2013 NCMA 6
And Still More: The Burden Shift to Contractor
1. Commercial Items: Change in Presumption
If the item is a major system (or a subsystem or component of a major system), the presumption of development exclusively at private expense does not apply, unless the item qualifies as COTS. The contractor/subcontractor bears the burden of proof of development at private expense. Failure to respond to a formal validation request alone can be the basis for the Government’s final decision.
DoD extended this policy to noncommercial computer software for major systems, by adding a new provision to the clause at DFARS 252.227-7019 (Validation of asserted restrictions—Computer software).
With respect to computer software, the “major systems rule” was adapted only for application to noncommercial computer software. The validation procedures are not applicable to assertions based on mixed funds, and do not restrict the contractor’s ability to segregate mixed-funding software development into privately-funded and Government-funded portions.
November 13, 2013 NCMA 7
Increased Access to Data Developed at Private Expense
2. Government’s Limited Rights are Expanded to Include Access for Support Contractors
FY 2010: § 821 Support contractor access to data. FY 2011: § 801 Litigation support contractor access. FY 2012: § 802 Litigation support contractor additional
access.
November 13, 2013 NCMA 8
Segregation & Reintegration Data: A New Type of Limited Rights Data
3. SEGREGATION OR REINTEGRATION DATA: “. . . is necessary for the segregation of an item or process from, or the reintegration of that item or process (or a physically or functionally equivalent item or process) with, other items or processes” (10
U.S.C. § 2320 (a)(2)(D)(i)(II), and (b)(9)(B)(ii))
FORM, FIT, AND FUNCTION DATA:
DFARS: “. . . data that describes the required overall physical, functional, and performance characteristics (along with the qualification requirements, if applicable) of an item, component, or process to the extent necessary to permit identification of physically and functionally interchangeable items.” (DFARS 252.227-7013(a)(11))
FAR: “… data relating to items, components, or processes that are sufficient to enable physical and functional interchangeability, and data identifying source, size, configuration, mating, and attachment characteristics, functional characteristics, and performance requirements. For computer software it means data identifying source, functional characteristics, and performance requirements but specifically excludes the source code, algorithms, processes, formulas, and flow charts of the software .” (FAR 52.227-14(a))
“OMIT” DATA:
“. . . necessary for [O]peration, [M]aintenance, [I]nstallation, or [T]raining (other than detailed manufacturing or process data)” (10 U.S.C. § 2320 (a)(2)(C)(iii))
November 13, 2013 NCMA 9
Segregation & Reintegration Data: A New Type of Limited Rights Data
New exception to the prohibition against disclosure outside USG of proprietary data (i.e., data related to technology developed 100% at private expense)
Along with “emergency repair & overhaul”. . .
Purpose of Release: only for segregation/reintegration
Implied Data Type: necessary for S/R
Procedural: notice to data owner & NDA for recipient
Included in the expanded Deferred Ordering scheme
ONLY data type for which development funding is irrelevant
No change to applicable license rights (e.g., Limited Rights)
Compensation only for converting & delivering in required form
November 13, 2013 NCMA 10
4. DoD’ Deferred Ordering Rights Expanded Prescription: mandatory, or optional?
“Regulations … shall require that, whenever practicable, a contract …” (pre-existing language at 2320(b))
Current DFARS 252.227-7027: entirely optional
No time limit – “at any time”
Current -7027 clause: limit is 3yrs after contract
Data generated “or utilized” under the contract
Current -7027 clause only if “generated” under the contract
DoD must determine that the data meets BOTH of the following:
1)Necessary for reprocurement, sustainment, modification, or upgrade of a major/weapon/noncommercial system, AND
2)Is either:
Development funded in whole or in part by the Govermment –OR– Necessary for segregation or reintegration
Coming Back for More (Data)
November 13, 2013 NCMA 11
Trade Agreements Act and Software: The Talend Ruling
5. Software “Manufacturing” and the TAA
U.S. Customs and Border Protection Advisory Ruling HQ H192146, June 9, 2012. The CBP has determined that software products are compliant with the Trade Agreements Act (TAA) when that software is manufactured in a designated country through numerous, complex and significant activities, including key product research, writing the specification and architecture, and the actual software build – even if the majority of its source code was created in a non-designated country.
The Talend Ruling is significant because government users now have useful guidance specifically addressing a very common scenario for the manufacture of open source software (and any kind of software for that matter). The Talend ruling is practical guidance on TAA compliance for open source software that is
“manufactured” with best practices, best of class inputs and best talent coming from a variety of countries. Consistent with the well-established rules of government procurement and substantial transformation, the CBP confirmed that open source software is evaluated and treated equally with non-open source software.
Open source software can meet the requirements of the TAA when it is developed and substantially transformed in the US or a designated country, even when it includes, or is based upon, source code from a non-designated country.