Comments on issue #193 ("ITAPS Comments on the Federal Source Code Policy").

As issue #193 is closed, I'm filing this new ticket to make a few comments on it:

ITAPS complains of a lack of clarity about exactly what the proposed policy means by "custom code", and worries that requiring the government to have full rights to new custom code could inadvertently force vendors of proprietary code to de-proprietize parts of their existing, non-custom code as well, simply because the new custom code and the existing proprietary code are technically linked in such a way that the custom code is only useful in concert with the proprietary code.

This amounts to an argument for preserving and reinforcing the current situation, in which vendors of proprietary software products are effectively incentivized to design monolithic, all-or-nothing products that lack clear module boundaries, APIs, and plugin systems, despite the fact that it is virtually always in the government's interest to have modular, API-enabled, plugin-supporting software. The point of this source code policy is that if vendors want to be able to meet the government's proposed requirements, and yet not have to give up exclusivity in their proprietary code, then it is the vendor's responsibility to design the software system in such a way that it can support the policy's requirements without endangering those exclusivities that are not covered by the policy. To worry that the policy would somehow force an undesirable outcome for the vendor is to take a technical responsibility that is properly the vendor's and transfer it to the government instead. There is no reason to do this.

The list of concerns headed "Other elements of the policy regarding the use of COTS that need further elaboration and clarification" is confusing and, in places, spurious. There is no need to provide "[c]larification that the Policy does not prohibit the Covered Agencies from licensing back the custom code to the party that developed it so that party can re-use it with other customers", as such a prohibition would not exist with any open source license; the policy should not provide special reassurances regarding conditions that do not exist, as the number of such conditions is infinite. There is likewise no need to specify "what constitutes 'professional services' in connection with COTS software and whether or not they are covered by the Policy" -- the policy itself does not use the phrase "professional services", and there in principle is no such thing as an open source license for professional services. There is no need to exempt "non-COTS commercial items" (by which ITAPS probably means non-COTS proprietary commercial items, though ITAPS's terminology is consistently imprecise regarding this distinction) from review under this policy; such items should still be reviewed, and the government can decide on a case-by-case basis whether their procurement is justified, under the policy, given the needs that particular software fulfills. I regret that due to time limitations, I cannot respond to the other points in that list, but most of them are out-of-scope, inapplicable, or show a reluctance to interpret the policy's language in the most natural and sensible way.

ITAPS writes:

If government agencies want the ability to reuse and modify, then it will become very difficult and/or expensive for the contractor (or anyone else) to provide maintenance support for it. Consequently, this element of the policy could have the opposite effect by increasing cost for the federal government. The federal government should assume that contractors will charge a premium to the first agency to acquire the code to compensate for the fact that they can only charge for the code one time. The savings for the government are supposed to come from the fact that reuse would be free, however, such reuse may not happen (and is in fact unlikely, since the code was custom-developed because no vendor expected much, if any, commercial demand for it), and so there may be no savings.

This defies market logic. Part of the point of the policy, and of open source software generally, is to separate capital costs from marginal costs, that is, to decouple the cost of creation from the cost of maintenance. When the government needs to procure maintenance contracts, it should simply do so; this policy will lower costs by helping to ensure that the government has a competitive marketplace of support vendors to choose from, instead of being (for all practical purposes) locked in to the vendor that originally supplied the code. It is entirely reasonable that "contractors will charge a premium to the first agency to acquire the code to compensate for the fact that they can only charge for the code one time"; this is a fine outcome, and nothing in the policy argues against it. The government's cost savings come from greatly lowered costs of reuse and from being able to procure from a competitive marketplace for support; the policy is fairly explicit in making this argument. ITAPS argues that custom-developed code is unlikely to see much re-use, but this assertion just doesn't hold up against the reality of the open-source marketplace and the considerable reuse of custom code in practice. (A good way to test ITAPS's theory would be to look at the degree of re-use in proprietary code when, for example, the same vendor sells a similar software system in multiple non-federal jurisdictions, with only the necessary customizations made for each jurisdiction. There, re-use would naturally result in lower costs for the vendor, and is thus strongly incentivized. If some of ITAPS's members would like to make their source code available under NDA for a study of how much re-use happens under those circumstances, I believe the results would be enlightening, but not necessarily aligned with the argument ITAPS makes in its comments in issue #193.)

ITAPS's most direct argument is also the one least supported by evidence (at least as presented in their comment). In a curiously passive-voice construction, ITAPS writes "Unlimited rights mandated by the Federal Acquisition Regulation for government-financed software, however, are frequently identified as a direct impediment to participation in the government market by innovative and cutting edge technology firms." In other words, so the argument goes, if the government gets more code, more control, and more re-use, all for less money overall, then companies won't make as much money and therefore won't innovate as much. ITAPS provides no evidence to support this claim, and it is counterintuitive on its face: a company that has to compete for the business of informed customers who have real marketplace choices will, in general, become more innovative, not less.

ITAPS recommends implementing the proposed policy as a pilot program, without specifying how simply implementing the policy as proposed would be effectively different from a pilot program in terms of evaluation and outcome. ITAPS writes "If an insufficient community arises to support the publication of 20% of federal government custom code, then plans to expand the policy to more or all custom code should be deferred." But 20% is already a low number, and makes this proposed policy a pilot program in any case. By simply implementing the policy as proposed, the government is running the pilot program ITAPS calls for, and the government may evaluate at any time, or at multiple times, how the program is faring and adjust the policy accordingly.

ITAPS writes that "[s]everal companies ... do not see how an open source policy and the tech neutrality policy are compatible." If so, these (unnamed) companies are conflating two unrelated domains. Open source licensing is not specific to any particular type of technology, and can be applied to any technology. The policy has nothing to say about technology choices, either implicitly or explicitly, and is therefore technology-neutral.

The section on "Security" is so wrong I do not even know where to start. ITAPS writes that "[t]he quality and safety of open source software depends upon a robust community evaluating and testing software code on a continuous basis." No, the quality and safety of open source software depends on the same things that the quality and safety of any software depend on. This includes robust and continuous testing, and code review, and every other security analysis method used for software. This is a general problem in ITAPS's response: the notion that an open source license changes something technical about the software in question. It does not. When a computer chip executes an instruction stream, it does not know what license the bits are under -- licenses are an agreement among humans, and have no bearing on the behavior of the code at the machine level. Security, and every other aspect of software quality, is ensured the same way for open source software as it is for any other kind of software. However, I must add that open source software in general has a pretty good record on security (this is one reason it is so widely used by DoD projects). It is true that security vulnerabilities in open source software, when found, tend to become widely known, simply because of the tradition of transparency in communications about open source software. This is a perception bias and is unrelated to the actual prevalence of security vulnerabilities in open source vs proprietary software. In a dark room, you will see dirt where you shine the flashlight, but that does not mean the floor isn't dirtier somewhere else.

ITAPS asks that this policy not apply to cloud offerings. It may be that the policy should be adjusted to more clearly address cloud offerings, or a separate policy issued regarding cloud offerings, but nothing in the current proposed policy prevents the government from procuring cloud services, and it is in the government's interests for those to be open source as often as possible. Simply declaring cloud offerings off-limits from the desirable changes proposed here does not make sense.

The recommendations in "Anti-Deficiency Act Clarifications" seem like an antiquated and overly-cautious interpretation to me, but perhaps if further clarification would reassure ITAPS members then it should be added; it does not seem like it would do any harm, at any rate.

The "Resource Clearances" section is confused on the difference between modifying an original and modifying a copy, and on the difference between code and the person who wrote that code. Any code deployed into production for government use should undergo the necessary vetting, and typically the vendors working with the government would be responsible for that vetting. All code contributed is visible and subject to such review. People have clearances; code does not -- code just does whatever it is written to do, regardless of its origins.

At this point, I became exhausted, and therefore did not review the sections "Unaccounted for Costs", "Applicability to Grants and Cooperative Agreements", and "Conclusion" in ITAPS's comments in issue #193.

Thank you for your consideration of these remarks.

-Karl Fogel Partner, Open Tech Strategies, LLC http://opentechstrategies.com/

WhiteHouse / source-code-policy

Comments on issue #193 ("ITAPS Comments on the Federal Source Code Policy"). #250