This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
openchain:spec-1.1-draft-public-comments [2017/03/20 16:08] mgisi [8) Suggest: zzzzzz] |
openchain:spec-1.1-draft-public-comments [2017/08/21 23:54] (current) mgisi [14) Suggest: Discuss how we a reference to SPDX in the spec] |
||
---|---|---|---|
Line 25: | Line 25: | ||
=== Response: === | === Response: === | ||
- | Redefined "Identified Licenses" to: | + | There was a fair amount of discussion and proposals on how to update the definition to be more clear. It was decided, due to limited time, to move this discussion to the next version where we can give it the time it deserves. |
- | **Identified Licenses** - //a set of licenses governing the FOSS used to construct the Supplied Software.// | + | |
---- | ---- | ||
Line 181: | Line 180: | ||
=== Response: === | === Response: === | ||
- | TBD. | + | The section + definition were re-written to include a reference to SPDX. |
+ | |||
+ | |||
+ | ==== 15) Suggest: Minor feedback in section 2.1 ==== | ||
+ | Submitted By: Jilayne Lovejoy | ||
+ | |||
+ | in 2.1 and the specificity of “electronic communication” and "via a published contact email address” is really just a question I had as to whether we mean to be that narrow/specific - if I recall, the LF list has both email and phone number and I’d think a phone number would be fine too? In any case, not a key issue, more of a question/clarification. | ||
+ | |||
+ | |||
+ | === Response: === | ||
+ | TBD - | ||
+ | |||
+ | ---- | ||
+ | |||
+ | ==== 16) Suggest: Minor edit to section 3.2 rationale ==== | ||
+ | Submitted By: Jilayne Lovejoy | ||
+ | |||
+ | The only other minor edit I had was some wording that I thought seemed a bit extra in the 3.2 Rationale - I was thinking the when it says “an organizations’ typical common FOSS use cases…” that seemed like enough and that “as a result of that organization’s business practices” seems to be saying the same thing in a different way. | ||
+ | |||
+ | **3.2 Rationale** | ||
+ | To ensure the FOSS management program is sufficiently robust to handle an organization’s | ||
+ | common FOSS use cases <del>as a result of that organization’s business practices</del>. That a procedure | ||
+ | exists to support this activity and that the procedure is followed. | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | === Response: === | ||
+ | TBD - | ||
+ | |||
+ | ---- | ||