Hal Hearst, senior product manager, Synopsys presented at Flight West 2018.

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 2015
Situation:
• Limited OSS use and availability
• SCO-IBM lawsuit prompts inspection of code
snippets
• Security? Someone else’s problem
Best practices:
• Audit/scanning tools
• Match individual files
• Match code snippets
Situation:
• Increasing adoption of OSS
• GPL lawsuits prompts better governance
• Recognized need to consider security,
maintenance and other cost factors
Best practices:
• Formal OSS Policies
• Approval process
• Whitelist catalog
Situation:
• Package Management has lead to explosive
numbers of OSS components
• 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 does not violate policy
• Integration into DevOps process
LESSONS LEARNED: RISK LANDSCAPE IS CHANGING, AGILITY IS KEY
20182004

4. • License Families
• Predefined License Groups primarily based upon reciprocity
• Range from permissive to reciprocal via network usage
• Editable with Professional Edition
• 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 – Standard Edition

5. • License Risk
• Fixed Risk Model Based Upon:
• Project/Version - Distribution Type
• Component Usage (incorporation method)
• License Family (group)
• Can use for decision support & reporting
• Component Review Flag
• Typically used to verify accuracy of scan & make new components obvious
• Not used to approve the component
• Can be used in Policy Rules
Key Hub Functionality – Standard Edition

6. • Policy Management
• Controlled by Policy Manager Role
• Define the rules which govern license use (and security)
• Policy Violations create Notifications
• Policy Violations can be overridden – depending upon rules
• License Management
• Controlled by License Manager Role
• Create/Review/Annotate OSS Licenses
• Create White Lists / Black Lists via License Status
Key Hub Functionality - Professional

7. • 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
• Editable License Text
• Automated or Manual Creation
• Text, HTLM or JSON format
Key Hub Functionality - Professional
* A basic notices report is include in the Standard Edition

8. • Hub Alerts
• License policy violations can create Notifications
• Distribute Notifications thru a channel of choice
• Email / HipChat / Slack
• Realtime or Daily Digests
• Workflow Integration (Jira)
• License policy violations can create Jira tickets
• Capture additional info – track & route through a workflow
• Recommend doing this for “reviewed” components
Key Hub Functionality – Integrations

9. 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?

10. 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?

11. 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 fail all unapproved components
• Heavy use of External Workflow
What kind of program do you want?

12. The Problem with Review Based

13. 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

14. License Planning
Distribution Model
License Family Usage External SaaS Internal Open Source
AGPL
Dynamically Linked No 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 OK OK OK
Implementation of Standard OK OK OK OK
Reciprocal
Dynamically Linked No 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
Reciprocal
Dynamically Linked Check 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

15. Q & A
THANKS!!