2024: Domino Containers - The Next Step. News from the Domino Container commu...
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