Open Systems Architecture Understanding and Using Data Rights

Open Systems Architecture Understanding and Using Data Rights
Better Buying Power DPAP/DP Contracting Training Session Nickolas H. Guertin, PE Director for Transformation DASN RDT&E

Crafting a Market Place Maturing the Defense Contracting Environment
Defining Our Future Risk-prudent competition Business Architectures that mirror Technical Architectures Constant battle rhythm of competition Level playing field Wider access to innovation How do we establish real acquisition choice?

Strategy for Achieving Beneficial Market Behavior
What to get what we want? Why competition? What about risk? How to reduce complexity? What makes competition real? How to level playing field? How to manage the competitive landscape? What we want: The best deal for the Navy and the Taxpayer Competition gets us the best deal. Competition forces the contractor to innovate at many levels, including price, offering, design, technology, and any other advantage he can offer. Competition at the module level is risk prudent, because it forces all to innovate and bring their best offerings. Reducing complexity: Decompose the system to loosely coupled, cohesive modules For competition to work, the incumbent(s) must feel that he can lose All players need to have an equal chance of winning before their skills and abilities are considered We must take action to put wording in our solicitations and contracts such that all can bid from the same knowledge base. To use the technical and programmatic data generated under government funds, our contracts must list the exact deliverables as CLINs, and the SOWs must show them as CDRLs. If we don’t, we can’t share the information We must Assert our rights and publish that data to level the playing field Government Shaped Business Market Dynamics

Technology-centric architecture Business-centric architectures

Market Entrance Barriers
Level Playing Fields

Transparency = Opportunity
Obscure Landscape Transparency = Opportunity Transparency reduces risk, increases reuse, and improves speed to the warfighter.

https://acc.dau.mil/bbp
Better Buying Power 2.0 Promoting Effective Competition for the Life Cycle This item is continued from BBP 1.0 and will focus on improving the Department’s early planning for open architectures and the successful execution of the plan to provide for open architectures and modular systems. This will include the development of a business model and associated intellectual property strategy (data rights planning) that can be implemented over the lifecycle of the product, starting while competition still exists. Enforce open system architectures and effectively manage technical data rights: 7

We Need Innovation and Lower Price
“Better Buying Power 2.0 is a natural recognition of the fact that we can and must do more each and every year to get even better buying power and better value for the taxpayer and the warfighter.” November 2012 DEPSECDEF Dr. Ashton Carter Leadership Wants Enduring solutions Lower-cost methods for delivering capability Access to innovation Industry Has the Ability – Naval OA Report to Congress SEWIP UCS FACE A-RCI/SWFTS Industry is ready. The environment is set. Secretary Work discussed the coming of a New Golden Age for American Maritime Power … The nation will inevitably allocate the resources necessary to implement our strategic concept and organizational construct, as long as we articulate them and can back them up with tangible actions. Our destiny is, thus, in our own hands. Together we must update the Cooperative strategy for 21st Century Seapower to better refine our strategic concept, and then tirelessly explain how the combined capabilities of the Navy-Marine Corps team, the Coast Guard, Military Sealift Command, Maritime Administration, and Merchant Marine for a National Fleet with a broad range of capabilities and capacities absolutely vital to our national security. We must continue to make real our organizational construct, which envisions naval forces operating ashore; manned and unmanned platforms operating above, on, under, and from the sea; with enablers such as distributed sensor networks and durable data communication links, modular, adaptable payload bays, open-architecture combat systems, innovative payloads, network-enabled weapons, and flexible logistics systems – all operated by the finest sailors and Marines in our history. They fight as a single interconnected and cohesive team.

Consistent Contract Language
Many Different Voices Consistent Contract Language

Open Systems Architecture An Integrated Business and Technical Strategy
OSA merges technical architecture with open business model: OSA = Technical Architecture Open standards, published key interfaces, full design disclosure Modular, loosely coupled but highly cohesive OSA = Open Business Model Within Government: Transparency and leveraging of innovation across the Enterprise With Industry: Sharing risk, asset reuse and reducing total ownership costs Data Rights = License Rights for Technical Data and Computer Software Vendor Lock = Prevented from bringing in new players and exercising acquisition choices A Successful Open System Architecture can be: Added to Modified Replaced Removed - Supported --- by different vendors throughout the life cycle

Coordinated Suite of Products
Open Business Model & IP Strategy DoD OSA Contract Guidebook Under Construction Training Strategic use of IP Rights 11 11

Under Construction Coordinated Suite of Products
Open Business Model & IP Strategy DoD OSA Contract Guidebook Under Construction DoD Open Marketplace Strategic use of IP Rights 12 12

