DoD ownership of IP doesn’t solve vendor lock- alt causes

Shyam Sankar is the Chief Technology Officer of Palantir Technologies. Caitlin Dohrman is the Chief Executive Officer of Tangram Flex. Madeline Zimmerman is a Department of Defense Deployment Strategist at Palantir Technologies. THE MILITARY’S INSISTENCE ON OWNING COMMERCIAL INTELLECTUAL PROPERTY IS LIMITING INNOVATION; War On The Rocks;

While the battle for intellectual property ownership is perceived as existential by both the Department of Defense and commercial providers, a closer look at the origins of each actor’s preferences reveals greater compatibility. Industry wants to ensure a return on its investment, which doesn’t require promoting vendor lock or undermining interoperability. The military wants to limit vendor lock and promote interoperability, regardless of whether commercial firms earn a return on investment. The key question then is: Does department ownership of commercial intellectual property actually support its stated interests, justifying the harm it causes to commercial actors? The answer, in short, is no. First, intellectual property ownership is not actually necessary to combat vendor lock and interoperability. For example, even if the department does not own a vendor’s baseline intellectual property, a legal precedent already exists so that no vendor can preclude the government from cloning the application programming interfaces of the function it wants and then re-competing the capability to the market. Additionally, the issue driving vendor lock and high switching costs is proprietary interfaces, not proprietary code or intellectual property. As the current special advisor to the secretary of the Air Force, Tim Grayson, said about software solutions from traditional defense contractors: “When we have worked interoperability at the data level what we have found is the biggest problem is legacy programs and their vendors don’t know their own systems. We might have to have them spend three to six months effectively reverse engineering their systems and documenting what their interfaces are.” Ironically, the complexity and bespoke nature of many custom government off-the-shelf solutions drives outcomes that the government is trying to avoid: increased technical debt and vendor lock to the developer. Second, regardless of who owns the intellectual property, the military can mandate application programming interfaces and interoperability with relevant government reference architectures. The department can also write into contracts mandatory data export or “burn down” requirements for key deliverables, which lowers the switching costs of changing vendors. This should be sufficient to meet most interoperability standards, and the department can always insist on a re-compete for any capability it feels does not pass muster. Third, the Department of Defense has already authorized new approaches to maximize interoperability and avoid vendor lock. For example, in 2017, U.S. law mandated that all major defense acquisition programs must be designed and developed using a modular open systems approach, and a 2019 tri-service memo reinforced this approach. The modular open systems approach is a technical and business strategy designed in part to lower the switching costs of moving from one vendor to another by mandating open standards and interoperable systems. Unfortunately, when the Department of Defense encourages unlimited rights or government purpose rights in the name of interoperability or a modular open systems approach, they box out commercial companies, who, ironically, are the entities most likely to be compliant with this approach. By definition, dual-use commercial capabilities are trying to capture a large segment of the total addressable market, and thus commercial providers build their products to be as open and modular as possible to satisfy the widest possible set of requirements. Fourth, we have heard officials express fears that during wartime conditions — where urgent changes and modifications must be made — the government will be unable to make system changes because it doesn’t own the source code and thus becomes reliant upon commercial actors. However, the ease with which a program can use and modify a technology is almost entirely divorced from “owning the source code.” To use a non-defense example, Windows users cannot modify their operating system source code, but there are limitless configurations and customizations they can build on top of this commercial baseline. Additionally, even if the U.S. government owned the source code, it likely would need a more upskilled workforce to modify, test, and deploy changes to the source code of a company’s commercial baseline under acute stress.