September 9, 2016
Who should own the rights to the software in the JSF?
The economics of intellectual property rights in weapon systems make for challenging managerial problems, and mandate some detailed legal work.
By James Hasik
The issue is longstanding. As Sandra Erwin reported for National Defense magazine, back in 2001, when the JSF program office was standing up, “little thought was given to who legally owned the rights to the technical data and intellectual property associated with the aircraft.” In 2007, the John Warner National Defense Authorization Act called for more attention, mandating that the managers of major defense programs establish “acquisition strategies that provide for technical data rights needed to sustain such systems and subsystems over their life cycle.” In 2010, making better decisions about intellectual property rights would be a major thrust of then-Under Secretary of Defense Ash Carter's original Better Buying Power (BBP) initiative. What came next were overenthusiastic efforts by not a few program managers unschooled in basic economics. In that first year, one supplier to the Pentagon requested my help in explaining to his customer why he couldn’t get the design rights for free after paying for the kit and the drawings. The underlying technology had been developed at the company’s expense—not the government’s, at least in that case—and letting go could create future competitors.
Now-Under Secretary Frank Kendall subsequent revision of the guidance (BBP 2.0) contained more nuanced language. By Valerie Insinna and Aaron Mehta's recounting in Defense News this week, the issue of intellectual property was seemingly not on his list of concerns with the F-35 for the next administration. His purview, however, is at a higher level, and technical data rights always seem a little arcane. As I wrote in “Better Buying Power or Better Off Not? Purchasing Technical Data for Weapon Systems” (Defense Acquisition Research Journal, July 2014, pp. 694–714), the details are sufficiently bedeviling that program managers can readily get the decision wrong in either direction. I covered this question here in an earlier essay, “Better Buying Power at Work: Technical Data for the Joint Light Tactical Vehicle,” in February 2014, but I repeat the point, as the issues seem evergreen:
this work is no easy task. Neither the government nor its potential suppliers can be certain of future costs and prices, as every actor in the system is planning, bidding, or negotiating with imperfect information about advanced technologies. The program manager will have broad technical knowledge of armored vehicles, and the should-cost analysis that BBP directs, but he is not a production manager with a first-hand understanding of contractors’ costs. Whoever is chosen as the original source will know his own production capabilities reasonably well, but much less about a competitor's costs. That potential second source will similarly understand his own production capabilities, but he will lack the tacit knowledge amassed during the development of the system.
With all that uncertainty, the program manager could easily pay too much now for rights that do not lead to lower future prices. Alternatively, he could easily bid too low now, and thus fail to secure a deal for rights that would have led to displacement of the first-tranche winner at a lower second-tranche price. The economics that such a manager must master are hardly basic. So are there any rules of thumb that might help?
At this year’s Acquisition Research Forum at the Naval Postgraduate School in Monterrey, Major Chris Berardi of the USAF and four co-authors presented their work on “Architecting Out Software Intellectual Property Lock-In.” By the subtitle, they specifically advanced this idea as “a method to advance the efficacy of BBP.” Their paper spends much space demonstrating statistically that three iterations and six years of BBP have not increased competition in contracting. (Kendall insists that his data show a reduction costs—arguably the more important ultimate effect—but his office has not released the full analysis.) Echoing my argument, the authors further observe that the 2007 NDAA is “a difficult statute to comply with because it asks members of the DoD acquisition community to predict what data rights are needed in the future.” What’s the answer? Options generally do have future value, so create some by mandating more open software architectures—as called for in the most recent iteration of BBP (3.0). Citing a paper by Alan MacCormack and others at Harvard Business School, they note that tightly coupled software architectures lead to components that are “hard to kill” in subsequent revisions, as they are harder to replace by other authors’ code.
As our friend Dr. Danny Lam has argued about the JSF, the tight coupling of the software and sloppy legal work regarding the rights thereto may have created a sinecure for Lockheed Martin and at least a few of its most dug-in subcontractors. So much of the functionality of the fighter resides in its software that any meaningful modifications require a trip back to Fort Worth. Berardi et alia’s recommendations for architectures merit strong consideration henceforth. Today's economic and legal questions, however, remain thorny. Together, more than a few contractors and more than a few customers want those airplanes built. Lockheed Martin and the JSF program office are the focal points for sorting out the issues. They’ll be at the problems for years. Hopefully, they won’t be at each other for years too.
James Hasik is a senior fellow at the Brent Scowcroft Center on International Security.