SCALE: Advocating FOSS at the DoD

Law, government regulations, and public policy rarely pique the interests of free software developers, which is unfortunate considering the impact these topics have on the success of free software. At SCALE 11x in Los Angeles, Mario Obejas provided an interesting look into the "dark arts" of policy-making, with an account of his trip to Washington DC to speak at a public forum on open source software in the Department of Defense (DoD). Obejas went to the forum on his own initiative, not his employer's, and his session reported on his presentation as well as those from big defense contractors, lobbying groups—and some well-known open source software vendors.

Departments, sub-departments, and agendas

Obejas works in information systems and engineering for a large defense contractor, although he declined to say which one because he wished to emphasize that he was not appearing or speaking on the company's behalf. The DoD forum in question was held in January 2012 by the Defense Acquisition Regulations System (DARS), a directorate of the Defense Procurement and Acquisition Policy (DPAP). At the name suggests, that office sets procurement policy for the DoD, which includes software and IT contracts in addition to aircraft carriers and similar high-visibility items. The forum was announced through the DPAP web site in December 2011, along with three agenda items about which the DoD solicited public input.

The first topic asked "What are the risks that open source software may include proprietary or copyrighted material incorporated into the open source software without the authorization of the actual author," thus exposing the contractor and the government to a copyright infringement liability (in this case, presumably, the question was about material copyrighted by parties other than the contractor, of course). The second topic asked whether contractors were "facing performance and warranty deficiencies to the extent that the open source software does not meet contract requirements, and the open source software license leaves the contractors without recourse." The third item was the question of whether the Defense Federal Acquisition Regulation Supplement (DFARS) should be revised to "specify clearly the rights the Government obtains when a contractor acquires open source software for the Government"

Obejas submitted a presentation proposal to the DoD forum as an individual open source enthusiast, he said, and was accepted. In January, he joined the other participants in a decidedly non-fancy auditorium chamber. Looking around the room, he said, the crowd included "lawyer, lawyer, lawyer, VP of engineering for Boeing, lawyer, lawyer, lawyer," and so on. In fact, he estimated that he was one of only three or four non-lawyers in the room, "but this is how policy gets crafted."

Presentations

The first presenter at the forum was Black Duck, a vendor of license compliance and source code management software products. On the copyright infringement topic, the Black Duck speaker commented that the reverse situation was considerably more likely to happen—open source code wandering into a proprietary product—or that open source code with conflicting licenses would be merged into a combined work. On the performance deficiency topic, Black Duck noted that contractors have the option of contracting with third-party open source companies for support if they encounter deficiencies with an open source components. The company spokesperson did not offer an answer on the DFARS agenda item, but did comment that the benefits of open source are too great to ignore, and advised that the DoD ensure its contractors are open source savvy to manage the risks involved.

Obejas spoke second. He briefly addressed the three agenda items, beginning by reminding the attendees of the DoD's own FAQ asserting that open source software is commercial and off-the-shelf, so it should be treated like other commercial off-the-shelf (COTS) products. Consequently, it follows that the risks asked about in the first two topics should be addressed in the same way as they are with proprietary software. On the third question about revising DFARS for clarity, Obejas said "I must be too much of an engineer but I don't see the downside of the DFARS being more specific."

But Obejas then introduced a major point of his own, arguing that open source adoption in DoD projects is inhibited by fear stemming from the misconception that the GPL forces public disclosure of source code. In reality, of course, the GPL allows a vendor to provide the corresponding source code of a binary to the customer when the binary is delivered. The customer in this case would be the DoD, who is not likely to redistribute the code to others. But the misconception that the source must be made available to the public persists, and contractors avoid GPL-licensed components as a result.

Obejas cited several factors contributing to this hangup, including the fact that the GNU project does not provide black-and-white rules on what constitutes a combined work under the GPL and what does not. Instead it uses "mushy" language like "communicate at arms length" and "partly a matter of substance and partly a matter of form." Managers react to this nebulous language with fear, and open source adoption is impeded. Better education and more specifics are the remedy, he said. The DoD FAQ and other documents already advise contractors that ignoring open source software makes them less competitive, but there is a disconnect between this policy and reality on the ground. Furthermore, the DoD has consulted with groups like the Software Freedom Law Center and has written Memoranda Of Understanding (MOU) documents, but they remain unpublished.

After Obejas, a representative from the OpenGeo project spoke about the copyright infringement and performance deficiency agenda topics, also advising that open source software does not carry different risks of copyright infringement or warranty liability than does proprietary software. There was also a paper submitted to the forum by the Aerospace Industries Association (AIA), a lobbying group. The paper was wishy-washy at some times and dead wrong at least once, Obejas said. On the copyright infringement topic, it listed examples of potential copyright infringement risks, but did not provide any statistics of prevalence. On the performance and warranty question, it said contractors are "absolutely without recourse" under open source licenses—but that that was also true of using proprietary software. It incorrectly claimed that open sources licenses prohibit the use of the software in "hazardous" activities, he said, and incorrectly said that the GPL was at odds with US export law. It also requested more clarity on incorporating GPL code, and cited the 2012 issue of the Apache License's indemnification clause as an example where licensing can be tricky to understand.

