This is a huge battle I am in the middle of fighting right now. I am working on a project that is extremely late and we are having all kinds of political pressure put on us by very senior people. Meanwhile their damn IA staff won't approve any of the tools or hardware that I <i>need</i> to help us get the job done.<p>One huge obstacle to open-source anything in DoD is the attitudes of their information assurance professionals. I have been told by numerous DoD IA people that "Open Source is bad because anyone can put anything in it" and "We'd rather have someone to call." I understand the second point -- we honestly don't have the time to run every last issue to ground and it's probably better if we do have some professional support for some of our most important tools. But the first just boggles my mind.<p>But the IA pros are, as a group, schizophrenic, because <i>somehow</i> people are getting things by them anyway. The system I'm working on has Python as a build dependency. The devs are creating reports using Jupyter notebooks.<p>Basically the DoD needs to stop being so damn obstinate about open source.
I love seeing this kind of work done. Not because its going to radically change the underlying technology, but having the air cover a project like this will provide can enable so many government coders who get shut down by their first tier manager who tells them they can't use open source components or can't open source their code. Its might seem silly but just getting the projects out in the open increases their hygiene more then any other single factor.
Speaking as a long time US soldier here is how the military perceives code:<p>* There is no copyright and plagiarism doesn't exist. Internally to the military everything is libre to the most maximum extreme. While people do get credit for their work they have no control over that work and anybody else in the military can use their work without permission.<p>* Service members and employees of the military are not allowed to sue the military. As a result software written by the military has no need to disclaim a warranty or protect itself from other civil actions.<p>* Information Assurance protections are draconian. This is half way valid in that there are good monitoring capabilities and military information operations are constantly under attack like you couldn't imagine. The military gets criminal and script-kiddie attacks just like everybody else, but they also get sophisticated multi-paradigm attacks from nation states. Everything is always locked down all the time. This makes using any open source software really hard unless it is written yourself or you work for some advanced cyber security organization.
No one wants yet another license.<p>Is there an explanation about why Unlicense is not appropriate? Or what it would take for an Unlicense derivative to meet the legal requirements? Could the laws be changed in small ways to allow US Government employees to more fully participate in open source?<p>"The Unlicense is a template for disclaiming copyright monopoly interest in software you've written; in other words, it is a template for dedicating your software to the public domain. It combines a copyright waiver patterned after the very successful public domain SQLite project with the no-warranty statement from the widely-used MIT/X11 license." <a href="http://unlicense.org/" rel="nofollow">http://unlicense.org/</a><p>I like how other commenters have included other successfully US.gov and specifically DoD open source such as BRL-CAD and NSA's Apache Accumulo.
And the DoD Open Source FAQ is interesting and something I haven't seen before: <a href="http://dodcio.defense.gov/Open-Source-Software-FAQ/" rel="nofollow">http://dodcio.defense.gov/Open-Source-Software-FAQ/</a><p>Open source and US.gov participation reminds me of what happened with NASA Nova. It was pretty sad that when OpenStack became relevant in the industry that seemed to cause a panic at NASA and they pulled completely out of OpenStack development. Instead of NASA being to help the project stay focused on being opinionated enough to be generally useful (out of the box), NASA was too afraid about the perception of competing with proprietary commercial interests. (It was nice to see last year, all these years later, that NASA’s Jet Propulsion Laboratory is now a user again having purchased RedHat OpenStack.)
The NSA open sourced what became Apache Accumulo years ago, so that government org has made peace with the copyright issue.<p>The DoD, though, is still trying to feel its way around. There seem to be some lawyers there who are very hard to convince. For years, they've been asking to have various licenses and CLAs modified and we've been telling them no.<p>Here's their latest request for the Apache License 2.1:<p><a href="http://markmail.org/message/eueu4rzlbpe2ugcj" rel="nofollow">http://markmail.org/message/eueu4rzlbpe2ugcj</a>
My only bit of experience working on a DoD-related project was a huge turn-off for me to do any more work in that space in the future because they were resistive about approving any open source software. The development mindset on the project was to re-implement everything (including some tricky algorithms we were using) because it was unreasonable to expect any timely approval, even if it's a feature from the current version of a library that was already approved for an older version. I don't see the reasoning with it, since if anything open source is <i>more</i> secure because you know exactly what is going on inside of it, compared to closed source which may be from a trusted source but you have no idea what it's really doing under the hood.<p>Hopefully this helps push things in the right direction, although I'm not optimistic.
BRL-CAD has been an open source US Department of Defense project for many years. It is architected with the *NIX philosophy of chaining small single purpose tools...The exception that proves the rule? It's own version of Emacs.<p>It highlights a unique aspect of Federal Government developed software: it's public domain rather than licensed based on copyright law. This facilitates reuse but complicates contribution by outside developers.<p><a href="https://brlcad.org/" rel="nofollow">https://brlcad.org/</a><p><a href="https://brlcad.org/d/about" rel="nofollow">https://brlcad.org/d/about</a>
It'll be interesting to see the intersection of this and forge.mil (which was/is the DoD's implementation of SourceForge and associated services). About 5 years ago, there was a fair amount of Open Source Software being ran in DISA for supporting the branches and the software that they wrote, but, there was little open-sourcing of that software, even amongst the individual branches of service (the Marines might write something that the Army could use, but, there were political or other factors that precluded that from happening).
Not only is helping the defense industry downright immoral, it's a waste of talent.<p>Just think back to why you studied computer science or coding. I hope it wasn't to help build spy tools on your friends & families. I hope it wasn't to help engineer destructive weapons that is dropped on innocent civilians.<p>Fuck code.mil, fuck lockheed martin.<p>edit: I've turned down VC money a while ago because I discovered they had previously sold a company to Lockheed Martin affiliate. Downvote all you want but I'm not some spinless piece of shit that will throw out principles and morals for it. I love making money but it's not worth losing your compass or soul over.
It sounds like there's a space for a company that simply validates these issues and supports opensource software, for customers like DOD. I'd expect that such a company could charge each customer quite a bit, and that each customer will want pretty much the same verification of the same libraries, with additional work only needed as new stuff gets requested. Thoughts?
> This can make it hard to attach an open source license to our code.<p>It's not clear to me why this is necessary/desired. Is it because of contribution to existing works protected by copyright or something else?<p>From the OSI's FAQ [1]:<p>> What about software in the "public domain"? Is that Open Source?<p>> There are certain circumstances, such as with U.S. government works ... we think it is accurate to say that such software is effectively open source, or open source for most practical purposes<p>What problem does this license aim to solve?<p>[1] <a href="https://opensource.org/faq#public-domain" rel="nofollow">https://opensource.org/faq#public-domain</a><p>EDIT: ok this comment [2] clears things up a bit. AFAICT It's specifically regarding a mechanism to permit foreign contributors while allowing them to disclaim liability.<p>[2] <a href="https://github.com/deptofdefense/code.mil/issues/14#issuecomment-282310303" rel="nofollow">https://github.com/deptofdefense/code.mil/issues/14#issuecom...</a>
> Usually when someone attaches an open source license to their work, they’re licensing their copyright in that work to others. U.S. Federal government employees generally don’t have copyright under U.S. and some international law for work they create as part of their jobs. In those places, we base our open source license in contract—rather than copyright—law.<p>> ...<p>> When You copy, contribute to, or use this Work, You are agreeing to the terms and conditions in this Agreement and the License.<p>I do not see how this is enforceable, or that it even makes sense, any more than it would make sense for <i>me</i> to take, say, a NASA photo and slap my own terms on it. If it's in the public domain, there's no ownership and no 'or else' to back a contract setting licensing terms.<p>The alternative is that I'm misunderstanding this license, of course. Where am I going wrong?
On one hand it's always cool to see increased adoption of open source, but it strikes me as more than a little subversive for the DoD to adopt an open source methodology. I can't help but see the appropriation of an inherently equitable and socialist means of sharing innovation (FOSS) by a violent, exclusionary, and globally oppressive regime to be a step in a very wrong direction.
I have never worked on code intended for military use. From my layman's point of view, it seems like DoD code would either be "the most boring legacy CMS you can imagine" or "top secret missile guidance AI systems". The former isn't interesting. The latter should probably stay closed-source.<p>Is there any DoD code that is both interesting and suitable for public consumption?
I did a senior research project with a DoD contractor at my university in my last semester. It was a lot of fun, and we got to get exposed to a handful of tools and practices these parties use. I'm very excited at the prospect that maybe some of them will become free. Kudos DoD!
It makes a lot of sense for Gov't funded IP to not have a copyright attached to it. I feel similarly for gov't funded research. Of course, this doesn't include things that should be export controlled for national security reasons.