Proposed revision of xSDK community package policy M7: open source license
curfman opened this issue · 30 comments
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.
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.
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.
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 :).
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:
- Provide source code for your application
- 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 "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 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).
@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).
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.
That is entirely fair, but I'm not sure xSDK needs to address it other than to encourage packages to use permissive licenses.
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
I agree with Jed on CLAs.
Should xSDK make any recommendations w.r.t. patent grants in licenses (Apache 2.0, LGPLv3, GPLv3)?
Based on these comments and discussion with the xSDK community, the working version of xSDK community package policies (in Google docs) has been revised as below.
Feedback on this proposed change is welcome by further comments on this Github issue and/or in the working version of the xSDK policy document in Google docs.
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.
I suggest a small change in the wording:
an open source license, for example, one of the OSI listed licenses
to
an open source license (defined as being OSI-approved)
The point is to provide clarity about the definition of "open source", to avoid future arguments. OSI is generally accepted as an arbiter of what is considered to be an "open source" license.
There is one potential side impact: this would discourage the use of "custom" open source license that hasn't gone through OSI review. While anyone can submit a license for OSI review, best practice is to use one that is already approved and in wide(r) use as opposed to creating a new one.
Custom licenses are bad. I second the above change.
Also I think “dependent” should be “dependency” in the last sentence above.
Actually here's a proposed rewrite of the entire thing that is much more concise, which you may or may not prefer...
The preferred software license for the xSDK is the BSD 3-Clause license. All new xSDK packages will be required to use this license. Current packages using other licenses are encouraged to relicense, where possible. Required dependencies must use an OSI-approved license which is considered compatible with the BSD 3-Clause for distribution purposes (see https://en.wikipedia.org/wiki/License_compatibility). Non-critical optional dependencies can use any OSI-approved license. RATIONALE: The choice of a permissive open source license is friendlier to use by commercial entities. Note that strong copyleft licenses (e.g. GPL) are not considered compatible with a permissive licenses. Weaker copyleft licenses (e.g. LGPL or GPL v2 with runtime exception) can be considered compatible for distribution purposes. Licenses that restrict commercial use are not acceptable in the xSDK.
Okay, maybe not that much more concise, but I tried.
So is xSDK going to reject new projects if they use MIT, Apache 2, or BSD 2-clause? There is a big difference between the original wording ("BSD style licenses") and this wording.
Yeah, I don't like the specific naming of 3-clause BSD. MIT and 2-clause BSD are basically equivalent and GitHub encourages MIT by putting it in the drop-down menu for a new project (though I personally think 2-clause BSD is more clear).
Apache 2.0 is a good license, but the indemnification clause has complicated implications that FSF and Fontana believe (for different legal reasons) render it incompatible with GPLv2 and related licenses.
The Rust folks use a dual MIT/Apache2 license for this reason, and I believe the LLVM folks are moving to a similar type of license (or maybe they are working something out with FSF -- I had a discussion with @hfinkel about this but forget the details). If I were to relicense I would probably do this to be maximally permissive.
Sorry, I guess I read the original as being more specific. So how about this:
The xSDK collaboration has a strong preference for packages to use permissive OSI-approved licenses (e.g., MIT or BSD 3-Clause). All new packages will be required to use such a license. Current packages using other licenses are encouraged to relicense, where possible. Required dependencies must use an OSI-approved license which is considered compatible with the preferred permissive licenses for distribution purposes (see https://en.wikipedia.org/wiki/License_compatibility). Non-critical optional dependencies can use any OSI-approved license. RATIONALE: The choice of a permissive open source license is friendlier to use by commercial entities. Note that strong copyleft licenses (e.g. GPL) are not considered compatible with a permissive licenses. Weaker copyleft licenses (e.g. LGPL or GPL v2 with runtime exception) can be considered compatible for distribution purposes. Licenses that restrict commercial use are not acceptable in the xSDK.
suggest rewording:
to use permissive OSI-approved licenses
to "to use an OSI-approved, permissive license"
Based on these comments and discussion with the xSDK community, the working version of xSDK community package policies (in Google docs) has been revised as below.
Feedback on this proposed change is welcome by further comments on this Github issue and/or in the working version of the xSDK policy document in Google docs.
Update of proposed new version M7: The xSDK collaboration has a strong preference for packages to use an OSI-approved, permissive open-source license (e.g., MIT or BSD 3-Clause). All new packages will be required to use such a license. Current packages using other licenses are encouraged to relicense, where possible. Required dependencies must use an OSI-approved license that is considered compatible with the preferred permissive licenses for distribution purposes (see https://en.wikipedia.org/wiki/License_compatibility). Non-critical optional dependencies can use any OSI-approved license. RATIONALE: The choice of a permissive open-source license is friendlier to use by commercial entities. Note that strong copyleft licenses (e.g., GPL) are not considered compatible with permissive licenses. Weaker copyleft licenses (e.g., LGPL or GPL v2 with runtime exception) can be considered compatible for xSDK distribution purposes. Licenses that restrict commercial use are not acceptable in the xSDK. In the future, xSDK leadership reserves the right to define a build where packages with weaker copyleft licenses (e.g., LGPL or GPL v2 with runtime exception) are optional, so that users who wish to avoid these restrictions can do so.
We did not vote on this policy at the 8/9/18 xSDK meeting. Questions of why there should be any licensing restrictions for member packages, provided there would be an option to disable non-permissive packages, were discussed at length.
LBNL is currently adding the following text to the standard BSD license -- can someone tell me why that would be considered a bad thing?
Assuming closing this issue was not intentional...
The following is the non-OSI text.
You are under no obligation whatsoever to provide any bug fixes,
patches, or upgrades to the features, functionality or performance of
the source code ("Enhancements") to anyone; however, if you choose to
make your Enhancements available either publicly, or directly to
Lawrence Berkeley National Laboratory or National Renewable Energy
Laboratory, without imposing a separate written license agreement for
such Enhancements, then you hereby grant the following license: a
non-exclusive, royalty-free perpetual license to install, use, modify,
prepare derivative works, incorporate into other computer software,
distribute, and sublicense such enhancements or derivative works
thereof, in binary and source code form.