The next speaker was Craig Bristol, an intellectual-property lawyer at DoD contractor Raytheon. He mostly discussed the aforementioned Apache license "debacle," and also stated publicly that he did not believe that open source and proprietary software should be treated the same. Obejas said that he respectfully disagreed with that viewpoint, but that it did concern him that a major contractor's IP lawyer took a public stance at odds with the DoD's written declarations.

The final speaker was from Red Hat, and did not address either of the first two agenda topics. Red Hat's speaker did say it was important to remove discrimination against open source, hailing the 2009 DoD memo on open source usage and the 2011 Office of Management and Budget (OMB) memo on software acquisition. Red Hat was wary of changing the DFARS, however, saying the DoD must make sure it addressed both open source and proprietary software and that it does not build on legacy misconceptions.

Discussion

The DoD forum included a question-and-answer session, during which Obejas requested that the DoD publish its memos and accounts of its conversations with the Free Software Foundation (FSF) and related groups. Several others agreed that the complexity of current software development regulations is making matters worse, and that an effort should be made to reduce regulatory complexity.

The session ended with comments from Dan Risacher, who is the DoD's official "Developer Advocate" and was the primary author of the 2009 memo. Risacher said that the government has done the legal research and determined that open source software meets the definition of commercial computer software as defined by the DFARS—even though some "non believers" at the forum disagreed with that conclusion.

He then responded to two points from the AIA paper. First, he said that when contractors encounter any warranty problems with open source software components, those are the contractor's problem to deal with:

He also rejected the notion that the GPL requires public disclosure, calling it "completely a misunderstanding of the license."

Risacher's comments marked the end of the DoD forum recap, but Obejas also addressed two "weird edge cases" encountered during the event. The first was the Apache indemnification clause debate. The issue stemmed from clause 9 of the Apache License, which says that the licensee may choose to offer indemnity to its clients, but if it does so it must also extend that same indemnity to the upstream project. A US Army lawyer interpreted that clause incorrectly, Obejas said, and commented publicly that the Apache License loads unlimited legal liability onto the government in the form of liability guarantees to multiple (upstream) third parties. That would run afoul of regulations. The Apache project responded that the indemnification clause is only triggered if the licensee chooses to offer indemnity. Eventually the Army came around and dropped its objection in March 2012, Obejas said, but considerable time and effort were consumed in the process.

The second edge case he described was an unnamed government contractor who built a software product based on classified modifications to a GPL-licensed work. The contractor asked the government to give it a waiver from copyright law compliance, so that it would not be required to deliver the relevant source code. The notion that a company would knowingly violate copyright law is objectionable enough, Obejas observed, but the contractor's concern was also based on the misconception that the GPL requires public source code disclosure. In reality, the US government is the contractor's customer, and would not distribute the binary (or source code) to anyone itself.

In conclusion, Obejas said he can muster little sympathy for a company that starts building a product with components it acquired through a well-known open source license, then expects the government to relieve it from its legal obligation. Contractors are responsible for the components they deliver to the government, and should pick them prudently—including complying with open source licenses. The DoD already recognizes the value of open source software, he said. He wants contractors (including the company he works for) to recognize that value as well, and to utilize it.

The future

Moving forward, Obejas noted several practical obstacles to increasing open source adoption in DoD contract work. Contractors' Information Systems offices do not always agree with the DoD's interpretation of licensing issues, he said. Contractors have different incentives than their government customers, and they may decide that complying with open source licenses takes more work than sticking with proprietary software. Inertia is a another real problem; defense contractors frequently want to see precedents before they adopt a new strategy. Consequently, very few contractors want to be the first to try something new, such as using open source software components.

That last point was where Obejas said that publishing more legal case studies and clearer guidelines on license compliance—in particular on how to combine proprietary and free software components in a single product—would attract more contractors to open source. On Sunday afternoon, Obejas raised the issue in Bradley Kuhn's talk about the AGPL. Kuhn's reply was twofold. First, he said that there were already sufficient public examples of how to combine GPL components with non-free components, including compliance actions and court cases.

But more importantly, providing clear guidelines about how to combine free and non-free components without running afoul of the license runs contrary to the FSF's (or other licensor's) goals. It would amount to unilaterally "disarming," Kuhn said. A guide to how to walk the line between compliance and non-compliance would essentially be a guide to how to skirt the license when making derivative works. In addition, any such published guidelines would be fodder for precedent in future court cases—including cases between third parties. Fundamentally, the goal of the copyleft movement is to expand the scope of software freedom, he said; it is unreasonable to expect copyleft proponents to weaken their position just to provide "clarity" for people not interested in furthering the principle of copyleft.

Of course, groups like the FSF and SFLC should be expected to take a hardened position on combining free and non-free software; they exist for the purpose of promoting free software. It is the defense contractors whose decisions are motivated by other factors (such as profitability), which will shape how they select components and which subcontractors they work with. But defense contractors are in an unusual position in one big respect: they have one large client (the government), and they can be fairly certain that the client will not give away their product to the public and cost them future revenue. It is impressive how far open source has worked its way into the DoD contractor world already—whichever direction it heads in the days to come. Or, as Obejas put it, whatever else one thinks about the government, it is pretty cool to stop and notice that the DoD even has a position like the one Dan Risacher's occupies: developer advocate.