getting the automotive industry on the right side of open source compliance
DESCRIPTION
The proliferation of open source software use combined with recent legal actions has raised industry awareness that open source code must be managed in compliance with applicable software licenses. Leading development organizations are establishing policies around open source usage and implementing engineering development processes which insure that software products remain in compliance. In this presentation, Dr. Haddad provides an introduction to open source compliance and discusses some of the best practices related to ensuring open source compliance in the enterprise.TRANSCRIPT
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
The Linux Founda.on Confiden.al 3
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
The Linux Founda.on Confiden.al 4
A Changing Business Environment
The Linux Founda.on Confiden.al 5
• 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
The Linux Founda.on Confiden.al 6
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.
The Linux Founda.on Confiden.al 7
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
The Linux Founda.on Confiden.al 8
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
10 The Linux Founda.on Confiden.al
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?
12 The Linux Founda.on Confiden.al
Building Blocks of a Compliance Program
The Linux Founda.on Confiden.al 13
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?
14 The Linux Founda.on Confiden.al
Sample End-‐to-‐End Compliance Process
The Linux Founda.on Confiden.al 15
What are some of the best prac-ces can we learn from?
16 The Linux Founda.on Confiden.al
Best Prac-ces in Select Areas
• Iden-fica-on • Audit / Source code scan • Resolving issues • Reviews • Approvals • No-ces • Verifica-ons
The Linux Founda.on Confiden.al 17
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
The Linux Founda.on Confiden.al 18
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
The Linux Founda.on Confiden.al 19
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.
The Linux Founda.on Confiden.al 20
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
The Linux Founda.on Confiden.al 21
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?
The Linux Founda.on Confiden.al 22
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.
The Linux Founda.on Confiden.al 23
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.
The Linux Founda.on Confiden.al 24
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.
The Linux Founda.on Confiden.al 25
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
The Linux Founda.on Confiden.al 26
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
The Linux Founda.on Confiden.al 27
Open Compliance Program compliance.linuxfounda-on.org
The Linux Founda.on Confiden.al 28
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
The Linux Founda.on Confiden.al 30
Open Compliance Summit – Oct 24-‐25 hnp://www.linuxfounda.on.org/events
The Linux Founda.on Confiden.al 31
Closing
The Linux Founda.on Confiden.al 32
• 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
The Linux Founda.on Confiden.al 33
Q & A
Compliance.LinuxFounda-on.org
The Linux Founda.on Confiden.al 34
Ibrahim Haddad, Ph.D. Director, Technology & Alliances [email protected]