The Open Technology Development (OTD) report by the Defense Department’s (DoD) Office of Advanced Systems and Concepts (ASC) makes recommendations on internal DoD software code practices, with consequent “parallel shift(s)” requiring adjacent changes in the DoD’s external technology acquisitions, contracts and procurement. 6. The stated goal of the OTD report is to make OSS the "default in the development of technology within the DoD.” 30. The underlying justification for OSS purports to help the DoD remedy the current situation where “software code is reused on a limited basis” and “sharing of code across the DoD enterprise does not occur.” 21. Consequently: “As a result the possibility that development funding is wasted by multiple efforts is high.” 21.

OTD entails “open standards, services based architectures, open source collaboration, and reference open source implementations.” 8. Thus, the OTD program would include “OSS initiatives (e.g., Linux and Apache)” but is not “limited to OSS development and licensing regimes (e.g., GPL), which enforce unlimited redistribution of code.” 8.

The main takeaways of the report:

An OSS “Roadmap”: The sweeping advocacy of OSS, lack of any real analysis, and presentation of an extensive plan for DoD OSS software policy implementation, suggest that the report compliments other substantive government OSS research. This is a “procedural,” not a “substantive” report.
Industrial Policy: Proposed partnering with open source companies through procurement and contracting suggests the report aims beyond the mere goals of costs savings and efficiency in DoD technological development.
OSS, Inside and Outside the DoD: Although purportedly geared at creating an “internal DoD OSS program,” the paper quickly points out that a “parallel shift” in the DoD’s external acquisitions and procurement must similarly adopt OSS centric strategies.
OSS and IP: IP legal issues receive mixed review, with some certainty over the status of non-distributed code within the DoD, but obvious confusion over code that would cross the DoD’s boundaries. The report is unquestionably unfriendly towards IP by highlighting the strengths of OSS without qualification and making statements such that IP can “bog down” good ideas as justification for an extensive internal DoD OSS policy.

The organization that produced the report, ASC, states its role within the DoD as that “to find, demonstrate, transition, and transfer the best operational concepts and technology solutions for transformational, joint, and coalition warfare.” ASC ties OTD to other DoD open source efforts by asserting that OTD “is consistent with external initiatives in other areas of DoD and should be linked with those efforts when possible.” 32.

Implementation
Sparse business, legal, policy and technological substantive analysis on IP and OSS gives way to the bulk of the paper, which proposes detailed OSS implementation strategies within the DoD: “to facilitate the transition to OTD practices… to modify the current system and processes so that OTD practices become default behavior for DoD technology acquisitions programs.” 9. The transition includes proposals to propagate the program at different department levels.

…a dedicated OTD…transition manager... When challenges inevitably arise from the status quo, that person can “block and tackle” from inside the building. Senior Leadership will need to define and implement changes to the current review and approval process to establish new requirements, processes, procedures, and gates that embed OTD practices into the infrastructure. 62.

Suggested metrics and benchmarks for the OTD project reflect its perspective on proprietary and open source technologies. One of the proposed metrics quantifies the level of “vendor lock-in” by measuring the necessity to work with a particular vendor to meet various technological goals; which could cause the DoD to re-evaluate “technical architecture and contracting/legal agreements.” 43. Similarly, a “leverage quotient” metric would show how well the OTD project enables “leveraging use of existing software.” 43. The goal of these quantitative indexes is to “institutionalize OTD behavior into the technology integration and development efforts.” Further, rather than focusing on only new DoD project, OTD may affect how existing DoD department reports influence the way by which “DoD projects are rated and ranked according to how they promulgate OTD methods.” 53.

Internal and External DoD Open Source Code Use
In addressing open source code for internal DoD use, the paper refers to “code whose distribution may be limited to (the) DoD, and indeed may only be accessible on classified networks.” 8. Implying that some open source legal issues may not be relevant in such cases, ASC states that “many of the legal and IP issues surrounding OSS in the private sector do not necessarily apply to software that is developed exclusively for DoD use and not released outside of DoD.” 38. Further, for code to be distributed outside the DoD, legal issues may be “navigated within the Federal Acquisition Regulation...” 38. ACS writes of government OSS use:

There is a clear distinction between using open source code developed in the private sector and fostering an OTD…within DoD. A distinction has been made for use of OSS by both the White House and the DoD Chief Information Officer; both state that OSS can be treated like proprietary software as long as the software meets DoD requirements. 37.

Despite some certainty on strictly internal OSS use, later, the OTD report seems less clear on IP issues, noting that there is no “DoD mandated policy on how to deal with copyrighting of software created, or modified by government employees, since copyright is automatically granted to the creator of the software work...” 37.