Government Purpose Rights
9th Advanced Contracting Course 19 March 2009 Development Funding 100% Govt 100% Private Mixed Limited Rights (LR) – or – Restricted Rights (RR) < LR or RR Unlimited Rights (UR) > UR (Title or Ownership) Government Purpose Rights (GPR) Data for Competition Does Not Have to Cost More Money 13 13

Government License Rights
Within Government Modify, reproduce, use, display, perform: UL GPR SBIR RR LR Third Parties UL GPR (with NDA and for Government purposes

With whom can it be shared within Government and/or with 3rd parties?
Whose IP? Unlimited? GPR? Restricted? Proprietary? With whom can it be shared within Government and/or with 3rd parties?

DoD OSA Contract Guidebook Open Business Model & IP Strategy Under Construction DoD Open Marketplace Strategic use of IP Rights 16 16

IP and Data Rights Strategy Decisions
Presentation Title April 12, 2017 IP and Data Rights Strategy Decisions Integrated EXCOMMs Control Sensor & Vehicle Control JTM Ship Control Training Weapon Control Mission Readiness IS3 NAV Command, Control, & Intelligence Acoustic Sense Suite Int Bridge E-O Surv EO/IR Imagery Eng Control System DAP CDL-N DBR IFF ES Suite MF Towed Array Towed Torpedo CM AGS MK57 VLS CIGS 57mm SM-2 Signatures ADC ESSM VLA TLAM GIANT Chaff NULKA LEAD LRLAP Decoy System 3P Round IPC AUX IBS Nav Radar E-O Surveillance Navigation PAAA DDS LOS / BLOS SATCOM HF Array UCARS TSCEI Hardware & COTS TSCE Core Services ECS Where do we want innovation from small business? What limits competition and third party product integration? How do we manage acquisition of components? Where is it acceptable to have COTS, limited, or restricted rights? Where can we use SNLs to drive fruitful market forces? GPR Restricted Rights To Be Negotiated COTS Unlimited SBIR? What does your map look like? 17 Speaker Name

Coordinated Suite of Products
DoD OSA Contract Guidebook Open Business Model & IP Strategy Under Construction DoD Open Marketplace Strategic use of IP Rights 18 18

The DoD OSA Contract Guidebook for PMs can help you
Leverage a consistent message to Industry Reduce our risk in contracting: Statement of Work Deliverables Instructions to Offerors and Grading Criteria Checklists to ensure we get OSA products Leverage Data Rights for the life cycle Capture OSA Best Practices for the program Early-and-often Design Disclosure Breaking Vendor Lock Peer Reviews for technology evaluation Minimize duplication / maximize Enterprise value More on this later! Chapter I: RECOMMENDATIONS FOR SECTION C (STATEMENT OF WORK) LANGUAGE Chapter II: DEVELOPING CONTRACT LINE ITEM NUMBERS (CLINs) – PLACEHOLDER Chapter III: EXAMPLES OF SECTION H (SPECIAL CONTRACT REQUIREMENTS) LANGUAGE Chapter IV: RECOMMENDATIONS FOR SECTION L (INSTRUCTIONS TO OFFERORS) LANGUAGE Chapter V: RECOMMENDATIONS FOR SECTION M (EVALUATION CRITERIA) LANGUAGE Chapter VI: RECOMMENDATIONS FOR INCENTIVIZING CONTRACTORS Appendix 1: RECOMMENDED CDRL AND DELIVERABLE ITEMS Appendix 2: OSA CHECKLIST (short) Appendix 3: OSA CHECKLIST (long) Appendix 4: RECOMMENDED DATA LANGUAGE FOR CODE HEADERS Appendix 5: OPEN SOURCE SOFTWARE Appendix 6: GLOSSARY OF TERMS Appendix 7: ASSESSING A PROGRAM’S INTELLECTUAL PROPERTY RIGHTS NEEDS AND DEVELOPING A DATA RIGHTS STRATEGY (DRS) Appendix 8: CLICKWRAP OR EMBEDDED LICENSE ISSUES.. 175 Appendix 9: BETTER BUYING POWER: UNDERSTANDING AND LEVRAGING DATA RIGHTS IN DoD ACQUISITIONS Appendix 10: BREAKING and AVOIDING VENDOR LOCK Appendix 11: SAMPLE CONTRACT DATA REQUIREMENTS LISTS (CDRLs)

Approach to Breaking Vendor Lock
Establish an Environment for Change Publish the intent to compete Establish Gov’t/Industry/Academia forum Establish a Flexible Contracting Approach Leverage and Exercise Data Rights Assess what you have and what you need Determine what the Government has unlimited rights in Require delivery of non-delivered CDRLs, confirm that markings are correct and assert data rights Change approach to Systems Engineering Develop a common architecture across a product line or similar Programs of Record Functionally decompose legacy programs Create an alternative Limit integrator role Use GPR for next competition InJect OSA through technical insertions Use government labs for integration Hold Competition Vendor-to-vendor cooperation past performance evaluation Associate contractors sink/swim together Establish an Environment for Change Establish an Environment for Change Incentive fees Include OSA and data rights as part of evaluation Reward reuse in evaluation criteria

Case Study: ONR SEWIP Program
Multi-Function Electronic Warfare (MFEW) was prototype by Office of Naval Research (ONR) ONR asserted Government Purpose Rights (GPR) on most of the hardware and software Surface Electronic Warfare Improvement Program (SEWIP) Productionized MFEW Provided MFEW GPR data as GFI with the RFP SEQIP RFP - rights were evaluated (Contract Guidebook) The RFP required priced option for data and data rights and included evaluation criteria on that option in the RFP This resulted in all offerors addressing data rights Some IRAD offered as GPR by contractor The Government obtained a better price and better performance

DoD OSA Contract Guidebook Open Business Model & IP Strategy Under Construction Strategic use of IP Rights Training 22 22

Open Architecture Tools and Resources
DoD OSA and Data Rights Team Naval Open Architecture Enterprise Team (OAET) Open Architecture Website: Defense Acquisition University Continuous Learning Modules Open Systems Architecture Software Reuse Data Rights Open Architecture Assessment Tool (OAAT) Version 3.0 Key Open Sub-Systems (KOSS) tool FORGE.MIL community - share DoD Open Systems Architecture Contract Guidebook For Program Managers v.1.0 Naval OSA Strategy and Business Innovation Initiative Other OA resources and tools as you seek OA

Message to Industry We will use Open Business Models and assert our Data Rights to pursuing competition and get a better deal More opportunities to win work by competing Platform, System, Component We will use competition more aggressively… Breaking Vendor Lock and obtaining a better deal is our responsibility

Contracting Challenge
Can a qualified, capable third party – Big or Small . . . Add, Modify, Replace, Remove, or Provide support . . . based on an open business model with Open Systems Architecture? My boss, her, boss, OSD AT&L challenge us all to be able to acquire smarter and get more for our money. Great engineering and excellence in business strategy on behalf of the taxpayer and war fighter. This is less about close industry partnerships and more about sustaining arms-length business relationships centered around innovation and competition. Recognize that the fiduciary responsibilities for Industry are not the fiduciary responsibility of the Government PM

Intellectual Property Rights
Richard Gray

DoD Open Systems Architecture Contract Guidebook for Program Managers v.1.0

Market Entrance Barriers
Level Playing Fields

Agenda Dependencies between Contracting and OSA
Contents of the Guidebook Highlights of Guidebook v.1.0 In order to take full advantage of the guidebook, you will likely want to know what role contracts play in developing open architecture. Additionally, we would like to tell you how each of the sections of the guidebook help you to more easily implement OA. Towards the end of the brief, we will review the highlights of the Guidebook. Finally, we will talk about the OSA resources available to you so that you know how to get the latest information. Please consider this the agenda for the next XXX minutes. Let start with the role that contracts play in setting the stage for open architecture.

Compendium of Best Practices Can Help PMs
Leverage a consistent message to Industry Reduce our risk in contracting: Statement of Work Deliverables Instructions to Offerors and Grading Criteria Leverage Data Rights for the life cycle Capture OSA Best Practices for the program Early-and-often Design Disclosure Breaking Vendor Lock Peer Reviews for technology evaluation Minimize duplication / maximize Enterprise value Chapter I: RECOMMENDATIONS FOR SECTION C (STATEMENT OF WORK) LANGUAGE Chapter II: DEVELOPING CONTRACT LINE ITEM NUMBERS (CLINs) – PLACEHOLDER Chapter III: EXAMPLES OF SECTION H (SPECIAL CONTRACT REQUIREMENTS) LANGUAGE Chapter IV: RECOMMENDATIONS FOR SECTION L (INSTRUCTIONS TO OFFERORS) LANGUAGE Chapter V: RECOMMENDATIONS FOR SECTION M (EVALUATION CRITERIA) LANGUAGE Chapter VI: RECOMMENDATIONS FOR INCENTIVIZING CONTRACTORS Appendix 1: RECOMMENDED CDRL AND DELIVERABLE ITEMS Appendix 2: OSA CHECKLIST (short) Appendix 3: OSA CHECKLIST (long) Appendix 4: RECOMMENDED DATA LANGUAGE FOR CODE HEADERS Appendix 5: OPEN SOURCE SOFTWARE Appendix 6: GLOSSARY OF TERMS Appendix 7: ASSESSING A PROGRAM’S INTELLECTUAL PROPERTY RIGHTS NEEDS AND DEVELOPING A DATA RIGHTS STRATEGY (DRS) Appendix 8: CLICKWRAP OR EMBEDDED LICENSE ISSUES.. 175 Appendix 9: BETTER BUYING POWER: UNDERSTANDING AND LEVRAGING DATA RIGHTS IN DoD ACQUISITIONS Appendix 10: BREAKING and AVOIDING VENDOR LOCK Appendix 11: SAMPLE CONTRACT DATA REQUIREMENTS LISTS (CDRLs)

Dependencies between Contracting and OSA
Obtain Access to Design Artifacts Build Modular Components Reuse Components Assert Intellectual Property Rights Publish Interfaces Choose Standards Over Custom Encourage Transparency Conduct Peer Reviews Allow & Encapsulate Proprietary Elements Foster Enterprise Collaboration Technical Practices Business Practices The business practices and the technical practices of OA are rooted in the contract. Each practice must be specified in the contract in order for the contractor to adhere to it. The contract sets up the goal posts, bounds and rules for the aquisition. The guidebook expounds on each of these practices listed. For example, recommendations for Section L: Instructions to Offerers contain contract language in support of conducting peer reviews, one of the business practices shown here in the tree. Let’s look at the contents of the guidebook to see how the guidebook will help you create and manage a contract that embraces these principles. Practices Rooted in the Contract

Contents of the Guidebook*
Customizable Cut-and-Paste Contract Language Section C: Statement of Work Section H: Special Contract Requirements Section L: Instructions to Offerors Section M: Evaluation Criteria Recommendations for Incentivizing Contractors Many opportunities for shaping market forces 11 Appendices for Strategy and Execution * One of the main avenues for following the practices listed in the last slide is the use of OA specific contract language contained in each of the sections C, H, L, and M. Benefits to User: Ease Contract Officers and Program Managers are busy people. Language is already written here. Choose and customize the language you need. Standardization Standardize the way that the Navy contracts for open architecture—Speak with one voice As more and more contracts include this language, the acquisition community will become familiar with implementing OA Practices will become the norm. Recommendations regarding incentivizing contractors--Manage the open architecture thrust throughout the execution of the contract. Making sure contractors are rewarded for OA so that you get the product you want Specific list of OA award fee criteria Considerations for and components of award terms Appendices include the following: Contract Data Requirements Lists and Deliverables--Making sure you get what you need to execute OA practices for the future (OA is a forward looking cost savings) Deliverables that significantly support Naval Open Architecture Help with reuse Help with recompetes Help with follow-on development Encourages collaboration Data Language for Code Headers Help ensure government knows its rights by properly labeled deliverables Provides key information for those seeking to use these items in the future OSS Section--Relieves some of the confusion about Open Source Software Definition of Open Sourse Software Considerations for open source What to watch out for OSA Checklist—compass to ensure you are on course to OA Quick check on a system’s programmatics that, when properly applied, will yield the benefits of an open system For a presentation to higher ups, highlight that because the book, if followed, ensures OA by making it easy, standardizing, relieving confusion, we can realize the savings OA presents with reuse, competition, and lower cycle time from demand to delivery to fleet customer.

C - Statement of Work Open Systems Approach & Goals
Software Development Plan Integrated Development Environment Product Reuse OSA Approach to Technical Development Reviews Opening Gambit: If we want OA to be in the space between the goal posts, we need to ask for it. Unique Selling Proposition: DASN RDT&E has provided a section in the OSA Contract Guidebook to address SOW language in the RFP/Contract so that OA exists in the space between the goal posts. WIIFY: The new OSA Contract Guidebook provides advice to Program Managers and Contract Officers to make it easier for you to write contracts that encourage open architecture practices which in turn will produce an open product and the appropriate level of data rights to enable competition and reuse, keys to lowering total ownership cost.

Foster Enterprise Collaboration Organize Communities of Interest
Business Principles Design Artifacts are Deliverables Foster Enterprise Collaboration Organize Communities of Interest Reduce Life-Cycle Costs Capability to Warfighter Faster Continuous Competition Eliminate Vendor Lock Ensure you get what you ask for Structure RFPs for Competition Increase Innovation Strategy for Reuse Mix of large and small Businesses Ensure you obtain what you ask for IP Strategy OSA Training for PMs and Staff SimultaneousMultiple Providers Application of the OSA business principles described in the Guidebook bears numerous fruits that enable open systems acquisitions.

Technical Principles Build Modules Of Components Reuse Components
Use OSA Technical Reference Frameworks Choose Standards Over Custom Allow & Encapsulate Proprietary Elements Publish Interfaces Enable Product Lines Improve TOC Eliminate Vendor Lock Level the Playing Field Provide product to war fighter quicker Systems of Components (Modularity) Page 8: 1. Open Systems Approach and Goals The Government intends to procure system(s) having an Open System Architecture and corresponding components. As part of this contract, the contractor shall define, document, and follow an open systems approach for using modular design, standards based interfaces, and widely-supported consensus-based standards. Page 9: b. Modular, Open Design – The contractor shall develop an architecture that is layered and modular and uses standards-based COTS/NDI hardware, operating systems, and middleware that all utilize either non-proprietary or non-vendorunique key Application Programming Interfaces (APIs). The contractor’s design approach shall be applied to all subsystems and components. As part of its open system management plan, the contractor will be required, at a minimum, to describe how the proposed system architecture meets these goals, including the steps taken to use non-proprietary or non-vendor unique COTS or reusable NDI components wherever practicable. Page 10: e. Modular Open Systems Approach (MOSA) – The contractor shall describe its rationale for the modularization choices made to generate the design. The contractor’s design approach shall produce a system that consists of hierarchical collections of software and hardware configuration items (components). These components shall be of a size that supports competitive acquisition as well as reuse. The contractor’s design approach shall emphasize the selection of components that are available commercially or within the DoD, to avoid the need to redevelop products that already exist and that can be re-used. The contractor’s rationale must explicitly address any tradeoffs performed, particularly those that compromise the modular and open nature of the system. Page 11: g. MOSA Support Plan – The contractor shall provide a plan for supporting the proposed Modular Open System Approach Page 11: i. Technology Insertion – The contractor’s architectural approach shall support the rapid and affordable insertion and refreshment of technology through modular design, the use of open standards and open interfaces. Page 11: f. MOSA Objectives – The contractor shall specify how it plans to use MOSA to enable the system to adapt to evolving requirements and threats; accelerate transition from science and technology into technology and deployment; facilitate systems reconfiguration and integration; reduce the development cycle time and total life cycle cost; maintain continued access to cutting edge technologies and products from multiple suppliers; and mitigate the risks associated with: (1) technology obsolescence, (2) being locked into proprietary or vendor-unique technology, and (3) reliance on a single source of supply over the life of the system. Page 12: k. Interface Design and Management – The contractor shall: vi. If applicable, select external interfaces from existing open or Government standards with an emphasis on enterprise-level interoperability. The contractor shall describe how its selection of interfaces will maximize the ability of the system to easily accommodate technology insertion (both hardware and software) and facilitate the insertion of alternative or reusable modular system elements Reuse Components Page 10: d. The system architecture shall minimize inter-component dependencies to allow components to be decoupled and re-used, where appropriate, across various Naval programs and platforms. Page 12: k. Interface Design and Management – The contractor shall: vi. If applicable, select external interfaces from existing open or Government standards with an emphasis on enterprise-level interoperability. The contractor shall describe how its selection of interfaces will maximize the ability of the system to easily accommodate technology insertion (both hardware and software) and facilitate the insertion of alternative or reusable modular system elements Page 13 n. Reuse of Pre-existing or Common Items – The contractor shall re-use pre-existing or common items unless a determination is made to not re-use. Publish Interfaces Page 9: a. i. 3) Data shall be transmitted through well and openly defined interfaces. Page 10: c. System Requirements Accountability – The contractor will be required to ensure that all system requirements (including those contained in the Initial Capabilities Document, Capabilities Development Document, Capabilities Production Document, and in this Section C) are accounted for through a demonstrated ability to trace each requirement to one or more modules that consist of components that are self-contained elements with well-defined, open and published interfaces implemented using open standards. Page 11: h. Design Information Documentation – The contractor shall document and model the system or component (e.g., software, hardware, middleware) design information using industry standard formats, (e.g., Unified Modeling Language). It shall also document and model how it will use tools that are capable of exporting model information in a standard format (e.g., Extensible Markup Language Metadata Interchange (XMI) and AP233/ISO 10303). The contractor shall identify the proposed standards and formats to be used. The contractor shall maintain the design information, including any models used, so that it is current with the as-built system. Choose Standards Page 8: 1. Open Systems Approach and Goals The Government intends to procure system(s) having an Open System Architecture and corresponding components. As part of this contract, the contractor shall define, document, and follow an open systems approach for using modular design, standards based interfaces, and widely-supported consensus-based standards. Page 9: b. Modular, Open Design – The contractor shall develop an architecture that is layered and modular and uses standards-based COTS/NDI hardware, operating systems, and middleware that all utilize either non-proprietary or non-vendorunique key Application Programming Interfaces (APIs). The contractor’s design approach shall be applied to all subsystems and components. As part of its open system management plan, the contractor will be required, at a minimum, to describe how the proposed system architecture meets these goals, including the steps taken to use non-proprietary or non-vendor unique COTS or reusable NDI components wherever practicable. Page 9: ii. The contractor shall ensure that their projects, at the architectural and operational level, continue to promote the use of an open architecture as well as adoption of Net Centric Enterprise Services (NCES) concepts. The contractor shall assist in the continuing pursuit of Net-Centric/FORCEnet compliance. Contractor plans must comply with the appropriate and applicable standards. The contractor shall ensure that the program is capable of interacting with the Joint Environment and DoD Global Information Grid when developing applications that share data via external communications. Page 10: d. The interfaces between the layers shall be built to open standards or available to the Government with at least Government Purpose Rights. Page 11: i. Technology Insertion – The contractor’s architectural approach shall support the rapid and affordable insertion and refreshment of technology through modular design, the use of open standards and open interfaces. Eliminate Proprietary Elements Page 9: b. Modular, Open Design – The contractor shall develop an architecture that is layered and modular and uses standards-based COTS/NDI hardware, operating systems, and middleware that all utilize either non-proprietary or non-vendor unique key Application Programming Interfaces (APIs). The contractor’s design approach shall be applied to all subsystems and components. As part of its open system management plan, the contractor will be required, at a minimum, to describe how the proposed system architecture meets these goals, including the steps taken to use non-proprietary or non-vendor unique COTS or reusable NDI components wherever practicable. Page 12: k. Interface Design and Management – The contractor shall: iii. Identify processes for specifying the lowest level (i.e. subsystem or component) at and below which it intends to control and define interfaces by proprietary or vendor-unique standards and the impact of that upon its proposed logistics approach. Page 12: l. Treatment of Proprietary or Vendor-Unique Elements – The contractor shall explain the use of proprietary, vendor-unique or closed components or interfaces. If applicable, the contractor will define its process for identifying and justifying proprietary, vendor-unique or closed interfaces, code modules, hardware, firmware, or software to be used. When interfaces, hardware, firmware, or modules that are proprietary or vendor-unique are required, the contractor shalldemonstrate to the Government that those proprietary elements do not preclude or hinder other component or module developers from interfacing with or otherwise developing, replacing, or upgrading open parts of the system.

