-
Notifications
You must be signed in to change notification settings - Fork 146
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GSI license #476
Comments
The GSI Handling Review team is going through open GSI issues. May this issue be closed? |
@RussTreadon-NOAA Does GSI have a license nowadays? |
No, I am not aware of the GSI having a license. I am not aware of any plans for the GSI to obtain or add a license. |
My recommendation would be to fix that. Here is the legal statement (from https://www.synopsys.com/blogs/software-security/unlicensed-open-source-scenarios.html#:~:text=This%20means%20that%20no%20one,permission%20to%20use%20the%20software.):
|
Thank you @climbfuji . Since we no longer have a GSI code manager, let me refer this to others in EMC for their consideration. To help me explain this request to other staff, why does GSI need a license? It's been around for years and is widely used by many. What impact does adding a license have on current users? What impact will it have on future users? Is there a standard template license used by codes accessible from NOAA-EMC? |
I believe (but not 100% sure, not a legal expert) that the Federal Government / DOC / NOAA require any software that is developed to have an open source license that satisfies certain requirements. There's a lot of complicated legal language out there, check https://resources.data.gov/open-licenses. Most EMC software projects have a GNU Lesser General Public License 3.0 (LGPL) license, so I would go with that one unless that is not possible for GSI. For spack-stack, for example, we had to go for a Creative Commons Zero license, since JCSDA cannot do LGPL3 (we can only do Creative Commons Zero and Apache2), but the Federal Government cannot do Apache2. It's complicated ... |
But independent of all of that, having a software license is considered best practice because it gives users and developers clear guidelines on what they are supposed/allowed to do and what not. |
Thank you @climbfuji for patiently explaining this to me. I reached out to EMC staff to see how to move forward in a manner consistent with EMC practice. |
@ShunLiu-NOAA , @CoryMartin-NOAA , and @hu5970 : what's the path forward with this issue? |
@RussTreadon-NOAA I think we need to ask EMC management to confirm what software license we can/should use |
I'll reinitiate this conversation with EMC management. |
We used to have community version of GSI, which is under "GPL-3.0 license". |
This is good to know. Thank you @hu5970 for sharing this information. I'll relay this to EMC management. |
I would be very careful with GPLv3. It's not compatible with software using Apache (such as JEDI etc). Apache projects cannot link to/use GPLv3 software. Look at fv3atm - this is LGPL (no version specified), which works for the federal government and can be used by Apache 2 projects. |
Thank you @climbfuji for your input. |
As far as NOAA or JEDI-folks are concerned, yes. License compatibility is a one-way street. Apache 2 projects like JEDI can link to "lgpl 2.1 or later" software, but not the other way round. |
Work for this issue will be done in RussTreadon-NOAA:feature/license |
Copy global-workflow |
@climbfuji , I followed the lead of global-workflow and copied their GSI PR #745 has been opened to merge the license into |
This project doesn't seem to have a license, can you add the correct one please?
The text was updated successfully, but these errors were encountered: