Security teams are often seen as roadblocks to rapid development or operations implementations, slowing down production code pushes. As a result, security organizations will likely have to change so they can fully support and facilitate cloud operations.
This presentation will explain how DevOps and information security can co-exist through the application of a new approach referred to as DevSecOps.
Slides for a college course based on "Incident Response & Computer Forensics, Third Edition" by by Jason Luttgens, Matthew Pepe, and Kevin Mandia".
Ch 1: Real-World Incidents
Teacher: Sam Bowne
Website: https://samsclass.info/121/121_F16.shtml
Security teams are often seen as roadblocks to rapid development or operations implementations, slowing down production code pushes. As a result, security organizations will likely have to change so they can fully support and facilitate cloud operations.
This presentation will explain how DevOps and information security can co-exist through the application of a new approach referred to as DevSecOps.
Slides for a college course based on "Incident Response & Computer Forensics, Third Edition" by by Jason Luttgens, Matthew Pepe, and Kevin Mandia".
Ch 1: Real-World Incidents
Teacher: Sam Bowne
Website: https://samsclass.info/121/121_F16.shtml
You'll understand how hackers can attack resources hosted in the Azure and protect Azure infrastructure by identifying vulnerabilities, along with extending your pentesting tools and capabilities.
What is SPYWARE?
Spyware is a type of malware that's hard to detect.
It collects information about your surfing habits, browsing history, or personal information (such as credit card numbers), and often uses the internet to pass this information along to third parties without you knowing.
o Key loggers are a type of spyware that monitors your key strokes.
Spyware is mostly classified into four types:
1.System monitors
2.Trojans
3.Adware
4.Tracking Cookies
spyware is mostly used for the purposes of tracking and storing internet users' movements on the web and serving up pop-up ads to internet users.
History and development of spyware.
The first recorded on October 16, 1995 in a UseNet post that poked fun at microsoft's business model.
Spyware at first denoted software meant for espionage purposes.
However, in early 2000 the founder of zone labs, gregor freund, used the term in a press release for the zone alarm personal firewall.
Use of exploits in JavaScript, internet explorer and windows to install.
Effect and behavior.
Unwanted behavior and degradation of system performance.
Unwanted CPU activity, disk usage, and network traffic.
Stability issues:-
Application's freezing.
Failure to boot.
System-wide crashes.
Difficulty connecting to the internet.
Disable software firewalls and anti-virus software.
Routes of infection.
Installed when you open an email attachment.
Spyware installs itself
Install by using deceptive tactics
Common tactics are using a Trojan horse.
USB Keylogger.
browser forces the download and installation of spyware.
Security Practices.
• Installing anti-spyware programs.
• Network firewalls and web proxies to block access to web sites known to install spyware
• Individual users can also install firewalls.
• Install a large hosts file.
• It Install shareware programs offered for download.
• Downloading programs only from reputable sources can provide some protection from this source of attack
Anti-spyware Programs
• Products dedicated to remove or block spyware.
• Programs such as pc tool’s spyware doctor, lava soft's ad-aware se and patrick kolla's spybot - search & destroy.
Legal Issues.
Criminal law
US FTC actions
Netherlands OPTA
Civil law
Libel suits by spyware developers
Webcam Gate
Thank You!
Stay Connected
Stay connected with me at Facebook :- https://www.facebook.com/mangesh.wadibhasme
Follow at Instagram: - @mangesh_hkr
"CERT Secure Coding Standards" by Dr. Mark ShermanRinaldi Rampen
OWASP DC - November 2015 Talk
Abstract:
This presentation will start with an overview of CERT’s view of the tools, technologies and processes for building secure software from requirements to operational deployment, including architecture, design, coding and testing. After providing the context for building secure software, the discussion will focus on the current state of the CERT Coding Standards: what is available, how the rules evolve and how the rules are put into practice.
Bio:
Dr. Mark Sherman is the Technical Director of the Cyber Security Foundations group at CERT within CMU’s Software Engineering Institute. His team focuses on foundational research on the life cycle for building secure software and on data-driven analysis of cyber security. Before coming to CERT, Dr. Sherman was at IBM and various startups, working on a mobile systems, integrated hardware-software appliances, transaction processing, languages and compilers, virtualization, network protocols and databases. He has published over 50 papers on various topics in computer science.
Penetration testing reporting and methodologyRashad Aliyev
This paper covering information about Penetration testing methodology, standards reporting formats and comparing reports. Explained problem of Cyber Security experts when they making penetration tests. How they doing current presentations.
We will focus our work in penetration testing methodology reporting form and detailed information how to compare result and related work information.
Threat modeling is an approach for analyzing the security of an application. It is a structured approach that enables you to identify, quantify, and address the security risks associated with an application.
Application Security - Your Success Depends on itWSO2
Traditional information security mainly revolves around network and operating system (OS) level protection. Regardless of the level of security guarding those aspects, the system can be penetrated and the entire deployment can be brought down if your application's security isn't taken into serious consideration. Information security should ideally start at the application level, before network and OS level security is ensured. To achieve this, security needs to be integrated into the application at the software development phase.
In this session, Dulanja will discuss the following:
The importance of application security - why network and OS security is insufficient.
Challenges in securing your application.
Making security part of the development lifecycle.
LinuxCon Europe 2014: License Compliance and Open Source Software Logistics f...Black Duck by Synopsys
Software deployment is moving rapidly from “on premises” to service-based and cloud models–requiring developers to upgrade knowledge of OSS licenses. Most OSS licenses were developed around traditional delivery models; however, these models didn’t anticipate advances in cloud computing, which has resulted in some popular licenses having implications for SaaS. With the shift to SaaS and cloud, this new class of licenses (including the AGPL) has become increasingly important. In this presentation, Kirsten Newcomer will review the application of OSS licenses, particularly AGPL and similar licenses, to these services. Newcomer will also review reasoning behind the proliferation in projects with AGPL-type licenses, the new compliance and license complexities introduced by Docker, and the logistical challenges inherent in managing open source in SaaS applications.
Discussing the primary reasons organizations are doing audits today. We take a look at what's involved in the audit process, what type of reports you can expect to receive, and possible next steps.Presented January 2016 at the Open source compliance seminar hosted Brooks Kushman and Rogue Wave Software.
You'll understand how hackers can attack resources hosted in the Azure and protect Azure infrastructure by identifying vulnerabilities, along with extending your pentesting tools and capabilities.
What is SPYWARE?
Spyware is a type of malware that's hard to detect.
It collects information about your surfing habits, browsing history, or personal information (such as credit card numbers), and often uses the internet to pass this information along to third parties without you knowing.
o Key loggers are a type of spyware that monitors your key strokes.
Spyware is mostly classified into four types:
1.System monitors
2.Trojans
3.Adware
4.Tracking Cookies
spyware is mostly used for the purposes of tracking and storing internet users' movements on the web and serving up pop-up ads to internet users.
History and development of spyware.
The first recorded on October 16, 1995 in a UseNet post that poked fun at microsoft's business model.
Spyware at first denoted software meant for espionage purposes.
However, in early 2000 the founder of zone labs, gregor freund, used the term in a press release for the zone alarm personal firewall.
Use of exploits in JavaScript, internet explorer and windows to install.
Effect and behavior.
Unwanted behavior and degradation of system performance.
Unwanted CPU activity, disk usage, and network traffic.
Stability issues:-
Application's freezing.
Failure to boot.
System-wide crashes.
Difficulty connecting to the internet.
Disable software firewalls and anti-virus software.
Routes of infection.
Installed when you open an email attachment.
Spyware installs itself
Install by using deceptive tactics
Common tactics are using a Trojan horse.
USB Keylogger.
browser forces the download and installation of spyware.
Security Practices.
• Installing anti-spyware programs.
• Network firewalls and web proxies to block access to web sites known to install spyware
• Individual users can also install firewalls.
• Install a large hosts file.
• It Install shareware programs offered for download.
• Downloading programs only from reputable sources can provide some protection from this source of attack
Anti-spyware Programs
• Products dedicated to remove or block spyware.
• Programs such as pc tool’s spyware doctor, lava soft's ad-aware se and patrick kolla's spybot - search & destroy.
Legal Issues.
Criminal law
US FTC actions
Netherlands OPTA
Civil law
Libel suits by spyware developers
Webcam Gate
Thank You!
Stay Connected
Stay connected with me at Facebook :- https://www.facebook.com/mangesh.wadibhasme
Follow at Instagram: - @mangesh_hkr
"CERT Secure Coding Standards" by Dr. Mark ShermanRinaldi Rampen
OWASP DC - November 2015 Talk
Abstract:
This presentation will start with an overview of CERT’s view of the tools, technologies and processes for building secure software from requirements to operational deployment, including architecture, design, coding and testing. After providing the context for building secure software, the discussion will focus on the current state of the CERT Coding Standards: what is available, how the rules evolve and how the rules are put into practice.
Bio:
Dr. Mark Sherman is the Technical Director of the Cyber Security Foundations group at CERT within CMU’s Software Engineering Institute. His team focuses on foundational research on the life cycle for building secure software and on data-driven analysis of cyber security. Before coming to CERT, Dr. Sherman was at IBM and various startups, working on a mobile systems, integrated hardware-software appliances, transaction processing, languages and compilers, virtualization, network protocols and databases. He has published over 50 papers on various topics in computer science.
Penetration testing reporting and methodologyRashad Aliyev
This paper covering information about Penetration testing methodology, standards reporting formats and comparing reports. Explained problem of Cyber Security experts when they making penetration tests. How they doing current presentations.
We will focus our work in penetration testing methodology reporting form and detailed information how to compare result and related work information.
Threat modeling is an approach for analyzing the security of an application. It is a structured approach that enables you to identify, quantify, and address the security risks associated with an application.
Application Security - Your Success Depends on itWSO2
Traditional information security mainly revolves around network and operating system (OS) level protection. Regardless of the level of security guarding those aspects, the system can be penetrated and the entire deployment can be brought down if your application's security isn't taken into serious consideration. Information security should ideally start at the application level, before network and OS level security is ensured. To achieve this, security needs to be integrated into the application at the software development phase.
In this session, Dulanja will discuss the following:
The importance of application security - why network and OS security is insufficient.
Challenges in securing your application.
Making security part of the development lifecycle.
LinuxCon Europe 2014: License Compliance and Open Source Software Logistics f...Black Duck by Synopsys
Software deployment is moving rapidly from “on premises” to service-based and cloud models–requiring developers to upgrade knowledge of OSS licenses. Most OSS licenses were developed around traditional delivery models; however, these models didn’t anticipate advances in cloud computing, which has resulted in some popular licenses having implications for SaaS. With the shift to SaaS and cloud, this new class of licenses (including the AGPL) has become increasingly important. In this presentation, Kirsten Newcomer will review the application of OSS licenses, particularly AGPL and similar licenses, to these services. Newcomer will also review reasoning behind the proliferation in projects with AGPL-type licenses, the new compliance and license complexities introduced by Docker, and the logistical challenges inherent in managing open source in SaaS applications.
Discussing the primary reasons organizations are doing audits today. We take a look at what's involved in the audit process, what type of reports you can expect to receive, and possible next steps.Presented January 2016 at the Open source compliance seminar hosted Brooks Kushman and Rogue Wave Software.
Software audit strategies: how often is enough? Protecode
With the widespread use of open source software in proprietary software projects, organizations are looking for ways to mitigate licensing, security and quality vulnerabilities related to open source code. These organizations are increasing deploying software audits which involve scanning a software portfolio to uncover all software packages as well as their associated licensing and copyright obligations, security vulnerabilities and other code attribute information.
Discover how to create a viable Connected Car business model and drive consumer uptake through a safer driving experience. Everyone is aware of the need to worry about security but it isn't just about security--it's about all of the coding fundamentals including code quality, security, and open source management.
In this presentation you will learn how to:
-Measure the gaps in your developer's code first: Nearly 90% of all detected security holes can be traced back to just ten types of vulnerabilities
-Educate your developers: 57% of people don't think automotive software development teams have the skills necessary to combat software security threats
-Empower your developers with the right policies, processes, and tools to fill these gaps: 48% of people believe one of the main challenges of security automobile software is due to lack of defined corporate application security policies
SFO15-TR7: OSS License Compliance
Speaker: Kate Stewart
Date: September 24, 2015
★ Session Description ★
A training session on the what, why and how to be compliant with Open Source licensing. A must attend session for those who plan to ship a product based on Open Source software.
★ Resources ★
Video:
Presentation:
Etherpad: pad.linaro.org/p/sfo15-tr7
Pathable: https://sfo15.pathable.com/meetings/303085
★ Event Details ★
Linaro Connect San Francisco 2015 - #SFO15
September 21-25, 2015
Hyatt Regency Hotel
http://www.linaro.org
http://connect.linaro.org
Investigation report on 64 bit support in Android Open Source Projecthidenorly
AOSP is working to support 64bit world for Android. This is investigation report regarding 64 bit support in Android Open Source Project. You can know how 64bit Android works and what is 32bit only process as of now.
Static analysis works for mission-critical systems, why not yours? Rogue Wave Software
Take a deep dive into the world of static code analysis (SCA) by immersing yourself into different analysis techniques, examples of the problems they find, and learning how SCA fits into various types of environments, from the developer desktop to the QA team. The goal is to provide a solid foundation for you to make the best decision for testing technology and process selection, including: Types of defects found by SCA;
Typical myths and barriers to adoption; and How SCA aligns to different testing maturity levels.
Best practice recommendations for utilizing open source software (from a lega...Rogue Wave Software
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.
Open Source Licensing Fundamentals for Financial ServicesFINOS
Andrew Hall, The Hall Law Firm: Open Source Licensing Fundamentals for Financial Services.
Andrew and Lena will address fundamental concepts of open-source licensing to assist executives in better understanding the benefits, obligations, restrictions, and risks involved in leveraging and contributing to open-source solutions and incorporating open-source licensing into commercial strategies.
The discussion will include: an overview of the different categories of open-source licenses (such as copyleft, prohibitive, and permissive); the obligations and restrictions commonly associated with the use of open-source software; the “copyleft,” “tainting,” or “viral” effect of copyleft licenses; community and private open-source license enforcement trends; and the adoption of open-source software and licensing in support of commercial product and service offerings.
A primer on adapting open source software to an IT service organization. Focuses on how open source licenses are different and how it may affect your business model and intellectual property.
Open Source software can be found everywhere, from WiFi routers to the largest web sites on the Internet. This presentation looks at how it all got started and what it can mean for you.
Open source licenses can be more than a little confusing for those of us that just want to write a little bit of code. However, with open source components playing such a big part in the products that we create, open source licenses and compliance simply can’t be ignored.
We’ve compiled the one stop resource guide for working compliantly with open source components, including answers to FAQs about the most popular licenses in 2018. Read all about the hottest licensing trends that you need to be following and some predictions for 2019.
This presentation is an introduction to Free and Open Source Software Licensing and Business Models. An open-source license is a type of license for computer software and other products that allows the source code, blueprint or design to be used, modified and/or shared under defined terms and conditions. This allows end users to review and modify the source code, blueprint or design for their own customization, curiosity or troubleshooting needs.
Dr. Ibrahim Haddad, Head of the Samsung OSG, speaks on the role of legal counsels and their staffs in scaling open source compliance efforts within large organizations.
JMeter webinar - integration with InfluxDB and GrafanaRTTS
Watch this recorded webinar about real-time monitoring of application performance. See how to integrate Apache JMeter, the open-source leader in performance testing, with InfluxDB, the open-source time-series database, and Grafana, the open-source analytics and visualization application.
In this webinar, we will review the benefits of leveraging InfluxDB and Grafana when executing load tests and demonstrate how these tools are used to visualize performance metrics.
Length: 30 minutes
Session Overview
-------------------------------------------
During this webinar, we will cover the following topics while demonstrating the integrations of JMeter, InfluxDB and Grafana:
- What out-of-the-box solutions are available for real-time monitoring JMeter tests?
- What are the benefits of integrating InfluxDB and Grafana into the load testing stack?
- Which features are provided by Grafana?
- Demonstration of InfluxDB and Grafana using a practice web application
To view the webinar recording, go to:
https://www.rttsweb.com/jmeter-integration-webinar
Transcript: Selling digital books in 2024: Insights from industry leaders - T...BookNet Canada
The publishing industry has been selling digital audiobooks and ebooks for over a decade and has found its groove. What’s changed? What has stayed the same? Where do we go from here? Join a group of leading sales peers from across the industry for a conversation about the lessons learned since the popularization of digital books, best practices, digital book supply chain management, and more.
Link to video recording: https://bnctechforum.ca/sessions/selling-digital-books-in-2024-insights-from-industry-leaders/
Presented by BookNet Canada on May 28, 2024, with support from the Department of Canadian Heritage.
The Art of the Pitch: WordPress Relationships and SalesLaura Byrne
Clients don’t know what they don’t know. What web solutions are right for them? How does WordPress come into the picture? How do you make sure you understand scope and timeline? What do you do if sometime changes?
All these questions and more will be explored as we talk about matching clients’ needs with what your agency offers without pulling teeth or pulling your hair out. Practical tips, and strategies for successful relationship building that leads to closing the deal.
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
Elevating Tactical DDD Patterns Through Object CalisthenicsDorra BARTAGUIZ
After immersing yourself in the blue book and its red counterpart, attending DDD-focused conferences, and applying tactical patterns, you're left with a crucial question: How do I ensure my design is effective? Tactical patterns within Domain-Driven Design (DDD) serve as guiding principles for creating clear and manageable domain models. However, achieving success with these patterns requires additional guidance. Interestingly, we've observed that a set of constraints initially designed for training purposes remarkably aligns with effective pattern implementation, offering a more ‘mechanical’ approach. Let's explore together how Object Calisthenics can elevate the design of your tactical DDD patterns, offering concrete help for those venturing into DDD for the first time!
Key Trends Shaping the Future of Infrastructure.pdfCheryl Hung
Keynote at DIGIT West Expo, Glasgow on 29 May 2024.
Cheryl Hung, ochery.com
Sr Director, Infrastructure Ecosystem, Arm.
The key trends across hardware, cloud and open-source; exploring how these areas are likely to mature and develop over the short and long-term, and then considering how organisations can position themselves to adapt and thrive.
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024Tobias Schneck
As AI technology is pushing into IT I was wondering myself, as an “infrastructure container kubernetes guy”, how get this fancy AI technology get managed from an infrastructure operational view? Is it possible to apply our lovely cloud native principals as well? What benefit’s both technologies could bring to each other?
Let me take this questions and provide you a short journey through existing deployment models and use cases for AI software. On practical examples, we discuss what cloud/on-premise strategy we may need for applying it to our own infrastructure to get it to work from an enterprise perspective. I want to give an overview about infrastructure requirements and technologies, what could be beneficial or limiting your AI use cases in an enterprise environment. An interactive Demo will give you some insides, what approaches I got already working for real.
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...Ramesh Iyer
In today's fast-changing business world, Companies that adapt and embrace new ideas often need help to keep up with the competition. However, fostering a culture of innovation takes much work. It takes vision, leadership and willingness to take risks in the right proportion. Sachin Dev Duggal, co-founder of Builder.ai, has perfected the art of this balance, creating a company culture where creativity and growth are nurtured at each stage.
Essentials of Automations: Optimizing FME Workflows with ParametersSafe Software
Are you looking to streamline your workflows and boost your projects’ efficiency? Do you find yourself searching for ways to add flexibility and control over your FME workflows? If so, you’re in the right place.
Join us for an insightful dive into the world of FME parameters, a critical element in optimizing workflow efficiency. This webinar marks the beginning of our three-part “Essentials of Automation” series. This first webinar is designed to equip you with the knowledge and skills to utilize parameters effectively: enhancing the flexibility, maintainability, and user control of your FME projects.
Here’s what you’ll gain:
- Essentials of FME Parameters: Understand the pivotal role of parameters, including Reader/Writer, Transformer, User, and FME Flow categories. Discover how they are the key to unlocking automation and optimization within your workflows.
- Practical Applications in FME Form: Delve into key user parameter types including choice, connections, and file URLs. Allow users to control how a workflow runs, making your workflows more reusable. Learn to import values and deliver the best user experience for your workflows while enhancing accuracy.
- Optimization Strategies in FME Flow: Explore the creation and strategic deployment of parameters in FME Flow, including the use of deployment and geometry parameters, to maximize workflow efficiency.
- Pro Tips for Success: Gain insights on parameterizing connections and leveraging new features like Conditional Visibility for clarity and simplicity.
We’ll wrap up with a glimpse into future webinars, followed by a Q&A session to address your specific questions surrounding this topic.
Don’t miss this opportunity to elevate your FME expertise and drive your projects to new heights of efficiency.
Generating a custom Ruby SDK for your web service or Rails API using Smithyg2nightmarescribd
Have you ever wanted a Ruby client API to communicate with your web service? Smithy is a protocol-agnostic language for defining services and SDKs. Smithy Ruby is an implementation of Smithy that generates a Ruby SDK using a Smithy model. In this talk, we will explore Smithy and Smithy Ruby to learn how to generate custom feature-rich SDKs that can communicate with any web service, such as a Rails JSON API.
FIDO Alliance Osaka Seminar: The WebAuthn API and Discoverable Credentials.pdf
Guide to Open Source Compliance
1. Open Source Compliance
Samsung Open Source Group 1
Ibrahim Haddad, Ph.D.
Group Leader
Samsung Open Source Group
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. 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. Content
Terms and Definitions
License Obligations – GPL example
Samsung Open Source Group 4
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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. How are the various GNU licenses compatible with each other?
Samsung Open Source Group 24
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. 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
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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
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. 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. 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. 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. Type of Compliance Failures
• Intellectual property (IP) failures
• License failures
• Compliance process failures
Samsung Open Source Group 47
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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Partial List of Companies Targeted with Non-Compliance
Samsung Open Source Group 61
And many more …
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. What have we learned?
Samsung Open Source Group 63
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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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