openchain:sandbox
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Last revision Both sides next revision | ||
|
openchain:sandbox [2014/12/01 20:09] hutch@qti.qualcomm.com |
openchain:sandbox [2014/12/09 14:00] slamons [Yes, some of this matches what I have and/or what I want:] |
||
|---|---|---|---|
| Line 9: | Line 9: | ||
| * Contract Terms, applied as-needed: | * Contract Terms, applied as-needed: | ||
| * Specify acceptable licensing | * Specify acceptable licensing | ||
| - | * this varies by situation/use | + | * 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 | * Request a list of license information, as a deliverable | ||
| * this might also be addressed less formally | * 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 | * Know the supplier | ||
| * Case-by-case scanning of source code for licenses | * Case-by-case scanning of source code for licenses | ||
| * Reputation/relationship | * 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. | ||
| ==== What do you want to have? ==== | ==== What do you want to have? ==== | ||
| * Improved license information deliverables | * Improved license information deliverables | ||
| * Easily processed to confirm compatibility: | * Easily processed to confirm compatibility: | ||
| - | * mutually-compatible, as a set | + | * Mutually-compatible, as a set |
| - | * policy-compatible, suitable to the business/project goals | + | * 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 | * Trust the upstream chain | ||
| - | * Minimize the need for [redundant] license scanning/review | + | * Minimized need for [redundant] license scanning/review |
| - | * Accepted industry practices | + | * Accepted industry practices in-use |
| - | * Accepted baseline knowledge | + | * 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. | ||
| + | |||
| + | ==== Yes, some of this matches what I have and/or what I want: ==== | ||
| + | (please add your ID to this list) | ||
| + | |||
| + | *hutch@qti.qualcomm.com | ||
| + | *spl518@gmail.com | ||
openchain/sandbox.txt · Last modified: 2014/12/09 14:01 by slamons
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International
