A large company employing thousands of software developers worldwide faces many challenges to consistently manage its processes for using and releasing software under Free Software licenses. Open source knowledge and expertise often varies dramatically across business verticals, as does understanding of how open source communities function. The underlying compliance requirements of Free Software licenses, however, are the same for every organization, regardless of size. What can companies do to ensure certain degrees of cohesion and competency are reflected across their diverse open source offerings? This presentation will present some of my experiences with developing and refining corporate-wide practices that are designed to be transparent, repeatable, and scalable. The lessons learned can be applicable to any entity dealing with Free Software.

1. Alexios Zavras
Open Source Compliance
Intel Corp.

2. 2
About me
Alexios Zavras (zvr)
▪ First time in SFScon!
▪ Greek, living in Munich, Germany
▪ PhD Computer Science
▪ Free Software since 1983
– Long-term view
– Member of communities
▪ Senior Open Source Compliance Engineer of Intel
Disclaimer: views expressed herein are mine; they do not necessarily reflect the views of Intel Corp.

3. Who is Intel?
You may have heard of us…
• Leading manufacturer of computer and communications products
• Headquartered in Santa Clara, California
• Over 100.000 employees, 190 sites in 90+ countries
• Over 15.000 employees developing software

4. Intel and Free Software
No discussion on merits of Free Software anymore
Both consume and contribute
• Consistently a top or #1 corporate contributor to Linux
• One of top corporate contributors to AOSP/Chromium, Apache Spark,
OpenStack and many others
• Deliver enabling, tuning, and optimizations to hundreds of FOSS projects
• Every business unit is active in Free Software!

5. Challenges (these might be familiar)
Size and scope of operations
• Who is doing what, where?
Heterogeneous organizational structures
with varying levels of FOSS knowledge
• There’s a whole spectrum
Policies and practices must scale
• Repeatable and understandable
Like a giant game of whack-a-mole

6. 6
Software Licenses
Software Licenses specify:
▪ Rights
– What you may do
– e.g., copy the code, modify it, re-distribute it
▪ Obligations
– What you must do
– e.g., use the same license, mention author’s name

7. 7
Compliance
Software nowadays is a combination of components
We should comply with all obligations of all licenses
▪ Straightforward
▪ But not trivial or easy
Everyone struggles!
▪ Small group of people
▪ Industry collaborations

8. FOSS governance/compliance program
is necessary to mitigate risks
Compliance isn’t just a matter of law, but makes us better community citizens
Policies should address both inbound and outbound software
Ideas for attributes of an effective program:
• Mandatory training
• Use of supportive tools
• Review by panel of experts

9. Mandatory training
Free Software licensing basics
• What it is, how it works
• Understanding license obligations and how to fulfill them
• Identifying potential license conflicts
Other topics
• Handling 3rd party IP
• Handling own IP
• Internal processes and tools

10. Use of support tools
Many tools available to detect presence of FOSS and manage BOMs
▪ Choose what works best for you
But… don’t rely on scanning alone to “know” what’s in your code
• PLAN BEFORE DETECTION!
• Development teams should be trained to document the name, origin,
and license of any 3rd party code before incorporating into a project
• Use scanning to verify plan
• Avoid surprises

11. The ‘secret ingredient’: review by panel of experts
“Given enough eyeballs, all bugs are shallow”
Technical and legal representation
Peer review functionality (but not code review)
• Architectural review
• Feedback on likely community acceptance of a particular action or strategy
• Advice on community etiquette
Operates like an FOSS project
• Group of committers, maintainers, and BDFL
• All are welcome; members ‘rise to the top’ based on contributions

12. 12
SPDX – Software Package Data Exchange
Standards for communicating components and licenses
▪ Specification
▪ License List
Working groups:
▪ Technical
▪ Legal
▪ Outreach

13. 13
SPDX Licenses
Authoritative list of names and short identifiers
▪ MIT, BSD-3-Clause, GPL-2.0-or-later, …
▪ Expressions
EPL-2.0 OR MPL-2.0
▪ Use in source files:
– SPDX-License-Identifier: Apache-2.0
– Already in many projects, including the Linux kernel

14. 14
OpenChain
Making Open Source license compliance simpler, across the supply chain
▪ Specification
▪ Curriculum
▪ Conformance
▪ Tools

15. Recommendations for companies of any size
You need a governance/compliance policy – if you don’t have one yet, get on it
Educate, educate, educate
• Leverage free training resources
Develop internal OSS community that role models best of OSS norms
• Forms basis for ‘expert review panel’
Join the community!
• You are not alone (nor unique)!

16. 16
Questions?