You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: Guides/Official/OpenChain-in-Mergers-and-Acquisitions/2.0/en/Assessment-Of-OS-Practices-In-Merger-and-Acquisition.md
+74-73Lines changed: 74 additions & 73 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,7 @@
1
1
---
2
2
title: A Contribution to the OpenChain Project
3
3
author: Ibrahim Haddad, Ph.D.
4
+
markdown_version: Carlo Piana
4
5
---
5
6
6
7
**A Contribution to the OpenChain Project**
@@ -65,7 +66,7 @@ The checklist explores 13 specific areas to evaluate:
65
66
7. Appropriate staffing for compliance execution
66
67
67
68
8. Adaptation of business processes to accommodate open source specific
68
-
> requirements
69
+
requirements
69
70
70
71
9. Training
71
72
@@ -76,7 +77,7 @@ The checklist explores 13 specific areas to evaluate:
76
77
12. Maintaining inventory of open source software
77
78
78
79
13. Automation and tool support for large scale use, consumption, and
79
-
> compliance
80
+
compliance
80
81
81
82
The remainder of this paper is dedicated to exploring these 13 different
82
83
categories and various elements within each category.
@@ -93,80 +94,80 @@ software, including open source software in a code base readied for
93
94
release as a product or a service.***
94
95
95
96
- Open source software discovery occurs at an early point in the
96
-
> product development cycle.
97
+
product development cycle.
97
98
98
99
- The product team systematically identifies all the software and
99
-
> additional materials that must be subjected to compliance
100
-
> analysis.
100
+
additional materials that must be subjected to compliance
101
+
analysis.
101
102
102
103
- Third party suppliers disclose all open source software in their
103
-
> deliverables.
104
+
deliverables.
104
105
105
106
- The organization has a defined format for the disclosure.
106
107
107
108
- The open source compliance team reviews the disclosure for
108
-
> accuracy and completeness using whatever tools are available
109
-
> to it.
109
+
accuracy and completeness using whatever tools are available
110
+
to it.
110
111
111
112
- The organization investigates the third party supplier's use of open
112
-
> source software and its open source compliance practices as part
113
-
> of its supplier selection process.
113
+
source software and its open source compliance practices as part
114
+
of its supplier selection process.
114
115
115
116
- The organization investigates the third party supplier's
116
-
> compliance and supply chain management practices to evaluate
117
-
> their adequacy.
117
+
compliance and supply chain management practices to evaluate
118
+
their adequacy.
118
119
119
120
- The organization uses defined guidelines to determine if
120
-
> automated scanning or other confirmation of the supplier's
121
-
> disclosure is needed.
121
+
automated scanning or other confirmation of the supplier's
122
+
disclosure is needed.
122
123
123
124
- Software license agreements include appropriate terms and
124
-
> conditions concerning open source software.
125
+
conditions concerning open source software.
125
126
126
127
- Procurement (i.e., Supply Chain) staff and others who interface
127
-
> with suppliers have been trained in open source software
128
-
> matters and include open source software concerns in their
129
-
> discussions with third party suppliers.
128
+
with suppliers have been trained in open source software
129
+
matters and include open source software concerns in their
130
+
discussions with third party suppliers.
130
131
131
132
- The organization periodically conducts audits of open source
132
-
> software use.
133
+
software use.
133
134
134
135
- At an agreed-upon frequency, the organization conducts an
135
-
> audit/inventory of open source software used internally and
136
-
> records its findings.
136
+
audit/inventory of open source software used internally and
137
+
records its findings.
137
138
138
139
- The organization audits and inventories the open source software
139
-
> included in its products and services.
140
+
included in its products and services.
140
141
141
142
- The organization identifies the conditions or events that
142
-
> trigger a fresh audit of the product's source code or of the
143
-
> incremental changes to a code base whose open source
144
-
> compliance had previously been verified.
143
+
trigger a fresh audit of the product's source code or of the
144
+
incremental changes to a code base whose open source
145
+
compliance had previously been verified.
145
146
146
147
- A bill of materials is prepared to reflect the open source content
147
-
> of a specific product or service release.
148
+
of a specific product or service release.
148
149
149
150
- Code scans are used to prepare the bill of materials wherever
150
-
> source code is available.
151
+
source code is available.
151
152
152
153
- Supplier disclosures are used in cases where source code is not
153
-
> available.
154
+
available.
154
155
155
156
- The organization uses a systematic approach to identify changes in
156
-
> the code baseline and to perform incremental compliance on changes
157
-
> in an efficient manner.
157
+
the code baseline and to perform incremental compliance on changes
158
+
in an efficient manner.
158
159
159
160
- The organization systematically achieves closure on issues arising
160
-
> from discovery activity.
161
+
from discovery activity.
161
162
162
163
- The organization systematically tracks open issues.
163
164
164
165
- The organization assigns adequate resources to achieve closure
165
-
> in a reasonable timeframe.
166
+
in a reasonable timeframe.
166
167
167
168
- The organization periodically reviews commercial and open source
168
-
> tools to assess the costs and benefits of their use in discovering
169
-
> open source software in code baselines.
169
+
tools to assess the costs and benefits of their use in discovering
170
+
open source software in code baselines.
170
171
171
172
## 2. Review and Approval of the Use of Open Source Software
172
173
@@ -178,61 +179,61 @@ software in products for distribution and, if mandated by company
178
179
policy, in internal projects.***
179
180
180
181
- The organization subjects all open source software used in products
181
-
> to review and defines what contextual changes in open source
182
-
> software use trigger re-approval activity.
182
+
to review and defines what contextual changes in open source
183
+
software use trigger re-approval activity.
183
184
184
185
- The organization considers issues relevant to the use of a specific
185
-
> open source software package and version, such as bug fixes the
186
-
> community has made in subsequent versions, security
187
-
> vulnerabilities that have been identified in a specific package
188
-
> version, technology incorporated into the package that might be
189
-
> subject to export control regulations, etc.
186
+
open source software package and version, such as bug fixes the
187
+
community has made in subsequent versions, security
188
+
vulnerabilities that have been identified in a specific package
189
+
version, technology incorporated into the package that might be
190
+
subject to export control regulations, etc.
190
191
191
192
- An open source review board (OSRB) is used to review and approve
192
-
> planned uses of open source software in products or services.
193
+
planned uses of open source software in products or services.
193
194
194
195
- The OSRB is staffed with appropriately skilled and knowledgeable
195
-
> individuals.
196
+
individuals.
196
197
197
198
- Appropriate resources are available for the interpretation of
198
-
> open source licenses and definition of obligations to be
199
-
> satisfied.
199
+
open source licenses and definition of obligations to be
200
+
satisfied.
200
201
201
202
- Sufficient staffing is provided to the OSRB to achieve
202
-
> turnaround time on submissions that supports product
203
-
> development cycles.
203
+
turnaround time on submissions that supports product
204
+
development cycles.
204
205
205
206
- OSRB procedures (inputs to a review, participants, review
206
-
> procedures, analysis procedures, decision outcomes, appeal and
207
-
> waiver procedures, etc.) are defined and documented.
207
+
procedures, analysis procedures, decision outcomes, appeal and
208
+
waiver procedures, etc.) are defined and documented.
208
209
209
210
- The OSRB considers and provides architectural guidelines and/or
210
-
> requirements for OSS inclusion in products to be distributed.
211
+
requirements for OSS inclusion in products to be distributed.
211
212
212
213
- The OSRB uses independent analysis methods to confirm the open
213
-
> source software content reported by teams when they submit an
214
-
> open source software use case for approval.
214
+
source software content reported by teams when they submit an
215
+
open source software use case for approval.
215
216
216
217
- Records of OSRB deliberations are maintained (cases, status,
217
-
> past decisions, requirements imposed on product teams, etc.)
218
-
> and used in future deliberations.
218
+
past decisions, requirements imposed on product teams, etc.)
219
+
and used in future deliberations.
219
220
220
221
- The OSRB decides whether to approve the proposed open source
221
-
> software use and identifies obligations that must be
222
-
> satisfied, if any, and conditions that must be met, if any,
223
-
> before product distribution is approved.
222
+
software use and identifies obligations that must be
223
+
satisfied, if any, and conditions that must be met, if any,
224
+
before product distribution is approved.
224
225
225
226
- The organization provides a definition and examples of the
226
-
> information that must be submitted to the OSRB for approval of
227
-
> open source software use.
227
+
information that must be submitted to the OSRB for approval of
228
+
open source software use.
228
229
229
230
- Proposed use of open source software includes a description of
230
-
> the architectural interfaces and dependencies between any open
231
-
> source components and the rest of the system.
231
+
the architectural interfaces and dependencies between any open
232
+
source components and the rest of the system.
232
233
233
234
- The OSRB communicates perspectives across business units to achieve
234
-
> a consistency of interpretation of license obligations and review
235
-
> practices.
235
+
a consistency of interpretation of license obligations and review
236
+
practices.
236
237
237
238
## 3. Obligation Satisfaction
238
239
@@ -821,7 +822,7 @@ you build your product or software stack.
821
822
8. Perform verification to all steps previous to distribution.
822
823
823
824
9. Distribute source code and perform final verifications in relation
824
-
> to distribution.
825
+
to distribution.
825
826
826
827
The output of the process is an open source bill of materials (BoM) that
827
828
you can publish, along with a written offer and various copyright,
@@ -1182,7 +1183,7 @@ If you are the target, you can maintain proper open source compliance
1182
1183
practices by ensuring your development and business processes include:
1183
1184
1184
1185
- Identifying the origin and license of all internal and external
1185
-
> software.
1186
+
software.
1186
1187
1187
1188
- Tracking open source software within the development process
1188
1189
(components and snippets).
@@ -2158,22 +2159,22 @@ packages.
2158
2159
### Open Source Compliance Tools\*
2159
2160
2160
2161
-[FOSSology](https://www.fossology.org/) is an open
2161
-
> source license compliance software system and toolkit.
2162
+
source license compliance software system and toolkit.
0 commit comments