Embed Size (px)
Citation preview
1
Ibrahim Haddad, Ph.D.
Head of Open Source Group, Samsu
ng
Building Trust in the SW Supply Chain
Starts by Building Trust With Your Co
mpany
Collaboration Summit 2
015
Santa Rosa, CA
2
It’s about trust & perception.
3
The example everyone knows
FSF accused Ciscoof a license violation
After much bad press, source code was made available
adopted this technology into its WRT54G wireless broadband router
boughtfor $500M in
2003
used GPL code to customize Broadcom’s standard Linux distribution
embedded the code in one of its chipsets
4
We had non-compliance cases in the past
5
Compliance hiccups fall under 5 buckets
1. Policy failure Employee did not follow policy / internal guidelines
1. Process failure Process oversight, corner cases, human error
2. Tooling failure Industrial scale automation leads to defects as you perfect
the tool or its usage
3. SW Procurement failure Incoming non-compliance via 3rd party
1. Misc. failure Notice error, code versioning error, web site access error, etc
.
6
Learning from our experiences …
1. Training Formal training delivered by the Open Source Group (OSG)
2. Policy Training + ongoing seminars + lighter and localized policy
1. Process Training + clearer, more efficient and localized process
2. Tooling Training + additional tooling (including in-house)
3. SW Procurement Training + reform agreements + templates
4. Misc. Update process to include verification steps
1. Direct hotline to OSG Open Source Group acts as advisor on any open source
compliance inquiry.
7
How does our compliance program look now?
Policy
Process
Team
Tools
Education
Usage
Automation
Contribution Distribution Auditing
Auditing Code
Project Management
InventoryManagement
Linkages Analysis
CodeInspection
Formal Training
Guidelines Brown Bag Seminars
Obligations Fulfillment
Usage Contribution Distribution Auditing Obligations Fulfillment
Usage e-Form
Contribution e-Form
Templates
InternalWeb Portal
External Web Portal
Strategy
Core Team
ExtendedTeam
Messaging Internal External
ComplianceStrategy
Inquiry Response
Invited Speakers
Employee Orientation
Workflow
Legal Support License CompMatrices
How To’sInternal/External Counsels
License Playbooks
AdvisorTeam
8
What does it take to establish “ope
n source compliance” trust?
9
Establishing trust with your company
Policy
Process
Staffing
Tools
Education
10
Simple and Clear is the new Smart
Policy
We must ensure that all incoming software (in house, 3rd party co
mmercial, open source, other) is compliant with the license it is provided
under by following the open source compliance process defined in $U
RL.
Process
Incoming Software
Outgoing: SoftwareNotices
iden
tifi
cati
on
Rev
iew
s/A
pp
rova
l
Ver
ific
atio
ns
Au
dit
Res
olv
e Is
sues
Co
mp
ile O
blig
atio
ns
11
Approvals (our example)
1. Open source proprietary source code / technolo
gy
2. Contribute major patches to an existing open so
urce project (new significant improvements/fu
nctionalities)
3. Start a new open source project
1. Contribute minor patches to an existing open so
urce project (1 time blanket approval)
2. Other contributions (documentation, testing, etc
. – 1 time blanket approval)
OSS Review Board
Project Leader
12
Staffing
Dedicated.
Background as Senior Engineers and Product Archit
ects.
Trained and coupled with Open Source experts.
13
Tools
Buy it.
Build it.
Combination.
14
Update software procurement practices
• Package name
• Version
• Original download URL
• License and License URL
• Description
• Modified?
• Dependencies?
• Intended use in your product
• First product release that will incl
ude the package
• Development team's point of
contact
• Availability of source code
• Were the source code will be
maintained
• Whether the package had
previously been approved for use
in another context
• Nature of the license obligations
• Inclusion of technology subject to
export control
• Etc.
Mandatory disclosure.
Verified for completeness, consistency, and accuracy.
15
Education
Mandatory for all engineering staff.
Senior staff require the in-person training.
16
Building trust with your compa
ny’s compliance practices will
add trust to the software suppl
y chain.
17
Scaling across ecosystem partner
s.
18
What does that mean?
Across the companies we work with as suppliers and pa
rtners:
Everyone knows their FOSS responsibilities Policy + Process + Education
Responsibility for achieving compliance is assigned Staffing + Education
FOSS content (packages/licenses) is known Process + Tools
FOSS content is reviewed and approved Process + Policy + Staffing
FOSS obligations are satisfied Process + Operation/Execution
19
Goal Everyone knows their FOSS responsibilities
FOSS policy exists
FOSS compliance training program actively used
Supporting Practices
20
Goal Responsibility for achieving compliance is assigned
FOSS Compliance Officer exists
Compliance activities are resourced
Supporting Practices
Licensing expertise is available
Processes, procedures, templates, forms, etc. are developed
Compliance tools are evaluated, developed or acquired, and deployed
21
Goal FOSS content (packages/licenses) is known
Code audits are conducted
Supplier compliance is managed
Supporting Practices
FOSS compliance records are maintained
Supplier compliance practices are assessed
Supplier FOSS disclosures are made & reviewed
Supplier FOSS obligations are satisfied
22
Goal FOSS content is reviewed and approved
OSRB exists and is staffed
Planned FOSS use is reviewed in context
Supporting Practices
License obligations are identified, understood, anddocumented
Issues are resolved and approval decisions are followed
23
Goal FOSS obligations are satisfied
Documentation obligations are met
Source code obligations are met
Supporting Practices
Community interface exists
Email and postal addresses work
Web portal works
Community requests and inquiries are satisfied
24
Building trust within the SW supply chain is doable
Companies need to meet these 5 well defined goals:
Have it verified or certified by a 3rd party or via
self-verification process following a specific defined
model.
Goal 1 Everyone knows their FOSS responsibilities
Goal 2 Responsibility for achieving compliance is assigned
FOSS content (packages/licenses) is knownGoal 3
FOSS content is reviewed and approvedGoal 4
FOSS obligations are satisfiedGoal 5
25
Imagine a world where all companies
you exchange software with have met t
hese5 basic goals:
Policy, Process, Tool, Staffing, Educati
on.
26
27
Call to action:
Help shape that vision with OpenC
hainhttps://wiki.linuxfoundation.org/openchain
