Open Source in the Military? 398
djmcmath asks: "Does anyone have any experience with Open Source Software and/or GPL'd software in military applications? I'm only asking because I'm involved in work on the combat systems for a new submarine, and had considered an Open Source solution. (I apologize, I must be intentionally vague for obvious reasons.) So ignore the obvious questions (Is it really suitable? Are closed-source proprietary options better? Does MS have a good solution?) and skip to the good stuff. What about the fact that my code would be classified Secret under US Code Umptifratz? I cannot distribute my code (and it's changes) without being tried for treason. What happens to the rest of the combat system code when I submit my GPL'd module?" Open Source and the Military: it's a tricky combination of keeping what can be open, open and keeping your secrets...well, secrets! However, open source in the military need not be as high profile as weapons systems. One of the only major OS projects that I'm aware of that had any form of military involvement was GRASS, the open-source GIS system. I'm sure there may be a few others out there. Does anyone know of other OS projects with military association? If there are any projects out there that interface with classified bits, how did you deal with those issues?
OSS in the USAF (Score:4, Interesting)
We use Samba for sharing printers between Windows NT and Solaris. We don't change the source code, but we do use OSS. I believe that we also use GCC for some things, because (and I am not 100% sure on this since I am not a sysadmin) I don't think Solaris comes with a C compiler. We also use DivX for... I could tell you but then I'd have to kill you
I've thought about this before because of our software licensing. Let's say Microsoft thinks they need a license audit. What's more important: maintaining our security by not allowing Microsoft access to sensitive computer systems, or complying with their "copyright" policies? If a computer is located in a secure area protected by federal classification law, who will know?
It goes both ways. The government could potentially abuse the GPL, but they could do the same to the draconian licensing terms in commercial software. It is my experience that the people in charge of acquiring systems will make sure their subordinates comply with the law. The higher-ups at my squadron stress that we must obey licensing laws because it's The Right Thing To Do.
I like open source software. I think it's the greatest thing since sliced bread. But for some applications, such as classified computer systems, it may be best to stick to closed source if you need to change the open source software.
One Approach - Loose Integration (Score:5, Interesting)
I worked on a terrain database analysis tool, called ZCAP [ucf.edu],
that was funded a few years back by U.S. Army STRICOM [army.mil]
and the Defense Modeling and Simulation Office [dmso.mil]
We distributed the application (and still do) in a complete package
that included a number of supporting free source applications, such as gnuplot
and tcl/tk. We handled the combination of free source, (no longer)export-restricted
software, and proprietarty libraries by loosely integrating
using system calls under a tk-based gui. Not very clean, but there
is a lot of good code in there, and I'm planning to gpl it in the near future.
RTEMS is pretty much BSD code from the US miltary (Score:2, Interesting)
As a side note I see that RTEMS stands for something new - perhaps I am having a 1984 experience but I seem to remember it used to stand for "Real Time Executive for Missile Systems"
Don't say the us military has not done anything for open source or I will be forced to mention Arpanet
Embedded devices (Score:4, Interesting)
That brings up the question of embedded devices in general, e.g. what if the binary is in night vision goggles or a satellite radio issued to troops? They presumably can't be given the classified source code. I discussed embedded devices with RMS a long time ago and back then, he seemed to think it was technically a GPL violation, but if the code in the device can't be changed (i.e. it's in ROM) then it didn't really count as software, so he wasn't too worried. At that time, embedded CPU's weren't so ubiquitous and those that existed were mostly tiny and didn't run much GPL'd code. It might be time for a more formal policy on stuff like this.
Of course, the GPL'd code owner can always grant GPL exemptions for specific purposes (the GPL itself has a clause saying this and I think the FSF has given a few exemptions in the past), so the surest way to be in good standing is if you can get permission from the owner.
Disclaimer: IANAL and I don't speak for the FSF.
Sweet! (Score:3, Interesting)
Almost open source: BRLCAD (Score:2, Interesting)
If nothing else, maybe the BRLCAD developers can answer some of your questions.
-Sam
Not a big deal at all (Score:1, Interesting)
Source code should usually be unclassified if at all possible. Classified source code is a real hassle. It is usually pretty easy to declass code.
The real issue is this. Once you put a classification onto source code (or anything for that matter), you no longer own it. It becomes property of the US gov. I really don't know how that would work for OSS. It should be pretty easy to avoid in any event. Just keep the dirty words and secret numbers out of your code. You shouldn't be hard-coding anything anyway, let alone classified information.
We use Linux for a military project (Score:1, Interesting)
I work for a company that is a military contractor. Right now we have a contract to build what is, quite frankly, an ass-kickingly cool system -- I won't go into detail, but basically an embedded computer that can move around on the battlefield by firing solid-propellant fueled rockets. (How cool is my job?)
We use Linux for this device -- a decision that has paid for itself about 100 times over. The point is that Linux does not automatically infect everything with GPL. Parts of our system are GPL (and, we've distributed them publically). For example, this device does not use an x86 processor -- it uses a rather obscure processor, but one that does have Linux support. We've submitted kernel patches back to the folks who maintain the port to this processor. We have also distributed a number of kernel modules -- which are now being used by other organizations. These mods were general platform support stuff, not specific to our mission or the application.
What we have not distributed is the source code to the actual application that does the rocket-based mobility, or any of the inter-node radio communications code, etc. That stuff is the bread and butter of what the device actually does, and none of it is GPL. It runs on Linux, and uses glibc, but glibc is LGPL which means that it does not infect apps with GPLness.
Really, in this situation, I think everyone wins. Our company wins, because we developed this app in probably 1/3 the time that it would have taken had we tried using a proprietary system (the app requires kernel modications for various reasons). The Linux community wins, because it has gotten a lot of good code back from us. The the military wins, because they get an excellent product from us. U.S. taxpayers win because the thing costs a hell of a lot less than it would have if we'd used proprietary (costly) tools, which would have required twice as many (costly) engineers in order for it to work correctly.
And, I win, because I get to write Linux code at work. And my code makes things blow up. How cool is that?
-Unfortunately Anonymous.