Presented by: Jeff Luszcz, ZebraCatZebra Presented at All Things Open 2020 Abstract: Open Source powers the world, but you need to do more than use it. In this talk we will provide background on the most common types of open source licenses, business models, security issues and the processes required to help you remain secure and in compliance. We will discuss best practices, scanning tools, remediation, customer and partner expectations around OSS compliance and how to manage OSS during events such as a product release or M&A.

1. OPEN SOURCE LICENSING:
TYPES, STRATEGIES AND
COMPLIANCE
Jeff Luszcz
@JeffLuszcz
https://ZebraCatZebra.com​
This work is licensed under the Creative Commons Attribution 3.0 United States License.

2. A LITTLE ABOUT ME:
JEFF LUSZCZ
• Founded Palamida in 2004
• One of the first Scanning tools to manage
FOSS
• Designed compliance audit program and built
out Professional Services team to implement it
• Team helped everything from basic
compliance, M&A due diligence, and open
source project hygiene
• Worked with groups ranging from sole
proprietors to largest software companies
in the world
• Witnessed industry move from dozens of OSS
packages to 1000s of packages per application

3. TODAY'S AGENDA
Open Source
Licenses
•Why do we
have open
source
licenses?
•Open Source
License
History
•Types of Open
Source
Licenses
•Common
Obligations
Compliance
• Notices
• What are
others doing?
• Business
Models
• M&A
• OSS Releases
• Hot Topics
Security
• CVEs and
Vulnerabilities
• Fixing
Vulnerabilities
• Customer
Expectations
• Scanning and
Tooling
Best Practices
• Working with
Suppliers
• Becoming
Compliant
• Education
• Remediation
• Scanning Tools
• Open Chain
• Future
Thoughts

4. WHY DO WE NEED OPEN
SOURCE LICENSES?
Copyright law means that authors control their work (software).
You need explicit permission to use someone else's work
An author gives others permission using a license
A Commercial license typically gives permission for money
An Open Source License gives permission as long as certain obligations are
fulfilled
A license is a legal agreement which may be difficult to understand....
So we re-use COMMON open source licenses to make software re-use easier!

5. THERE IS A SPECTRUM OF
OBLIGATIONS
None Disclaim Notices
Weak
Copyleft
Copyleft
Network
Copyleft
Busines
Model
Restricti
A license may require one or more obligations
Some obligations are easier to comply with
than others

6. WHAT IS A LICENSE OBLIGATION?
Obligation AKA Description
Pay Money Commercial Pay money to use
Share Source Code Copyleft / Viral Bundle or share source code if
used
Share Credit Attribution / Notices Requires copyright or notice to
be shown in About Box /
Documentation / Webpage /
Source Code
Share Patents Patent Grant Provide free use of patents
required to use software
No Patent Lawsuits Patent Retaliation Clause Removes patent rights if user
sues for patent infringement
Restriction on Use Prevent use by certain industries
/ companies / governments /
military
Prevent use by military, nuclear
power plant, aviation, companies,
countries, business partners
Vanity License Obligation Requires some non-traditional
action
Buy me a beer if this helps you,
Do no evil, Get vaccinated

7. A HISTORY OF OPEN SOURCE LICENSING

8. A HISTORY OF OPEN SOURCE
LICENSING ERAS
Workstations
and Desktops
•1985 X11/MIT license
•1988 GPL licenses for Emacs/Bison/etc.
•1988 BSD license
•1989 GPL v1
•1991 GPL v2 / LGPL v2
•1995 Apache 1.0
•2000 Apache 1.1
Corporate
Internet &
•2002 Affero GPL v1
•2004 Apache 2.0
•2007 GPL v3 / LGPL v3 / Affero GPL v3
Cloud Era
•2018 Commons Clause
•2018 Server Side Public License
• ????

9. TWO (ORIGINAL) STYLES OF
OSS LICENSES
"Permissive" sometimes called Attribution or Notice licenses
Requires preserving or supplying copyright notices and
and/or license text
Copyleft (sometimes called Reciprocal or Viral) Licenses
Requires supplying some or all of the source code of a program under certain conditions

10. "PERMISSIVE" LICENSE
EXAMPLES
"Permissive"
sometimes called
Attribution or
Notice licenses
Apache BSD MIT

11. NOTICES
Many open source license requires copyright statements and/or
license text to be preserved and passed along to the end user.
These notices are often found in
•About Box
•Legal Info menu
•Documentation

