Proposed revision of xSDK community package policy M7: open source license

[curfman]

xSDK community package policies: https://xsdk.info/policies

working version in Google docs:
https://docs.google.com/document/d/1DCx2Duijb0COESCuxwEEK1j0BPe2cTIJ-AjtJxt3290/edit#heading=h.2hp5zbf0n3o3

In order to address questions that have arisen about open source licensing options, we propose to revise xSDK community policy M7 as below. The new version permits the use of GPLv2 with runtime exception and explains difficulties with copylefting in corporate environments.

Feedback on this proposed change is welcome by comments on this Github issue and/or in the working version of the xSDK policy document in Google docs (see hyperlink above).

A number of people have asked questions about software licensing options generally. Some information is available here:
https://bssw.io/resources/an-introduction-to-software-licensing

Proposed new version M7. The package source code must come with an open source license, for example, one of the OSI listed licenses. It is required that all future xSDK packages be released with permissive BSD style licenses; and it is recommended that current packages, when possible, convert to permissive BSD style licenses. The GPL license is not acceptable, nor is any license (for example, the ParMetis license) that restricts the commercial use of the software. No required dependent package may have a GPL or restricted commercial use license. While GPLv2 with runtime exception and LGPL are permissible xSDK licenses, package owners should be aware that in some corporate environments, any software with copylefting mechanisms is avoided. In the future, xSDK leadership reserves the right to define a build where packages with copylefting licenses are optional, so that users who wish to avoid copylefting restrictions can do so. Noncritical, optional dependent packages may have any license.

Current (old) version M7. The package source code must come with an open source license, for example, one of the OSI listed licenses. It is required that all future xSDK packages be released with permissive BSD style licenses; and it is recommended that current packages, when possible, convert to permissive BSD style licenses. The GPL license is not acceptable, nor is any license (for example, the ParMetis license) that restricts the commercial use of the software. No required dependent package may have a GPL or restricted commercial use license. The Lesser GPL (LGPL) is acceptable for current xSDK packages and required dependent packages but only when necessary. Noncritical, optional dependent packages may have any license.

[curfman]

Minor update to language suggested by David Bernholdt (@bernhold):

Update of proposed new version M7: The package source code must come with an open source license, for example, one of the OSI listed licenses. It is required that all future xSDK packages be released with permissive BSD style licenses; and it is recommended that current packages, when possible, convert to permissive BSD style licenses. The GPL license is not acceptable, nor is any license (for example, the ParMetis license) that restricts the commercial use of the software. No required dependent package may have a GPL or restricted commercial use license. While GPLv2 with runtime exception and LGPL are permissible xSDK licenses, package owners should be aware that in some corporate environments, any software with restrictive (sometimes referred to as copyleft) mechanisms is avoided. In the future, xSDK leadership reserves the right to define a build where packages with restrictive licenses are optional, so that users who wish to avoid these restrictions can do so. Noncritical, optional dependent packages may have any license.

[jedbrown]

It's ParMETIS, not ParMetis.

Note that GPL is in fact an OSI approved license. The GPL does not "restrict commercial use" in the sense of the ParMETIS license.

It can be freely used for educational and
research purposes by non-profit institutions and US government
agencies only. Other organizations are allowed to use ParMETIS
only for evaluation purposes, and any further uses will require prior
approval. The software may not be sold or redistributed without prior
approval. One may make copies of the software for their use provided
that the copies, are not sold or distributed, are used under the same
terms and conditions.

None of these restrictions exist in the text of the GPL. The GPL's copyleft policy implicitly restricts resale via proprietary software because (in classical library usage) it would compel disclosing source code that the vendor wants to keep proprietary. GPL software is alive and well in many in-house and server-side corporate software.

If I were writing this policy, I would forbid ParMETIS-style licenses (they are flagrantly not OSI-approved), but "strongly discourage" GPL and express intent to provide a copyleft-free distribution.

[tgamblin]

The policies seem to say “dependent” in a lot of places where they mean “dependency”. The distinction is important because it completely changes the meaning. If package X depends on Y, X is a dependent of Y, and Y is a dependency of X.

Note that this is consistent with how the IRS uses the term dependent, but it might be confusing because dependents are usually your kids, and edges in family trees are typically drawn based on who begat who, not based on dependency relationships :).

[tgamblin]

Something on the LGPL that has recently come up at LLNL: a lot of projects aren't aware that there are potential issues with LGPL for projects that want to use static linking (which is most of xSDK).

The license says that packages that depend on LGPL packages must make it possible for anyone using their package to relink with a different version of the LGPL library. For dynamically linked libraries, this is easy, but if you statically link, you need to do one of the following when you distribute your application:

1. Provide source code for your application
2. Distribute object files for the application so that someone could relink it if they wanted to.

Industry is kind of allergic to (1), and (2) is a major burden that most projects don't want to deal with. That, in conjunction with the LGPL being kind of convoluted in general, dissuades people from using it.
This problem is more serious in HPC, where static linking is common and even expected on some platforms.

