DoD Study Urges OSS Adoption

Krishna Dagli writes to mention an Ars Technica article about the Open Technology Development road map, a report for the U.S. government advising the DoD on ways to integrate OSS into DoD policies. From the article: "The report argues that the standard practices associated with purchasing of physical goods are not adequate or fully applicable to software. According to the report, the DoD is 'limiting and restricting the ability of the market to compete for the provision of new and innovative solutions and capabilities' by 'treating DoD-developed software code as a physical good.' The report also points out that utilizing open source technology will force the commercial software industry to respond with greater agility and competitiveness."

Comments

Well...

[fitten]

What if other projects adopt "no military" clauses like we've seen lately? This certainly has to be in the list of risks that the DoD will face.

Anyway, other than toolkits and general systems (a Linux based workstation to compile code on, use OpenOffice to write documents, and such) there's not going to be a lot of OSS that will be reusable for the developers since they will be writing software for missile guidance systems and interfacing to hardware not generally available to the public. Some GUI toolkits, maybe, and GCC, of course.

Plus, how will GPL's clauses about not having to release code for things you do on-site relate to the contractor/subcontractor relationships that are present in DoD projects and if parts are sold to other countries (like selling an F-16 to Israel, for example)?

I'm obviously not talking much about office productivity and listening to mp3s and stuff because I'm pretty sure that's not what the DoD is talking about here.

Re:Well...

[Chris Burke]

What if other projects adopt "no military" clauses like we've seen lately? This certainly has to be in the list of risks that the DoD will face.

I doubt it, as that's not a clause of the standard GPL, and a pretty stupid clause to boot. If people want to complain that their screwdriver was eventually used to attach two pieces of a bomb, they should be protesting the decisions that require bombs to be made and used, not refusing to allow their screwdriver to be used in military applications since it's simply untennable. If war is to be waged, war machines will be made, using your code or no. Eliminate the root cause, not innefectually stymie the effect just to have a slightly clearer conscience.

Frankly I think it's dumb. Look at what the NSA has done for open source; the DoD could theoretically provide similar benefits. The DoD will continue to exist. Having the OSS community benefit from DoD development would be a good way for us to directly benefit from their continued existence.

Anyway, other than toolkits and general systems (a Linux based workstation to compile code on, use OpenOffice to write documents, and such) there's not going to be a lot of OSS that will be reusable for the developers since they will be writing software for missile guidance systems and interfacing to hardware not generally available to the public. Some GUI toolkits, maybe, and GCC, of course.

The DoD does a lot more than write code for missles. They crunch masses of data on commercially available parts, and OSS will be very useful for them in that regard. Also, I doubt that the embedded systems for missles are really that exotic -- they may be using hardened versions of microcontrollers, but I doubt they'll be using some completely esoteric ISA that would be difficult to port an OSS real-time OS to.

Plus, how will GPL's clauses about not having to release code for things you do on-site relate to the contractor/subcontractor relationships that are present in DoD projects and if parts are sold to other countries (like selling an F-16 to Israel, for example)?

If they sell it to other countries or give it to contractors, then it's no longer on-site as you've distributed it. In which case, distributing the source would be appropriate. By the same logic that you chose OSS in the first place, your customers, e.g. Israel, would want to be able to view the source code for validation and maintenence purposes.