CC0 for software produced by US federal employees

[jhollist]

I have a question about the license requirements for JOSS, in particular the requirement that all submissions be accompanied by an OSI approved license. OSI does not include CC0 on its list (see https://opensource.org/faq#public-domain and https://opensource.org/faq#cc-zero). I do understand the reasons behind this; however, by restricting JOSS submissions to the list of OSI licenses and not explicitly stating how public domain software is to be handled, JOSS has effectively excluded all federal employees from submitting software as we are unable to license our work.

So my question, is it possible to submit to JOSS under CC0 even though it is not OSI approved ?

Thanks for your time and thanks for you work on JOSS. It is a great addition for those developing scientific software!

Some other info/threads on Fed's and Public Domain for software:

• Copyright, Copyleft, and Licensing? WhiteHouse/source-code-policy#258
• https://github.com/18F/open-source-policy/blob/master/policy.md#open-source-licenses
• “Open Source Software” includes public domain software and requires clear international legal status WhiteHouse/source-code-policy#76

[arfon]

Thanks for the question @jhollist. I'm very sympathetic to this request as I realise that CC0 is the only option for many federal employees in the US.

One question I have for you: would there actually be a verbatim copy of the CC0 license in the repository or would there just be some language in the README about releasing this under public domain? I've seen both on GitHub.

/ cc @massonpj @openjournals/joss-editors

[jhollist]

I can only speak to my personal experience with EPA and as an R package developer.

I will list CC0 in DESCRIPTION of the package, but have not (yet) included a separate CC0 LICENSE file. I probably should do that as well. In addition to this, we have some additional "waiver" verbiage that gets added to the README.

Whether or not the verbatim copy is included or other public domain language is used is probably negotiable. We initially went with CC0 as it is the most commonly used dedication for other fed repos (e.g., https://github.com/18F/open-source-policy, https://github.com/USGS-R/streamMetabolizer). If there is another public domain dedication that we could use that is probably OK too, but would required approval from our office of general counsel. Doable, but not quickly.

And thanks for the quick response on this!

[danielskatz]

I'm somewhat opposed to this. Creative Commons recommends against using their licenses to release software. (https://creativecommons.org/faq/#can-i-apply-a-creative-commons-license-to-software)

[arfon]

I'm somewhat opposed to this. Creative Commons recommends against using their licenses to release software.

I have the same reservation but I'm concerned that by sticking to this line then we exclude software produced by anyone subject to/following the federal policy on software (e.g. https://github.com/18F/open-source-policy/blob/master/policy.md#open-source-licenses). It seems unrealistic for JOSS to affect these policies?

[jhollist]

@danielskatz agreed that the CC licenses should not be used, but as I understand it (i.e. I am not a lawyer!) CC0 is not a license. Further, on the link you provide they have the following statement:

Also, the CC0 Public Domain Dedication is GPL-compatible and acceptable for software. For details, see the relevant CC0 FAQ entry.

Which suggests that, from the standpoint of CC, we are good.

[danielskatz]

@arfon, while 18F is part of the US government, they do not set the US government's rules. For example, see https://code.nasa.gov/#/guide which says code released by NASA is released under the NASA Open Source Agreement (NOSA), which is an OSI-approved license (https://opensource.org/licenses/NASA-1.3)

@jhollist, I agree that CC0 is formally acceptable for software, but it's still not recommended. I'm surprised that EPA has given up it's authority in favor of 18F (GSA). I don't think it has any obligation to do this, but I guess I'm not going fight about it.

Maybe the real question here is what the result of this discussion should be. If it's that we accept CC0-licensed software when it comes from some US government agencies, fine. What I really don't want to do is to set a policy that CC0-licensed software is always acceptable.

[jhollist]

There is a lot of variability in interpretation of the rules and that is left up to the individual agencies. NASA has a much stronger history of open source work than does EPA. EPA hasn't ceded authority per se, just looking for models to follow. The public domain model seems to be more prevalent across the agencies and is what EPA has approved. As such the only thing I am allowed to use is CC0.

So, I do agree with your take on the real question. Allowing CC0 on software that cannot otherwise be released under an OSI approved license (i.e. submissions from most Feds) would be a great solution.

[jhollist]

@danielskatz you also piqued my interest on the NOSA and I did a bit of digging (thanks to @chrismattmann) and a lot of this comes down to different authorities. NASA centers have software release authority. EPA (and presumably 18F, USGS, etc.) do not have this authority and that explains (some) of the variation in what is and isn't allowed wrt licensing software.

[danielskatz]

interesting, thanks.

[arfon]

Allowing CC0 on software that cannot otherwise be released under an OSI approved license (i.e. submissions from most Feds) would be a great solution.

That's what I'd like to support here if we can under a very limited set of circumstances.

What I really don't want to do is to set a policy that CC0-licensed software is always acceptable.

💯 totally agree.

[jhollist]

It appears there is consensus on allowing CC0 in cases where an OSI approved license is not possible. What are the next steps? Can I do anything to help out?

Thanks again for the conversation on this and thanks for all your work on JOSS!

[arfon]

It appears there is consensus on allowing CC0 in cases where an OSI approved license is not possible. What are the next steps? Can I do anything to help out?

I'd like to get a 👍 from @massonpj before proceeding here. Next steps would be to update the author/reviewer guidelines to state that CC0 is acceptable for a very limited number of scenarios (such as this one)

[jhollist]

Sounds good!

[massonpj]

Sorry for not replying sooner, but I wanted to get some more info from a few other folks.

I have a few thoughts,

First, I don't think there is actually a prohibition on assigning an OSI approved license to software developed by the US gov. The reference to 18F in this thread is a notification that all work of the US Government is owned by the public, and then 18F adds their own policy of attaching a CC0 license, so I expect that their policy is not relevant to any other federal agency/department.

I would look at section 5.1 Pilot Program of the Federal Source Code Policy, "Publication of Custom-Developed Code as OSS" which states, "Each agency shall release as OSS [open source software] at least 20 percent of its new custom-developed code." (https://sourcecode.cio.gov/OSS/) The policy goes on to define custom code: "Custom-developed code also includes code developed by agency employees as part of their official duties." My interpretation here would be that @jhollist can indeed attach an OSI approved license.

Secondly, public domain software is 1. not a license, 2. does not address patent claims and other software specific issues common to licensing, and 3. does not ensure software freedom. Even a permissive license like the MIT requires that the originally licensed work carry forward the MIT license (ensuring software freedom)--as you know this is not the case with public domain. Anyone can take public domain code and attach their own license, thus negating the software freedom intended by the original author. As the journal is, The Journal of "Open Source Software," I wouldn't expect that public domain software would be included.

Third, I go back to a previous point. If an employee of the US Federal Government releases his/her work to the Public Domain, then as a U.S. citizen, he/she can take that work and assign any license he/she wants, then submit it to JOSS.

Finally, as a practical matter, the OSI works daily to address ambiguity and outright fraud from unscrupulous--or even just uninformed--actors related to "fauxpen source software" and "open-washing." We work to create a clear line exactly around these issues with the general public, business, gov. etc. and we especially wouldn't want to see any practices within an Affiliate Member that adds to the confusion or blurs the lines of what constitutes open source software licenses.

I would hope that all submissions to JOSS carry an OSI approved license.

Pat (the downer) Masson

[jhollist]

@massonpj Thanks for detailed response! Clears up a lot of things for me.

Couple of thoughts.

1. Seems we (feds) are in the midst of a lot of change wrt open source and what we had been doing may not be what we will be doing in the near future. I was excited to see the new Federal Source Code Policy and expect it to clear things up within the agencies. They do have a section on licensing (https://sourcecode.cio.gov/Implementation/#licensing) but unfortunately it those details have not yet been laid out.
2. Your points about public domain not requiring that future work also be public domain is something I did not realize. I understand that this is really the deal breaker and that public domain software is NOT open source software because of that. As such, I agree that CC0 shouldn't be allowed for JOSS.
3. For the time being, this means I won't be able to submit my work as I need to get some clarification on what we can do wrt licensing. While it may be legal for me to submit my work with an OSI license and I would retain copyright, that might not go over well with the powers that be in my agency. I have started some of the leg work on this on a related issue so I'll see where that goes.

Thanks again for taking the time to respond.

Lastly, while the result of this discussion is a downer, I am pretty sure you don't need to shoulder the burden for that!

[danielskatz]

Thanks much - This is a great explanation of some of the things I was thinking but without proper logic or justification, and it adds more good points as well.

Dan

On Oct 8, 2016, at 5:34 AM, Patrick Masson [email protected] wrote:

Sorry for not replying sooner, but I wanted to get some more info from a few other folks.

I have a few thoughts,

First, I don't there is actually a prohibition on assigning an OSI approved license to software developed by the US gov. The reference to 18F in this thread is a notification that all work of the US Government is owned by the public, and then 18F adds their own policy of attaching a CC0 license, so I expect that their policy is not relevant to any other federal agency/department.

I would look at section 5.1 Pilot Program of the Federal Source Code Policy, "Publication of Custom-Developed Code as OSS" which states, "Each agency shall release as OSS [open source software] at least 20 percent of its new custom-developed code." (https://sourcecode.cio.gov/OSS/ https://sourcecode.cio.gov/OSS/) The policy goes on to define custom code: "Custom-developed code also includes code developed by agency employees as part of their official duties." My interpretation here would be that @jhollist https://github.com/jhollist can indeed attach an OSI approved license.

Secondly, public domain software is 1. not a license, 2. does not address patent claims and other software specific issues common to licensing, and 3. does not ensure software freedom. Even a permissive license like the MIT requires that the originally licensed work carry forward the MIT license (ensuring software freedom)--as you know this is not the case with public domain. Anyone can take public domain code and attach their own license, thus negating the software freedom intended by the original author. As the journal is, The Journal of "Open Source Software," I wouldn't expect that public domain software would be included.

Third, I go back to a previous point. If an employee of the US Federal Government releases his/her work to the Public Domain, then as a U.S. citizen, he/she can take that work and assign any license he/she wants, then submit it to JOSS.

Finally, as a practical matter, the OSI works daily to address ambiguity and outright fraud from unscrupulous--or even just uninformed--actors related to "fauxpen source software" and "open-washing." We work to create a clear line exactly around these issues with the general public, business, gove. etc. and we especially wouldn't want to see any practices within an Affiliate Member that adds to the confusion or blurs the lines of what constitutes open source software licenses.

I would hope that all submissions to JOSS carry an OSI approved license.

Pat (the downer) Masson

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub #179 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/ACx2NWz2PF0xgpAmKIXXs20FAVVTMTKoks5qxp6sgaJpZM4KMtkQ.

Daniel S. Katz
Assistant Director for Scientific Software and Applications, NCSA
Research Associate Professor, ECE
Research Associate Professor, iSchool
University of Illinois
(217) 244-8000
[email protected] mailto:[email protected] or [email protected] mailto:[email protected]
http://danielskatz.org http://danielskatz.org/

[arfon]

Sorry for not replying sooner, but I wanted to get some more info from a few other folks.

@massonpj thank you so much for these insights. Your feedback and insights here are very valuable.

@jhollist - I'm going to close this issue as I believe we've agreed that CC0 is not appropriate for JOSS. Please update this thread (you can still comment on closed issues) with any further insights you might have based on your discussions with legal folks at your institution.

[jhollist]

I have been following up within EPA on this and have an additional question.

Would dual-licensing the submission as CC0 and MIT (for example) be allowed? @arfon I know we talked about this off line a while back. I am getting some hints that this might be OK on our end.

[arfon]

Would dual-licensing the submission as CC0 and MIT (for example) be allowed? @arfon I know we talked about this off line a while back. I am getting some hints that this might be OK on our end.

Yes, I believe that would be acceptable to JOSS.

[ckaran]

I think there may be some issues here that need to be addressed further. As background, I am the person at the US Army Research Laboratory (ARL) responsible for developing ARL's Open Source Policy. I'm also one of the many people trying to implement the Federal Source Code Policy, and as such regularly attend the meetings run by the authors of the policy, ironing out issues that come up. Here is what I've learned in developing ARL's policy, and in attending various meetings:

1. Different counsel have different opinions, but some believe that licenses that depend on copyright could be attacked in court and declared unenforceable on public domain software. The problem with this is one of severability; most OSI-approved Open Source licenses do not address it, which means that if a clause that depends on copyright is declared invalid (because US Government software is in the public domain), then the entire license might be declared unenforceable. Since licenses usually address liability, warranty, IP, and other issues, this could lead to significant problems and litigation.
2. Copyright attaches to works as they are produced, and can't be attached to it afterwards. That means that dual licensing may fail because the original work is in the public domain; only the portion produced by a Government employee in their own time and on their own dime can have copyright attached. Once again, this means that a smart lawyer could argue that the license is unenforceable on the work as a whole, leading to the same issues as above.
3. Moreover, depending on the contract the employee signed, work that is similar in nature to what the employee is paid to do by the Government might automatically be Government work, even if the employee is doing it on their own time and dime (this prevents an employee from working on a project at work for 10 years, and then claiming ownership of it because they did some of the work at home).
4. ARL deals with IP rights in a two-step process. First, all external contributors to a project must sign a contributor license agreement (CLA) before their work is accepted into a project. This ensures that the rights are licensed to the Government such that the work can be redistributed. Second, all internal contributors have already assigned their rights in the work to the Government, and the Government is waiving any patent rights when redistributing the software (the ARL logo is a Federally registered trademark, and those rights are reserved). There is no copyright on internal works, so those are already taken care of. So once ARL's code is put out under CC0, we're pretty sure all the various IP rights have been handled.

Another thing to consider for dual licensing under the scheme proposed by @massonpj is the 'sniff-test'; if you were on a jury and found out that a work was 99.9% public domain, but licensed under a copyright-dependent license, wouldn't you feel like someone was trying to pull something over on you? I personally want Open Source to be ethically above reproach, so I'd like to avoid any shenanigans.

That said, I'm still trying to get an answer out of the White House lawyers to see if they will approve our using any of the OSI-approved licenses. They are still looking into it, but various issues surrounding copyright (including those induced by severability) are not making them happy.

[massonpj]

Thanks @ckaran for the insights, that's definitely great info.

For me, the issue is the use of the label "open source." The list of OSI approved licenses are an internationally recognized standard. Unfortunately we're seeing more and more instances where software is called "open source" but carries a license that actually violates the Open Source Definition and would never be approved as an open source software license. One relevant example (considering the Army thread here), is Qabel, which describes itself as "an application-spanning and open-source service platform," however, "The QaPL does not satisfy the standards of those 'Open Source' or 'Free Software' licenses, due to non-commercialization and non-military clauses."

As CC0 and public domain are not open source software licenses approved by the OSI (although the OSI does acknowledge public domain "is effectively open source, or open source for most practical purposes"), and the open source label is often abused (leading to ambiguity), and my scheme doesn't pass the snif-test (which BTW I agree is not the most elegant work-around), I am not sure how else one can be above reproach and still ensure the integrity of open source software by allowing the use of non-open source software licenses?

That being said, we too at the OSI are working with various federal agencies to resolve this issue. I'd love to chat with you, @ckaran, to see if we might be able to work together. I think we're both working toward the same goal.

Thanks again for educating me.

[labarba]

How about a solution where we extend the eligibility for submissions—something like "JOSS also accepts public-domain software, in addition to open-source software (in the OSI sense)" ?

[pjotrp]

OSS licenses are much needed in science. Watering down the requirement will hurt science, hurt research and hurt the track record of individual researchers.

We have no need for publishing papers that do not carry an appropriate license.

Agencies that do not recognize this have their own agenda and JOSS should not support them in any way. Note that we are pragmatic. For instance we agreed that we can accept Matlab (which is closed) based papers as long as the published software carries a FOSS license.

As an editor it is where I draw the line: non-FOSS is not acceptable.

A dual-license can be OK, though we should encourage people not to add a public domain option as the implications may be similar to a pure public domain position.

[arfon]

How about a solution where we extend the eligibility for submissions—something like "JOSS also accepts public-domain software, in addition to open-source software (in the OSI sense)" ?

I'm sympathetic to this idea but I think in this case we would need to rename the journal. Being an OSI affiliate means that we have additional responsibilities in 'protecting' the open source definition which I take personally take very seriously.

[ckaran]

@massonpj I'm on both the OSI License Review and License Discuss mailing lists; I was the one pushing the ARL Open Source License (ARL OSL) a while back. I would love to work with OSI to get this resolved in a clean manner that would work for everyone; I understand the concerns that @pjotrp and @arfon have brought up, but as a US Government employee, my hands are currently tied. US Government works generally don't have copyright attached. What happens if I put my work out under a license like the ASL 2.0, and it's declared invalid in court because the US Government doesn't have copyright? Not only does this affect the US Government, it also affects anyone that has forked and included the work in their own projects. Can you imagine the chaos if everyone that included such code in their own projects was suddenly required to strip that code out? Or worse, they start getting sued because the patent clause was thrown out (something similar to the Rambus situation)? Even if the downstream users and people that incorporated the code in good faith aren't sued, it could create a great deal of needless FUD.

I want the license matters to be squeaky-clean and above board. That was why I was pushing the ARL OSL before; with some tweaking by both OSI and Government lawyers, it should survive attempts to break it on copyright grounds, while also meeting all Open Source principles. Without it, or something like it, the Government is currently going to be stuck using CC0 for large amounts of code.

So I beg of you, please take a good long look at how to license code that is in the public domain in an OSI-approved manner. Government attempts at Open Source need it.

[jhollist]

I agree with @ckaran that an OSI approved license for public domain software would be a boon to a lot of us in Gov. We want to contribute to open source projects but have decades (centuries?) of precedence that loom large.

Also, it really isn't that agencies have their own agendas (well, they do, but not necessarily in this regard), but more that the contributions to open source, with approved open source licenses, is a very new thing for the agencies to consider.

And lastly, @massonpj if you are looking for additional federal contacts, please don't hesitate to contact me. I may not be the best at US EPA wrt to this, but I can't certainly get you in touch with those that are.

[massonpj]

@ckaran I hear you on all points, and so you know, we are working with multiple US agencies who are all expressing the same desires and same concerns / constraints. I am not at even going to try and offer a solution to the broad and complex issues facing the US government and public domain v open source--I am simply too ignorant of all the factors affecting you all, and not qualified from a legal standpoint to make recommendations.

I think the OSI's role here should be to coordinate a broader and more inclusive discussion from the multiple stakeholders. I'm going to "make a list" (that's very government-like) of those here and with whom we are speaking to see if we can get the conversation going (@jhollist, you're on it!)

I will continue however to represent the years of work of the OSI and open source software community have committed to creating awareness and acceptance of the "open source software" label through very specific criteria in licensing. There are indeed licenses that have not been reviewed by the OSI that are OSD complaint, and of course the is PD and CC0. But open source software means something, and so does the due diligence invested by those who review and certify each approved license, and we need to protect that or else jeopardize what we've all accomplished.</LectureThatEveryoneAlreadyKnows&Appreciates>

[ckaran]

@massonpj Can you ask those agencies if they are a part of the Federal process at code.gov? If they aren't, then they really should be. You have my email address; pass it along to anyone that could use it, and I'll aim them at the right people.

And as a personal note, I completely agree with your lecture. I personally want to make sure that all Government works that are open source are also Open Source, and can be incorporated into other works without any difficulty. I think it would be a complete waste of everyone's time if the Government put its code out there for others to use, but they couldn't use it due to licensing issues.

[nuest]

This might be relevant for some people here:

"@statedept Publishes Open Licensing “Playbook” for Federal Agencies" via OSI Affiliate @creativecommons" https://twitter.com/OpenSourceOrg/status/822866604664979457?s=09

https://creativecommons.org/2017/01/20/state-department-publishes-open-licensing-playbook-federal-agencies/

[ckaran]

@nuest The playbook is interesting, but it seems to sidestep the essential question; can works that don't have copyright use licenses that rely on copyright without causing legal headaches down the road? I don't see an answer there, only comments that personnel should use an appropriate license.

[jeffhammond]

While this is closed, since it has not been mentioned already, 17 U.S. Code §105 was cited by a federal employee to explain why their software was not subject to copyright in the United States. The latter caveat may be relevant to a journal that is read internationally.

[ckaran]

Unfortunately, we're still only allowed to use CC0 for Government works that don't have copyright attached... I know that @mattbailey0 is working on the issues, but they are complex and are taking time to sort out.

[shawoods]

@ckaran and others please check out http://Code.mil. The Defense Digital Service is experimenting with a way to use open source licenses for Government written code even without U.S. copyright protections. We would really appreciate your feedback--the good, bad, and ugly;-) @ckaran It would be great for you to email [email protected] so we can get connected. We saw what ARL did -- super informative documentation!

[ckaran]

@shawoods I'll email you directly, and I'll read over your license. Thank you!

[jhollist]

All, just circling back to this as I found out today that guidance has finally been released for the Open Source Pilot of the Federal Source Code Policy. Details are https://code.gov/#/policy-guide/docs/open-source/licensing and it is good news! Don't know what role you played in this, @massonpj but if you did THANKS! Word I have gotten from elsewhere at EPA is that we will be following this. Just need to wait and see what specific licenses EPA is comfortable with.

One step closer to submitting to JOSS!

[ckaran]

@jhollist The guidelines still don't answer the question about whether or not we're allowed to use OSI-approved licenses on software that doesn't have copyright attached. I've emailed the appropriate people, I'm hoping we'll get an answer back.

[jhollist]

Sorry to comment on an old, dead issue, but wanted to provide one last follow up.

After many years, many meetings, many emails, we finally have run the gauntlet and software developed by EPA employees can be released using the MIT License. Other licenses (Apache 2.0, GPL 3, and a few others) are undergoing review by our Office of General Counsel now so the list of approved licenses for us may expand.

Hopefully this closes the loop. Plan to submit a few things to JOSS in the coming months!

[arfon]

Hopefully this closes the loop. Plan to submit a few things to JOSS in the coming months!

🎉 great news!

[massonpj]

After many years, many meetings, many emails, we finally have run the gauntlet and software developed by EPA employees can be released using the MIT License.

@jhollist, great news. Is there any public information on this? I expect the OSI would love to point this information/progress. Thank you for sharing.

[jhollist]

@massonpj let me ask around to see if anything has been made public (other than my comment on this issue!)

[ckaran]

@jhollist How did you guys get around the copyright issues? We still haven't gotten around them yet.

[jhollist]

@ckaran In short, we asked our lawyers to review and they approved. As I am merely an ecologist who writes R code, I am not sure about the details of the discussion around that. Sorry!

[ckaran]

Got it, our lawyers reviewed it and said that it could be can of worms, so use CC0 instead.

[jhollist]

I think it is tricky either way, hence the differing opinions!

[ckaran]

@jhollist ARL is standing up a task force to improve its current policy/procedures/support tools so that we can do OSS in a better way. Would EPA be interested in being a part of that task force? The plan is to put together what will effectively be an Open Source GOTS package on code.gov that any government agency can then download and tweak to their own needs. We'd like to get as many agencies involved as we can, so that we all have consistent procedures on how to do OSS.

[jhollist]

@ckaran certainly worth talking about. We can take this part of the discussion off the issue since getting a bit out of scope of the original post. Feel free to email me at hollister.jeff at epa.gov and we chat more there.

[jedbrown]

There is a lot of good material in this report.
https://www.nap.edu/catalog/25217/open-source-software-policy-options-for-nasa-earth-and-space-sciences

[ckaran]

@jhollist Will do, I'll email you shortly.

@jedbrown Thank you for that link! We're in contact with the team at NASA that developed their OSS policy, and they have their own headaches as well (the laws are different for NASA than for DOD). I'm hoping that they'll come into our task force as well, maybe we can come up with something consistent.

[labarba]

I'm one of the co-authors of the report linked by @jedbrown.

@ckaran : What do you mean "the laws are different for NASA than for DOD"?

[ckaran]

@labarba Well, there's the Space Act for one. The lawyers I've talked to said that there are others. I know that there are differences in the FAR and DFAR, and although those aren't laws, they point to differences. If it's really important to you, I can ask the lawyers and see if I can come up with a better list.

[labarba]

The reason I asked is that in our research for the National Academies report, we uncovered a lot of misconceptions about the legal issues surrounding open source software written by federal employees, and some of these included assertions as to the special status of NASA that turned out to be wrong.

For example, some thought that NASA-produced works had special status in contrast with other federal agencies, because NASA centers have software release authority. See:

NASA - Software Release Process
September 28, 2011
https://www.nasa.gov/centers/johnson/techtransfer/technology/software-release.html

Release of NASA Software - Revalidated w/change 1
NPR 2210.1C, Effective Date: August 11, 2010
https://nodis3.gsfc.nasa.gov/displayDir.cfm?Internal_ID=N_PR_2210_001C_&page_name=main

But NASA employees are really in the same boat as all federal employees.

https://invention.nasa.gov/evaluation-protection.php

Can NASA software be copyrighted?
Copyright protection is not available in the U.S. for software developed solely by federal government employees in the scope of their employment, although foreign copyright may be available. Copyright protection may be available in the U.S. for software that is co-developed with federal government employee(s) along with non-federal government employee(s). NASA can also obtain copyright in software from third parties via an assignment or license.

The point is that, legally, there's no prohibition on the ability to release software for federal agencies, and one cannot argue that because NASA is specifically granted release authority, it implies that other agencies must have specific authority in order to release it.

Another point is that copyright is not harmonized around the world. Works by US government employees in the course of their duties are not protected by copyright in the US. An open-source license on a US government work applies where there is copyright (i.e., outside the US) and signals the desired use and distribution modes in the US (e.g., presentation using the work without attribution would be illegal outside the US yet legal but simply rude within the US).

[ckaran]

OK, we're on the same page on all those points then. The issues that I'm worried about are in my earlier post, which, as far as I know, are still issues. They are part of what I'm hoping our task force can figure out, and for those portions that we need higher authorities to deal with, I'm hoping that the task force can develop a clean, clear explanation of the problems, and the recommended solutions. If that includes changing US law so that US government works do have copyright attached, then that might be a way to go. If nothing else, it would 'level the playing field'.

[jhollist]

@massonpj let me ask around to see if anything has been made public (other than my comment on this issue!)

Nothing has been made public yet, but we've been given the go ahead to use CC0, MIT, GPL 3, LGPL 2.1, and Apache 2 so it is public in that sense. If and when something is more public, I'll follow up here.