For this reason, MFEM has a NOTICE file that adds a "static linking exception" to their LGPL, but it's still a little shaky because their LGPL LICENSE file still includes the tricky language. Hypre's license does not have this exception, but the developers never intended to make it burdensome to use static libraries when they chose the LGPL.

Some of our teams are considering switching to permissive licenses to avoid this confusion. Alternately, MPL is an OSI-approved, weak copyleft license that doesn't have these issues, so it might be helpful to encourage LGPL projects to switch to MPL if they're opposed to going fully permissive.

[bernhold]

Jed's right. A couple of more general thoughts... You might consider a two-stage policy that says an OSI-approved (Open Source Initiative) license is REQUIRED and a permissive license is ENCOURAGED. However, the ParMETIS license does NOT meet the criteria for an open source license, and would not be approved by OSI, as Jed observes. If it were important to be able to include PerMETIS, they might be encouraged to consider a dual-license approach. They could specify an OSI-approved license for education and research purposes and some other license for other uses. This may or may not allow them to accomplish their goals, but might provide a little more clarity to the rest of the community.

…

On 06/14/2018 11:17 AM, Jed Brown wrote: It's ParMETIS <http://glaros.dtc.umn.edu/gkhome/metis/parmetis/overview>, not ParMetis. Note that GPL is in fact an OSI approved license <https://opensource.org/licenses/category>. The GPL does not "restrict commercial use" in the sense of the ParMETIS license. It can be freely used for educational and research purposes by non-profit institutions and US government agencies only. Other organizations are allowed to use ParMETIS only for evaluation purposes, and any further uses will require prior approval. The software may not be sold or redistributed without prior approval. One may make copies of the software for their use provided that the copies, are not sold or distributed, are used under the same terms and conditions. None of these restrictions exist in the text of the GPL. The GPL's copyleft policy implicitly restricts resale via proprietary software because (in classical library usage) it would compel disclosing source code that the vendor wants to keep proprietary. GPL software is alive and well in many in-house and server-side corporate software. If I were writing this policy, I would forbid ParMETIS-style licenses (they are flagrantly not OSI-approved), but "strongly discourage" GPL and express intent to provide a copyleft-free distribution. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#56 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAaBqQdCeb7C1bKzVmsryTvouiH_w5QNks5t8n6SgaJpZM4UZjPu>.

[jedbrown]

@bernhold "an OSI-approved license for education and research purposes" is not an OSI-approved license. https://opensource.org/faq#commercial

Can Open Source software be used for commercial purposes?

Absolutely. All Open Source software can be used for commercial purpose; the Open Source Definition guarantees this. You can even sell Open Source software.

However, note that commercial is not the same as proprietary. If you receive software under an Open Source license, you can always use that software for commercial purposes, but that doesn't always mean you can place further restrictions on people who receive the software from you. In particular, copyleft-style Open Source licenses require that, in at least some cases, when you distribute the software, you must do so under the same license you received it under.

George should change his toxic license. (He fixed the METIS license a few years ago.) xSDK should not coddle that behavior or facilitate other packages behaving in that way.

[bernhold]

Todd, I did not realize this was an issue. Thanks for mentioning it. But I do wonder about the practical impact. These days, I think most HPC systems actually do support dynamic linking, and I think it is widely used. And I think the vast majority of applications likely to call an xSDK library are also distributed as source, which makes it easy to satisfy the license. Yes, perhaps there are some proprietary codes out there distributed only in binary form AND statically linked. But how many, really? And how important a part of the customer base are they? Maybe others have a different perspective.

…

On 06/14/2018 12:31 PM, Todd Gamblin wrote: Something on the LGPL that has recently come up at LLNL: a lot of projects aren't aware that there are potential issues with LGPL for projects that want to use static linking (which is most of xSDK). The license says that packages that /depend on/ LGPL packages must make it possible for anyone using their package to /relink/ with a different version of the LGPL library. For dynamically linked libraries, this is easy, but if you statically link, you need to do one of the following when you distribute your application: 1. Provide source code for your application 2. Distribute object files for the application so that someone could relink it if they wanted to. Industry is kind of allergic to (1), and (2) is a major burden that most projects don't want to deal with. That, in conjunction with the LGPL being kind of convoluted in general, dissuades people from using it. This problem is more serious in HPC, where static linking is common and even expected on some platforms. For this reason, MFEM has a |NOTICE| file that adds a "static linking exception" to their LGPL, but it's still a little shaky because their LGPL |LICENSE| file still includes the tricky language. Hypre's license does not have this exception, but the developers never intended to make it burdensome to use static libraries when they chose the LGPL. Some of our teams are considering switching to permissive licenses to avoid this confusion. Alternately, MPL <https://opensource.org/licenses/MPL-2.0> is an OSI-approved, weak copyleft license that doesn't have these issues, so it might be helpful to encourage LGPL projects to switch to MPL if they're opposed to going fully permissive. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#56 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAaBqXlmXqt6692KPGLStosAzS5XWoyXks5t8o_VgaJpZM4UZjPu>.

