Navy Now Mandated To Consider FOSS As an Option

lisah writes "In a memorandum handed down from Department of the Navy CIO John Carey this week, the Navy is now mandated to consider open source solutions when making new software acquisitions. According John Weathersby, executive director of the Open Source Software Institute, this is the first in a series of documents that will also address 'development and distribution issues regarding open source within Navy IT environments.'"

Yeah, and the USAF uses ADA

[Liquidrage]

When I was writing software for the USAF we were required to use ADA. I worked at the USAF's largest software factory. No one there used ADA for anything.

So to me the announcement means nothing. Military doesn't always eat it's own dog food.

Re:Inconceivable!

[Simon80]

You may not be able to imagine it, but the US Navy has realized [wikipedia.org] it!

Re:Finally! An F-22 Problem?

[Nom du Keyboard]

Maybe now someone will finally download (or, dare I say, contribute?) to my sourceforge project. It's an Open Source nuclear submarine guidance system forked from an early beta of GAIM.

What happens when it crosses the International Dateline? [defenseindustrydaily.com]

Consider eh?

[Zironic]

If I understand this correctly.

Before the navy had no idea under what label they were supposed to put open source software so they didn't consider it (out of lazyness?). Now open source is defined as a commercial item so the navy can purchase it the same way they do with other software.

However this doesn't seem to in any way prevent the large companies from doing what they always do. Just bribe the officials responsible for deciding what software/hardware to use and get them to make the navy pay for their expensive useless stuff.

I doubt we'll see any great rise in the amount of open source software used in the navy just yet. It's a fairly big step in the right direction though. I would seriously not have thought that one of the big difficulties of using open source was defining it for your paper work o.O

Why the Navy wants FOSS

[greginnj]

I'm amazed at the number of people asking for cost comparisons and going on about how there are also training costs, blah blah blah. RTFA and we see:

misconceptions about whether or not open source software qualifies as COTS (commercial off-the-shelf) or GOTS (government off-the-shelf) software has hindered the Navy's ability to fully utilize open source software.

Which, if you use your critical reading skills, would tell you that the Navy is already trying to use FOSS, but is having trouble doing so. We all know about military spending -- they don't give a rat's ass about saving 10% off the fully loaded cost. What we're talking about is Naval Engineering [hotmcl.org]:

The term Seabee Ingenuity grew from deeds recorded during the Solomon campaign. A Seabee Warrant Officer repurchased equipment from customers to set up shop. Bulldozer head gaskets were fashioned from scraps of metal and paper. Waxed paper and tinfoil from cigarette packages served as condensers while 55-gallon drums replaced worn-out radiators. Tires were filled with sawdust and concrete. One Seabee turned his dozer into a piece of combat equipment and wiped out a gun emplacement in the Treasury Islands. The work accomplished by these new Construction Battalions seemed almost impossible and yet the CAN DO standards set the precedence for the battalions that followed.

Now, imagine a similar situation involving software. Your control system is acting up while you're on patrol in the South China Sea -- do you send an email to Redmond and wait for the response, or do you open the hood and fix it yourself? As the pdf memorandum said:

As with any COTS solution, the use of OSS must adhere to all Federal, DoD, and DON policies and be based on open standards to support the DoD's goals of net-centricity and interoperability.

Go Navy!

GPLv3, new clause

[Anonymous Coward]

Can we please put a clause in GPLv3 that prevents GPL'd software from being used to kill people?

Re:Great! This is what you have to do

[jd]

There are only a handful of OS' that are considered "trusted". HP-UX BLS, Trusted Unicos 8.0, SEVMS, CS/SX, Trusted IRIX, Trusted Solaris, VSLAN, Trusted XENIX, XTS-300, XTS-400, PR/SM, SACDIN, THETA and Genesis. I see a distinct lack of OS/X, Microsoft isn't even remotely close, Linux has 30% of the RBAC requirements to be really secure in a modern environment - which is better than many, and OpenBSD is only considered watertight from external attacks - it has minimal security between users.

When you consider that you can build role-based access controls that can migrate with applications across clusters, when network connection types, network bandwidth, shared memory and inter-process communication have mandatory access controls, you really begin to see just how pathetically limited generally-available OS' really are. There's no reason for it - there's nothing that prevents a widely-available system from being harder than a diamond-encrusted pulsar.

