Hal Hearst, principal product manager at Black Duck By Synopsys takes you through using Black Duck Hub for open source license management.

1. Open Source License
Management in the Black
Duck Hub
Hal Hearst – Principal Product Manager
hhearst@synopsys.com

2. What is this topic?
• A set of best practices
• Tips and Tricks
• How to …
Use all the features in Black Duck Hub to
help your teams build fast while
maintaining license compliance

3. What has 16 Years of Experience Taught Us?
2002 2008 2016
Situation:
• Limited OSS use and availability
• SCO-IBM lawsuit prompts inspection of
code snippets
Best practices:
• Match individual files
• Match code snippets
Situation:
• Increasing adoption of OSS
• GPL lawsuits of Cisco, etc. prompts
better governance
Best practices:
• Approval process
• Whitelist catalog
Situation:
• Software Freedom Law Center focuses
on education, not lawsuits
• Heartbleed vulnerability (2014) bring
security to the forefront.
Best practices:
• Automated ID of OSS
• Choose OSS that do not violate policy
• Integration into DevOps process
LESSONS LEARNED: RISK LANDSCAPE IS CHANGING, AGILITY IS KEY
2018

4. • License Risk
• Fixed Risk Model
• Based upon:
• Project/Version - Distribution Type
• Component Usage (incorporation method)
• License Family (group)
• License Management
• Create/Review/Annotate OSS Licenses
• Create White Lists / Black Lists via License Status
Key Hub Functionality

5. • Policy Management
• Define the rules which govern license use
• Can also define security policies
• Project/Version Settings
• Distribution Type (Internal, External, SaaS, Open Source)
• Component Usage
• How is OSS Component Incorporated in a BOM
• Degree of Integration… or Linking… or isolation
• Affects license risks & obligations
• Hub Does not determine this….
• So, when should you check or verify it?
Key Hub Functionality

6. • Component Level License Text
• License Text associated with Component, not the license
• Important for Licenses that are modified for each component
• MIT, BSD, ISC, etc.
• Typical modification is the copyright statement
• Notices Report Functionality
• Attribution Statements
• License Text
• Automated Creation or Manually Requested
Key Hub Functionality

7. Fully Automated
• Speed to Market & scalable
program very important
• More concerned with security risks
than license risks
• Most applications internal
• Willing to trust external party
license assessments
How?
• Trust BD’s license family
• Simple policy rules based upon
License Family
What kind of program do you want?

8. Semi Automated
• Speed to Market & scalable
program important, but need more
controls
• OSS License risk is material
• Applications Distributed
• Trust (but verify) external party
license assessments
How?
• License Review Process
• Policy Rules on license Status
• More complex policy rules
• Exception based reviews
What kind of program do you want?

9. Review Based
• OSS License risk is significant
business risk
• Willing to sacrifice some convenience
for more control
• Applications distributed and/or
redistributed by partners
• Trust nothing….
How?
• License & Component Review
Process
• Policy Rules on Component
Review Status
• Heavy use of External Workflow
What kind of program do you want?

10. The Problem with Review Based

11. Suggested License Management Workflow
Review Licenses
in Use
License Planning
Create Policy to
trigger violations
Create / Edit Custom
& KB Licenses in
necessary
Review BOMs for
policy violations
Determine course of
action for OOP
components
Research components
with Unknown Licenses /
License Not Found
Confirm usage of
components with license
risk is correct
Generate Notices
File Report
Determine if any
components or
subprojects should be
excluded from report
Add attribution
statements and edit
license text if necessary

12. License Planning
Distribution Model
License Family Usage External SaaS Internal Open Source
AGPL
Dynamically Linked Check No OK Check
Dev Tool / Excluded OK Ok OK OK
Source Code No No OK Check
Statically Linked No No OK Check
Separate Work OK Check OK OK
Implementation of Standard OK OK OK OK
Reciprocal
Dynamically Linked Check OK OK Check
Dev Tool / Excluded OK OK OK OK
Source Code No OK OK Check
Statically Linked No OK OK Check
Separate Work OK OK OK OK
Implementation of Standard OK OK OK OK
Weak
Reciprocol
Dynamically Linked OK OK OK Check
Dev Tool / Excluded OK OK OK OK
Source Code Check OK OK Check
Statically Linked Check OK OK Check
Separate Work OK OK OK OK
Implementation of Standard OK OK OK OK
Permissive
Dynamically Linked OK OK OK Check
Dev Tool / Excluded OK OK OK OK
Source Code OK OK OK Check
Statically Linked OK OK OK Check
Separate Work OK OK OK OK
Implementation of Standard OK OK OK OK
Unknown All No No No No
For a license group:
• What circumstances are OK?
• i.e. do not violate a policy rule
• What conditions are never ok?
• i.e. violate a policy rule that
cannot be overridden
• What conditions are OK, but need
verification?
• i.e. violate a policy rule that can
be overridden

13. Q & A
THANKS!!