Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Giving Everyone Access To Open Source Best Practices: The OpenChain Curriculum


Published on

This talk will explain how the OpenChain Curriculum team assembled and released extensive compliance training material under CC-0 licensing. It will expand on how this material can be either used for generic in-company or cross-company training and how it helps to comply with the OpenChain Specification. A run through of the key material will be given to illustrate how it can support every company in the adoption and customization of best practices to suit their needs. The talk will conclude with a brief overview of how to engage with the OpenChain Curriculum, the broader OpenChain Project, and what can be expected around Open Source supply chain management in the coming year.

Published in: Software
  • Be the first to comment

Giving Everyone Access To Open Source Best Practices: The OpenChain Curriculum

  1. 1. Giving Everyone Access To Open Source Best Prac8ces OpenChain Project - The Linux Founda8on Available under the CC ACribu8on-NoDeriva8ves 4.0 Interna8onal license.
  2. 2. The value of open source is efficiency: 2 1. Efficient code crea8on 2. Efficient code support 3. Efficient code evolu8on
  3. 3. Open source license compliance is an opportunity for efficiency. 3
  4. 4. Open source license compliance reduces: 4 1. Legal and reputa8on risk 2. Costs of custom process management 3. Costs related to compliance viola8ons
  5. 5. Many companies do a great job of reducing this inefficiency internally. 5
  6. 6. However, most companies rely on a supply chain. 6
  7. 7. We can significantly improve efficiency around open source license compliance in the supply chain. 7
  8. 8. OpenChain Project addresses the ques8on of “how do I trust open source compliance in my supply chain?” 8
  9. 9. More Trust = More Collabora8on = More Efficiency. 9
  10. 10. There are three parts to OpenChain Project: 10 1. Specifica8on 2. Conformance 3. Curriculum
  11. 11. The OpenChain Specifica8on defines a core set of requirements every quality compliance program must sa8sfy. Learn more here: hCps:// 11
  12. 12. OpenChain Conformance allows organiza8ons to display their adherence to these requirements. Learn more here: hCps:// 12
  13. 13. The OpenChain Curriculum provides the educa8onal founda8on for open source processes and solu8ons. Learn more here: hCps:// 13
  14. 14. Digging Deeper 14
  15. 15. The core of the OpenChain Curriculum is a reference deck to help people meet the requirements of the OpenChain Specifica8on. 15
  16. 16. The deck can also be used for general training. 16
  17. 17. The deck is not intended to cover everything. 17
  18. 18. It is intended to be a useful star8ng point. 18
  19. 19. Contents 1. What is Intellectual Property? 2. Introduction to FOSS Licenses 3. Introduction to FOSS Compliance 4. Key Software Concepts for FOSS Review 5. Running a FOSS Review 6. End to End Compliance Management (Example Process) 7. Avoiding Compliance Pitfalls 8. Developer Guidelines
  20. 20. What is “Intellectual Property”? • Copyright: protects original works of authorship • Protects expression (not the underlying idea) • It covers software, books, and similar works • Patents: useful inventions that are novel and non-obvious  • Limited monopoly to incentivize innovation • Trade secrets: protects valuable confidential information • Trademarks: protects marks (word, logos, slogans, color, etc.) that identify the source of the product • Consumer and brand protection; avoid consumer confusion and brand dilution This chapter will focus on copyright and patents, the areas most relevant to FOSS compliance.
  21. 21. Check Your Understanding • What type of material does copyright law protect? • What copyright rights are most important for software? • Can software be subject to a patent? • What rights does a patent give to the patent owner? • If you independently develop your own software, is it possible that you might need a copyright license from a third party for that software? A patent license?
  22. 22. CHAPTER 6 End to End Compliance Management (Example Processes)
  23. 23. Example Small to Medium Company Checklist Ongoing Compliance Tasks: 1. Discover all FOSS early in the procurement/development cycle 2. Review and Approve all FOSS components used  3. Verify the information necessary to satisfy FOSS obligations 4. Review and approve any outbound contributions to FOSS projects Support Requirements: 1. Ensure adequate compliance staffing and designate clear lines of responsibility  2. Adapt existing Business Processes to support the FOSS compliance program 3. Have training on the organization’s FOSS policy available to everyone 4. Track progress of all FOSS compliance activities You can get detailed checklists for these items here:
  24. 24. Example Enterprise Process Queued for Process Identification Audit ResolveIssues Reviews Approvals Registration Notices Verifications Distribution Verifications Own Proprietary Software 3rd Party Software FOSS Outgoing Software Notices & Attributions Written Offer Scan or audit source code – and – Confirm origin and license of source code Resolve any audit issues in line with company FOSS policies Identify FOSS components for review Verify source code packages for distribution – and – Verify appropriate notices are provided Record approved software/version in inventory per product and per release Publish source code, notices and provide written offer Review and approve compliance record of FOSS software components Compile notices for publication Post publication verifications Example of Compliance Management End-to-End Process
  25. 25. CHAPTER 7 Avoiding Compliance Pitfalls
  26. 26. Intellectual Property Pitfalls Type & Description  Discovery Avoidance Unplanned inclusion of copyleft FOSS into proprietary or 3rd party code: This type of failure occurs during the development process when engineers add FOSS code into source code that is intended to be proprietary in conflict with the FOSS policy. This type of failure can be discovered by scanning or auditing the source code for possible matches with: • FOSS source code  • Copyright notices Automated source code scanning tools may be used for this purpose This type of failure can be  avoided by:  • Offering training to engineering staff about compliance issues, the different types of FOSS licenses and the implications of including FOSS in proprietary source code  • Conducting regular source code scans or audits for all the source code in the build environment. 
  27. 27. Check Your Understanding •What types of pitfalls can occur in FOSS compliance? •Give an example of an intellectual property failure. •Give an example of a license compliance failure. •Give an example of a compliance process failure. •What are the benefits of prioritizing compliance? •What are the benefits of maintaining a good community relationship?
  28. 28. CHAPTER 8 Developer Guidelines
  29. 29. Developer Guidelines • Select code from high quality, well supported FOSS communities • Seek guidance • Request formal approval for each FOSS component you are using • Do not check un-reviewed code into any internal source tree • Request formal approval for outside contributions to FOSS projects • Preserve existing licensing information • Do not remove or in any way disturb existing FOSS licensing copyrights or other licensing information from any FOSS components that you use. All copyright and licensing information is to remain intact in all FOSS components • Do not re-name FOSS components unless you are required to under the FOSS license (e.g., required renaming of modified versions) • Gather and retain FOSS project information required for your FOSS review process
  30. 30. Check Your Understanding • Name some general guidelines developers can practice when working with FOSS. • Should you remove or alter FOSS license header information? • Name some important steps in a compliance process. • How can a new version of a previously-reviewed FOSS component create new compliance issues? • What risks should you address with in-bound software? Learn more through the free Compliance Basics for Developers hosted by the Linux Foundation at: compliance-basics-for-developers
  31. 31. We also have a GitHub repository with more material: hCps:// 19
  32. 32. Everything is Crea8ve Commons 0 (public domain). 20
  33. 33. This means the knowledge can be used, shared, remixed and incorporated anywhere in any way. 21
  34. 34. We are always looking for dona8ons of material or 8me to improve our curriculum. 22
  35. 35. Let’s Talk 23 Shane Coughlan +818040358083