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.
Jeremiah Foster <jeremiah.foster@...>
On Sun, Jun 12, 2016 at 9:48 PM, J Lovejoy <opensource@...> wrote:
This is an important issue where I work for example, we often have to separate software created on dependencies from upstream versus work created in-house. Each can have a different license strategy so the ability to clearly define what is "supplied software" and what is not is useful for any compliance officer at our office.
In distributed software development teams flung across multiple time zones, we rely on things like recorded video, video meetings, messaging platforms and email. While these are not difficult to track they do often require printed material. We develop a lot of that in house so having material from OpenChain that we can incorporate for training would be very helpful.
We go through a "launch process" when we release software under open source licenses -- would this process, which can go quite deep into licenses and compliance, perhaps qualify as a a kind of "continuing education unit" for engineers who've already gone through training? I don't imagine it is a substitute for the training itself.
Shane Martin Coughlan <shane@...>
On Jun 13, 2016, at 04:48 , J Lovejoy <opensource@...> wrote:Happy to explore the creation of a template test after we complete our training slides.