12. COPYLEFT / RECIPROCAL /
VIRAL LICENSES
Copyleft (sometimes called Reciprocal or Viral) Licenses
Lesser General Public License (LGPL)
Requires supplying source all code from LGPL module if distributing a program using a LGPL
module
General Public License (GPL)
Requires supplying source for all linked code if distributing a program
Affero General Public License (AGPL)
Requires supplying source code if using a modified network application under the AGPL

13. LESSER GENERAL PUBLIC
LICENSE (LGPL)
LGPL
The LGPL is a Weak Copyleft license.
Only the source from the LGPL module needs to be shared
The LGPL does have some Linking requirements which complicates this obligation
The module should be dynamically linked though there are some other complex ways to
comply.

14. GENERAL PUBLIC LICENSE
(GPL)
LGPL
The GPL is a Strong Copyleft license.
The entire program's source needs to be shared if the program is distributed

15. AFFERO GENERAL PUBLIC
LICENSE (AGPL)
LGPL
The AGPL is a Network Copyleft license.
This means the entire program's source needs to be shared if access is given over a
Network (e.g. Software as a Service)
This license was designed to close the "ASP Loophole" in the GPL

16. COMMON COPYLEFT/VIRAL
LICENSES
Strong Copyleft:
 Affero General Public License (AGPL)
 General Public License (GPL)
 Sleepycat
 Creative Commons-Share Alike (CC-SA) - often used with Stackoverflow
code samples!
Weak-Copyleft:
 Lesser General Public License (LGPL)
 Eclipse Public License (EPL)

17. CORRESPONDING
SOURCE CODE
BUNDLE
Copyleft style licenses require some or all of your
source code to be shared
This is commonly through an included source
bundle (e.g. tarball or source zip) or a written
offer
Download links to source code are often
provided but may not be sufficient
It is important that the Corresponding Source is
provided, this could include build scripts,
makefiles, etc... in addition to the source code

18. POST AGPL NON-OSS LICENSES:
COMMONS CLAUSE, SERVER
SIDE PUBLIC LICENSE
The AGPL attempted to close what was perceived as a loophole for OSS license
obligations for Cloud applications
Some companies are building applications / databases and seeing others make
money off of selling access or hosting to those same applications
The Commons Clause, Server Side Public License and other similar licenses put
restrictions on certain business cases such as hosting builds of the original
software
These are not OSS licenses, but often mentioned in similar contexts
Often seen around Open Core projects!

19. WALKTHROUGH A COMMON
LICENSE (BSD)
Copyright <YEAR> <COPYRIGHT HOLDER>
Redistribution and use in source and binary forms, with or without modification, are
permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of
conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of
conditions and the following disclaimer in the documentation and/or other materials
provided with the distribution.
3. Neither the name of the copyright holder nor the names of its contributors may be
used to endorse or promote products derived from this software without specific prior
written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.

20. WALKTHROUGH A COMMON
LICENSE (BSD)
Copyright <YEAR> <COPYRIGHT HOLDER>
Redistribution and use in source and binary forms, with or without modification, are
permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of
conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of
conditions and the following disclaimer in the documentation and/or other materials
provided with the distribution.
3. Neither the name of the copyright holder nor the names of its contributors may be
used to endorse or promote products derived from this software without specific prior
written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
Copyright statement
Redistribution and use permission
Retain copyright notice in source
Retain copyright notice and license in
binaries
Non-endorsement clause
Disclaimer

21. PATENT RELATED
OBLIGATIONS
Certain licenses imply or explicitly require patent grants
/ permissions for contributions
e.g. Apache 2.0 and the Mozilla Public License 2.0
Others forbid patent infringement suits via a Retaliation
clause (license terminates!)
e.g. Apache 2.0 and the Mozilla Public License 2.0
Some OSS packages may require a separate Patent
license to be paid to use legally
Especially common for Audio and Video Codecs!

22. DUAL LICENSING
It is common to see a software package licensed
under multiple licenses
(e.g. "GPL v3 or Commercial")
Two common reasons
1) As a business model forcing function ("scary" vs
"friendly")
Often (GPL or Commerical) or (AGPL or Commercial)
2) To allow a certain OSS community to use a library
with no license conflicts
This is why you'll see so many older "GPL or MIT" or
"MPL 1.1/GPL 2.0/LGPL 2.1" licenses

23. DUAL LICENSING EXAMPLES
MySQL: GPL v2 or Commercial
MongoDB: Server Side Public License (SSPL) or Commercial
iText: AGPL or Commercial
wolfSSL: GPL v2 or Commercial
Older versions of jQuery were GPL or MIT, now it's simply MIT

