NASA and open-source software
From the moon landing to the James Webb Space Telescope and many other scientific missions, software is critical for the US National Aeronautics and Space Administration (NASA). Sharing information has also been in the DNA of the space agency from the beginning. As a result, NASA also contributes to and releases open-source software and open data. In a keynote at FOSDEM 2023, Science Data Officer Steve Crawford talked about NASA and open-source software, including the challenges NASA has faced in using open source and the agency's recent initiatives to lower barriers.
Software has always been a big part of NASA's work. Who hasn't seen the photo of computer scientist Margaret Hamilton next to a hard-copy stack of the Apollo software she and her team at MIT produced? The stack of code is as tall as she is. In 2016, the original Apollo 11 Guidance Computer source code for the command and lunar modules was published on GitHub in the public domain. You can even compile the code and run it in a simulator.
Sharing its discoveries has also always been a part of NASA's heritage, Crawford emphasized. He showed section 203(a) of the National Aeronautics and Space Act of 1958, which created NASA. It states that the agency shall "provide for the widest practicable and appropriate dissemination of information concerning its activities and the results thereof".
From open development to spin-offs
In recent years, more and more of this sharing was also in the form of releasing software. For instance, when NASA's drone copter Ingenuity made it first flight on Mars in 2021 as part of the Perseverance mission, it used an open-source flight-control framework, F Prime. NASA's Jet Propulsion Laboratory (JPL) released the framework in 2017 under the Apache 2.0 license. One of the example deployments even runs on the Raspberry Pi. But the NASA mission also used a lot of open-source dependencies. To celebrate Ingenuity's first flight, GitHub recognized the more than 12,000 people who contributed to these dependencies with a badge on their profile.
Another high-profile mission that Crawford talked about is the James Webb Space Telescope, launched in December 2021. It's a collaboration with the European Space Agency (ESA) and the Canadian Space Agency (CSA), and the successor to the Hubble Space Telescope launched in 1990. Its calibration software is developed openly on GitHub, enabling scientists to test their projects. The software library is developed in Python and makes use of Astropy, which handles common astronomy tasks, such as converting between different coordinate systems and reading and writing files with astronomical data. NASA not only uses open-source projects in F Prime and the James Webb Space Telescope's calibration software, but in a lot of other projects too. Some of those projects can be seen in Crawford's slide above.
Crawford listed a lot of other open-source software NASA has released in its long history, calling it "just a small sampling". He also noted that some of these projects became spin-offs. For instance, in 2008 NASA started a project called Project Nebula to standardize its web sites. It then evolved into something that was addressing more general needs. This caused NASA to join forces with Rackspace to create the open-source cloud-computing infrastructure project OpenStack, which is currently managed by the non-profit OpenStack Foundation.
Astronomical challenges
While the previous examples may be some high-profile successes, open source at NASA doesn't come without its challenges. "Civil servants can't release anything copyrightable", Crawford said, referring to the fact that under US copyright law, a work prepared by an officer or employee of the United States Government as part of that person's official duties is in the public domain.
Of course NASA has contributed to many open-source projects, but according to Crawford people often do this "not in their official capacity as NASA employees". In 2003 NASA created a license to enable the release of software by civil servants, the NASA Open Source Agreement. This license has been approved by the Open Source Initiative (OSI), but the Free Software Foundation doesn't consider it a free-software license because it does not allow changes to the code that come from third-party free-software projects. "It isn't widely used in the community and complicates the reuse of NASA software with this license", Crawford said.
Another challenge is NASA's famous bureaucracy, Crawford admitted: "NASA does not always engage well with the open-source community." As an example, he showed how curl's main developer Daniel Stenberg received an email from NASA's Commercial IT Acquisition Team, asking him to supply country of origin information for curl, as well as a list of all "authorized resellers". Stenberg noted the keynote (which he barely missed attending) in a recent blog post.
Lowering barriers for open-source software
There are some initiatives brewing at NASA that should make these challenges a thing of the past, though. In his talk, Crawford presented NASA's Open-Source Science Initiative (OSSI). Its goal is to support scientists to help them integrate open-science principles into the entire research workflow. Just a few weeks before Crawford's talk, NASA's Science Mission Directorate published its new policy on scientific information.
Crawford summarized this policy with "as open as possible, as restricted as necessary, always secure", and he made this more concrete: "Publications should be made openly available with no embargo period, including research data and software. Data should be released with a Creative Commons Zero license, and software with a commonly used permissive license, such as Apache, BSD, or MIT. The new policy also encourages using and contributing to open-source software." Crawford added that NASA's policies will be updated to make it clear that employees can contribute to open-source projects in their official capacity.
This new policy should lower the barriers between open-source software and NASA. Funding for external open-source projects has already improved: in 2021-2022 NASA selected 16 proposals to support 22 different open-source projects financially. This included the Python projects NumPy (used by Astropy), pandas, and scikit-learn, as well as the Julia programming language.
As part of its Open-Source Science Initiative, NASA has started its five-year Transform to Open Science (TOPS) mission. This is a $40-million mission to speed up adoption of open-science practices; it starts with the White House and all major US federal agencies, including NASA, declaring 2023 as the "Year of Open Science". One of NASA's strategic goals with TOPS is to enable five major scientific discoveries through open-science principles, Crawford said.
Keep contributing
Open-source software will clearly play an important role in open science, and was already instrumental in various breakthrough discoveries. When scientists created the first image of a black hole in 2019 from data generated by the Event Horizon Telescope, Dr. Katie Bouman who led the development of the imaging algorithm was explicit about it: "We're deeply grateful to all the open source contributors who made our work possible." This was also the message Crawford ended his talk with: "Keep contributing, building, and sustaining your code." After his "Thank you for your contributions", his words were followed by big applause from a room full of open-source developers.
Index entries for this article | |
---|---|
GuestArticles | Vervloesem, Koen |
Conference | FOSDEM/2023 |
Posted Feb 15, 2023 22:24 UTC (Wed)
by amacater (subscriber, #790)
[Link]
Posted Feb 15, 2023 23:04 UTC (Wed)
by randomguy3 (subscriber, #71063)
[Link] (20 responses)
If NASA employees produce public domain works, then surely that's trivially compatible with pretty much any open source or free software license? And how does the NASA Open Source Agreement factor in, or the later mentions of MIT (etc), if the work is not copyrighted anyway?
Posted Feb 15, 2023 23:43 UTC (Wed)
by dullfire (guest, #111432)
[Link] (6 responses)
It makes sense they could submit patches to BSD/MIT/GPL'd project. Those projects can totally use public domain patches. But I'm pretty sure NASA can't issue any licensing terms for their own software.
Posted Feb 15, 2023 23:50 UTC (Wed)
by randomguy3 (subscriber, #71063)
[Link]
Posted Feb 16, 2023 20:29 UTC (Thu)
by Kluge (subscriber, #2881)
[Link] (4 responses)
However, if that new driver is released under the GPL, you have effectively released the work product of a government employee outside of the public domain.
Posted Feb 16, 2023 21:14 UTC (Thu)
by dullfire (guest, #111432)
[Link] (2 responses)
This misunderstands what copyrights NASA would be eligible for if it was a private organization. A private organization would only have copyright on the patch they wrote. There is unlikely to be any issues with releasing the patch itself as public domain. Of course when applied to the GPL'd driver, the result is GPLd, but NASA isn't authoring the new driver, just the public domain patch.
Posted Feb 16, 2023 21:22 UTC (Thu)
by Kluge (subscriber, #2881)
[Link] (1 responses)
Posted Feb 17, 2023 2:22 UTC (Fri)
by Wol (subscriber, #4433)
[Link]
Wrong. So long as the two licences are compatible, WHAT licence it is is irrelevant.
What matters is that the two different *copyrights* can be distributed together. If the licences are compatible then that's fine.
Okay, it's *discourteous* to use a different licence, but it's not a problem.
Cheers,
Posted Feb 16, 2023 21:45 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link]
It's not a problem at all, in fact GPL explicitly allows this. You can release the driver in public domain, but it can be distributed only under GPL conditions. I.e. you can't make it private and distribute it under a commercial license.
Posted Feb 16, 2023 1:40 UTC (Thu)
by david.a.wheeler (subscriber, #72896)
[Link] (11 responses)
You're right, if there's no copyright AND there's no other constraint (e.g., patents & trademarks), you can insert the no-copyright work into a work with a copyright. So it's not a "problem" in the typical sense, because you CAN legally do it.
The usual objection involves government folks being worried that they'll be re-paying for software the government already paid to develop. OSS licenses - even permissive ones - typically *do* impose some requirements, typically an attribution requirement. If the software has to reveal that it's written from XYZ, a user can find XYZ. You can't impose *any* requirements on a work without copyright, including an attribution requirement. In my opinion, the real solution is that government people should do market research before they buy anything, as already required by regulation. Market research in most cases would quickly find them alternatives. But government employees are typically overworked, and market research is often skimped as a result. That still doesn't really excuse it though; don't pay a lot of money before looking at your alternatives.
The blog post "How to apply an Open Source License to a US Government Work" by Dan Risacher https://risacher.org/jfdi/2014/07/how-to-apply-an-open-so... does an awesome job discussing this. Basically:
There are some weirdnesses in this case. Some organizations (e.g., Apache Software Foundation) require organizations to sign statements involving copyright, and government lawyers get all confused. Historically organizations would make exceptions for the US government, but many foundations aren't familiar with the peculiarities of the US government. There's still a copyright outside the US, so I think they can simply sign with a clean conscience, but I'm not a government lawyer so they don't need to listen to me.
The OSI's position is that "public domain is not a license". That is true in a sense, but misleading. There's a license, it's just that it's granted by the laws of the relevant nation instead of being a separate document. A bigger concern by the OSI - and one that *is* reasonable - is that simply not having a copyright doesn't mean that it's legal to use as OSS, because it could still be covered by patents and/or trademarks. Trademarks are easily dealt with, but patents aren't. If software is covered by patents, then the lack of copyright is irrelevant, and in this case the patent permissions granted by typical OSS licenses don't work (like the implicit ones in MIT and GPL 2.0, or the explicit ones in Apache-2.0 and GPL-3.0).
My personal opinion is that this is mostly a NASA "problem", in the sense that NASA's lawyers think it's a problem even though most of the rest of the US government doesn't think it's a problem to release code as public domain. Many programs have been released without copyright (e.g., expect), and the sky did not fall.
Posted Feb 16, 2023 8:50 UTC (Thu)
by amacater (subscriber, #790)
[Link]
The US is an outlier here, especially if PD applies within the US but the US government could, if it chose, apply copyright to anyone outside the US for software written by its public servants.
Apache and so on want licensing under the Apache licence as much for clarity as for anything else. Due diligence on software license terms will mean that mixing PD with anything else causes a licensing headache. NASA's getting permission to use other licenses is a big win for all here. Much the same argument applies to Crown copyright for UK Government works - that also causes problems for others trying to deal with it - my understanding is that Crown copyright can be waived at the discretion of the originating entity with appropriate sign off and is, essentially, just attribution.
Posted Feb 16, 2023 13:33 UTC (Thu)
by randomguy3 (subscriber, #71063)
[Link]
Posted Feb 16, 2023 13:45 UTC (Thu)
by kleptog (subscriber, #1183)
[Link] (1 responses)
For example, I don't really think attribution needs to be a deal-breaker here.
Posted Feb 17, 2023 1:04 UTC (Fri)
by david.a.wheeler (subscriber, #72896)
[Link]
Posted Feb 16, 2023 14:54 UTC (Thu)
by Karellen (subscriber, #67644)
[Link] (3 responses)
But isn't that the case for any OSS? Can't it be the case for OSS you've written yourself, even unknowingly? If you're not aware that a term is actually a trademark, or because some patent you had no way of knowing exists actually does?
Posted Feb 17, 2023 1:11 UTC (Fri)
by david.a.wheeler (subscriber, #72896)
[Link] (2 responses)
You're right that this doesn't prevent patent trolls, but no licenses could. That would require a change in law. Patent trolls are generally non-practicing entities.
Posted Feb 17, 2023 8:56 UTC (Fri)
by Karellen (subscriber, #67644)
[Link] (1 responses)
Only if you own the patent. I was trying to describe the case where you might unknowingly reimplement someone else's patent. Which is entirely possible, even in the absence of patent trolls. (Unless you believe that non-troll patents are in fact so innovative and groundbreaking that the chances of someone else stumbling on the same solution to a similar problem are truly negligible)
Posted Feb 19, 2023 18:42 UTC (Sun)
by ssmith32 (subscriber, #72404)
[Link]
Posted Feb 16, 2023 23:58 UTC (Thu)
by rfontana (subscriber, #52677)
[Link] (2 responses)
Posted Feb 17, 2023 0:55 UTC (Fri)
by Paf (subscriber, #91811)
[Link]
Posted Feb 17, 2023 1:01 UTC (Fri)
by david.a.wheeler (subscriber, #72896)
[Link]
Posted Feb 16, 2023 23:46 UTC (Thu)
by rfontana (subscriber, #52677)
[Link]
The submitted versions of the revised NOSA (which occurred mostly during the time I was on the OSI board) however had a number of problems which may have come down simply to poor drafting, but I had a concern that the NASA lawyers (who seemed to be primarily patent lawyers by training) were trying to draft the license in such a way that patent licensing obligations would not apply equally to NASA and to NOSA licensees. (NASA has a revenue-generating patent portfolio program.)
Posted Feb 17, 2023 4:49 UTC (Fri)
by gsmecher (subscriber, #100051)
[Link]
Unfortunately, NASA is still asking open-source maintainers to provide country-of-origin information. One of the lists I subscribe to received one of these requests earlier this month.
Posted Mar 12, 2023 19:58 UTC (Sun)
by brlcad (guest, #126839)
[Link]
That said, there's been great strides in understanding since then that 1) US Gov't can hold copyright (e.g., assignment), 2) US Gov't asserts copyright internationally (despite Berne defaults), and 3) there are ample examples of US Gov't applying a copyright-based license to a Gov't work and nobody blinked.
I'm particularly fond of DoD's modern approach (since 2018, see code.mil) in suggesting most OSI-approved licenses may be used, recommending a few (all copyright-based) to keep proliferation and understanding to a minimum, and adding an INTENT file. That file spells out the caveat that some content may be public domain in some situations, and it leaves it at that.
NASA and open-source software
NASA and open-source software
NASA and open-source software
NASA and open-source software
NASA and open-source software
NASA and open-source software
NASA and open-source software
NASA and open-source software
Wol
NASA and open-source software
NASA and open-source software - public domain
1. Just release as public domain.
2. Create a joint work that's partly public domain.
3. Rely on the fact that "no copyright" only applies within the US; copyright still applies outside the US.
NASA and open-source software - public domain
NASA and open-source software - public domain
NASA and open-source software - public domain
NASA and open-source software - public domain
NASA and open-source software - public domain
simply not having a copyright doesn't mean that it's legal to use as OSS, because it could still be covered by patents and/or trademarks.
NASA and open-source software - public domain
NASA and open-source software - public domain
if you contribute to the project, you grant patent uses.
NASA and open-source software - public domain
NASA and open-source software - public domain
NASA and open-source software - public domain
NASA and open-source software - public domain
NASA and open-source software
NASA and open-source software
NASA and open-source software