H - Additional Special Contract Requirements
Early and often technical disclosure throughout development cycle Process for access and transparency of design artifacts Forge.mil Program ( Identify restrictions on use of technical data and software Pre-award identification and assertion Copies of negotiated, commercial and non-standard licenses Contractor use of commercial computer software including OSS Shall not create any Government distribution obligation Request permission to use commercial computer software Specially negotiated license rights for Government use of data

L&M - Instructions to Offerors and Eval. Criteria
Rule Book Scoring Factors include: Technical approach and processes Interface design and management Life Cycle management and open systems System compliance with OSA guidance Open Systems Architecture management approach Data rights and patent license rights Opening Gambit: If we want OA to be part of the design of the acquisition, we must instruct offerers how to talk about OA in their proposals and tell them how we will be evaluating them. We must tell them the rules and scoring of the particular acquisition we are making. Unique Selling Proposition: ASN RDT&E has provided sections L and M in the OSA Contract Guidebook to address instructions to offerors and evaluation criteria language in the Contract so that everyone is playing knowing all the rules and parameters. WIIFY: The new OSA Contract Guidebook provides advice to Program Managers and Contract Officers to make it easier for you to write contracts that encourage open architecture practices which in turn will produce an open product and the appropriate level of data rights to enable competition and reuse, keys to lowering total ownership cost.

OSA Proposal Requirement
Submission of Open System Management Plan: Approach for OSA technical frameworks and services Approach to sharing of design information How architecture approach will allow technology refresh Description of asset reuse approach Description of modular open systems approach (MOSA)

Incentivizing Contractors
How do we balance the government getting the best OSA deal and industry making a profit? Suggested OSA related award fee criteria: Commonality and reuse of components Modularity of products Implementation of layered and modular system Early and often disclosure of design data Use of open, standards-based interfaces with at least GPR Incorporation of components from external sources Opening Gambit: If we want contractors to comply with OA practices, it can’t be harmful to them. Any initiative, such as OA, must be mutually beneficial. Unique Selling Proposition: DASN RDT&E has provided a section in the OSA Contract Guidebook to address incentivizing contractors so that contractors want to give the government the open products that it asks for, becoming our partners in OA. WIIFY: The new OSA Contract Guidebook provides advice to Program Managers and Contract Officers to make it easier for you to write contracts that encourage open architecture practices which in turn will produce an open product and the appropriate level of data rights to enable competition and reuse, keys to lowering total ownership cost.

Appendices Recommended CDRL and Deliverable Items OSA Checklist (short) OSA Checklist (long) Recommended Data Language for Code headers Open Source Software Assessing Intellectual Property Rights Glossary of Terms Clickwrap or Embedded License Issues Better Buying Power Breaking and Avoiding Vendor Lock Sample CDRLs Appendices include the following: Contract Data Requirements Lists and Deliverables--Making sure you get what you need to execute OA practices for the future (OA is a forward looking cost savings) Deliverables that significantly support Open Architecture Help with reuse Help with recompetes Help with follow-on development Encourages collaboration Data Language for Code Headers Help ensure government knows its rights by properly labeled deliverables Provides key information for those seeking to use these items in the future OSS Section--Relieves some of the confusion about Open Source Software Definition of Open Sourse Software Considerations for open source What to watch out for OSA Checklist—compass to ensure you are on course to OA Quick check on a system’s programmatics that, when properly applied, will yield the benefits of an open system For a presentation to higher ups, highlight that because the book, if followed, ensures OA by making it easy, standardizing, relieving confusion, we can realize the savings OA presents with reuse, competition, and lower cycle time from demand to delivery to fleet customer.

OSA Checklists Developed to facilitate implementation of OSA
Easy way to check system OSA implementation Short checklist intended to check on programmatics Long version is aligned to the six principles of DoD OSA

Open Source Software Guidance
Benefits of OSS Awareness of the Government’s interests Understand where OSS is better for your program. DoD Memorandum Clarifying Guidance Regarding OSS Oct 2009 Opening Gambit: Memo and Quote from Memo Unique Selling Proposition: DASN RDT&E has provided an appendix in the OSA Contract Guidebook to address confusion regarding OSS. WIIFY: This section provides a list of possible benefits of OSS, advice, and a list of things that you need to know to protect the government’s interests when using OSS. This section will make it easier for you to utilize OSS in the best interest of your program. “To effectively achieve its missions, the Department of Defense must develop and update its software-based capabilities faster than ever, to anticipate new threats and respond to continuously changing requirements. The use of Open Source Software (OSS) can provide advantages in this regard.. …. Unfortunately, there have been misconceptions and misinterpretations of the existing laws, policies and regulations that deal with software and apply to OSS, that have hampered effective DoD use and development of OSS.” -David M. Wennergren

Assessing Intellectual Property Rights
Programs to identify and manage intellectual property Guidebook gives details on data rights assessment questions Discusses points to consider when performing an assessment Cites sections of the FAR and DFARS related to IPR Goal: Programs develop an Intellectual Property Strategy

Data Language for Code Headers
Deliverables with embedded comments to enable reuse Used for types of licensing rights: Unlimited Rights Government Purpose Rights Specially Negotiated License Rights

Recommended OSA CDRL and Deliverables
Examples: Open systems management plan Results of periodic OSA assessments Common data model for the system Executable code Software test programs and source code Interface requirement specification

Benefits from the PMs OA Guidebook
Inter-operability Reduce Cost Increase Innovation Enable Reuse/ Product Lines Reduce Technical Risk Enable Competition Reduce Possibility for Vendor Lock Improve Total Ownership Cost Provide product to war fighter quicker Level the Playing Field Increase Product Quality Enable Design Disclosure Some of the bigger picture benefits of contracting with OA in mind are listed here as the fruit of the OA tree. [Highlight a relevant few with examples and explanation.] We have now covered the essential sections of DoD v.1.0; let’s review the highlights. Vision: Every Program Manager Executing an Open Contract!

Differences from V 0.1 (December 2011)
Improved guidance on data rights licensing strategy and business modeling Rewrote the Open Source Software Guidance section Rewrote the Introduction Updated and revised material on Data Rights Resolved inconsistencies across the chapters and appendices Participation by all services, OSD OGC and DAU by subject matter experts from different disciplines To help achieve this goal, the Open Architecture Enterprise Team (OAET) developed the Naval OA Contract Guidebook for Program Managers

Competition Reward Strategic Reuse Enforce Open Architecture
Manage the Market Involve Small Business Data Rights Level the Field Reward Strategic Reuse Reuse is one important step to improving our buying power. Why have we paid for The same systems to be consistently and regularly be re-compiled by The same vendors? We have enable them to charge the Navy many Times for the same code, for radars, sonars, track managers, on and on. Enforce Open Architecture We exist as a change averse organization. Under our current budget crisis, now is the time to embrace Open Architecture and Product lines. Manage the Market One of the most important work products that has been created for OA is the Contract Guidebook. Included in the pages are clauses which define behaviors necessary to derive savings from our Contractors, and assure that we get best value for our dollars. Involve Small Business The life blood of Open Architecture is small business. Small Businesses innovate, and bring dramatically Lower costs to competitive bids. Data Rights Level the Field The DoD has not been assertive enough concerning data rights and Intellectual Property. By simply enforcing the very laws that already spell out the rights and obligations of our Suppliers, we get the tools needed to re-compete our already-paid-for systems. Buy More for Less Open Architecture is not a 10% proposition. It is a 100% move to a different mode of behavior, where OM&N is reduced to a very few spares, and repairs are rare, since the new system that replaces the current tech insertion is only months away. It is a mindset, and a commitment to the future and to the warfighter. It is walking away from our friend primes, and embracing the diversity of small business, and becoming educated on the latest technologies. There is no half-way, half does not work. The environment is tough, and competition yields different winners hat must work hard to meet demands. That is the environment we face, OA only allows us to win in this environment, instead of watching our buying power wither away. Buy More for Less!

Questions or Comments?

Backup on OSS

Considerations for OSS
Inability to Negotiate Viral Licenses Authorization and Consent Use of OSS Under a Contract but Not for Delivery While there are several benefits of OSS, there are some attributes of OSS that require caution and prudence. Inability to Negotiate The owner(s) of the intellectual property rights in the open source software generally are not available for negotiating lesser or greater rights than those rights provided by the license that governs the open source software. Accordingly, the Government must accept open source software under the terms and conditions dictated by the open source software license with the knowledge that the Government will not be able to negotiate the open source software license terms. Viral Licenses If OSS is modified, “viral’ open source software licenses require that the modified open source software, if further distributed, be distributed under the terms and conditions of the license covering the original unmodified open source software. Accordingly, the Government cannot modify open source software that is governed by viral licenses by merging open source software with computer software that is classified or otherwise not releasable to the public due to proprietary restrictions (for commercial computer software) or data rights restrictions (for non-commercial computer software). In some cases, a well-defined Application Programming Interface (API) may be provided to serve as a buffer between the open source software and the other non-open source software. Authorization and Consent Open source software may be covered by a patent of the United States, or by copyright under the Copyright Act (Title 17, U.S. Code). When the Government “authorizes and consents” to patent or copyright infringement under 28 U.S.C. §1498, the government may be sued for money damages for the infringement but not enjoined from using the open source software. As a general rule, the Government should not insert an authorization and consent clause in contracts involving open source software deliverables, or where open source software is used to develop a non-commercial computer software deliverable. Exceptions: the quality of the open source software justifies acceptance despite the licensing constraints, there are no acceptable substitutes, where time constraints for delivery do not allow for substitutes. However, where the Government does not “authorize or consent,” the contractor may be sued for money damages and may be enjoined from further use of the open source software. Use of OSS in Performing Under a Contract But Not for Delivery In cases where the contractor proposes to use open source software while performing under a contract, but not to deliver open source software, program managers and data managers should take care that such use does not create Government obligations under the open source software licensing scheme. [Contract Language Provided]

What to Know What is open source software Licensing constraints How the open source software will be used Likelihood of modification and/or distribution to third parties How OSS’s modifications impacts on non-open source software Navigating through the issues listed on the last slide requires a PM or data manager to know the following pieces of information to make educated desicions.

OSS Licenses Identify open source software
Sample language to prevent use of “clickwrap” licenses Addresses contractor, sub-contractor or third party licenses Contractor must Identify open source software Provide copies of any and all licenses Ensure Government is permitted to use the deliverables Comply with any and all requirements of the licenses

Open Systems Architecture Understanding and Using Data Rights

Similar presentations

Presentation on theme: "Open Systems Architecture Understanding and Using Data Rights"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Open Systems Architecture Understanding and Using Data Rights

Similar presentations

Presentation on theme: "Open Systems Architecture Understanding and Using Data Rights"— Presentation transcript:

Similar presentations

About project

Feedback