Best practices for open source legal compliance
•Télécharger en tant que PPTX, PDF•
2 j'aime•862 vues
Presented at Sensors Expo and Conference 2015, this session covers: Trends in open source software (OSS); The open source audit and license identification; Developing an OSS process and policy; Compliance; and Legal implications.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (16)
Similaire à Best practices for open source legal compliance
Similaire à Best practices for open source legal compliance (20)
Plus de Rogue Wave Software
Plus de Rogue Wave Software (20)
Dernier
Dernier (20)
Best practices for open source legal compliance
- 1. Best practice recommendations for utilizing open source software (from a Legal Perspective)
- 2. Dave McLoughlin, Director OSS Auditing Presenters Rogue Wave Software Dave.McLoughlin@roguewave.com © 2015 Rogue Wave Software, Inc. All Rights Reserved. Marco Gatti, IP Attorney Brooks Kushman Mgatti@brookskushman.com
- 3. Agenda • Trends in Open Source Software (OSS) • The open source audit and license identification • Developing a OSS process/policy • Compliance • Legal implications © 2015 Rogue Wave Software, Inc. All Rights Reserved.
- 4. Trends in open source Use of open source continues to grow 90% of companies use OSS components in commercial software (Gartner) >80% of a typical Java application is open-source components and frameworks (TechCrunch) 11 million developers worldwide make 13 billion open source requests each year © 2015 Rogue Wave Software, Inc. All Rights Reserved.
- 5. Open source components provide critical functionality Improves developer productivity No license fees Innovation drives open source use “More eyes” improves security Leveraged development effort Apache, Tomcat, Wildfly, Jakarta Commons, Jquery Communities continuously improve features Mature, commoditized applications and libraries Massive peer review © 2015 Rogue Wave Software, Inc. All Rights Reserved.
- 6. Assessing risk in open source For all its benefits, risks exist License risk Failure to comply with OSS license may create liability Security risk The OSS component can include vulnerabilities Support risk Who do you call for help? © 2015 Rogue Wave Software, Inc. All Rights Reserved.
- 7. Managing OSS risk 20% Scanning to discover open of organizations lack meaningful controls over OSS selection and use Scanning to discover open of developers need not prove security of OSS they are using Scanning to discover open of the organizations claim to track vulnerabilities in OSS over time 76% 80% Increased use + few controls = unmanaged risk 11 million developers worldwide make 13 billion open source requests each year © 2015 Rogue Wave Software, Inc. All Rights Reserved.
- 8. OSS audit & license identification © 2015 Rogue Wave Software, Inc. All Rights Reserved. Ad hoc or automated scanning tools Interview developers and build list of OSS Run a scanning tool to find matches Analyze results Review matches: code, copyright, license, urls, author information Find and validate copyright and license Create Bill of Material: OSS and associated licenses Compliance checklist
- 9. Example report © 2015 Rogue Wave Software, Inc. All Rights Reserved. Open Source Bill of Material (BOM) License Information Compliance Information
- 10. OSS best practices OSS Policy Acquisition & approval Support & maintenance Tracking Audit & governanceTraining Legal compliance Community interaction © 2015 Rogue Wave Software, Inc. All Rights Reserved.
- 11. – License requirements – Security requirements – Support requirements Establish OSS policies – Risk tolerance v. OSS value – Recognize development realities – Start small, streamline, and expand Set the guiding principles Institutionalize the policy at the development level © 2015 Rogue Wave Software, Inc. All Rights Reserved.
- 12. Feed and maintain policies OSS Policy Legal Technical Security Business © 2015 Rogue Wave Software, Inc. All Rights Reserved.
- 13. OSS licenses & terms • OSS Developer chooses • Hundreds of pre-existing licenses to choose from • Developers may make their own license © 2015 Rogue Wave Software, Inc. All Rights Reserved.
- 14. Example of license obligations © 2015 Rogue Wave Software, Inc. All Rights Reserved.
- 15. OSS License Potential Conflicts © 2015 Rogue Wave Software, Inc. All Rights Reserved.
- 16. Example – Reviewing Clauses of LGPLv2 • Allows the open source software to be “linked” (“dynamically”) with software without having the OSS terms apply to the proprietary S/W. • Allows developers and companies to integrate LGPL software into their own software without being required to release their proprietary source code ~ depending on integration (i.e., static vs. dynamic linking). • Requires that the open source software is modifiable by an end-user (via source code availability), therefore the LGPL open source software are usually used in the form of a shared library so that there is a clear separation between the proprietary software and open source software. © 2015 Rogue Wave Software, Inc. All Rights Reserved.
- 17. Example - LGPLv2 Two Kinds of “Linking”: Static vs. Dynamic • Static libraries (e.g., .a file): Library of object code which is linked with, and becomes part of the application (i.e., executable). • Dynamically linked shared object libraries (e.g., .dll, .so file): The libraries must be available during compile/link phase. The shared objects are not included into the executable component but are selected during the execution of the executable. Depending on how the developer links the LGPLv2 OSS will determine whether you have to make proprietary software available © 2015 Rogue Wave Software, Inc. All Rights Reserved.
- 18. LGPLv2.1 – Static vs. Dynamic Static Linking Dynamic Linking © 2015 Rogue Wave Software, Inc. All Rights Reserved. The product having an executable that contains an OSS Library header files which dynamically call the OSS Libraries.
- 19. Example - LGPLv2.1 Section 5 © 2015 Rogue Wave Software, Inc. All Rights Reserved.
- 20. LGPLv2.1 Section 6 © 2015 Rogue Wave Software, Inc. All Rights Reserved.
- 21. Lean Header Loaded Header Example - LGPLv2.1 “Loaded Header File”?
- 22. LGPLv2.1 • We researched the FSF’s position on the header file implementation. In 2003, Richard Stallman (the author of the LGPL license) stated as follows: Someone recently made the claim that including a header file always header file always makes a derivative work. That's not the FSF's view. the FSF's view. Our view is that just using structure definitions, typedefs, definitions, typedefs, enumeration constants, macros with simple bodies, with simple bodies, etc., is NOT enough to make a derivative work. It derivative work. It would take a substantial amount of code (coming from code (coming from inline functions or macros with substantial bodies) to substantial bodies) to do that. Based on this interpretation, the OSS header files having template code would follow under FSF’s view of header files not being a derivative work.© 2015 Rogue Wave Software, Inc. All Rights Reserved.
- 23. OSS – Copyright Cases • Jacobsen v. Katzer, 535 F.3d 1373 (Fed. Cir. 2008) • Welte v. Fantec GmbH (6/14/13 – Germany) • XimpleWare Corp. v. Versata © 2015 Rogue Wave Software, Inc. All Rights Reserved.
- 24. Other OSS Copyright Cases © 2015 Rogue Wave Software, Inc. All Rights Reserved.
- 25. Enforcement • Free Software Foundation (FSF) is in some ways the de facto enforcer of the GPL license • FSF conducts a compliance laboratory that investigates violations • FSF is available for hire to assist companies to comply © 2015 Rogue Wave Software, Inc. All Rights Reserved.
- 26. Summary • Three takeaways – Understand the use of OSS – Create Policies that works for your company/organization – Be aware of legal obligations based on OSS license © 2015 Rogue Wave Software, Inc. All Rights Reserved.
Notes de l'éditeur
- The open source revolution is in full swing. It’s been a wonderful tool for software developers. Using open source allows organizations to add tested, proven functionality to their code base, without having to write the code from scratch or purchase third party, proprietary code to add the same functionality. Estimates now indicate over 90% of all companies now use open source in their commercial software, and that up to 80% of all code in new java applications is from open source components. If one looks at public repositories, including the Central Repository and SourceForge, over 13 billion downloads occur every year. This benefit comes with risk, however. The vast majority of companies using open source have little, if any oversight as to the selection and use of the libraries and their licenses. In addition, millions of OSS components with known vulnerabilities are downloaded for use each year. Managing this process better is possible, and what we will be discussing today.
- Mature: Best in class, vetted solutions, leveraged development effort Mature: Apache, Tomcat, Wildfly, Jakarta Commons, JQuery Disruptors: Open source is a sandbox for new ideas Disruptors: OpenStack, Hadoop/Hbase, NodeJS
- We are going to focus on 3 risks in open source software, and best practices for assessing and mitigating those risks. License Risk – Using open source with the wrong license could prevent you from legally distributing an application, or force you to open source your proprietary code. Security Risk – Like any other software, open source can include vulnerabilities. Even when disclosed and fixed, open source being open source, older, vulnerable builds are still available for download. Support Risk – While the acquisition cost of open source is low, the total cost of ownership can be high. Much of this depends on the relative maturity of the project’s community. The takeaway from this is if we are using more and more open source, without putting controls in place, we are inviting unmanaged risk into our applications.
- Open source use is certainly beneficial, and the risks can be mitigated. The root of the problem we see with open source usage is a lack of controls over the selection, use, and monitoring of components. That is, if we are using more and more open source, without putting controls in place, we are inviting unmanaged risk into our applications. Through our research we found that: 76% of the organizations we interviewed admit they have no meaningful controls 80% of the developers state that they can use any open source package they choose, without proving the security of those components Only 20% claim to track vulnerabilities in OSS over time This may be true to the extent that publicized problems, such as Heartbleed, are tracked, but to review, we just learned that 13 billion requests are made each year I personally, have never talked to a security person who can demonstrate how they track each package used, everywhere in their organization This leads us to our next topic – getting control over the open source in your organization.
- The first step is to document internal policies for open source use. This includes the types of licenses you will allow, any security requirements you may have, and determining how the OSS package will be supported. These decisions are determined by each organizations primarily by their appetite for risk, compared to the value derived from the open source, for each class of applications. Internet facing applications and those apps that access sensitive information require a higher security standard than some internal applications (with a smaller perceived attack surface). Good open source practices are good development practices, but we also need to recognize development realities. Open source often enters a code base organically; a developers think about functionality and deadlines. If he requires specific functionality, has used the open source previously, he is inclined to use it again to accelerate productivity. Finally, we need to institutionalize the policies. While many organizations have some standards, our research shows that those typically are not well managed or enforced. A successful governance program requires a certain level of discipline, and occasional trade-offs. Exceptions to the policies may ultimately be necessary due to design choices, functionality or market pressure, but these should be taken with full awareness by all parties. Most importantly, a successful governance program requires the ability to detect breaches of policy after the review is completed, which we will discuss in a few minutes.
- As you develop your best practices for legal, technical business, set up a pipeline via your OSS review board to constantly update your policies. OSS policies are based on multiple factors. Legal, technical and business are the top three. From a legal view what risk and practices do you want your team to utilize to ensure compliance and risk avoidance From a technical/security view as you monitor and update OSS what version and packages do you want to avoid or which version do you want your team to use From a business view, when is commercial software better? What business issues need to be addressed by OSS. Should you only use supported OSS?
- GPLv3 software cannot be included in Apache projects because when an Apache project software becomes a derivative work of some GPLv3 software, then the Apache software would have to be distributed under GPLv3. For example, merely linking to the GPLv2 and GPLv3 may be considered a derivative work, therefore would have the entire project licensed under GPL. FSF never considered the Apache license to be compatible with GPLv2 because of the patent termination and indemnification provisions. Indemnification Patent termination -
- Jacobsenv. Katzer - The conditions set forth in the Artistic License are vital to enable the copyright holder to retain the ability to benefit from the work of downstream users. By requiring that users who modify or distribute the copyrighted material retain the reference to the original source files, downstream users are directed to Jacobsen's website. Thus, downstream users know about the collaborative effort to improve and expand the SourceForge project once they learn of the “upstream” project from a “downstream” distribution, and they may join in that effort. The clear language of the Artistic License creates conditions to protect the economic rights at issue in the granting of a public license. These conditions govern the rights to modify and distribute the computer programs and files included in the downloadable software package Welte – sued Fantec twice, source code availabel for download was incomplete and outdated, german court rejected fantec’s argument that its supplier assured compliance with the GPL terms, court held, can’t rely on suppliers word, must perform audit yourself, XimpleWare Corp v. Versata Filed NDCA November 2013 Copyright infringement Breach of contract Unjust enrichment Unfair competition $150 million + attorney fees "XML Parser" licensed under GPL v.2 Available on SourceForge.net 1st motion for preliminary injunction Denied because Versata represented no future sales of products including XML Parser 2nd motion for preliminary injunction Versata continued to sell products including XML Parser Motion was pending – Case Settled