The other three issues are:
1) The software itself would be software (bad idea man), and thus would require patching itself against 0-day threats as weaknesses are found in itself, and it couldn't contain itself in a useful way using Object Oriented Programming or even Aspect Oriented Programming concepts. (They're all scope limiting, it's just another container that can't -easily- contain itself).
1a) As such ***it needs to rely heavily on hardware elements (good thing mentioned on TomsHardware, funny that)*** and various enhanced (hardware, and firmware interaction) subsystems, otherwise it'll 'evolve' (as in mutate, change, by 'people') to become just the typical garbage software product in +5 to +10 years time. (and very expensive to maintain, in a new pseudo-closed garden of their own creation... maybe?).
They could look back at it, and it would make the EU Typhoon look like a good product by comparison.
1b) There are ***some*** processors on the market that would be a step in the right direction but you'd want to re-write large parts of all TCP/IP firmware before even contemplating doing this. (Everything in Defence is meant to be TCP/IP v4/v6 capable, with their own magic network class to boot!).
Sadly, finding support for them ***in the real world market*** (outside DARPA?) become a pain in the ass post 2003.
2) Once someone codes a back-door to just ***launch all the nukes*** and claim 'it become self aware', who is going to prove you wrong? (Yes, a software scapegoat would be nice wouldn't it?).
3) ... and will that $2 million be useful in a world more like Chernobyl?
4) If, or when, an Australian creates it will Australian laws regarding ownership of the software take precedence?
5) Without information on DARPA's current systems it wouldn't be viable to start coding, and real-time contents result in garbage 'hacked together quickly' code.
Remember: Bill Gates once said: "The worst thing you can do is rush."