This article is also posted to my Intelink blog.
I learned the other day about Hellekson’s Law, which states that more specific policy can be improved for the general case by removing delimiters that narrow the policy scope.
In particular, the thought was originally formulated with respect to government policies regarding Open Source Software: if there is an agency policy about open source software, then it could be improved by removing the words “open source”. Whatever policy statement applies to open source software, probably applies to software in general.
This makes sense to me… although I suspect that it doesn’t apply in all cases. Sometimes there may be specific statements that apply uniquely to open source software, specifically because of it’s open-sourciness. As the original author of the Department of Defense policy statement on open source software, I’m intrigued: how did I do?
Let’s analyze the policy/guidance section of the DoD memo and see if it articulates policy that should apply to all software, not just OSS:
a. In almost all cases, OSS meets the definition of “commercial computer software” and shall be given appropriate statutory preference in accordance with 10 USC 2377 (reference (b)) (see also FAR 2.101(b), 12.000, 12.101 (reference (c)); and DFARS 212.212, and 252.227-7014(a)(1) (reference (d)))
This first paragraph makes the legal observation that OSS is just software like any other commercial computer software and should be treated the same as all other software. Can’t apply Hellekson’s law here – if we took out “open source” it would become tautological, or false.
To explain this, let me note that, specifically, FAR 2.101 says:
“Commercial computer software” means any computer software that is a commercial item.
“Commercial item” means—
(1) Any item, other than real property, that is of a type customarily used by the general public or by non-governmental entities for purposes other than governmental purposes, and—
(i) Has been sold, leased, or licensed to the general public; or
(ii) Has been offered for sale, lease, or license to the general public;
Open-source software is used by the non-governmental entities and for non-governmental purposes, and is offered for license to the general public. GOTS (government off-the-shelf) software does not meet this definition, and this is the essential distinction I was making.
Back to the DoD memo:
b. Executive agencies, including the Department of Defense, are required to conduct market research when preparing for the procurement of property or services by 41 USC Sec. 253a (reference (e)) (see also FAR 10.001 (reference (f)). Market research for software should include OSS when it may meet mission needs.
This is the second half of the thought… since OSS is COTS (commercial off-the-shelf), it should be considered, alongside other COTS. It is unfair (and illegal) discrimination to exclude OSS. I judge that this statement follows Hellekson’s law – the statement being made is specific to OSS, and addresses a real divergence of the then-standard practice from what the law requires.
(1) There are positive aspects of OSS that should be considered when conducting market research on software for DoD use, such as:
Here begins a list of the advantages for OSS to consider when doing market research. Hellekson’s law would imply these had better be unique to OSS, or stated in a way that is broader than OSS.
(i) The continuous and broad peer-review enabled by publicly available source code supports software reliability and security efforts through the identification and elimination of defects that might otherwise go unrecognized by a more limited core development team.
Check. OSS is essential to this thought, but it isn’t stated as being about OSS; it’s a broad statement based on the essential characteristic of OSS that I was examining.
(ii) The unrestricted ability to modify software source code enables the Department to respond more rapidly to changing situations, missions, and future threats.
Check. This is true of OSS — or GOTS — but I didn’t write OSS; I said the advantage is in being able to modify the code – not how that characteristic was achieved.
(iii) Reliance on a particular software developer or vendor due to proprietary restrictions may be reduced by the use of OSS, which can be operated and maintained by multiple vendors, thus reducing barriers to entry and exit.
Partial fail. I could have replaced “OSS,” here with “software”, and it would still have been true, although there’s not too many non-open-source software products that can be maintained by multiple vendors.
(iv) Open source licenses do not restrict who can use the software or the fields of endeavor in which the software can be used. Therefore, OSS provides a net-centric licensing model that enables rapid provisioning of both known and unanticipated users.
Check. This is an odd policy statement full of hidden meanings. The words “net-centric licensing” harkens to another CIO memo generated by a dispute with a particular mercenary proprietary software vendor and an (ultimately futile) search for licensing terms that didn’t suck. I was pointing out that OSS licenses meet that need. The open-source aspect is essential to this idea.
(v) Since OSS typically does not have a per-seat licensing cost, it can provide a cost advantage in situations where many copies of the software may be required, and can mitigate risk of cost growth due to licensing in situations where the total number of users may not be known in advance.
Check-minus. OSS saves money on per-seat costs, or is a hedge when you can’t predict per-seat costs. I could have said this without limiting it to OSS: “Software that does not have a per-seat licensing cost can provide…”
(vi) By sharing the responsibility for maintenance of OSS with other users, the Department can benefit by reducing the total cost of ownership for software, particularly compared with software for which the Department has sole responsibility for maintenance (e.g., GOTS).
Check-minus. OSS saves money compared to GOTS because the maintenance burden is shared with other users. I could have said this without the words “open source”.
(vii) OSS is particularly suitable for rapid prototyping and experimentation, where the ability to “test drive” the software with minimal costs and administrative delays can be important.
Check. OSS can be acquired at the speed of light(-in-fiber), rather than the speed of contracting.
(2) While these considerations may be relevant, they may not be the overriding aspects to any decision about software. Ultimately, the software that best meets the needs and mission of the Department should be used, regardless of whether the software is open source.
Check-plus! It’s like I’m pounding my fist on Hellekson’s law here, even though it wouldn’t be written until 6 years later.
c. DoD Instruction 8500.2, “Information Assurance (IA) Implementation,” (reference (g)) includes an Information Assurance Control, “DCPD-1 Public Domain Software Controls,” which limits the use of “binary or machine-executable public domain software or other software products with limited or no warranty,” on the grounds that these items are difficult or impossible to review, repair, or extend, given that the Government does not have access to the original source code and there is no owner who could make such repairs on behalf of the government. This control should not be interpreted as forbidding the use of OSS, as the source code is available for review, repair and extension by the government and its contractors.
Check. The original text in DoDI 8500.2 was Hellekson-compliant, focusing on binary software without warranty. The OSS memo simply clarifies and emphasizes that OSS is not in that category – despite this control having been used to restrict use of OSS prior to this statement.
d. The use of any software without appropriate maintenance and support presents an information assurance risk. Before approving the use of software (including OSS), system/program managers, and ultimately Designated Approving Authorities (DAAs), must ensure that the plan for software support (e.g., commercial or Government program office support) is adequate for mission need.
Check. Not “Open Source Software”, but “any software”.
e. There is a misconception that the Government is always obligated to distribute the source code of any modified OSS to the public, and therefore that OSS should not be integrated or modified for use in classified or other sensitive DoD systems. In contrast, many open source licenses permit the user to modify OSS for internal use without being obligated to distribute source code to the public. However, if the user chooses to distribute the modified OSS outside the user’s organization (e.g., a Government user distributes the code outside the Government), then some OSS licenses (such as the GNU General Public License) do require distribution of the corresponding source code to the recipient of the software. For this reason, it is important to understand both the specifics of the open source license in question and how the Department intends to use and redistribute any DoD-modified OSS.
Check-minus. Partial fail on this one. I was trying to address the misconception that the GPL requires me to give away all my source code to any-and-all, which is not correct. Alas, the policy statement needs to be Helleksonized: “For the above reasons, it is important to understand both the specifics of the open source software license in question and how the Department intends to use and/or distribute the software or any derivative works.”
f. Software source code and associated design documents are “data” as defined by DoD Directive 8320.02 (reference (h)), and therefore shall be shared across the DoD as widely as possible to support mission needs. Open source licenses authorize widespread dissemination of the licensed software, thus allowing OSS to be shared widely across the entire Department. One way to make software source code accessible across the Department is to use the collaborative software development environment at https://software.forge.mil/, operated by the Defense Information Systems Agency.
Check. The policy statement here, “software source code & design artifacts are ‘data’ per DoDD 8320.02…” talks to all software, not just OSS. It goes on to suggest that OSS licenses are a good way to achieve this policy goal.
g. Software items, including code fixes and enhancements, developed for the Government should be released to the public (such as under an open source license) when all of the following conditions are met:
Check. Policy statement mentions OSS only as a parenthetical suggestion.
(1) The project manager, program manager, or other comparable official determines that it is in the Government’s interest to do so, such as through the expectation of future enhancements by others.
Check. OSS is mentioned only as an an suggestive example.
(2) The Government has the rights to reproduce and release the item, and to authorize others to do so. For example, the Government has public release rights when the software is developed by Government personnel, when the Government receives “unlimited rights” in software developed by a contractor at Government expense, or when pre-existing OSS is modified by or for the Government.
Check. “Open Source” is one of three examples of how the government might acquire release rights.
(3) The public release of the item is not restricted by other law or regulation, such as the Export Administration Regulations or the International Traffic in Arms Regulation, and the item qualifies for Distribution Statement A, per DoD Directive 5230.24 (reference (i)).
Check. No mention of OSS at all.
Overall, I give myself an “A-” for compliance with Hellekson’s Law. A few minor slips, but not bad.