24. LICENSE
VERSIONS
As time goes on, OSS licenses may be updated
These changes are denoted with version number or
name changes
Most common examples are the
• General Public License v1, v2 and v3
• Apache Software License v1, v1.1 and v2.0
• BSD (0 clause, 1 clause, 2 clause, 3 clause)
Some licenses have many variants, but NO difference in
their names
Most common example of this is the MIT license which
has at least 23 variants!
• See https://fedoraproject.org/wiki/Licensing:MIT

25. DISTRIBUTION /
WHEN DO I NEED
TO CARE?
Many open source licenses ONLY
come into effect when software
is distributed
This might be as a downloaded
application, App, Container or on
a Device

26. DISTRIBUTION USE CASES
Products (or modules of products) can be used and distributed in many ways:
•Internal Use
•Binary/ EXE delivered to end user
•Container based
•Mobile applications
•Self-hosted Software as a Service (SaaS)
•SaaS Pushed to "The Cloud!" (AWS, Azure, Google Cloud Platform)
•Javascript files downloaded to local web browser as part of SaaS app
•"Private" cloud version for Marquee customer
Distribution models affect OSS License obligations!

27. WHAT LOOKS
LIKE OSS
BUT ISN'T!
Code marked "For Non-
commercial use" (aka NC)
Freeware
Click though EULAs
One-off licenses
"All Rights Reserved"
Code with no declared license

28. OPEN SOURCE LICENSING:
TYPES, STRATEGIES AND
COMPLIANCE
Jeff Luszcz
@JeffLuszcz
https://ZebraCatZebra.com​

29. A LITTLE ABOUT ME:
JEFF LUSZCZ
• Founded Palamida in 2004
• One of the first Scanning tools to manage
FOSS
• Designed compliance audit program and built
out Professional Services team to implement it
• Team helped everything from basic
compliance, M&A due diligence, and open
source project hygiene
• Worked with groups ranging from sole
proprietors to largest software companies
in the world
• Witnessed industry move from dozens of OSS
packages to 1000s of packages per application

30. TODAY'S AGENDA
Open Source
Licenses
•Why do we
have open
source
licenses?
•Open Source
License
History
•Types of Open
Source
Licenses
•Common
Obligations
Compliance
• Notices
• What are
others doing?
• Business
Models
• M&A
• OSS Releases
• Hot Topics
Security
• CVEs and
Vulnerabilities
• Fixing
Vulnerabilities
• Customer
Expectations
• Scanning and
Tooling
Best Practices
• Working with
Suppliers
• Becoming
Compliant
• Education
• Remediation
• Scanning Tools
• Open Chain
• Future
Thoughts

31. LET'S TALK ABOUT THE
PUBLIC DOMAIN
Has a legal meaning, but often used as "Magic words" when discussing licensing
These words are often misused by developers when releasing software
"This code is licensed to the public domain under the GPL license" (NO!)
Or
"This code is Public Domain" when they mean "It's Open Source"
Some countries do not recognize the "Public Domain"
Creative Commons Zero (aka CC0) have been created to give similar permissions

32. WHEN DON’T WE KNOW
ENOUGH?
Something is licensed under a "Creative Commons license"! (CC is a
family of licenses, if something is CC-licensed you need to know
more)
"The Code is on Github" (What is it license?)
I got the code from our supplier / Part of a SDK (Is is OSS or
Commercial?)
We bought a license! (When does it expire?)

33. HOW HAS OSS USE
CHANGED OVER THE
YEARS?
2020 MEAN / Microservices
[5000 components]
2010 Cloud /
[500 components]
2000 LAMP
components]

34. HOW DO YOU
GET OPEN
SOURCE?
Using a repository manager like Maven,
NPM, pip, etc...
Direct download of source archive from
web
Some magic shell script!
Cut and Paste of snippets
Copied from a Pastebin / Gist
Download from a Content Delivery
Network (CDN)
Bundled with other projects (OSS and
Commercial!)
As part of your infrastructure (OS, DB,
etc...)
From a vendor / supplier

35. WHAT IS THE SOFTWARE
SUPPLY CHAIN
The Software Supply Chain is similar to the physical product supply chain
Often contains hundreds of suppliers (thousands in the case of Automotive
products!)
Has layers of complexity and layers of suppliers.
Mixture of OSS, Commerical and "free"
Contains software components, tool chains and documentation
You may have no access or contact with many of your suppliers
You may not even know who they are!

36. OPEN SOURCE LICENSE
POLICIES
https://opensource.google/docs/thirdparty/li
censes/
Not all licenses are appropriate for your use
case
Open Source License Policies are how you can
define what licenses are acceptable for your
organization or product.
Often based on distribution model
It is important to make a clear license policy
and have all developers understand what is
expected.
Need to be updated periodically
It is VERY expensive to rip out unacceptable

