Practical Steps to Scale Legal Support for Open Source

Siemens.comUnrestricted © Siemens AG 2016

Four practical steps to scale

legal support for OSS useBlack Duck Flight 16, October 5, 2016

Unrestricted © Siemens AG 2016

Page 2 Thomas Schubert (LC TE SL)

Help > About

I joined Siemens 2013

My team comprises five + nine members

We support two major software-heavy divisions, Digital Factory

and Process Industries and Drives generating a combined

annual revenue of approximately 20 billion Euro.

Our portfolio transitions from a hardware to a software world



The Siemens Digital Enterprise Software Suite

enables our customers to plan, engineer, run and maintain their factories



At Siemens, proper Software Clearing is the

foundation of a healthy Software business

Our clearing activities protect our software business, enabling us to

1. Maintain our ability to sell our products (faster)

2. Protect our proprietary and acquired IP from devaluation

3. Mitigate security vulnerabilities

4. Enable controlled contributions to the OSS Community

5. Protect Siemens from exposure caused by copyright trolls and “disgruntled employees”

Clearing ensures compliance with all license obligations of the third-party software in our products

Key OSS Challenges for

big software companies



Challenge 1: Applications are complex and require in-depth analysis

Sample Application V1

Open Source Components

License 1

Oblig

ation

1

Oblig

ation

2

Oblig

ation

N

License 2

Oblig

ation

1

Oblig

ation

2

Oblig

ation

N

License N

Oblig

ation

1

Oblig

ation

2

Oblig

ation

N

Commercial Components

License

Oblig

ation

1

Oblig

ation

2

Ob

liga

tio

n

N

Component Bundles

License

Oblig

ation

1

Oblig

ation

2

Oblig

ation

N



Challenge 2: OSS packages are getting bigger as platforms evolve

1. A typical Application contains 30-80 OSS Components

2. Each OSS Component has an average of 5-20 licenses

Extreme Example 1: Chromium, 212 licenses, >100,000 files

Extreme Example 2: QT, >600 licenses, >130,000 files, includes Chromium

Sometimes, the main license is permissive and sub-licenses are restrictive (e.g. GPL)

3. Each license has 3-15 obligations in average

This could mean, e.g.: 50 components × 10 licenses × 10 obligations = 5,000 obligations

Every release needs to go through this process (including minor releases, patches, fixes)

There is very little help out there to efficiently manage this complexity (e.g., SPDX is not really relevant)

The industry is moving to online-only deployment which likely increases compliance exposure



Challenge 3: Alternative OSS licensees pose interpretation challenges

1. Cumulative Licensing

Issue: Multiple cumulative licenses apply to the same code

Example: BSD3 and MIT

No decision required, both licenses apply

2. Variable Licensing

Issue: A variable license applies to the code

Example: GPL any version

Decision required

3. Conditional Licensing

Issue: License privilege applies if implementation meets a certain condition

Example: GPL2 with Classpath exception

Exception check required

4. Alternative Licensing

Issue: Multiple alternative licenses apply to the same code

Example: BSD or GPL2

Decision required

Four steps to manage

these key challenges



Step 1: Define sustainable Software Clearing operating model

Build the right team

Establish scalable platform

Create high-performance

operation



Step 2: Agree clearing standard, improve checklists, deliver on time

Define parameters

Define risk appetite and level of OSS package analysis: Main license only or all licenses

Agree license models: Inbound analysis must follow outbound (sale) license models

• Identify your complete set of legal outbound license models

• Clear inbound licenses in accordance with the outbound models (e.g. SaaS and Affero GPL)

• Don’t forget distribution models on the horizon (e.g. SaaS)

Manage commercial suppliers: Do you (re-)do their work or accept a compliance risk?

Align delivery

Standardize license analysis: Reduce the number of obligations to a minimum (“Lean Legal”)

Coordinate internal supply chains: Agree how to handle component bundles

Document processes, offer training, eliminate manual work, reuse existing information

Measure performance

Measure clearing data and KPIs

Obtain clarity on present and future demand for OSS (and also commercial software)



Step 3: Never stop optimizing

Old Word report New database-driven report



Step 4: Invest in Outsourcing

Some clearing activities are repetitive

Scanning

Interpretation of simple commercial EULAs

Scalability is very difficult to accomplish without outsourcing/offshoring

An efficient operation requires near-shore or off-shore clearing teams (ideally with second source)

A functioning outsourcing requires an upfront investment in the people

Technology

Practical Steps to Scale Legal Support for Open Source