O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Guide to Open Source Compliance

4.588 visualizações

Publicada em

A practical guide to open source compliance, authored by Ibrahim Haddad, head of the Samsung Open Source Group.

Publicada em: Tecnologia
  • Seja o primeiro a comentar

Guide to Open Source Compliance

  1. 1. Open Source Compliance Samsung Open Source Group 1 Ibrahim Haddad, Ph.D. Group Leader Samsung Open Source Group
  2. 2. Disclaimer Disclaimer I am not a lawyer These slides do not provide any legal advice Please consult with your legal counsel if you need specific legal advice Samsung Open Source Group 2
  3. 3. Introduction to Open Source Licenses Samsung Open Source Group 3 I am not a lawyer These slides do not provide any legal advice Please consult with your legal counsel if you need specific legal advice
  4. 4. Content Terms and Definitions License Obligations – GPL example Samsung Open Source Group 4
  5. 5. Open Source Software Licenses In general, OSS licenses makes the source code available under terms that allow for modification and redistribution without having to pay the original author. OSS licenses may have restrictions such as requirements related to attributions, copyright statement preservation, providing a written offer to make the source code available, or others. Samsung Open Source Group 5
  6. 6. Impact of FOSS Licenses FOSS licenses may impact: - Use of the software - Modification of the software - Maintenance of the software - Distribution of the software and its derivatives - Intellectual property rights (IPR) Samsung Open Source Group 6
  7. 7. Permissions Granted FOSS licenses may permit: - Modification of the source code - Recompilation of the software - Redistribution of the original source code, modified source code and/or binaries - Integration of the software with proprietary software - Redistribution of the resulting software as part of, or within, proprietary products Samsung Open Source Group 7
  8. 8. Possible Imposed Conditions FOSS licenses may impose conditions that include one of more of the following: - Notification to the recipient that the software is licensed under the respective FOSS license - Source code distribution to the recipient of the software - Distribution of any integrated proprietary source code - Most FOSS licenses do not include any warranty or indemnity to customers Samsung Open Source Group 8
  9. 9. OSI Approved OSS Licenses One popular set of open source software licenses are those approved by the Open Source Initiative (OSI) based on their Open Source Definition (OSD) Complete list of OSI-approved OSS licenses is available at http://www.opensource.org/licenses/ Note: - Many development organization with FOSS policies allow only (a subset) of the OSI Approved licenses without full legal review. - This is because the licenses are well-known. Samsung Open Source Group 9
  10. 10. Definitions and Concepts Samsung Open Source Group 10 I am not a lawyer These slides do not provide any legal advice Please consult with your legal counsel if you need specific legal advice
  11. 11. Proprietary License A proprietary software license is a license that has rules defined by its creators or owners and includes restrictions that applies on the usage, modification and distribution of the software in question. Proprietary licenses are unique to each vendor, so there are as many forms as there are vendors and each must be evaluated individually. FOSS developers often use the term “proprietary license” to describe a commercial non-FOSS license. Samsung Open Source Group 11
  12. 12. Permissive License A permissive software license is a term used often to describe non-viral free software licenses. Example: BSD License - The BSD license is an example of a permissive license that allows unlimited redistribution for any purpose as long as its copyright notices and the license's disclaimers of warranty are maintained. - The license contains a clause restricting use of the names of contributors for endorsement of a derived work without specific permission. Samsung Open Source Group 12
  13. 13. Freeware Freeware is software distributed under a proprietary license at no or very low cost. - The source code may or may not be available, and creation of derivative works is usually restricted. - Freeware software is usually fully functional (no locked features) and available for unlimited use (no locking on days of usage). - Freeware software licenses usually impose restrictions in relation to copying, distributing, and making derivative works of the software, as well as restrictions on the type of usage (personal, commercial, academic, etc.). Samsung Open Source Group 13
  14. 14. Shareware The term shareware refers to proprietary software provided to users on a trial basis, for a limited time, free of charge and with limited functionalities or features. - The goal of shareware is to give potential buyers the opportunity to use the program and judge its usefulness before purchasing a license for the full version of the software - Most companies are very leery of Shareware, because Shareware vendors often approach companies for large license payments after the software has freely propagated within their organizations. Samsung Open Source Group 14
  15. 15. Public Domain The term public domain refers to intellectual property not owned or controlled by anyone, and therefore it is considered public property available for anyone to use for any purpose. An example of public domain source code is the JavaScript implementation of object notation available for download from http://www.json.org/json2.js. The script declares the following: Public Domain. NO WARRANTY EXPRESSED OR IMPLIED. USE AT YOUR OWN RISK. Samsung Open Source Group 15
  16. 16. Distribution Distribution is the provision of a copy of a piece of software in binary or source code form to another entity (an individual or organization outside your company or organization). - The GPL V3 uses the term “conveyance” instead. The right to distribute verbatim source code and derivative works (i.e. modifications applied to the original source code base) is central to the definition of Open Source. There are several interpretations of what constitutes a distribution and what triggers license obligations with that respect. - License interpretations are outside the scope of this course. Consult with your Legal counsel on this. Samsung Open Source Group 16
  17. 17. Use and Modification The rights to use and modify source code are a primary benefit of open source licenses. Many Open Source Licenses, including the GPL, do not restrict internal use or development within the licensee’s enterprise (unlimited copies, users, etc.). Samsung Open Source Group 17
  18. 18. Derivative Work The term derivative work refers to a new work based upon an original work to which enough original creative work has been added so that the new work represents an original work of authorship rather than a copy. The interpretation of what constitutes a derivative work is subject to debate in the FOSS community and within FOSS legal circles. - It is best to assume the broadest interpretation of the license terms and not to rely on any legal ambiguity. Samsung Open Source Group 18
  19. 19. License Reciprocity License reciprocity is a term that describes the requirement to license distribution of derivative works under the same terms as the original work. Example of license reciprocity from the GPL version 2: “You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed...under the terms of this License.” Samsung Open Source Group 19
  20. 20. License Proliferation 1 of 2 License proliferation is a term that refers to the problems created when additional software licenses are written for software packages. The issue stems from the tendency for organizations to write new licenses in order to address real or perceived needs for their software releases. Samsung Open Source Group 20
  21. 21. License Proliferation 2 of 2 Often when a software developer would like to merge portions of different software programs they are unable to do so because the licenses are incompatible. - When software under two different licenses can be combined into a larger software work, the licenses are said to be compatible. As the number of licenses increases, the probability that a FOSS developer will want to merge software together that are available under incompatible licenses increases. There is also a greater cost to companies that wish to evaluate every FOSS license for software packages that they use. Samsung Open Source Group 21
  22. 22. License Compatibility License compatibility is a term that refers to the problem encountered when combining source code originating from different software components licensed under incompatible licenses making it impossible to combine the source code to create a new software component. The FSF provides the following example to illustrate the case of license compatibility: A license p is compatible with a license q (or is q-compatible) if A work licensed under p can be distributed under the terms of q. Example: - The X11 license is compatible with the GPL version 2, because works licensed under the X11 license, can be distributed under the terms of the GPL. Samsung Open Source Group 22
  23. 23. GPL Compatibility GPL compatibility refers to the situation of determining if a certain license has compatible terms with the GPL. Many of the FOSS licenses, such as the BSD license and the LGPL, are GPL-compatible, meaning that their source code can be combined with a source code that is licensed under the GPL without conflict; the new program resulting from the combination would have to be licensed under the GPL applied. Other FOSS and proprietary software licenses are not GPL-compatible since they have conflicting terms and conditions. Reference: http://www.fsf.org/licensing/licenses/ Samsung Open Source Group 23
  24. 24. How are the various GNU licenses compatible with each other? Samsung Open Source Group 24
  25. 25. Dual licensing Dual licensing refers to the practice of distributing software under two different sets of terms and conditions. When software is dual licensed, recipients can choose which terms they want to use or distribute the software under. Example: MySQL - MySQL is available under a dual license model: Commercial or GPL. Samsung Open Source Group 25
  26. 26. Attribution Notice An attribution notice is a notice included in the product documentation that acknowledges the identity of the original authors of the FOSS included in the product. Samsung Open Source Group 26
  27. 27. Copyright Notice A copyright notice is an identifier placed on copies of the work to inform the world of copyright ownership. Example: Copyright © Ibrahim Haddad (2011). All Rights Reserved. Samsung Open Source Group 27
  28. 28. License Notice A license notice is a notice that acknowledges the license terms and conditions of the FOSS included in the product. Samsung Open Source Group 28
  29. 29. Modification Notice A modification notice is a notice of the modifications made to the source code in a change log file, such as those required by the GPL and LGPL. Example of a modification notice at the beginning of the source code file: /* * Date Author Comment * ------ --------- -------------- * 01/05/2010 Ibrahim Haddad Fixed memory leak in FastForward() * */ Samsung Open Source Group 29
  30. 30. Introduction to Open Source Compliance Samsung Open Source Group 30 I am not a lawyer These slides do not provide any legal advice Please consult with your legal counsel if you need specific legal advice
  31. 31. A Changing Business Environment Middleware Commercial Applications (3rd Party) Proprietary Applications (Proprietary, 3rd party or a mix) Proprietary OS Samsung Open Source Group 31 Open Source Applications (possibly include Open Source code) Middleware Proprietary Applications (Open Source, Proprietary, 3rd party or a mix) Linux OS Open Source Driver Chip Open Source Driver Chip Commercial Applications (possibly include Open Source code) Chip Proprietary Driver Chip Proprietary Driver Chip Proprietary Driver Chip Proprietary Driver
  32. 32. A Changing Business Environment High Level Architecture of a Traditional Software Platfor Applications (3rd Party Commercial / Proprietary ) Middleware (3rd Party Commercial / Proprietary ) Operating System (3rd Party Commercial / Proprietary ) Drivers (3rd Party Commercial / Proprietary ) H/W Chips (Multiple Vendors) m • Commercial licenses are negotiated • There is a limited number of licenses • The business environment is very predictable • Companies ensure contractual protection through their commercial contracts and licenses • Risks are mitigated through license negotiation • The providers of each software component are known Samsung Open Source Group 32
  33. 33. A Changing Business Environment Proliferation of FOSS in Modern Software Platforms • Licenses are not negotiated; they are imposed • There are potentially tens of licenses involved • The business environment is not as predictable as in a purely commercial environment • There are potentially thousands of contributors to the various FOSS used • The origin of some components may not clear • Maintenance and support are variable and “self-service” • Risks are mitigated through design, engineering practices and compliance Applications (3rd Party / Proprietary / FOSS) Middleware (3rd Party / Proprietary / FOSS) GNU Linux Operating System FOSS Drivers H/W Chips (Multiple Vendors) Samsung Open Source Group 33
  34. 34. Mitigating Risks Through Design Establishing an OSS-friendly architecture • Modular • Open, published interfaces • Availability of OSS components Samsung Open Source Group 34 Choosing Optimal OSS Components • Architectural compatibility • Functional fit • Maturity of code and community • Compatibility of license with intended use • Availability of maintenance and support • Availability of indemnification
  35. 35. Mitigating Risks Through Compliance Practices Identification of the origin and license of used software Identification of license obligations Fulfillment of license obligations when product ships Samsung Open Source Group 35
  36. 36. What is FOSS Compliance? Compliance means that users of FOSS must observe all the copyright notices and satisfy all the license obligations for the FOSS they use. In addition, companies using FOSS in commercial products, while complying with the terms of FOSS licenses, want to protect their intellectual property and that of third party suppliers from unintended disclosure. Samsung Open Source Group 36
  37. 37. What is FOSS Compliance? Open Source Compliance refers to the aggregate of - policies - processes - training - tools that enables an organization to effectively use open source software and contribute to open communities while - respecting copyrights, - complying with license obligations, and - protecting the organization's intellectual property and that of its customers and suppliers. Samsung Open Source Group 37
  38. 38. What Basic Compliance Obligations Must Be Satisfied? OSS license obligations generally are triggered when external distribution occurs. - Code intended only for internal use sometimes gets distributed later on, so compliance practices should be applied to internal code, too. Depending on the license(s) involved, obligations could consist of: - Inclusion of copyright and license in the source code and/or product - documentation or user interface, so that downstream users know the origin of the software and what their rights are. - Disclaimers of warranty on behalf of the authors - Notices as to source code availability – for original work, for combined work or modifications, and so on - Etc. Analysis performed during review of intended open source use is needed to clarify obligations Samsung Open Source Group 38
  39. 39. Compliance Objectives 1. Comply with third party software supplier contractual obligations in light of FOSS licensing obligations 2. Facilitate effective usage of FOSS in commercial products 3. Protect commercial product differentiation while complying with FOSS contractual obligations Samsung Open Source Group 39
  40. 40. Compliance Benefits • Increased understanding of the benefits of FOSS and how it impacts your organization • Increased understanding of the costs and risks associated with using FOSS • Better relations with the FOSS community and FOSS organizations • Increased knowledge of available FOSS solutions • Be prepared for possible acquisition, sale, new product or service release, where compliance assurance is mandatory before the completion of any of these transaction • Improve your overall FOSS strategy using the results from your compliance program Samsung Open Source Group 40
  41. 41. Failure to Comply • Some companies’ lack of compliance with FOSS license obligations has resulted in: - Companies being forced by third parties to block product shipment until the fulfillment of FOSS license obligations have been verified - Companies needing to pay undisclosed sums of money for breach of FOSS licenses - Companies being mandated by Court to establish a more rigorous Open Source compliance program and appoint a “Open Source Compliance Officer” to monitor and ensure compliance with FOSS licenses - Companies losing their product differentiation and intellectual property rights protection when required to release source code to the FOSS community and license it royalty-free - Companies suffering negative press and unwanted public scrutiny as well as damaged relationships with customers, suppliers and the FOSS community Samsung Open Source Group 41
  42. 42. The Compliance Approach in a Nutshell Samsung Open Source Group 42
  43. 43. When a vendor discloses FOSS, what do they need to tell you? • Package name • Version • Original download URL • License and License URL • Description • Modified? • Dependencies? • Intended use in your product • First product release that will include the package • Development team's point of Samsung Open Source Group 43 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.
  44. 44. What should be verified about the disclosure? • Completeness, consistency, accuracy - Use tools whenever source code is available to scan for open source • Does the declared license match what's in the code files? • Do the version numbers match? • Does the license truly permit the proposed use of the software? - Example: License for development but not distribution Samsung Open Source Group 44
  45. 45. What else will you need from the supplier besides disclosure? • Whatever is needed to satisfy obligations, including - Copyright notices and attributions - License text - Source code (including modifications made by the supplier) for open source that carries an obligation to offer source code to recipients Samsung Open Source Group 45
  46. 46. Compliance Failures: What are they, and how to avoid them? Samsung Open Source Group 46 I am not a lawyer These slides do not provide any legal advice Please consult with your legal counsel if you need specific legal advice
  47. 47. Type of Compliance Failures • Intellectual property (IP) failures • License failures • Compliance process failures Samsung Open Source Group 47
  48. 48. Intellectual Property Failures • These failures evolve around the contamination of proprietary, third party or FOSS code with source code that comes with incompatible or conflicting licenses. • Such failures may result in companies losing their product differentiation through the release of the source code to the FOSS community. Samsung Open Source Group 48
  49. 49. Example of Intellectual Property Failures Failure Type & Description Discovery Avoidance Inclusion of FOSS into proprietary or 3rd party code: This type of failure occurs during the development process when engineers add FOSS code into proprietary or 3rd party source code in the form of copy and paste into proprietary or 3rd party software. This type of failure can be discovered by scanning the source code for possible matches with: • FOSS source code • Copyright notices Automated source code scanning tools are used for this purpose Samsung Open Source Group 49 This type of failure can be avoided by: • Offering training to engineering staff to bring awareness to compliance issues and to the different types and categories of FOSS licenses and the implications of including FOSS source code in proprietary source code • Conducting regular source code scanning for all the source code in the build environment (proprietary, 3rd party and FOSS) which will flag
  50. 50. Example of Intellectual Property Failures Failure Type & Description Discovery Avoidance Linking of FOSS into proprietary source code (or vice versa): This type of failure occurs as a result of linking software (FOSS, proprietary, 3rd party) that have conflicting and Incompatible licenses, or if the FOSS has a license with a “viral effect”. This type of failure can be discovered using the dependency tracking tool that allows you to discover linkages between different software components. Samsung Open Source Group 50 This type of failure can be avoided by: 1. Offering training to engineering staff to avoid linking software components with conflicting licenses 2. Continuously running the dependency tracking tool over your build environment Inclusion of proprietary code into FOSS through source code modifications This type of failure can be discovered using the bill of materials difference tool to identify and analyze the source code you introduced to the FOSS. This type of failures can be avoided by: 1. Offering training to engineering staff 2. Conducting regular code inspections
  51. 51. Possible Results from Intellectual Property Failures • An injunction preventing a company from shipping a product • A requirement to publish a company’s proprietary source code under an open source license • Significant re-engineering to eliminate incompatible licenses (especially between 3rd party proprietary licenses and FOSS licensed code) • Embarrassment or worse with customers, distributors, 3rd party proprietary software suppliers and FOSS suppliers Samsung Open Source Group 51
  52. 52. License Compliance Failures • While typically less damaging than Intellectual Property Failures, License Compliance failures may result in: - An injunction preventing a company from shipping a product until source code is published - Support or Customer Service headaches as a result of version mis-matches - Embarrassment and/or bad publicity with customers and FOSS suppliers Samsung Open Source Group 52
  53. 53. License Compliance Failures Failure Type & Description Avoidance Source Code Publishing Failure This type of failure can be avoided by making source code publishing a checklist item in the product release cycle before the product becomes available in the market place. Source Code Versioning Failure This type of failure can be avoided by adding a verification step into the compliance process to ensure that the exact version of source code that corresponds to the distributed binary version is being published. Failure to Publish Source Code Modifications This type of failure can be avoided by: 1. Re-introducing the revised software component in the compliance process 2. Adding the “compute diffs” of any modified FOSS to the checklist item before releasing FOSS used in the product Samsung Open Source Group 53
  54. 54. License Compliance Failures Failure Type & Description Avoidance Failure to mark FOSS Source Code Modifications: Failure to mark FOSS source code that has been changed or failure to include a description of the changes. This type of failure can be avoided by: 1. Adding source code marking as a checklist item before releasing the source code to ensure you flag all the source code you introduced to the original copy you downloaded 2. Conducting source code inspections before releasing the source code 3. Adding a milestone in the compliance process to verify that changed source code has been marked as such 4. Offering training to engineering staff to ensure they modify the change log of all FOSS or proprietary software that is going to be released to the public Samsung Open Source Group 54
  55. 55. Compliance Process Failures • When the compliance process fails to function correctly any one of the Intellectual Property or License Compliance failures might occur with their respective consequences. • In addition Compliance Process failures also tend to: - Negatively impact product development and release schedules - Introduce bugs due to undocumented component version skew Samsung Open Source Group 55
  56. 56. Compliance Process Failures Description Avoidance Prevention Failure to submit an OSRB request to use FOSS This type of failure can be avoided by offering training to Engineering staff on the company’s OSS policies and processes. If a FOSS component was found In the build system and does not have a corresponding compliance ticket, then a new ticket (usage request form) is then re-generated Samsung Open Source Group 56 This type of failure can be prevented by: 1. Conducting periodic full scan for the software platform to detect any “undeclared” 2. Offering training to engineering staff on the company’s OSS policies and processes 3. Including compliance in the employees performance review Failure to take the FOSS training This type of failure can be avoided by ensuring that the completion of the FOSS training is part of the employee’s professional development plan and it is monitored for completion as part of the performance review This type of failure can be prevented by mandating engineering staff to take the OSS training by a specific date
  57. 57. Compliance Process Failures Description Avoidance Prevention Failure to audit the source code This type of failure can be avoided by: 1. Conducting periodic source code scans/audits 2. Ensuring that auditing is a milestone in the iterative development process Samsung Open Source Group 57 This type of failure can be prevented by: 1. Providing proper staffing as to not fall behind in schedule 2. Enforcing periodic audits Failure to resolve the audit findings (analyzing the “hits” reported by the tool) This type of failure can be avoided by not allowing a compliance ticket to be resolved (i.e. closed) if the audit report Is not finalized. A compliance ticket is closed only if there are no open sub-tasks attached to it and no open issues) This type of failure can be prevented by implementing a policy in the compliance management system that does not allow it to close a compliance ticket if it has open sub-tasks or open issues Failure to submit OSRB form in time This type of failure can be avoided by filing OSRB requests early even if engineering did not yet decide on the adoption of the FOSS source code This type of failure can be prevented through education
  58. 58. GPL Violations 101 Samsung Open Source Group 58 I am not a lawyer These slides do not provide any legal advice Please consult with your legal counsel if you need specific legal advice
  59. 59. Agenda This presentations provides an overview of several compliance disputes and present a brief discussion on who enforced compliance, the reasons for non compliance and how the dispute was resolved. Samsung Open Source Group 59
  60. 60. Introduction Several organizations are involved in enforcing compliance on behalf and with the help of FOSS developers and enthusiasts who monitor product announcements and license compliance activities. The most notable enforcers are: - Free Software Foundation (FSF) - Software Freedom Law Center (SFLC) - Software Freedom Conservancy (SFC) - gpl-violations.org Samsung Open Source Group 60
  61. 61. Partial List of Companies Targeted with Non-Compliance Samsung Open Source Group 61 And many more …
  62. 62. Example: The Trail of the CISCO Compliance Problem FSF accused Cisco of a license violation After much bad press, s ource code was made available by Samsung Open Source Group 62 adopted this technology i nto its WRT54G wireless broadban d router bought for $500M in 2003 Major loss of Cisco’s Intellectual Property rights an d competitive advantage. Loss of revenue est. $50 M used GPL code to custo mize Broadcom’s standard Li nux distribution embedded the code i n one of its chipsets How did this story end?
  63. 63. What have we learned? Samsung Open Source Group 63
  64. 64. Lessons Learned from Compliance Disputes • Open Source compliance disputes move rapidly to lawsuits. • Based on the publically known compliance disputes, none of the defendants chose to challenge the allegations. Samsung Open Source Group 64
  65. 65. Lessons Learned from Compliance Disputes • All of the disputes reached a settlement agreement which included one or more of the below mentioned terms: - Company to take necessary action to become compliant Our number one goal in any GPL violation case is to get proper and full compliance with the license; everything else is secondary. – David Turner, GPL Compliance Engineer, Free Software Foundation - Company to appoint a compliance officer to monitor and ensure GPL compliance Samsung Open Source Group 65
  66. 66. Lessons Learned from Compliance Disputes Company to notify previous recipients of the product that the product contains GPL code and inform them of their rights to receive a copy of the source code In fact, in nearly every GPL enforcement cases that I've worked on in my career, the fact that infringement had occurred was never in dispute. The typical GPL violator started with a work under GPL, made some modifications to a small portion of the codebase, and then distributed the whole work in binary form only. It is virtually impossible to act in that way and still not infringe the original copyright. – Bradley M. Kuhn, Policy Analyst and IT Director, Software Freedom Law Center Samsung Open Source Group 66
  67. 67. Lessons Learned from Compliance Disputes • Company to publish licensing notice on their website • Company to provide additional notices in product publications • Company to make available the complete and corresponding source code used in their product freely available on its website • Company to cease binary distribution of the FOSS in question until it has published complete corresponding source code on its web site • Company to pay an undisclosed amount of financial consideration to the plaintiffs • Company to make available the complete and corresponding source code used in their product, releasing code that contains their product differentiation as open source under the GPL. Samsung Open Source Group 67
  68. 68. Settlement with WestingHouse • Case was settled early August 2010 and included: - ~ 150,000 USD in damages, lost revenue and lawyer fees - Millions $ in inventory lost (HDTV using busy box were donated to charity) Samsung Open Source Group 68
  69. 69. Lessons Learned from Compliance Disputes - Company incurred costs associated with non-compliance. The costs included: ∙ Discovery and diligence in response to the compliance inquiry where company teams spent time to investigate and perform diligence in relation with the inquiry ∙ Settlement costs ∙ Outside and in-house legal costs ∙ Damage to brand, reputation, and credibility ∙ Ongoing enforcement costs and compliance costs Samsung Open Source Group 69
  70. 70. Lessons Learned from Compliance Disputes • In almost all cases, the failure to comply with the FOSS license obligations has also resulted in: - Public embarrassment - Negative press - Damaged relationships with some of their customers, suppliers and most notably the FOSS community Samsung Open Source Group 70
  71. 71. Ensure Compliance Prior to Product Shipment To avoid being successfully challenged with regard to FOSS compliance, companies must make compliance a priority before product ship. Companies must establish and maintain consistent compliance policies and procedures and ensure that FOSS licenses, proprietary and 3rd party licenses co-existence well before shipment. Samsung Open Source Group 71
  72. 72. Ensure Compliance Prior to Product Shipment To that effect, companies need to implement an end-to-end FOSS management infrastructure that will allow it to: - Identify all FOSS it is using in its products - Collect the applicable FOSS licenses for review by the legal department - Develop FOSS use and distribution policies and policies - Institutionalize FOSS and compliance training to ensure that all employees are aware of the legal risks involved with using FOSS and aware of company policies - Ensure that your software vendors, suppliers and subcontractors are adhering to FOSS license requirements - Furthermore, companies need to know not only which FOSS they are using, but also how they are using them. Samsung Open Source Group 72
  73. 73. Ensure Compliance Prior to Product Shipment As a company that uses FOSS in commercial product, it is best to create and maintain a good relationship with the FOSS community, in particular, the specific communities related to the FOSS projects you use and deploy in your commercial product. In addition, good relationships with open source organization can be very helpful in advising on best way to be compliant and also help out if you experience a compliance issue. Samsung Open Source Group 73
  74. 74. GPL 2.0 and LGPL 2.1 Obligations Samsung Open Source Group 74 I am not a lawyer These slides do not provide any legal advice Please consult with your legal counsel if you need specific legal advice
  75. 75. Background • GPL was originally written by Richard Stallman in 1989 for the GNU project. • The GPL grants rights to copy, modify, and distribute the program subject to certain conditions. • The license focuses on making future software more widely accessible by requiring that any distribution of derivative works must be under the terms of the GPL. Samsung Open Source Group 75
  76. 76. Versions • There are three versions of GNU GPL: - GNU GPL Version 1 ∙ February 1989: the original version - GNU GPL Version 2 ∙ June 1991: the second version and currently is the most widely used Open Source license - GNU GPL Version 3 ∙ June 2007: the latest version Samsung Open Source Group 76
  77. 77. Fulfilling Obligations of the GPL v2 (1/9) • For purposes of this discussion, we focus on GPL version 2. • Please refer to “Practical Guide to GPL Compliance” published by the Software Freedom Law Center and available online at www.softwarefreedom.org • If you distribute a software package licensed under the GPL version 2, you need to perform certain tasks to fulfill the GPL version 2 license obligations. Samsung Open Source Group 77
  78. 78. Fulfilling Obligations of the GPL v2 (2/9) • Include a copy of the GPL license in documentation available to the end-user (usually in a product or user manual) Samsung Open Source Group 78
  79. 79. Fulfilling Obligations of the GPL v2 (3/9) • Provide the source code including any modifications you have made under the GPL v2 Samsung Open Source Group 79
  80. 80. Fulfilling Obligations of the GPL v2 (4/9) • Provide the modifications you introduced to the GPL v2 licensed source code under the GPL v2 Samsung Open Source Group 80
  81. 81. Fulfilling Obligations of the GPL v2 (5/9) • Mark the source code modifications you have made and carry a prominent change log describing the changes in the source code. • An example of a change log file provides the date of the change, who made it and a brief comment: /* * Date Author Comment * ------- ---------- -------------- * 01/02/2010 Ibrahim Haddad Fixed memory leak in play_record() */ Samsung Open Source Group 81
  82. 82. Fulfilling Obligations of the GPL v2 (6/9) • Inform the users of how they can obtain the source code - This obligation is usually referred to as a written offer to provide source code upon request. - Companies usually either provide a URL from which users can download the source code or contact information for users to contact and received information on how to receive the source code. Samsung Open Source Group 82
  83. 83. Fulfilling Obligations of the GPL v2 (7/9) • Update the copyright notice and the change log notice for any files that you have modified in the source code: - For the copyright notice, you must keep intact existing copyright notices and add your own. - For each file that you modified, each time, you need to update the change log to reflect the date, author and brief description of the modification made. Samsung Open Source Group 83
  84. 84. Fulfilling Obligations of the GPL v2 (8/9) • Add a copyright notice, a license notice, change log notice and a disclaimer notice for any new source files that you add to the GPL v2 source code: - Example of a copyright notice at the beginning of the source code file: /* * Copyright © 2010, FooBar Inc. */ - Example of a license notice at the beginning of the source code file: /* * This code is licensed under the GPL version 2. * See <README or COPYING file> for the full GPL notice * and license text. */ Samsung Open Source Group 84
  85. 85. Fulfilling Obligations of the GPL v2 (9/9) • Example of a change log at the beginning of the source code file: /* * Date Author Comment * ------- ---------- -------------- * 01/04/2010 Ibrahim Haddad - Fixed warning in foo.c * - Fixed a bug in readdir */ • Example 2 of a license notice at the beginning of the source code file: /* * This program is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or (at * your option) any later version. * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software Foundation, * Inc., 675 Mass Ave, Cambridge, MA 02139, USA */ Samsung Open Source Group 85
  86. 86. LGPL v2 – Lesser General Public License • LGPL v2.1 is typically used for libraries • Similar to GPL v2 but dynamic linkage to GPL v2 incompatible components (including proprietary) is allowed. • License obligations summary: - Must include a copy of the license in documentation available to the end-user - Must inform user of how to obtain the source code and that it is covered by LGPL v2.1 - Must give prominent notice that the library is used in the work - Must redistribute source code for the library [including modifications, if any] - When redistributing source code, must include a copy of the license - Source code modifications must be clearly marked as such and carry a prominent change log - Modifications become LGPL v2.1 - End-user must be able to replace the library Samsung Open Source Group 86
  87. 87. Affero GPL • There are two versions of the Affero GPL: - Affero General Public License version 1: March 2002 (based on GPL v2) - GNU Affero General Public License version 3: November 2007 (based on GPL v3) • Both versions are designed to close a perceived application service provider "loophole" (the "ASP loophole") in the ordinary GPL, whereby using but not distributing the software, the copyleft provisions are not triggered. • Each version differs from the version of the GNU GPL on which it is based in having an additional provision addressing use of software over a computer network. Samsung Open Source Group 87
  88. 88. Affero GPL • The additional provision requires that the complete source code be made available to any network user of the AGPL-licensed work, typically a Web application. • The FSF has recommended that the GNU AGPLv3 be considered for any software that will commonly be run over a network. • The Open Source Initiative approved the GNU AGPLv3 as an open source license in March 2008. Samsung Open Source Group 88
  89. 89. Compliance End-to-End Management Samsung Open Source Group 89 I am not a lawyer These slides do not provide any legal advice Please consult with your legal counsel if you need specific legal advice
  90. 90. Introduction • Compliance management consists of a set of actions that controls the intake and distribution of FOSS used in commercial products. • The result of compliance due diligence is an identification of all FOSS used in the product and a plan to meet the FOSS license obligations. Samsung Open Source Group 90
  91. 91. Compliance End-to-End Process • Compliance management activities provide a record of diligence with regard to the usage of FOSS and provide appropriate compliance records demonstrating the diligence process and allowing you to build a product map identifying all the software components of the product and their origin from an authorship and license perspective. Incoming FOSS Samsung Open Source Group 91 Applicable FOSS + modifications made available Compliance Due Diligence
  92. 92. Incoming Software Identification Audit Resolve Issues Reviews Approvals Registration Samsung Open Source Group 92 Notices Verifications Distribution Verifications Proprietary Software 3rd Party Software FOSS Outgoing Software Open Source BoM: Notices & Attributions Written Offer Scan source code and identify possible code matches – and – Confirm origin and license of source code Resolve any issues (code matched) – and – Ensure linkages are in line with company policies Identify source code changes in the build environment (new, modified and retired components) Verify source code packa ges for distribution – and – Verify appropriate notice s are provided Record approved software/version in inventory per product and per release Publish source code, notices and provide writt en offer Review and approve compliance record of every single software component Compile notices for publication Post publication verifications Compliance Management End-to-End
  93. 93. Compliance End-to-End Process • Compliance due diligence involves the following: - FOSS used in the product has been identified, reviewed and approved - The product implementation includes only the approved FOSS - FOSS used in the product have been registered in the FOSS inventory system - All obligations related to the use of licensed material have been identified - Appropriate notices have been provided in the product documentation: these include a written offer to provide source code, attributions and copyright notices - Source code including modifications (when applicable) have been prepared and ready to be made available once the product ships - Verifications of all the steps in the process Samsung Open Source Group 93
  94. 94. Elements of Compliance Management 1. Identification of FOSS 2. Auditing source code 3. Resolving any issues uncovered by the audit 4. Completing reviews 5. Receiving approval to use FOSS 6. Updating software inventory 7. Updating end user documentation 8. Performing verification of all previous Samsung Open Source Group 94 steps prior to distribution 9. Distributing FOSS including any modifications (if any) when applicable 10. Performing final verifications in relation to distribution
  95. 95. Identification of FOSS • Pre-requisites: - One of the following conditions is met: - An incoming OSRB form requesting using a specific FOSS - A discovery of a FOSS being used (without proper authorization) via a platform scan - A discovery of a FOSS being used as part of third party software Samsung Open Source Group 95 • Outcome: – A compliance record is created (or updated) for the FOSS – An audit is requested to scan the source code Incoming: FOSS Outgoing: FOSS + Mods Identification Audit Resolve Iss ues Reviews Approvals Registratio n Notices Verification s Distribution Verification s
  96. 96. Identification of FOSS in a Product • Incoming request to use FOSS • Auditing the full platform code • Third party software provider due diligence • Auditing proprietary software components • FOSS component added to the repository but it does not correspond to a usage form Samsung Open Source Group 96
  97. 97. Auditing Source Code • Auditing source code is the second step in the compliance due diligence. • It consists of scanning the source code using automated source code analysis tools to discover source code matching FOSS source code. Incoming: FOSS Samsung Open Source Group 97 Outgoing: FOSS + Mods Audit identification Resolve Issue s Reviews Approvals Registration Notices Verifications Distribution Verifications
  98. 98. Auditing Source Code (Goals) • The auditing personnel perform a source code scan iteratively from one release to another release label, to build a chain of evidence that what is included in the release is compliant to the various applicable FOSS license. • The goals with the audit are to: - Identify the bill of material of the component in question - Confirm the origin(s) of the source code - Flag dependencies, code matches and licensing conflicts - Understand the licenses that govern its use, modification and distribution - Identify the obligations of the various licenses Samsung Open Source Group 98
  99. 99. Auditing Source Code Pre-requisites: • A proper compliance record is created capturing all necessary information about the usage of that specific FOSS and providing the location of the source code within the internal build system. • In some cases, specifically when a full platform scan is done, a FOSS component may be scanned before having a proper compliance report. In this case, a record is created when the FOSS component is discovered. Samsung Open Source Group 99 Outcome: • An audit report identifying the origins and licenses of the source code
  100. 100. Resolving Issues • In this step of the compliance due diligence, all identified issues during the auditing step are resolved. • In this case, the OSRB Chair will assign working tickets to the appropriate engineers to rework the code and report on completion. • Once the engineers have resolved the identified issues, the OSRB Chair will issue a new audit to get a confirmation that the resolved issues do not exist anymore. • The output from the auditing activities is a report that flag licensing conflicts such as including GPL code in a proprietary software component that has a conflicting license with the GPL. Samsung Open Source Group 100
  101. 101. Resolving Issues Pre-requisites: • A source code scan has been completed • An audit report is generated identifying the origins and licenses of the source code and flagging source code files that were not identified and that need further investigation Samsung Open Source Group 101 Outcome: • A resolution for each of the flagged files in the report and a resolution for any flagged license conflict Incoming: FOSS Outgoing: FOSS + Mods Resolving Issues identification Audit Reviews Approvals Registration Notices Verifications Distribution Verifications
  102. 102. Reviews • The goal of the various reviews is to ensure that all involved parties have reviewed the audit report, agree on the how the discovered issues have been resolved. • For any given software components, the reviewers of the compliance ticket are: - Internal package owner - OSRB chair (Compliance Officer) - Auditing personnel - Legal counsel - OSRB engineering representative - OSRB (Open Source Review Board) - OSEC (Open Source Executive Committee) Samsung Open Source Group 102
  103. 103. Reviews Pre-requisites: • Source code has been audited • All identified issues have been resolved Samsung Open Source Group 103 Outcome: • OSRB members perform an architecture review and a linkage analysis for the specific component and mark it as ready for the next step (i.e. Approval) if no issues were uncovered Incoming: FOSS Outgoing: FOSS + Mods Reviews identification Audit Resolve Issues Approvals Registration Notices Verifications Distribution Verifications
  104. 104. Architecture Review • The goal with the architecture review is to analyze the interactions between the FOSS code and third party and proprietary code. • The result of the architecture review is an analysis of the licensing obligations that may extend from the FOSS components to the proprietary components. • The internal package owner, the OSRB engineering representative and the FOSS export usually perform the architecture review. If they identify a dependency resulting in a licensing conflict, the OSRB Chair will issue ticket to Engineering to resolve the Samsung Open Source Group 104
  105. 105. Architecture Review – Example Legend Proprietary 3rd Party Commercial GPL LGPL FOSS Permissive Function call Socket interface (fc) (si) System call (sc) Shared headers (sh) Samsung Open Source Group 105 User Space Kernel Space Hardware [Insert Components] [Insert interaction method] [Insert Components] [Insert interaction method] [Insert Components]
  106. 106. Linkage Analysis Review • The goal with linkage analysis is to find potentially problematic code combinations at the static and dynamic link level, such as linking a GPL library to proprietary source code component. • The OSRB Chair performs this review using an automated tool. • If the OSRB Chair identifies a linkage conflict, it is reported to Engineering to resolve it by reworking the source code. Samsung Open Source Group 106
  107. 107. Approvals • In this step, the software component is either approved for usage in the product or not. • The approval comes from the OSRB. Incoming: FOSS Samsung Open Source Group 107 Outgoing: FOSS + Mods Approvals identification Audit Resolve Issue s Reviews Registration Notices Verifications Distribution Verifications
  108. 108. Registration • Once is software component has been approved for usage in a product, its compliance ticket will be update to reflect the approval and it will be added to the software inventory that tracks FOSS that used in products. Incoming: FOSS Samsung Open Source Group 108 Outgoing: FOSS + Mods Registration identification Audit Resolve Issue s Reviews Approvals Notices Verifications Distribution Verifications
  109. 109. Registration • A software component is approved based on a specific version and usage model in a specific product version. • If a new version of this software component is available, engineering teams need to go through the process again to get approval for using the new version. • If engineering teams want to use the same software component in a different product, they need to issue a new request. • Approvals are dependent on usage models and for instance, a GPL software component that is approved for inclusion in Product A will not be approved for inclusion in Product B based on a different usage model. Samsung Open Source Group 109
  110. 110. Notices • Companies using FOSS in a commercial product must: - Acknowledge the use of FOSS by providing full copyright and attribution notices - Inform the end user of their product on how to obtain a copy of the FOSS source code (when applicable, for example in the case of GPL and LGPL) - Reproduce the entire text of the license agreements for the FOSS code included in the product. Incoming: FOSS Samsung Open Source Group 110 Outgoing: FOSS + Mods Notices identification Audit Resolve Issue s Reviews Approvals Registration Verifications Distribution Verifications
  111. 111. Notices • If companies are non-compliant with copyright license obligations, they can be sued by the copyright holder for copyright infringement and can potentially lose the right to use and distribute, statutory damages, and/or profit derived from the infringement. In order to fulfill documentation obligations, appropriates notices must be included with the product. • In this step of the compliance due diligence, the OSRB Chair prepares the notices and passes it to the appropriate departments for fulfillment Samsung Open Source Group 111
  112. 112. Pre-Distribution Verifications • The next step in the compliance due diligence is to decide on the method and mode of distribution, type of packages to distribute and mechanism of distribution Incoming: FOSS Samsung Open Source Group 112 Outgoing: FOSS + Mods Verifications identification Audit Resolve Issue s Reviews Approvals Registration Notices Distribution Verifications
  113. 113. Pre-Distribution Verifications • Part of the pre-distribution verifications is to ensure that: - FOSS packages destined for distribution have been identified and approved - The source code packages (including modifications) have been verified to match the binary equivalence shipping in the product - All appropriate notices have been included in the product documentation to inform end-users of their right to request source code for identified FOSS Samsung Open Source Group 113
  114. 114. Pre-Distribution Verifications Pre-requisites: • Component has been approved for usage • Component it has been registered in the software inventory • All notices have been captured and sent for fulfillment Samsung Open Source Group 114 Outcome: • Decision on distribution method and mode • Ensure that all the pre-distribution verifications have been successfully completed
  115. 115. Distribution • Once all pre-distribution verifications have been completed, the next step is to upload the FOSS packages to the distribution web site, identified with labels as to which product and version it corresponds to. Incoming: FOSS Samsung Open Source Group 115 Outgoing: FOSS + Mods Distribution identification Audit Resolve Issue s Reviews Registration Notices Verifications Approvals Verifications
  116. 116. Distribution Pre-requisite: All pre-distribution verification have been checked and no issue is discovered Outcome: The source code of the component in question is uploaded to the web site for distribution (if that was the distribution method of choice) Samsung Open Source Group 116
  117. 117. Final Verifications • Once you upload the FOSS packages to the distribution web site, there are verification steps to validate that the package has been uploaded correctly, can be downloaded and uncompressed on an external computer without errors. Incoming: FOSS Samsung Open Source Group 117 Outgoing: FOSS + Mods Verifications identification Audit Resolve Issue s Reviews Approvals Notices Verifications Distribution Registration
  118. 118. Final Verifications Pre-requisite: The source code is published on the web site Outcome: Verifications that the source code is: Uploaded correctly Corresponds to the same version that was approved Accessible for download for the public Samsung Open Source Group 118
  119. 119. Practical Guidelines Samsung Open Source Group 119 I am not a lawyer These slides do not provide any legal advice Please consult with your legal counsel if you need specific legal advice
  120. 120. General Guidelines • Request formal approval for each open source software you are using in product or in SDK (refer to your company’s Usage Policy) • Request formal approval for your contribution to open source software (refer to your company’s Contribution Policy) • Save the web site from which you downloaded the open source package and save a mint copy of the package you downloaded • Consult with your manager when you upgrade your open source software version. License changes can occur between versions. • Don’t change or eliminate existing comments in headers • Do not check un-approved code into any source tree without authorization Samsung Open Source Group 120
  121. 121. General Guidelines • Do not re-name open source modules • Do not send modifications to any public source tree without getting approval. Making even small contributions without your company’s permission can compromise your company’s IP (due to implicit or explicit patent licenses) • Do not discuss coding or compliance practices with persons outside the company • Good programming practices are also legal best practices - Clean integration - Modularity - Minimization of data sharing - Transparent APIs Samsung Open Source Group 121
  122. 122. General Guidelines • Clean Bill of Material - Ensure that any in-bound software does not include FOSS. ∙ If it does, you need a complete listing for all FOSS, versions, licenses. - Always audit source code you received from your software providers or alternatively make it a company policy that software providers must deliver you a source code audit report for any source code you receive. • Approval Form for Each FOSS - Request approval for every FOSS you are using in product. • Understand the Risks - Understand the FOSS implications of any software of an entity to be acquired as part of the due diligence performed prior to approval the corporate transaction. Samsung Open Source Group 122
  123. 123. General Guidelines • Upgrading to Newer Versions of FOSS - Ensure that each new version of the same FOSS component is reviewed and approved. When you upgrade the version of a FOSS package, make sure that the license of the new version is the same as the license of the older used version. License changes can occur between version upgrades. If the license changed, contact the OSRB to ensure that compliance records are updated and that the new license does not create a conflict. • Compliance Verification Golden Rule - Compliance is verified on a product-by-product basis: Just because a FOSS package is approved for use in one product does not necessarily mean it will be approved for use in a second product. Samsung Open Source Group 123
  124. 124. General Guidelines • Copy/Paste - Do not copy/paste FOSS code into proprietary or third party source code or vice versa without OSRB approval. - Approvals are given on a case-by-case basis. • Mixing Source Code with Different Licenses - Mixing of different FOSS licenses in a derivative work must be avoided. - Many FOSS licenses are incompatible with each other, especially when mixing licenses with the GPL. - When in doubt, always refer to the FSF resource page on license compatibility available at http://www.fsf.org/licensing/licenses/index_html. - The open source review board in your company must review all cases where more than one type of FOSS license is used and provide approval on a case-by-case basis. Samsung Open Source Group 124
  125. 125. General Guidelines • Source Code Comments - Do not leave any inappropriate comments in the source code that includes private comments, product code names, mention of competitors, etc. • 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. Samsung Open Source Group 125
  126. 126. Thank you. Samsung Open Source Group 126

×