Way to Question / Respond between organizations to topics about processes, legal matters etc.

[shanecoughlan]

From Item 6 here: https://github.com/OpenChain-Project/Contribution-Process-Specification/issues/2

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).

==

Shane: perhaps covers 3.2.1 and 3.2.2 from License Compliance ISO/IEC 5230:2020?

==

3.2 - Relevant tasks defined and supported

3.2.1 - Access

Maintain a process to effectively respond to external open source inquiries. Publicly identify a means by which a third party can make an open source compliance inquiry.

Verification material(s):

• 3.2.1.1 - Publicly visible method that allows any third party to make an open source license compliance inquiry (e.g., via a published contact email address, or the Linux Foundation's Open Compliance Directory).
• 3.2.1.2 - An internal documented procedure for responding to third party open source license compliance inquiries.

Rationale:

To ensure there is a reasonable way for third parties to contact the organization with regard to open source compliance inquiries and that the organization is prepared to effectively respond.

3.2.2 - Effectively resourced

Identify and Resource Program Task(s):

• Assign accountability to ensure the successful execution of program tasks.
• Program tasks are sufficiently resourced:
  • Time to perform the tasks have been allocated; and
  • Adequate funding has been allocated.
• A process exists for reviewing and updating the policy and supporting tasks;
• Legal expertise pertaining to open source license compliance is accessible to those who may need such guidance; and
• A process exists for the resolution of open source license compliance issues.

Verification material(s):

• 3.2.2.1 - Document with name of persons, group or function in program role(s) identified.
• 3.2.2.2 - The identified program roles have been properly staffed and adequate funding provided.
• 3.2.2.3 - Identification of legal expertise available to address open source license compliance matters which could be internal or external.
• 3.2.2.4 - A documented procedure that assigns internal responsibilities for open source compliance.
• 3.2.2.5 - A documented procedure for handling the review and remediation of non-compliant cases.

Rationale:

To ensure: i) program responsibilities are effectively supported and resourced and ii) policies and supporting processes are regularly updated to accommodate changes in open source compliance best practices.

[ContiMary]

I found this very confusing. why would an organization have this feedback mechanism when the project that is being contributed to will have its own mechanisms for even accepting the contribution, and should have a means to contact the person submitting the change. Are you thinking that the companies run compliance checks on every single contribution made to a public repository?