37. COMPLIANCE NOTICES
(CHROME)
Chrome's open source notices are found in its About Google Chrome menu

38. COMPLIANCE NOTICES
(CHROME)

39. COMPLIANCE NOTICES
(CHROME)

40. OSS SECURITY: WHAT IS A
CVE?
All software bugs, some are well known and even have names and
webpages!
The CVE list is a list of public software vulnerabilities (OSS and
Commercial)
https://cve.mitre.org
Each defect is given a number CVE-2020-0001 (label-year-id)
MANY other security defects don't get this level of visibility. They live
in the project defect tracker, are not named, and are hard to identify.

41. VULNERABILI
TIES, CVES
AND
PATCHING
Heartbleed
CVE-2014-0160
Affects OpenSSL
Struts
CVE-2017-5638
Affects Apache Struts, led to
the massive Equifax breach
($500 million and counting)

42. OSS SECURITY: FIXING
VULNERABILITIES
One big danger with OSS vulnerabilities is that attacks can be scripted and
attempted across multiple applications. They don't have to be targeted.
Components "age like milk, not like wine" have vulnerabilities found over
time
The simple fix for OSS vulnerabilities to upgrade to the latest "safe" release
This may close the security issue, but may introduce others
 License Changes
 Incapability
 Unwanted features / memory bloat / etc...
Blocking attacks through turning off features, firewall rules or shim layers can buy time
You need to have a plan!

43. OSS SECURITY: CUSTOMER VISIBILITY
OF VULNERABILITIES
Customers (and potential customers) often will run your product through a series of scanners or
security teams
DAST (Dynamic Application Security Testing) used to discover common defects in a running
application. Often identifies SQL injection and cross site scripting issues.
SCA (Software Composition Analysis) discovers OSS components and associates them with known
vulnerabilities (like CVEs, etc..)
Human Teams used to examine the architecture, passwords at rest, APIs etc...
They will expect you fix the most egregious issues.
They will make OSS disclosures part of the contract
RED flags will make them walk away!

44. REMEDIATION ($500 WORD
MEANING FIX!)
It's always better to build in OSS management in new products
Fixing an existing product is often difficult and expensive (but so is
doing nothing)
Legal concerns sometimes get in the way of technical analyses
Oddball licenses lead to large legal bills
GPL-violations can be very expensive to fix
Commerical violations can be VERY VERY expensive to fix
Your suppliers don't have to respect YOUR timetables (and often can't)

45. BEST PRACTICES: WORKING
WITH SUPPLIERS
Try to select vendors who:
• Can provide a current Bill of Materials
• Are Openchain certified
• Have a service level agreement (SLA) for security fixes / alerts
• Willing to get make these contract terms
Do validation tests on code from vendors using SCA & DAST tools as
possible
Remember: The Buck stops with you

46. HOW TO BECOME
COMPLIANT
Build a team of OSS Experts
Create a Bill of Materials (BOM – pronounced like bomb)
Generate SPDX reports
Education (e.g. Linux foundation IP and licensing Courses)
Become Openchain conformant

47. Jeff Luszcz
@JeffLuszcz
HTTPS://ZebraCatZebra.com
Q&A / BREAK
(COME BACK AT TOP OF
THE HOUR)

48. BEST PRACTICES:
EDUCATIONSoftware developers lack training regarding licensing and security
OSS Policies are missing, neglected or impossible to find
Legal can be scared to look for problems
Cost to fix goes up with every layer built upon a mistake
Discovering problems at "Sales time" become red alerts and can destroy
roadmaps and deals
No excuse not to Have EVERYONE get a basic training, good free training
exists
https://training.linuxfoundation.org/training/open-source-licensing-
basics-for-software-developers/

49. REMEDIATION STRATEGIES
A fancy word for fixing!
Rewind: remove a feature to resolve IP problem
Replace: rewrite code to remove and resolve an IP problem
Resolve: pay money or request new licensing
You will sometimes hear the term "shim" used to represent a piece of
code whose job it is to provide a firewall between commercial and
GPL code

50. OSS IN MERGERS AND
ACQUISITIONS
If you are buying or selling a company it is very common to perform OSS Due
Diligence using a third party expert
This typically involves
•Sell side providing "Disclosures" of the OSS they depend on
•Sell side providing access to source code to the independent third party
•Buy side may respond with a list of requested Remediations
•Buy side may require financial hold backs due to IP risk
Time frame for this is typically 2 weeks for first report, a few more weeks for
remediation

