Proposed revision of xSDK community package policy M7: open source license #56
Comments
|
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.
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:
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. For this reason, MFEM has a 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. |
|
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>.
|
|
@bernhold "an OSI-approved license for education and research purposes" is not an OSI-approved license. https://opensource.org/faq#commercial
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. |
|
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>.
|
|
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>.
|
|
@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. |
|
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>.
|
|
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 |
|
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: 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 "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...
|
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.
The text was updated successfully, but these errors were encountered: