getting the automotive industry on the right side of open source compliance

Ge#ng the Automo-ve Industry on the Right Side of Open Source Compliance: All the Basics You Must Know Ibrahim Haddad, Ph.D. Director, Technology and Alliances

Agenda

•  Compliance 101

•  Best Prac-ces – from an opera-onal perspec-ve

•  The Linux Founda-on Open Compliance Program

The Linux Founda.on Confiden.al 2

Compliance 101


A Changing Business Environment

Middleware (Proprietary, 3rd party or a mix)

Commercial Applications

(3rd Party)

Proprietary Applications

Proprietary OS

Open Source

Applications

Middleware (Open Source, Proprietary, 3rd party or a mix)

Linux Kernel

Proprietary Applications

(possibly include

Open Source code)

Open Source Driver

Chip

Open Source Driver

Chip

Commercial Applications

(possibly include

Open Source code)

Open Source Driver

Chip

Proprietary Driver

Chip

Proprietary Driver

Chip

Proprietary Driver

Chip


A Changing Business Environment


•  Commercial licenses are nego-ated

•  Limited number of licenses

•  The business environment is predictable

•  Companies ensure contractual protec-on through through license nego-a-on and commercial contracts

•  The origin of soRware components is known

•  FOSS Licenses are not nego-ated

•  Dozens of FOSS licenses involved

•  The business environment is less predictable

•  Thousands of contributors to the various FOSS used

•  The origin of some components may not be clear

•  Maintenance and support are variable and self-‐service

Compliance Objec-ves

•  Observe all the copyright no-ces and sa-sfy all the FOSS license obliga-ons

•  Ensure compliance with 3rd party soRware licensing

•  Protect product differen-a-on

•  Facilitate effec-ve usage of FOSS


Achieving Compliance

•  Through aggregate of: Ø  policies Ø  processes Ø  training Ø  tools

that enables an organiza-on to effec-vely use FOSS and contribute to projects Ø  respec.ng copyrights, Ø  complying with license obliga.ons, and Ø  protec.ng the organiza.on's intellectual property and that of its customers and suppliers.


What Basic License Obliga-ons Must Be Sa-sfied?

•  Depending on the license(s) involved, obliga-ons could consist of: Ø  Inclusion of copyright and license in the source code and/or product Ø  No.ces as to source code availability – for original work, for combined work or modifica.ons, and so on

Ø  Documenta.on, so that downstream users know the origin of the soNware and what their rights are.

Ø  Disclaimers of warranty on behalf of the authors Ø  Etc.

•  Analysis of source code is needed to clarify obliga-ons


How public non-‐compliance cases were se^led?

•  Become compliant •  Appoint a compliance officer •  Publish licensing no.ce on their website

•  No.fy 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

•  Provide addi.onal no.ces in product publica.ons

•  Make available the complete and corresponding source code

•  Cease binary distribu.on of the OSS in ques.on un.l it has published complete corresponding source code on its web site

•  Pay an undisclosed amount of financial considera.on to the plain.ffs

9 The Linux Founda.on Confiden.al

3 Key Lessons

•  Ensure Compliance Prior to Product Shipment

•  Non-‐Compliance is Expensive

•  Educa-on and Training are Key


11

Legal Localiza-on

Documenta-on

Supply Chain

IT

Corporate Development

Compliance Officer

Engineering

Product Team

OSEC

Who is responsible for achieving compliance?

The Linux Founda.on Confiden.al

How to Implement an Efficient and Light-‐weight Compliance Program?


Building Blocks of a Compliance Program


Policies and Processes

Teams

Tools

Educa.on

Usage

Automa.on

Contribu.on Distribu.on Audi.ng

Audi.ng Code Project Management

Inventory Management

Linkages Analysis

Code Inspec.on

Formal Training

Guidelines & Prac.ces

Brown Bag Seminars

Obliga.ons Fulfillment

Usage e-‐Form Contribu.on e-‐Form

Audi.ng e-‐Form

Templates

Internal Web Portal

External Web Portal

Strategy

Core Team (OSRB)

Extended Team

Messaging Internal

External

Compliance Strategy

Inquiry Response

Invited Speakers

Employee Orienta.on

Workflow

BoM Difference

Linguis.c Review

Binary Analysis

What compliance process should we have in place?


Sample End-‐to-‐End Compliance Process


What are some of the best prac-ces can we learn from?


Best Prac-ces in Select Areas

•  Iden-fica-on •  Audit / Source code scan •  Resolving issues •  Reviews •  Approvals •  No-ces •  Verifica-ons


Iden-fica-on

•  Iden-fy all the components included in the product and their origin.

•  There are three main sources for incoming source code: Ø  Proprietary:

§  Developed by your own engineers (may include snippets of FOSS or in many cases depends on or links to FOSS)

Ø  Third Party Commercial: §  Developed by third party soNware providers or consultants and offered to you under a

commercial or FOSS license (may include snippets of FOSS or in many cases depends on or links to FOSS)

Ø  FOSS: §  Developed by members of the FOSS community


Iden-fica-on – Basic Housekeeping

•  Print out and retain the license informa-on at the -me you download the soRware Ø  Backtracking doesn’t always work because:

§  Open source projects change their licenses §  You may wish to take the code under an earlier version than the current one

•  Double check that the license terms in the source distribu-on match the ones described on the project web site

•  If you cannot iden-fy a license, ask legal to iden-fy it for you


Source Code Audi-ng

•  Scan all source code to iden-fy origin and license •  Scan early and oRen. It allows you to:

Ø  Discover compliance problems as they occur Ø  Provide solu.ons to discovered problem within acceptable delays Ø  Keep the delta with the previous scan to a minimum Ø  Perform incremental scan in a very efficient way

•  Scan newer versions of previously approved packages: Ø  Each .me Engineers modify a previously approved component or plan to use a previously approved component in a different product, the source code of the modified component is re-‐scanned and the component has to go through the approval process again.


Resolving issues iden-fied by the audit

•  When in doubt with the scan results discuss with Engineering.

•  Inspect and resolve each file or snippet flagged by the scanning tool.

•  Iden-fy if your engineers made any code modifica-ons. Ø  Use tools to iden.fy code changes, who

made them and when Ø  Document all changes to open source

modules

•  If you iden-fies GPL-‐licensed source code (for instance) integrated in a proprietary component, you should report to Engineering and request correc-on. Ø  Re-‐scan the code to verify

•  In prepara-on of the legal review, provide Legal with all informa-on you discovered on the licensing of the specific component. Ø  For FOSS components, that includes

COPYING, README, or LICENSE files


If you can’t comply

•  If there are conflicts or compliance is not possible: Ø  Can you live without this code? Ø  Can you create a work around? Ø  Is there a newer (or older) version of this code under a different license? Ø  Is there an alterna.ve FOSS project with same func.on under a different license?

Ø  Can you contact the author(s) and ask for an excep.on / different license?


Architecture Review

•  The architecture review is an analysis of the interac-on between FOSS and your proprietary and third party soRware components that iden-fies: Ø  Components that are FOSS (used “as is” or modified) Ø  Components that are proprietary Ø  Components that are third party licensed under a commercial license Ø  Components dependencies Ø  Communica.on protocols Ø  Dynamic versus sta.c linking Ø  Components that live in kernel space versus user space Ø  Shared header files Ø  Other FOSS that the specific soNware component interacts with or depends on especially if

it is governed by a different FOSS license

•  The result of the architecture review is an analysis of the licensing obliga-ons that may extend from the FOSS to the proprietary or third party components.


Approvals

•  The OSRB is responsible for approving the usage of FOSS in products. Ø  Legal + Product Management + Technical Expert + Open Source Expert

•  There are two important prac-ces to note: Ø Make sure that all sub-‐tasks related to the compliance .cket have been completed and closed before approving the compliance .cket. ONen, it is easy to forget sub-‐tasks or pending sub-‐issues, which may lead to closing a compliance .cket that may s.ll have problems.

Ø  Record the minutes of the OSRB mee.ng and the summary of the discussions leading to the decisions of approval or denial. This informa.on can become very useful when you receive compliance inquiries.


No-ces

•  Wri^en offer •  License no-ce and text •  Copyright no-ce •  A^ribu-on no-ce •  Etc.

•  Be clear in the language of the wri^en offer and inclusive of all FOSS included in your product.

•  It is oRen the case that companies include this informa-on in the product manual, on their web site, inside a soRware development kit (when applicable), etc.


Verifica-ons

•  Due to the large number of verifica-ons steps, it is very useful to develop checklists to make sure you went through all the steps needed to complete your compliance.

•  Example of a post-‐distribu-on checklist: Ø  Validate that the FOSS package has been uploaded to the web site and that it is accessible from an external computer

Ø  Validate that the FOSS package can be downloaded from an external computer and uncompressed without errors

Ø  Validate packages compile and build properly Ø  Validate that it matches the binary in the product


Responding to Compliance Inquiries

Acknowledge

Inform

Investigate

Report

Rectify

Improve

Incoming Inquiry

These steps are taken only if a viola.on was found

Close Inquiry


Open Compliance Program compliance.linuxfounda-on.org


Goals of the Open Compliance Program

29

•  Increase awareness of compliance – neutral education and training

•  Bridge the disconnect between companies and the developer community

•  Standardize some aspects related to compliance across industries

•  Increase collaboration on open source compliance

The Linux Founda.on Confiden.al

All program elements are focused on the opera-onal side of compliance


Open Compliance Summit – Oct 24-‐25 hnp://www.linuxfounda.on.org/events


Closing


•  The Auto industry has the advantage of learning from many other industries who already did the migra-on towards Open Source.

•  Compliance is simple and easy to achieve – It is more of an opera-on and scaling challenge, than a legal one.

•  The Linux Founda-on offers a number of resources that you can use to enable be^er and more efficient compliance.

[email protected] compliance.linuxfounda-on.org


Q & A

Compliance.LinuxFounda-on.org


Ibrahim Haddad, Ph.D. Director, Technology & Alliances [email protected]

getting the automotive industry on the right side of open source compliance

Technology

linux founda

foss foss

open source compliance

analysis of source code

compliance process

source code availability

incoming source code

source code andor product