Should the U.S. armed forces begin releasing software under an OSI approved open source license rather than as public domain?
This question has generated many pixels’ worth of traffic on the OSI License discuss email list. This post is just a brief summary of a little of the discussion, which has been going on for some weeks and shows no sign of slowing down.
There are currently 80 Open Sourse Initiative-approved open source licenses. It’s nice that the Army (I’m a veteran) wants to not only write software licensed as open source, but OSI-approved open source software. (Go Army!)
But does the Army really need its own special OS license? Should the Air Force have a different one? Will the Navy want a Coastal Combat Open Source License, along with a separate Blue Water Open Source License? That might sound far-fetched, but Mozilla has three separate open source licenses, Microsoft has two, and Canada’s province of Québec also has three. So why shouldn’t the U.S. Department of Defense have a whole slew of open source licenses?
There are five different GPL licenses alone, and I assure you that even the Coast Guard dwarfs the Free Software Foundation in both personnel and resources.
Before we all start laughing uncontrollably, let’s look at a serious consideration:
Most software written by U.S. government agencies is released (if, indeed, it is released at all) under the Creative Commons Zero (CC0) license, which mundanes usually call “public domain.” Except it’s not that simple. What about liability? What if, for example, you got your hands on public domain plans for a fusion reaction explosive device (which sounds much classier than “hydrogen bomb”), you and your friends in the high school science club made one, and it blew up? Who would be liable? Maybe in this case the liability question would only come into play if it didn’t blow up.
Either way, the American legal system is big on fixing blame. And “public domain” doesn’t necessarily protect the author, artist or inventor from liability the way a well-written FOSS license does. Worse, “public domain” and “liability” can both have different meanings under different legal systems.
Creative Commons licenses are not on the OSI list. One reason is that CC licenses tend to be oriented more toward literary works than toward software (or nuclear weapons). And they don’t talk much, if at all, about patents. Software licenses, on the other hand, often do concern themselves with patents. And a lot of US government software may have patented bits and pieces stuck in here and there. This is one justification for the government, if not a specific branch of the military, to have its own software license(s).
In case you feel like reading it, there is a document on GitHub titled The U.S. Army Research Laboratory (ARL) Software Release Process for Unrestricted Public Release. It is exactly what that long title says it is.
If you want to read every comment about this topic on the OSI License discuss email list, go ahead. The archives are public. That’s why I’m not going any farther here. Those who want to go deeper into the question of how many FOSS licenses the American military should have can dive into those archives. The rest of you? Well… I have a little story to tell:
- Once upon a time, there was a useful free software project founded by a Dutch pacifist. He liked the GPL a lot. But he got upset with the U.S. military for a number of reasons and wanted to change the terms under which his project was licensed so that it was under the GPL for everyone except the U.S. military, who weren’t allowed to use it at all. Naturally, that is 100 percent opposed to the practice and spirit of the GPL, which says (in essence) that even if you are a member of the KKK, Jews and black people can still use any GPL software you wrote or to which you have contributed.
In the end, the Dutch pacifist, who is a very good dude, realized that GPL means GPL, and that was that, and that people he didn’t like were free to use his free software same as anyone else — unless he wanted to write his own free software license, which he didn’t.
Obviously, the U.S. Army has no problem with American soldiers using FOSS software it has released. They’d probably even let Marines use it if they asked politely enough. (Yes, that’s a joke.)
But really, should the Army have its own software license? Can’t all the services share one license or at least have a couple of shared licenses for different purposes? And are the military’s software licensing requirements any different from the GSA’s? Or NASA’s? Come to think of it, there’s already a NASA Open Source Agreement that looks like it would be insanely easy to modify for any other government agency to use. As in fill-in-the-blanks-easy.
So why can’t the Army use the NASA Open Source Agreement? Why can’t all government agencies use it — or one of the other 79 existing OSI-approved licenses?
Not long ago, FOSS license proliferation got silly. It seemed that Bob and his brother Willy wanted the OSI to approve “Bob and Willy’s Homebrew Software (and Moonshine) License,” which may be hyperbole but isn’t as far from the truth as I’d like. In fact, at one point the OSI started deapproving licenses hardly anyone used, and asked anyone who did use small-bore specialty licenses to please move to a similar but more widespread one.
Are we once again heading in the direction of a custom FOSS license for every person on the planet?
Can’t we nip this in the bud, starting with the U.S. Department of Defense, where each service has its own camouflage pattern and possibly (for all I know) toothpaste?
It takes time, work, and money to write, edit, and — most of all — approve something in the federal government. As a taxpayer, I’d rather see a few excellent government-approved FOSS licenses than one for every agency and military service.
Robin "Roblimo" Miller
Latest posts by Robin "Roblimo" Miller (see all)
- No, Evil Hackers Aren’t After You - March 17, 2017
- Should the U.S. Army Have Its Own Open Source License? - March 9, 2017
- New Open Source License Compatibility Company Debuts with a Bang - February 23, 2017