[Improvement] Revisit Definitions 2.7 - Open Source
shanecoughlan opened this issue · comments
This issue is a formal request to open a discussion around the definitions of open source licenses used in this Specification. This request comes from our colleague at CAICT and is tabled for discussion as we edit the next generation of the standard.
== This is the relevant text ==
2.7 - Open Source Software
Software subject to one or more licenses that meet the Open Source Software Definition published by the Open Source Software Initiative (see www.opensource.org/osd) or the Free Software Definition published by the Free Software Foundation (see www.gnu.org/philosophy/free-sw.html).
== End of relevant text ==
From zhagnjunxia at CAICT:
在Neo4j,Inc.v.PureThink,LLC案中，加州北部法院和联邦第九巡回法院都并不认为OSI定义的开源才是真开源，而是把瑞典许可协议也视为开源许可协议。另外类比5230openchain开源合规规范，里面要解决的很大一部分问题就是非osi认证的许可协议带来的合规问题（当然GPL系列也是主要合规问题来源），所以我认为不能认为osi定义的才是开源许可协议
Machine translation:
In Neo4j, Inc. v. PureThink, LLC, the Northern Court of California and the Ninth Circuit did not consider open source as defined by the OSI to be true open source, but instead considered the Swedish license to be open source. In addition, by analogy with the 5230 open chain open source compliance specification, a large part of the problems to be solved are the compliance problems brought about by non-OSI certified licenses (of course, the GPL series is also the main source of compliance problems). So I don't think OSI defines an open source license.
tl;dr: the market has evolved over time and there are new types of license that are similar to traditional open source. Let's discuss what that means for us, and whether other / expanded definitions may be beneficial.
software subject to one or more licenses that meet the Open Source Definition published by the Open Source Initiative (see opensource.org/osd) or the Free Software Definition published by the Free Software Foundation (see gnu.org/philosophy/free-sw.html) or similar license
Like discussed in the meeting (2022-01-03) "or similar license" IMHO is a good addition to the definition.
Further discussion was contained here:
OpenChain-Project/License-Compliance-Specification#63
Consolidating to this issue (and closing License Compliance Spec Issue 63) because it seems we will conclude with:
- Our current approach appears workable for the market situation
- The one change should be to harmonize between Licensing and Security to this language:
"software subject to one or more licenses that meet the Open Source Definition published by the Open Source Initiative (see opensource.org/osd) or the Free Software Definition published by the Free Software Foundation (see gnu.org/philosophy/free-sw.html) or similar license"
This would involve adding "or similar license" to the Security Assurance Spec.
This was discussed on the monthly call of 2023-02-07. Conclusion was that Security Spec should align with Licensing Spec. Security Spec 2.0 (draft) is being updated to allow this.
OSI is very concerned about this change, which works against the interests of the wider open source community. It is based on an incorrect characterization of the holding of the Neo4J case. The comment stated (machine translated) "In Neo4j, Inc. v. PureThink, LLC, the Northern Court of California and the Ninth Circuit did not consider open source as defined by the OSI to be true open source, but instead considered the Swedish license to be open source." This is exactly backwards. As we explained at the time, the court held that it was false advertising to call software licensed under the "Sweden Software License" (an unapproved combination of the AGPL and the Commons Clause) "open source" software.
The change made here encourages users of OpenChain to make exactly the sort of error which the court found unlawful. We consequently request that you revert this change.
Hi @smaffulli (adding @heliocastro as co-chair of spec, also @Jimmy-ahlberg as OpenChain Chair)
Thanks for providing feedback! Just to clarify, our decision around the security assurance specification was to align with the pre-existing OpenChain ISO/IEC 5230:2020 standard for license compliance, rather than to undertake any expansion of the definitions historically used by the OpenChain Project. The outcome of the calls was to see the lack of alignment between the original standard and the new specification as a bug that happened to be flagged by the discussion point raised by the original contributor to this issue.
Original rationale
While I cannot speak for all parties involved in the original OpenChain ISO/IEC 5230:2020 specification language, @MarkGisi lead the original development in 2015~2020 in a process that received engagement from over 100 contributors, and the outcome reflected a stance that the standard helps set general context but it is up to the commercial parties involved to make their own decisions regarding specific policy.
Potential for new discussion
However, if you would like to propose that the OpenChain Project looks at narrowing the scope of the definition used then I suggest we open another GitHub issue to process that, to ensure we keep discussion focused on one proposal / one issue. My understanding is that you may like to discuss narrowing the definition of open source in OpenChain ISO/IEC 5230:(next generation) from the current language used, and by association the definition also applied in the next generation of the Security Assurance Specification.
Current definition used in the ISO/IEC standard
Here is the current language used in OpenChain ISO/IEC 5230:2020 for open source license compliance:
2.4 - open source
software subject to one or more licenses that meet the Open Source Definition published by the Open Source Initiative (see opensource.org/osd) or the Free Software Definition published by the Free Software Foundation (see gnu.org/philosophy/free-sw.html) or similar license
https://github.com/OpenChain-Project/License-Compliance-Specification/blob/master/Official/en/2.1/openchainspec-2.1.md#24---open-source
What the definition is for
Note that in the context of OpenChain ISO/IEC 5230:2020, open source is defined as software that meets the Open Source Definition or the Free Software Definition or similar license. The parties using the standard(s) may choose to have their compliance program address only licenses listed as open source by OSI, or only licenses listed by FSF, or both, or a wider net of licenses. In practice, many companies probably task their compliance programs with covering "both or more" to ensure the compliance program identifies and applies corporate policy to what the engineers are bringing into the organization or what the engineers propose to distribute outside of the organization.