Initial topics for discussion - tabled by Jimmy @ Ericsson to help initiate the practical discussion

[Jimmy-ahlberg]

I will leave some comments here that may or may not be useful to discuss:

1. To a receiving organization for open source contributions (most likely a project), it is of importance to understand if the contributions received have the internal approvals necessary for the developer to contribute the code. Thus a requirement should be that the organization contributing also (where so is required by their open source policy) document and maintains a registry of the approvals it has given. If the organizations policy says that any developer is free to contribute to any project, obviously no such approval is necessary.

2. Should we also include the use of a Open Source strategy in the contribution space? If so it should be documented and communicated to the program participants
   2.1it may be good to also include the requirement of a). having an Open Source strategy, b), evaluate if and how the contribution furthers that strategy.
   -In my view this should be more of a requirement to check the contribution against the strategy. The contribution may be against that strategy, but ultimately that's up to the company how and if they accept deviations from the strategy.

3. Should we include that there should be processes to deal with unauthorized open source contributions? i.e. what happens when someone does not follow the processes outlined. This should also be documented and communicated to the program participants.

4. Should we include a requirement that a process exists to check and get necessary signatures for CLA's? If so it should also be documented and communicated to the program participants.

5. Should we include a section on metrics and follow up? not necessarily what metrics and checks on contributions to do, but that some sort of programmatic approach exists to measure contributions done by the organization?

6. If a receiving organization (most likely a open source project) have questions as to the validity, internal approvals or other non technical questions there should be a process to address those from the contributing organization, similar to section 3.2.2 in the License Compliance specification (ISO:5230).

[shanecoughlan]

Thanks Jimmy. Flagged to all that this thread is open for your feedback. Please add your feedback to Jimmy here or - if you have ideas for the specification content - please open a new issue.

[shanecoughlan]

Item 1 moved to here:
#8

Item 2 moved to here:
#9

Item 3 moved to here:
#10

Item 4 moved to here:
#11

Item 5 moved to here:
#12

Item 6 moved to here:
#13

This parent issue is now being closed. We will focus on resolving the individual issues in their respective GitHub issue.