Update license

[mnlevy1981]

This PR switches from LGPL (implemented in #90) to Apache 2.0. I will tag the first version of CVMix with the new license as v1.0.0

Following discussion with UCAR's legal counsel, I propose the following path forward: there are 13 listed contributors including myself, and ideally I will hear back from the 12 others that this license change is acceptable. 5 of you are collaborators and I have requested a review of this PR: I will treat an approval as a tacit acceptance of the new license. The other 7 contributors are @qingli411 @gustavo-marques @alperaltuntas @klindsay28 @bolding @xylar @apcraig -- please reply here before 3p Mountain Time on Friday, April 11, with a comment about whether you are okay with this license change or not. A few possible paths forward:

1. I hear from everybody before the April 11th deadline, and everybody accepts the license change. I will merge this PR as soon as possible
2. I do not hear from everybody before the April 11th deadline, but everyone I do hear from accepts the license change. I will merge this PR sometime after the 3p deadline (possibly during the week of the 14th)
3. Somebody replies to say they do not approve of the license change -- this will be handled on a case-by-case basis. I will not apply a license you disapprove of to a library that contains code you wrote, but that leaves a few options that still involve changing the license. (Two that come to mind: we can discuss a different license or we can figure out how to remove your contributions from the code prior to applying the new license.) I'm sure we can come up with other possibilities as well, but hopefully that won't be necessary.

Note that the second item in the list treats "no response" as a vote in favor of the new license. April 11th is ~5 weeks away, which seems like a reasonable amount of time for someone to lodge a complaint. I'm happy to extend the deadline, though, if more time is needed.

[xylar]

@mnlevy1981, I approve. I don't have a deep understanding of the nuances of different licenses but I gather that LGPL has caused headaches for other communities. Do you care to share the reasoning here for changing the license?

[StephenGriffies]

@mnlevy1981, I approve.

[mnlevy1981]

I don't have a deep understanding of the nuances of different licenses but I gather that LGPL has caused headaches for other communities. Do you care to share the reasoning here for changing the license?

@xylar I forgot to link this PR to the issue ticket, but #87 (comment) touches on some of the issue:

the LGPL license we went with is too restrictive to allow collaboration with some industry partners (specifically, NVIDIA corporate policy forbids contributing to repositories bound by LGPLv3 out of concern that it puts them at risk of a lawsuit claiming their proprietary software is now also bound by LGPL)

It also turns out the UCAR's legal counsel has been recommending Apache (or MIT or BSD) instead of LGPL for a few years, and has suggested we move away from LGPL for CESM and its components. Since GFDL is looking into changing the license for MOM6 from LGPL to Apache (also to enable collaboration with industry partners), it seemed like the right move for us as well.

[klindsay28]

I approve of this PR.

[qingli411]

@mnlevy1981, I approve.

[vanroekel]

I approve.

[bolding]

I approve but have to following comments/questions.

A few years ago we added support for using CVMix from within GOTM. The CVMix code was added as a Git submodule and during configuration with CMake CVMix could be compiled in - or not.

1. Does anybody know about the implications on licenses from using Git submodules - where we in principle do not include or distribute code.
2. The change of license will be from now and forward in time? So if we fix the submodule hash to the last one before the license change we should be safe and would not have to remove the GOTM/CVMix integration.

I've written to the main GOTM contributers about the issue - and I'll use comments here in our internal GOTM discussions.

Best regards,
Karsten

[xylar]

@bolding, as I said above, I'm not super expert in licenses so take the following with a grain of salt.

However, my understanding is that the move from LGPL 3.0 to Apache 2.0 should be no problem at all for GOTM. With LGPL, there were restrictions about how the code could be incorporated in closed-source codes. But those should not have affected GOTM because it's open source. With Apache 2.0, even those restrictions are no longer there (seemingly the reason for the switch). Here is a summary from ChatGPT (also to be taken with a grain of salt):

Key Differences Between LGPL-3.0 and Apache 2.0

1. LGPL-3.0 is a weak copyleft license, meaning that while it allows dynamic linking with proprietary software, it still imposes some restrictions (e.g., users must be able to modify the library).
2. Apache 2.0 is a permissive license, meaning it allows anyone to freely use, modify, distribute, and even incorporate the code into proprietary projects without requiring modifications to be open-sourced.

[mnlevy1981]

@bolding -- I'll second everything @xylar said, I would be surprised if CVMix transitioning from LGPL to Apache affects GOTM in any way. It looks like GOTM uses the full GPL, not the [L]esser GPL we are moving away from, and that's a more restrictive license than Apache. Please do keep us posted on what the GOTM developers say!

[bolding]

@mnlevy1981 and @xylar

It is difficult waters we are entering ....

As is now the norm I asked AI - perplexity.ai - the following question:

are there issues with gpl version2 and having external components as git submodules using apache version 2?

and got this reply:

"There are potential issues when combining GPLv2 and Apache 2.0 licensed components, even when using git submodules:

License incompatibility: The GPLv2 and Apache 2.0 licenses are considered incompatible by the Free Software Foundation due to differing patent termination and indemnification provisions38.

Derivative work concerns: While git submodules are essentially links to external repositories, if you distribute your software as a whole (including submodules), it may be considered a derivative work under the GPL5.

Distribution requirements: If you distribute your GPLv2 software with Apache 2.0 components (even as submodules), you must comply with both licenses' requirements, which can be challenging due to their incompatibility13.

Linking restrictions: The GPL is stricter regarding linking, and using Apache 2.0 licensed components might violate the GPL's terms, even if they're in separate submodules1.

To mitigate these issues, consider:

Using GPLv3 instead of GPLv2, as it's compatible with Apache 2.08.

Keeping the components truly separate and not distributing them together.

Seeking alternative components with more permissive licenses.

Consulting with a lawyer specializing in software licenses for your specific case1"

The problem for us updating the GOTM license is that we have no way of tracking potential contributers as you have been able to do here.

[xylar]

@bolding, that sounds tricky indeed and I think that's why a lot of folks are moving away from GPL and variants. They're just too restrictive to be piratical.

[bolding]

@xylar you can argue they are to restrictive - on the other hand that a GPU manufacture should have a saying on the license of software paid by public money also seems to be wrong to me. And my main argument for GPL has always been that it guaranteed that ALL additions is always available to the public (except for a corner case where the is no distribution involved).

[xylar]

@bolding, I see what you're saying and that's certainly the GLP philosophy. It isn't the broader philosophy of the open-source community, at least in my experience on conda-forge.

[apcraig]

Looks good, I approve.

[gustavo-marques]

I approve.

[mnlevy1981]

@bolding I did a little searching on my own (wikipedia instead of GPT), and ended up finding Apache's own take on GPL compatibility. I think that link is probably the main source for GPT's response, as it matches pretty closely. If GOTM updates to GPTv3, we're fine:

The Free Software Foundation considers the Apache License, Version 2.0 to be a free software license, compatible with version 3 of the GPL. The Software Freedom Law Center provides practical advice for developers about including permissively licensed source.

Apache 2 software can therefore be included in GPLv3 projects, because the GPLv3 license accepts our software into GPLv3 works. However, GPLv3 software cannot be included in Apache projects. The licenses are incompatible in one direction only, and it is a result of ASF's licensing philosophy and the GPLv3 authors' interpretation of copyright law.

However, we can't use Apache v2 as-is if GOTM stays with GPLv2:

Despite our best efforts, the FSF has never considered the Apache License to be compatible with GPL version 2, citing the patent termination and indemnification provisions as restrictions not present in the older GPL license. The Apache Software Foundation believes that you should always try to obey the constraints expressed by the copyright holder when redistributing their work.

It does look like there's a work-around: the LLVM project proposed a couple of exceptions that can be added to the Apache license: the first allows distribution of compiled code even if the compiler injects code into the executable (not really applicable to us, since we provide the source code rather than executables), while the second allows the combined code (whatever is licensed under GPLv2 and uses the Apache2 code) to be included in a patent lawsuit [the restriction about not being involved in patent lawsuits is the section that makes Apache incompatible with GPL2]:

---- Exceptions to the Apache 2.0 License: ——

As an exception, if you use this Software to compile your source code and
portions of this Software are embedded into the binary product as a result,
you may redistribute such product without providing attribution as would
otherwise be required by Sections 4(a), 4(b) and 4(d) of the License.

In addition, if you combine or link compiled forms of this Software with
software that is licensed under the GPLv2 (“Combined Software”) and if a
court of competent jurisdiction determines that the patent provision (Section
3), the indemnity provision (Section 9) or other Section of the License
conflicts with the conditions of the GPLv2, you may retroactively and
prospectively choose to deem waived or otherwise exclude such Section(s) of
the License, but only in their entirety and only with respect to the Combined
Software.

---- end ---

I have a little bit of cleanup to do with the License.txt file I added, I realized I was supposed to add copyright information at the bottom... so I can add this addendum as well (and I might need to update the header to make it clear this exception has been added) and then we don't need GOTM to decide between updating their license or sticking with an old version of CVMix

[mnlevy1981]

The UCAR lawyer doesn't like "Copyright CVMix Developers" and wants us to go with

Copyright 2012 - 2025 [institutions]

This is where things get muddy, because his suggestion was "Copyright 2012-2025 UCAR"... I would like it to be clear that this project was born out of an initial collaboration of GFDL, LANL, and NCAR and does not solely belong to UCAR. My understanding is that GFDL can not claim a copyright, since they are a federal lab and everything they do is in the public domain. As federally-funded (but not federally-managed) labs, anything done by NCAR employees technically belongs to UCAR and I believe the copyright for original works out of LANL belong to Triad National Security. On top of that, we have since had contributions from collaborators outside of those three institutions, and I'd really rather not try to figure out what other institutions were involved. So I'm thinking the copyright isn't actually the place for this sort of recognition -- one possibility is to assign the copyright to Triad and UCAR, while also adding an "About" section to the README that acknowledges the history of this project. I will update the copyright in the next commit, and will mull over the wording for the README.

[bolding]

@levy - thanks for looking into this and sharing your findings.
And just to note - I'm not a CVMix developer and I defer from all rights I might have (don't know if that is the right term to use).
Another note - isn't it true that all Linux developers have passed on their rights to Linus Torvalds to avoid ending up in a situation.

[koldunovn]

Thank you very much for addressing this licensing issue, for FESOM and ICON that rely on CVMix, this transition will be very beneficial!

Just checking in: are there any updates or developments on this issue since the last round of comments?

[mnlevy1981]

Just checking in: are there any updates or developments on this issue since the last round of comments?

@koldunovn -- I'm trying to get in touch with one last developer, and then I will merge this in. Given time zone differences, it might not get merged until sometime next week

[ekluzek]

@mnlevy1981 I totally stole some of your text at the top, for the same sort of thing we are doing in mizuRoute. I'm glad you all were able to figure this out and model what we need to do. Thanks!

[mnlevy1981]

@bolding Just to be clear, do you think the LLVM exception proposed here will allow GOTM to continue to use the latest versions of CVMix despite being licensed under GPLv2?