pFUnit
pFUnit copied to clipboard
Goddard-Fortran-Ecosystem
pFUnit (and fargparse) license
Dear Tom,
I already wrote that I wanted to package pFUnit for the Debian Distribution (and its derivatives like Ubuntu or Mint).
The great thing about this is that they are then seamlessly available by default f.e. on Travis CI and other Continuous Integration platforms, making it much easier to provide the same support for Fortran as for other programming languages in modern ecosystems.
A few months ago I finished the package creation and uploaded it to Debian. Then the package needed to pass a review by our "ftp-master", who check the package for conformance with the Debian Policy. The same happened for the dependencies of pFUnit, namely fArgParse, gFTL, and gFTL-shared. While gFTL and gFTL-shared passed their review and are now in Debian (and in the upcoming Ubuntu 20.10 release), pFUnit and fArgParse were rejected:
From: Joerg Jaspert [email protected] To: Debian Science Team [email protected], Ole Streicher [email protected] Subject: fargparse_0.9.5-1_amd64.changes REJECTED Message-Id: [email protected] Date: Sat, 17 Oct 2020 23:00:09 +0000
Hi Maintainer,
I'm sorry to reject this, but I believe the used license is not a free one.
That is, NASA-1.3 is broken in section 3G, in multiple ways (requires any modificatin to be your own creation, may not violate any existing $longlist).
-- bye Joerg
=== Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns.
I am afraid that Joerg is right here -- the NASA license has a number of drawbacks which make it essentially non-free. Therefore, I would ask you to consider a change of the license? Since gFTL is under Apache-2.0, maybe this is would be a good alternative? Otherwise, there would be probably no way to have these packages in Debian and Ubuntu, which would be a real loss for the ease of testing Fortran packages.
Best regards
Ole
Ah. In theory the NASA lawyers assure me that the NOSA is all-but-equivalent to GPL, but even if true, it is understandable that other orgs would not want to deal with obscure licenses.
The tricky bit for me is that NASA will only grant an Apache license if when the "innovation" is at least partly due to a contractor. When the entire development is by a civil servant they believe that the NOSA is required. Having said that, it should be easy to get an Apache License for pFUnit, as the paperwork already shows contractor contributions. (The NOSA for pFUnit was issued well before Apache 2 even became an option.) fArgParse may be more difficult. That was pretty much a side project I did on my own. I'll check my emails and see if I can identify nontrivial contributions that I can sell to the lawyers.
The change may not be fast, as I'm also now on a staycation. I'll let you know when there is any update.
It looks like the NOSA license creates barriers for contributing to projects under that license, but does it necessarily prevent use of such software standalone or within other projects? I don't fully understand calling NOSA "non free". Is this referring to "free" as "without charge" or "without constraint"?
In any case, after looking through the conda-forge documentation, I don't immediately see a constraint on this license so I could try to submit it there.
Other package managers:
- [x] Homebrew - Requires a license which abide by Debian Free Software Guidelines
- [x] APT - See above, requires DFSG license
If it helps, the NASA lawyers tell me that the NOSA and the GPL are virtually the same, but nonetheless incompatible. :-)
I was also told that the NOSA would probably disappear at some point in the future. NASA will also let me release under Apache 2.0, but only if a contractor (non civil servant) contributed to the code. So for the offending layers, I need to have one of the contractors in my team contribute something nontrivial and then we can get the license changed. Unfortunately, there is no priority for this in my current work, so a bit difficult to make it happen. But it will eventually.
Whether or not any of this impacts creating a distribution, I cannot say. I think the Debian perspective is not so much that the NOSA is unworkable as that it is not worth their time to deal with it. That seems plausible to me. It would not be the first organization that basically said NOSA software is practically useless/unusable simply because the license is obscure.
@tclune
I think the Debian perspective is not so much that the NOSA is unworkable as that it is not worth their time to deal with it.
Just a correction: we are really unable to include pFUnit, if it (and fArgParse) is not Open Source (according to our DFSG).
I spent some time exploring building pFUnit with conda-build. On my Mac with GFortran, it worked out nicely. After doing conda-build to compile pFUnit, I could then conda install pfunit and my CMake configuration for the project using it looks exactly like the examples in the pFUnit repo:
find_package(PFUNIT REQUIRED)
enable_testing()
add_pfunit_ctest(
newtonraphson_utest
TEST_SOURCES test_newtonraphson.pf
LINK_LIBRARIES newtonraphson_fortran
)
I've created a pull request to conda-forge to see how their CI does with the initial configuration. Before I go any further, @tclune what do you think about this? If it works out, I'm happy to maintain the recipe.
And just to be clear, if this were accepted in conda-forge, then users would not have to compile pFUnit in order to use it. The big "if" is that they would have to be on a system that is compatible with the Conda pFUnit. For example, I compiled pFUnit through conda-build with the GFortran included in conda-forge. Then, I tried to compile a project (the newtonraphson library mentioned in add_pfunit_ctest) using the Intel compiler, but this failed. There's probably a workaround for this, but there are also probably other incompatibilities.
After rereading the comments above, it's probably worth considering the license again before any of this proceeds even if conda-forge would somehow let this through.
I finally managed to engage a relevant lawyer last week, and he nominally agreed to issue an Apache 2 license for fArgParse. I was supposed to have received some relevant paperwork, but have not seen anything yet. I also need to request the Apache 2 for pFUnit itself, but that should just be pro forma. So within a few weeks this should be straightened out.
Hi @tclune just checking in here. Still pending the Apache 2.0 license for fArgParse?
I nominally have permission from the NASA lawyer but am still waiting for paperwork from the tech transfer people. Realistically it'll be after the holidays now.
Hello @tclune is there any update on the Apache 2.0 license approval from the NASA legal folks?
Yes - and sorry for the delay. I had some email difficulties (forced to abandon my usual email client as due to an OS upgrade and IT security issues). I had been getting conflicting responses from the NASA lawyers and the tech-transfer people. I reopened the email chain on Monday, and they've escalated my issue to the top lawyer for software. I've given her my availability and hope to have a meeting within the next few days. The email exchanges give me some grounds for optimism, but ...
As a backup plan, I've thought of an enhancement that I could assign to one of the contractors in my shop. They can then file a new technology report and that will allow the Apache license. It just takes longer that way (or at least so I thought!) and it is so artificial. In hindsight, I should have just gone that path.
I'll report back here once I've met with the latest lawyer.
OK - I had a useful if somewhat fraught discussion with the lawyer yesterday. As I feared, I learned of several important processes that I should have been following across a number of projects. But at least there is a path forward.
Basically, I need to get Contributor License Agreements (CLAs)signed by any non-NASA collaborators. I'm not so concerned about doing this retroactively, but I'll need to get at least one of the past contributors to sign so that I can submit a "New Technology Report" (NTR) for fArgParse that involves at least one person that is not a civil servant. Once that NTR is approved, getting the Apache license is a simple email request. (That last bit I've done several times.)
So maybe a few days to get the CLA's from the lawyer and a few more to get a past contributor to sign one. The NTR submission is then 1-2 hours of my "spare" time. I'd guess that we can get the Apache license done in ~3 weeks if things go well.
All right, sounds like there's more clarity in what needs to happen to get the Apache License. Thanks for your efforts!
Let me know if there's any way I can help. For example, I'm happy to make a contribution to fArgParse and sign the CLA. I've already worked through some of the setup to have pFUnit distributed through conda, and while that's not exactly source code it is software infrastructure and could be included in the software repository. I could do the same for fArgParse.
Possibly. If your contrib was easily tied to the rationale for the new license it would be the most beneficial. Then they could just look at the NTR and connect the dots without needing further explanation. Failing that it I think the existing contribs should suffice presuming people are willing to sign.
I received the anticipated (dreaded) email from the lawyer yesterday with the CLAs for my various open source projects. I've already discussed with a relevant developer who says he will sign when I get him the form. So hopefully early next week I can submit the NTR for fArgParse. When that NTR is approved, getting the Apache license should be a matter of days. The good news is that the timeline is now more predictable. The bad news is that I now have to do the legwork.
No - still have not heard from the lawyer approving any of the CLAs. Just back from vacation and will ping the lawyer tomorrow, as I know through backchannels that several have been submitted.
The PR on conda-forge is already closed again: https://github.com/conda-forge/staged-recipes/pull/13282
This is still one last obstacle for a smooth conda/fortran workflow for me. I just want to ping @tclune to keep this issue alive :wink:
Thanks for pointing this out @MuellerSeb. I'll reopen the conda forge pull request when we get the go-ahead from the NASA folks / @tclune.
We missed the anniversary of this issue! Just joking. What is the current status here?
I honestly thought the process was all but complete several months ago. When the prerequisite steps were all done, a mistake in my understanding of how to word the request resulted in a rejection. (I thought the request for Apache would be on the original NTR (new technology report), but it should have gone with the new NTR. My email explained it clearly, but it was rejected due to the misunderstanding. I immediately clarified and submitted a new request. Heard nothing back. Wrote again and got a promise to act. Heard nothing back. Have written two more times and heard nothing back. Will write again today.
This NTR office used to be very proactive. They had a staff turnover and nothing seems to work. They must still be responsive to higher profile projects or proverbial heads would be rolling. Sigh.
I've escalated things to the head of the office. Friend-of-a-friend, so at least I've met him. We'll see if he can shake things loose.
OK - finally heard back from the aforementioned boss. It turns out there is another major step on my end to request the release of the software. This is baffling to me given that the software is already released. Basically have to answer a plethora of questions about IT security, patentability, accessibility, testing plans, etc. I'll try to get that done in the next week, but it is proposal writing month ...
This process is mind blowing. I heard through the US-RSE group that NASA is working on revamping their software licensing, so hopefully that makes this easier for the future. In any case, thanks for keeping up with this @tclune.