The reason that nobody bothers much with making OS' secure is that the DoD has long-proved (by buying Windows and by failing their security audits) that security doesn't matter enough to be worth the effort. Security to this level costs big money, and only the really big corporations can afford the costs or have the market to pay for it. Companies can lose hundreds of thousands of credit cards and maybe get rapped knuckles - if they're even discovered. Only one State requires reporting - but plenty of other places have e-Commerce. System crackers - black hats especially - are a pervasive part of society with no serious effort to secure networks against them.

If the money did exist, if there was serious interest in serious prevention, host intrusion detection wouldn't be MD5 checksums (which were beaten soundly, according to the Internet Auditing Project). Plain-text passwords wouldn't exist. One-time pads and public-key encryption would be the only way to log onto Slashdot or any other web service. Zombies, Trojans and Viruses would be found in technology museums, under "extinct electronic lifeforms". If a disk drive with tens of millions of credit cards or social security numbers went missing, in a secure world that would be cause for a few minutes downtime to replace what was lost, rather than a few weeks or months of running round in circles doing nothing.

You see any of that happening? No? Then security is still regarded as an optional extra, not as a fundamental design requirement, and will never reach its true potential. Furthermore, agencies will continue buying/copying OS' based on ease of initial deployment and not on whether it'll protect the data sufficiently.

Re:Why the Navy wants FOSS

[AHumbleOpinion]

"The term Seabee Ingenuity grew from deeds recorded during the Solomon campaign. A Seabee Warrant Officer repurchased equipment from customers to set up shop. Bulldozer head gaskets were fashioned from scraps of metal and paper. Waxed paper and tinfoil from cigarette packages served as condensers while 55-gallon drums replaced worn-out radiators. Tires were filled with sawdust and concrete. One Seabee turned his dozer into a piece of combat equipment and wiped out a gun emplacement in the Treasury Islands. The work accomplished by these new Construction Battalions seemed almost impossible and yet the CAN DO standards set the precedence for the battalions that followed."

Now, imagine a similar situation involving software ...

I can't. Are you familiar with the WW2 era Seabees. They weren't necessarily your teenage volunteers/draftees. Many were "old men" in their 30s and 40s who the Navy would have turned away due to their "advanced age", however these "old men" had many years of experience in construction, engineering and related disciplines so the Navy made an exception for the Seabees. So most of the people hacking away on FOSS would not be a similar fit experience wise, quality product wise, etc.

Re:Cool!!

[init100]

Of interest would be the clause about internal use - if one government agency modifies it can any other use it without requiring a broader release of the source?

No, this would not require a broader source release. Contrary to common belief, the GPL does not require that source must be published to the world when software covered by the GPL is distributed, only that the source is distributed along with the binary under the GPL. The recipient is free to publish though, so there is usually not much to gain by only distributing to your customers.

Parts of the Navy are way ahead of him already

[finlandia1869]

I'm not surprised by this at all. There's actually an effort within the Navy now to build a massive shared, OSS repository of combat system software components and code for combat systems stuff. Everyone gets to examine code, fiddle with it, pick at it, adapt it, go play. And you're required to submit whatever you come up with to the same scrutiny. It's part of a larger effort to get away from lock-in with Raytheon, LockMart, etc. and get more competition and more small players. The surface warfare centers have experimented with creating their own quasi-incubators for small business industry to get a foot in the door. I've heard of a few neat products so far.

My only fear is that all of our efforts will go for nothing when some doofus admiral says, "Vendor X says he can do it cheaper. Drop everything and go prove that you really know what you're doing." Yup. All of my team's work grinds to a halt for 3 months while we pursue a damn wild goose chase to justify that we're more trustworthy than a retired O-6 who's now a salesman.

Wish us luck. We'll bloody well need it.

Re:Why the Navy wants FOSS

[samkass]

Not everywhere. The Army currently has a bit of a split personality here. The "Future Combat Systems" projects are all being developed on linux, and all FCS software is written in C, C++, or Java (no .NET). At the same time, all of the current Army Battle Command Systems are being actively ported to Windows and away from unices, favoring .NET solutions, and requiring Vista compatibility for all the next versions of the software. Doesn't matter to my product, as we use Java and can run on all of it.