I was going through the specification more closely and also thinking about how I might explain or how it might read to people being exposed to it for the first time. As a result, I have a few questions or comments:
definition of Supplied Software - is so broad that it would include software provided as open source software by the organization. I don’t think we really intended it to be that way, and references to “Supplied Software” in several of the goals and verification artifacts are really referring to the use of third party FOSS in the distribution of products, not FOSS projects created by the organization. I’d think that FOSS that is created by the organization would be covered under G5, not so much as G2-4 - ??
Should we narrow the definition of Supplied Software as such? (also consider impact on definition of Software Staff)
1.2 re: mandatory training - includes verification artifacts of a method of tracking completion of the course by all Software Staff
- I’d be curious to hear of some example of “methods of tracking” that would be acceptable and realistic. The only thing I can come up with is to have either live training with attendance taken, or recorded training with a tracking mechanism - nothing wrong with either of these, but what if some engineers would prefer to read the material? I can’t think of anyway to track that, but for some people this is a preferred way of learning. Just wondered if anyone had thoughts on that.
1.2 and 1.2.3 - 85% must of all Software Staff must have done training within last 24 mos; can have test to satisfy training - thinking about this realistically, should the OpenChain curriculum team create a template of what the test might be along with standard training materials? The 85% within 24 mos could be a big challenge and really annoying for software staff who know this stuff, so the test could be key, but then we also may want to consider some way to not let the test option get too watered down??
2.1 - first bullet, “assign individual responsible for receiving FOSS compliance inquiries…" I think we should add "from third parties” - it says this in the rationale, but adding this would make it clear from the get-go that this section is dealing with a more public-facing role, versus internal role, which is dealt with later.
- FOSS liaison “must have an email-capalbe communications system” - um, so does this simply mean, I have an email address you can contact me at? This wording is a bit odd and sounds a bit over-complicated
2.1.1 FOSS Liaison function is publicly identified (including an email address).
- remove the word “function”
- is listing this person on the organization’s website enough? Above we reference the LF Open Compliance Directory, which is great, but seems like a narrow example, no? Maybe add a couple other example as to how this might be achieved in the bullets in 2.1?
2.2 FOSS Compliance Role - I think the intent here is this part is dealing more with the internal role - we might want to explicitly state that to better contrast to 2.1
2.2.4 “documented procedure exists that identifies an escalation path for issue resolution” - this starts to sound like the above section and FOSS Liaison role. I’m not entirely sure what escalation this is talking about - internally? I think we need some clarifying language here.
3.1 and 3.2 - it kind of seems like these could be collapsed, such that 3.2.1 becomes 3.1.2 and the description of 3.1 simply includes use case. I’m not sure what is achieved by making these separate, as they are part and parcel of the same function in my eyes.
G5 - I think this should cover code that the organization provides as open source (i.e., it’s own FOSS projects). Given the vast number of FOSS projects that have crappy license information - in terms of easily and clearly identifying both the inbound and outbound license - this would be a great help to everyone downstream as well. We could consider if this might eventually simply reference compliance with the requirements that the CII initiative is coming up with.