51. RELEASING SOMETHING
UNDER AN OSS LICENSE
Pick a license that works for your use case
Remove commercial code (as necessary)
Review use and license of multimedia, images, fonts, sounds, etc..
Review OSS usage and compliance with selected license
Review of Source Code Snippets may be warranted!
Remediate OSS as necessary, sometimes this means changing YOUR license
Generate License Notices
Decide on a Contributor Licensing Agreement, Developer Certificate of
Origin and/or Code of Conduct, etc...

52. WHY DO YOU NEED
AUTOMATED
SCANNING
For most systems we're now using hundreds to
thousands of components, way outside the
ability of humans to intimately be familiar with.
Dunbar's Number (pick one!) tells us a lot about
Human's ability to keep track of things!
"You" can manage 50 components
"We" can manage 500
"WHO" Can manage 5000?

53. BENEFITS OF SOFTWARE
COMPOSITION ANALYSIS
(SCA) SCAN TOOLS
Allows for the Automation of discovery of
OSS components, esp. those brought in
by repository manager tools like Maven or
NPM
Allows license policy to be set, enforced and
modified
Allows vulnerability policy to be set,
enforced and modified
Allows easy creation of up to date Bill of
Materials (BOM) reports
Allows for alerting on security or license
policy problems

54. SCA TOOLS (FREE AND
COMMERCIAL)
Fossa
Github Dependabot
Gitlab Dependency Scanning
JFrog
Revenera (formerly Palamida)
Sonatype
Synk
Synopsys / Black Duck
WhiteSource
binaryanalysis-ng
Eclipse SW360
Fossology
oss-review-toolkit
OWASP Dependency-Check
ScanCode

55. HOW DOES SCA FIND THIRD
PARTY CODE?
Repository Artifacts (maven, npm, pip, etc..)
License Text
Copyright Statements
Exact Files
(sha1, md5)
Source Code
Fingerprints

56. SOURCE CODE
FINGERPRINTS / SNIPPETS
Pros:
Fingerprints allow for the detection of cut and pasted code
Can discover "License Laundering"
Cons:
Can require expert analysis to confirm code origin
Lots of work
"False positives" - though this is sometimes an excuse not to do the
real anaysis

57. SAST / DAST TOOLS
SAST and DAST tools are used to discover new defects in source code
SCA is used to find your BOM and known vulnerabilities
Tools can be run locally or on hosted repositories
Github and Gitlab (and others) pushing security integrations heavily
https://www.theregister.com/2020/10/06/gitlab_scans_customer_code_finds/
Often best results when used on your proprietary code due to difficulty resolving other people's code defects in
OSS
You may want to run SAST/DAST on very small or orphaned projects

58. OPENCHAIN

59. COMPLIANCE BEST
PRACTICES
Use a Software Composition Analysis (SCA) scan tool or tools to build your
BOM
Automatically generate License reports and NOTICES files
Create Source bundles (e.g. tarballs) of copyleft licensed code (GPL, LGPL,
etc..)
Track Commercial libraries and dependencies, keep track of payments /
EULAs
Track webservices
Track changes to OSS source files, mark them appropriately
Check patent issues esp. when dealing with codecs,
Review Vulnerability Reports / CVEs
Run SAST/DAST
You keep this current!

60. THINGS LEARNED ALONG
THE WAY
Compliance is still a personality driven process
 When influencers leave, a company’s compliance process often falls apart
 Bus Factor=<1 at many companies
Experience levels vary greatly across the industry
BOM Inventory depends on who performed or what process was
followed.
Same project could report 10 or 1000 libraries depending on tool or
person.
Analysis Paralysis is a double edged sword
 Initial reviews lead to either NO further reviews or FAR MORE reviews
Remediation is an ART not a Science

61. WHAT IS HARD FOR
COMPANIES?
New code is valued over “maintenance” and few dev cycles are earmarked for
compliance*
 (*outside of post M&A work)
Top level package licenses can be managed but inner-package licensing is
difficult to understand
The typical BOM undercounts by 99%!
Each layer (build, dev, deployed) is managed by different teams who all are
scared to call the lawyers
“Here be dragons issues” like Old code with non-standard licenses from dead
people

62. WHAT’S ON THE HORIZON
The number of packages in a BOM has moved past where humans can easily
monitor using spreadsheets
The build environment and tool chain are being ignored by compliance teams at
the same time targeted Supply Chain Attacks are increasing
We need to start requiring accurate BOMS in contracts with real teeth
“Internal Audit” is waking up to OSS issues
Pressure building for new FOSS licenses / models especially in the database
space

63. Jeff Luszcz
@JeffLuszcz
HTTPS://ZebraCatZebra.com
QUESTIONS AND
THANKS!