[bernhold]

And I would argue that the dual-licensing might be an approach that both George and xSDK would consider an acceptable compromise. Maybe.

…

On 06/14/2018 12:56 PM, Jed Brown wrote: @bernhold <https://github.com/bernhold> "an OSI-approved license for education and research purposes" is /not/ an OSI-approved license. https://opensource.org/faq#commercial /Can Open Source software be used for commercial purposes?/ Absolutely. All Open Source software can be used for commercial purpose; the Open Source Definition guarantees this. You can even sell Open Source software. However, note that commercial is not the same as proprietary. If you receive software under an Open Source license, you can always use that software for commercial purposes, but that doesn't always mean you can place further restrictions on people who receive the software from you. In particular, copyleft-style Open Source licenses require that, in at least some cases, when you distribute the software, you must do so under the same license you received it under. George should change his toxic license. (He fixed the METIS license a few years ago.) xSDK should not coddle that behavior or facilitate other packages behaving in that way. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#56 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAaBqQr9-Gpjb3uPdGqu_SbumQQFq7kbks5t8pW-gaJpZM4UZjPu>.

[jedbrown]

@bernhold The "dual license" would have to be a legit OSI-approved license -- it cannot have a non-commercial clause. He could dual-license with the weird ParMETIS license or GPL, for example, which might have the effect he wants (but may also see in-house commercial use, for example).

[tgamblin]

@bernhold: the context where this came up was specifically with large industry partners who wanted to use our solvers. My understanding is that they chose another package because of the ramifications of using LGPL in an internal code that may be statically linked. You could argue that they are not distributing this code so it should not be an issue, but I think they did not want to take that risk.

Also note that changing licenses is not trivial. We're currently in discussions with other organizations at LLNL about exactly how we can do this for a few packages, and for large projects with lots of contributors, our IP office's idea of what is required (research, due diligence on EVERY contributor) is very different from what we think should be required (written permission from contributors, maybe via GitHub).

[jedbrown]

@tgamblin @bernhold I'm also unsure how compelling this statically-linked proprietary distribution mode is. Lots of commercial software is dynamically linked, they just bundle the libraries. Abaqus uses a bunch of LGPL software, for example.

[tgamblin]

I think most vendors would ship dynamic libraries. But I also think that, before it gets to that point, they’ll just opt for a permissibly licensed alternative, regardless of technical considerations, and avoid the whole issue. So it’s more fuel on the fire.

Projects are concerned because they’ve found themselves avoided for these reasons. Not because there isn’t a technical solution.

[jedbrown]

That is entirely fair, but I'm not sure xSDK needs to address it other than to encourage packages to use permissive licenses.

[bernhold]

Contributor agreements are one way to make this a little easier. Of course you have to plan in advance. There are many things that can be done with a contributor agreement. One of them would be to give to the project managers (or however it should be defined) the right to relicense he code. That might be constrained by saying it has to be an OSI-approved license or something, to make people more comfortable. On the other hand, you always have to remember that contributor agreements are legal documents, and if you're a lab employee, they almost certainly have to be signed off by your legal people -- you're not authorized. I had a case a while back where we wanted to contribute to an open source project, but their contributor agreement had some terms about patent licensing that DOE considered unacceptable. It took two years to get a signed agreement and that was only because our lawyers decided to go against DOE. And in the mean time, a sponsor terminated a project which was supposed to involve contributing the open source project. So the lesson is be cautious in what you put into a contributor agreement as much as a license agreement.

…

On 06/14/2018 01:04 PM, Todd Gamblin wrote: @bernhold <https://github.com/bernhold>: the context where this came up was specifically with large industry partners who wanted to use our solvers. My understanding is that they chose another package because of the ramifications of using LGPL in an internal code that may be statically linked. You could argue that they are not distributing this code so it should not be an issue, but I think they did not want to take that risk. Also note that changing licenses is not trivial. We're currently in discussions with other organizations at LLNL about exactly how we can do this for a few packages, and for large projects with lots of contributors, our IP office's idea of what is required (research, due diligence on EVERY contributor) is very different from what we think should be required (written permission from contributors, maybe via GitHub). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#56 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAaBqYBbUvv0aMYxWHz_1NVdVH-tA51pks5t8peRgaJpZM4UZjPu>.

[jedbrown]

CLAs are a significant tax and tend to chop off the long tail of contributors, including many that would otherwise stand a chance of becoming active developers thus undermining the long-term sustainability of the software project. Including language that would allow relicensing is further disincentive and creates a power asymmetry in the community. To clarify inbound=outbound, I prefer to use the Developer's Certificate of Origin, either formally via Signed-off-by, or the lightweight version of declaring in CONTRIBUTING.md that "By submitting a pull request, your are affirming the following". See also http://ebb.org/bkuhn/blog/2014/06/09/do-not-need-cla.html