Please help our OpenChain work move forward by contributing high-level answers to the following questions. These answers will guide our collaboration to focus on shared OpenChain problems, starting from where we are and moving forward. Please do not worry overly about the style of your answers, our greatest need is to gather input relating to the gaps to close and desired achievable tangible goals.

Please feel free to add to what others posted, using this as a collaborative space for collective information.

• Contract Terms, applied as-needed:
  • Specify acceptable licensing
    • variations by situation/use
      • approaches ranging from conservative to more realistic:
        • representation that no Open Source is included
        • exclude certain Open Source
  • Request a list of license information, as a deliverable
    • this might also be addressed less formally
    • often this is informal
    • Warrant that the list of license information is complete
  • Request information needed for license compliance
    • Warranty of license compliance

• Know the supplier
  • Case-by-case scanning of source code for licenses
  • Reputation/relationship

*Explaining to developers, managers, and suppliers what their obligations are and what we need from them because many still don't have a clue – especially some of the smaller vendors and entry level software developers.

• Improved license information deliverables
  • Easily processed to confirm compatibility:
    • Mutually-compatible, as a set
    • Policy-compatible, suitable to the business/project goals
  • Standard format for reporting license info (SPDX)
    • Broadly and well supported (use, tools, knowledge-base, advancing)

• Accepted and well understood practices around compliance

• Trust the upstream chain
  • Minimized need for [redundant] license scanning/review
  • Accepted industry practices in-use
    • Efficient means to satisfy source code availability requirements
    • Less critical: upstream contributions, not required for trust
  • Accepted set of “baseline knowledge” commonly known

*Better training for open source in general and suppliers/developers specifically. It should be concise and easily consumable (e.g. online) with perhaps some questions or interactive Q&A to test understanding. There are a lot of good resources out their already (e.g. great webinars produced by many in this group, LF materials, other materials under CC license or other permissive licenses). We should endeavor to pull the best and create a set of training that we can all leverage for companies to use for internal training and to provide to their suppliers.

(please add your ID to this list)

hutch@qti.qualcomm.com

spl518@gmail.com