[Improvement] Revisit Definitions 2.4 - Open Source

[shanecoughlan]

== Relevant Text ==

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

== End ==

An issue has been opened over the Security Assurance Specification has been opened that is also relevant to this specification. See the full text here: https://github.com/OpenChain-Project/Security-Assurance-Specification/issues/20

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.

[winterrocks]

From license compliance PoV it does not really matter much if the component is licensed under an OSI approved Open Source license or some other license and most of the organizations tend to list OSI OSD, FSF, source available, etc. licenses, so IMHO having "or similar license" is a good enough for this definition.

[heliocastro]

"or similar" is a language not usually accepted very well when we are dealing with compliance. It opens a deck of possibilities that undermine the trust over the original licensing intention of source.

We need raise the question where the current deck of licenses were all created around definition of open source software ( be it by OSI, FSF, etc. ) or it was created on their own, and then adjusted to proper fit some of the definition.

In both cases the resulting usage is directed affected by the definition itself, which impact vary from both cases.

So raise the characteristics of OSS have a huge impact on where we perceive licenses usage.

[shanecoughlan]

Please note, this issue is moving to: https://github.com/OpenChain-Project/Security-Assurance-Specification/issues/20

We just discussed on the North America / Europe January 2023 call. The discussion built on previous discussion on North America / Europe January 2023 call.

Outcomes:

1. The current approach in the licensing specification appears to reflect the market reality that companies are dealing with;
2. This is because it sets a baseline for general expectations (OSD or FSD) while allowing for the fact that companies will be dealing with similar or adjacent licenses that are similar but not included in these definitions;
3. The text use there is: "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" (See Section 2.4)
4. It is acknowledged that this means an imperfect match between what everyone will call open source;
5. But those market or individual organization differences fit into the complexity of the actual market.

As such, the main outcome of the discussion was that main consideration for us is the harmonization between the licensing and security specs, and in this context, using the language from the market proved licensing spec (including "or similar license") appears to be the best way forward.

This issue is not being closed immediately to allow for further comments. Comments by next North America / Europe call (Feb 2023) please.

[shanecoughlan]

(please note: leave the comments here: https://github.com/OpenChain-Project/Security-Assurance-Specification/issues/20)

[shanecoughlan]

Um. I told a lie. Closing here to ensure discussions moves to https://github.com/OpenChain-Project/Security-Assurance-Specification/issues/20