Many years ago, the Federal government put out a series of requirements, the FIPS standards. IIRC, the POSIX specs are part of FIPS. To generalize, Linux is an implementation of POSIX.
POSIX was pushed because of a few factors:
- vendors' operating systems are divergent, making it harder to migrate programs between systems
- vendors go out of business, shut down product lines, and make radical changes to them, so development using their APIs are an unsound investment over time
- government institutions have to carry the burden of systems they buy into for decades
FIPS are procurement standards. This means that in order to sell a computer solution to the Federal government, a vendor must satisfy the POSIX requirements. The intent is clear: to safeguard public investments. An improper balance of power in the hands of a supplier inevitably leads to deleterious actions against consumers. POSIX has the effect of making investors out of consumers.
What happened afterward is a travesty: Microsoft Windows/DOS based PC clones had picked up steam in the consumer market, and NT was being aimed at enterprises including government. Microsoft gave NT a partial POSIX subsystem, which just about nobody used, to get a rubber-stamp for sale into government accounts. A panel of judges gave the nod, and forced the Coast Guard to accept Windows based proposals in a 1995 case.
Apparently, the NT POSIX subsystem has been replaced a few times, and was crippled from the start. That's why everyone and their brother uses Cygwin, UnixUtils, or MinGW for porting Unix apps to Windows. But due to Windows' non-compliance, it doesn't run Unix style applications all that well.
Microsoft only added the DOA POSIX subsystem so they could claim compliance, when their compliance was a sham on its face. The subsystem was virtually a zombie interface.
The Coast Guard lawyers in the 1995 case would have done well to ask a multilingual colleague to assist, using a deliberately broken grammar in a non-English language to present some portion of their argument. Prior to being cited for contempt, they could then argue that their compliance with requirements for language interfaces in court was similar in kind to NT's conformance to POSIX interface requirements, and with identical outcomes.
Government purchases of closed systems like Microsoft Windows amount to a collusion with vendors in constructive non-compliance: apparently in conformance but with precisely the opposite effects as those intended by the standards authors. Such is the power of the judiciary to rewrite law.
One way to re-approach the original intent of FIPS is to reformulate compliance in terms of public trusts, or something akin to a credit union in which software is the primary asset. We have very good institutional precedents in the form of non-profit organizations, like the Apache Software Foundation and the Mozilla Foundation. (Indeed, these two alone account for a huge amount of the Web infrastructure that drives our economy.)
For software to be purchased by a government entity its assets and its dependencies should be escrowed in the public trust, largely if not completely. In the case of open source software using distributed version control services, this could be accomplished easily: just identify yourself and the repositories. Private concerns would have to accept that the public's interest in not losing access to the intellectual property outweighs their interest in keeping it private, and trust the escrow service to not leak their IP prematurely; or chose to not play in the public space.
Those institutions that adopted closed systems early got quick benefits, particularly in the predictability of the user interface and plug-and-play commodity hardware peripherals. But those same institutions are now bumping up against the inevitable consequences of the strategy. Adopting a strategy of developing for privately held operating systems is a good way to disadvantage yourself over the long term. A nod is as good as a wink to a blind horse.