I'm very familiar with the Department of Energy process, and there are a few considerations for every lab in the DOE. TL;DR: The DOE encourages open source sof

I'm very familiar with the Department of Energy process, and there are a few considerations for every lab in the DOE. TL;DR: The DOE encourages open source software, but it isn't default and there's some (low) barriers. In general, though, what you can do with your (non-export-controlled) code consists of (in order of increasing difficulty): 1. Nothing. Keep your code private. If you'd like to stop maintaining code but want to make sure it sticks around, the DOE has a software library, the ESTSC, in Oak Ridge (a division of OSTI). It may also be the case that the entity running the lab wants to claim ownership. 2. Open Source. Due diligence is needed to ensure funding agencies and MOUs are respected. Copyright is typically assigned to the contractor running the lab in question (i.e. for Berkeley lab, -> Copyright goes to UC, SLAC -> Stanford, etc...). Major international collaborations can be a bit tricky because foreign countries have their own rules. I think more work needs to be emphasized on this front going forwards. The DOE also wants to track the popularity of Open Source software, namely downloads. GitHub has met their requirements for reporting. The DOE discourages use of the GPL and similar licenses. The reason, as I understand it, is due to the fact that the Government (i.e. Defense) must be able to use and modify software (and give to contractors, etc...) without falling under any additional burden. I believe the BSD license is preferred most widely across the labs. In some cases, people at labs do release software under GPL. If they didn't get special permission, they are likely violating their lab's contract with the DOE. 3. Commercialize. This is really hard. You have to first perform market research, establish the market, spin off, deal with SBIRs, etc... This is a high barrier. I've been personally working on streamlining the process for (2) with legal for my lab, so that anybody can open source their software very easily, hopefully by just filling out a web page. I'm hoping the recent white house directives help eliminate some of the bureaucracy involved in the process. I've also been trying to reduce fragmentation across the lab. The lab has never offered an official SCM platform, and grad students/postdocs are notoriously bad at keeping important source code in their personal GitHub and then leaving after some time. It should be noted that almost all national lab facilities are effectively ran under contract, so nearly all national lab employees are not actually federal employees. So we do have a slightly different set of rules. Finally, there is already a decent presence on github and bitbucket of labs, in case you are interested: https://github.com/LLNL https://github.com/LLNL https://bitbucket.org/berkeleylab/ https://bitbucket.org/berkeleylab/ https://github.com/slaclab https://github.com/slaclab https://github.com/NERSC https://github.com/NERSC https://github.com/sandialabs https://github.com/sandialabs It should be noted this is an extremely, extremely small slice of the software that drives experiments, projects, and research in the lab. Many times software belongs to the project/research group, so there's likely a project github organization where the code naturally resides. This is sort of a consequence of labs becoming more and more multi-disciplined, i.e. the science missions of labs like SLAC and Fermilab are no longer aligned primarily around their accelerators. OSTI is supposed to maintain an index of that software if it's reasonably important, but it's not really enforced. PS: If someone from USDS/data.gov/18f can and would like to help out with this in any way, I'd be happy to collaborate!