While there is no discussion of specific licenses to fall in the OTD program, the report suggests the possibility of an OTD “open” license which would clarify “the legal status of OTD within DoD.” 38. With an OTD license, “software developed under OTDL will become source accessible across DoD and/or the federal government.” 38. The report points out that its licensing proposal will also distinguish DoD rights to code and commercial rights of developers under the Federal Acquisition Regulation. 38.

Importance of Open Source Software
Despite initially claiming to propose improvements for internal DoD technology use, the ACS report specifically cites integration of external open source entities as essential to OTD’s success: “To accomplish this transition, outside resources, contractors, and practices need to be brought in...” 33. Specifically, the DoD may “encourage(s) formal relationships with resources and organizations promoting this (the open source) approach.” 12.

Affiliation with open source movements will purportedly ameliorate transitional difficulties foreseen for OTD: “The primary challenges to this transition will be cultural, not technical...” 33. The implementation planning for OTD takes an aggressive approach to handling existing DoD software code practices.

The system (current DoD technology policies) is very good at protecting itself, new approaches, such as OTD, will have to endure legal, security, and process challenges. The current infrastructure will attempt to delay change, claim they are adapting by trying to assume control of the innovative process...33.

The report states that “(I)n a word, open source is collaboration.. it's public collaboration on a software project.” 22. ACS makes similar references to open source that sound similar to various OSS’ marketing efforts: “Accountability as the driver for the changes. It is hard to argue against accountability.” 33. Further, assertions on OSS development do not acknowledge drawbacks that accompany that development model:

The competitive and evolutionary nature of these (open source) collaborations quickly leads to standardization on the best-of breed tools for a given function. When something better comes along, it doesn't take very long for that capability to disseminate between various projects. 17.

OSS as an Industrial Policy?
OTD’s sweeping affinity for OSS is further reflected where the report suggests public procurement policy arising from OTD’s principles: “Part of the… campaign will be to engage companies who are willing to respond to those (open source) incentives.” 51. Although otherwise devoid of economic analysis, the OTD report adopts the standard economic justification for open source business models:

…it can be argued that technology is now a “commodity”, especially areas where robust open source solutions exist. Commodities should be acquired in an open market using commercial practices. Technological development and integration on these commodity open source technologies should be treated as a professional service, not a product. 20.

OTD’s support of OSS aims not only to change software code practices inside the DoD, but also in supporting OSS more generally, stating that various DoD programs can “promote the use of OTD by forcing contractors to use OSS and promulgate those changes…back into the private sector or DoD enterprise.” 31. Acknowledging extensive use of IP in the software industry, the report states that “OTD requires a shift from emphasis on IP and products to professional services and open collaboration.” ACS addresses the potential impact on industry competition:

…the government will place emphasis on a business model transition study that encourages the new practices. Early adopters will gain increased exposure and will be able to strategically position themselves for the future through successful demonstration of OTD results. 66.

The OTD report states, “DoD programs must replace closed systems and proprietary API’s with open standards and interfaces.” 16. The proposal is justified in terms of the DoD leveraging technology already in use rather than “subsidizing the rewriting of existing private-sector code.” 17. The “National Security” and “National Interest(s)” for OTD include that it “(s)trengthens the industrial base by not protecting industry from competition,” making “industry more likely to compete on ideas and execution versus product lock-in.” Further, without qualifying any lack of proprietary industry capabilities, the OTD report says that “funding should be focused on areas where external investment is not being made, areas where military requirements are not being addressed, and classified technologies.” 17.

Intellectual Property and Uncertainty
There is little to no legal or policy analysis of the IP issues involved in OTD. At best, the report acknowledges that such considerations need resolution: “A detailed legal study on the issues involving open source, IP, copyright, U.S. government law and contracting needs to be coordinated.”54. ASC proposes itself as “a nexus for the coordination and assembly of legal knowledge and groundwork that are relevant…” 54.

Although some IP analysis should be part of this current report, ACS provides insight into its perspective on a prospective IP study by stating that the uncertainty of IP has caused internal DoD technology managers to be “intimidated by vendors who make sweeping but unfounded statements about the IP… implications of open source.” 54. Further, the report states that the “practices, tools, and resources employed by OSS projects and solutions have consistently outperformed traditional closed source methodologies.” 30. However, the project does acknowledge that legal IP uncertainty may “slow adoption of OTD.” 37.

What is less clear…is how the U.S. Government deals with distribution of software code it has paid for or how federal government employees deal with copyright, since current OSS licensing uses copyright as its foundation. Legal and contract issues may arise when contractors and federal workers modify and distribute code into the public domain. 37.

posted by Noel Le @ 11:23 AM | Free Culture Movement, Tax-Funded IP

Link to this Entry | Printer-Friendly | Email a Comment | Post a Comment(0)