FLIGHT WEST 2018 Presentation - Open Source License Management in Black Duck Hub
2 likes932 views
This document provides an overview of open source license management best practices that have evolved over 16 years, from 2002 to 2018. It discusses how the risks have changed from lawsuits prompting code inspections to security vulnerabilities coming to the forefront. It also outlines the key functionality of Black Duck Hub for managing open source licenses, including predefined license groups, component usage settings, license risk modeling, policy management, license review workflows, and integrations. Finally, it proposes a suggested license management workflow involving license planning, policy creation, component reviews, attribution statements, and more.
Ad
More Related Content
What's hot (20)
Similar to FLIGHT WEST 2018 Presentation - Open Source License Management in Black Duck Hub (20)
Ad
More from Black Duck by Synopsys (20)
Ad
Recently uploaded (20)
![Pixologic ZBrush Crack Plus Activation Key [Latest 2025] New Version](https://cdn.slidesharecdn.com/ss_thumbnails/fashionevolution2-250322112409-f76abaa7-250428124909-b51264ff-250504160528-fc2bb1c5-thumbnail.jpg?width=560&fit=bounds)
FLIGHT WEST 2018 Presentation - Open Source License Management in Black Duck Hub
- 1. Open Source License Management in the Black Duck Hub Hal Hearst – Principal Product Manager [email protected]
- 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!!