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 Conﬁden.al 2

Compliance 101 The Linux Founda.on Conﬁden.al 3

A Changing Business Environment Commercial Proprietary Commercial Proprietary Applications Applications Applications Applications (3rd Party) (possibly include (possibly include Open Open Source code) Open Source code) Source Applications Middleware Middleware (Proprietary, 3rd party or a mix) (Open Source, Proprietary, 3rd party or a mix) Proprietary OS Linux KernelProprietary Proprietary Proprietary Open Source Open Source Open Source Driver Driver Driver Driver Driver Driver Chip Chip Chip Chip Chip Chip The Linux Founda.on Conﬁden.al 4

A Changing Business Environment •  Commercial licenses are nego-ated •  FOSS Licenses are not nego-ated •  Limited number of licenses •  Dozens of FOSS licenses involved •  The business environment is predictable •  The business environment is less predictable •  Companies ensure contractual protec-on through through license nego-a-on and •  Thousands of contributors to the various commercial contracts FOSS used •  The origin of soRware components is •  The origin of some components may not known be clear •  Maintenance and support are variable and self-‐service The Linux Founda.on Conﬁden.al 5

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 eﬀec-vely use FOSS and contribute to projects Ø  respec.ng copyrights, Ø  complying with license obliga.ons, and Ø  protec.ng the organiza.ons intellectual property and that of its customers and suppliers. The Linux Founda.on Conﬁden.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 •  Provide addi.onal no.ces in •  Appoint a compliance officer product publica.ons •  Publish licensing no.ce on •  Make available the complete their website and corresponding source code •  No.fy previous recipients of the product that the product •  Cease binary distribu.on of contains GPL code and the OSS in ques.on un.l it inform them of their rights to has published complete receive a copy of the source corresponding source code code on its web site •  Pay an undisclosed amount of financial considera.on to the plain.ffs The Linux Founda.on Confiden.al 9

3 Key Lessons •  Ensure Compliance Prior to Product Shipment •  Non-‐Compliance is Expensive •  Educa-on and Training are Key The Linux Founda.on Conﬁden.al 10

Who is responsible for achieving compliance? Documenta-on Engineering Supply IT Chain Compliance Oﬃcer Product Team Localiza-on Legal OSEC Corporate Development The Linux Founda.on Conﬁden.al 11

How to Implement an Eﬃcient and Light-‐weight Compliance Program? The Linux Founda.on Conﬁden.al 12

Building Blocks of a Compliance Program Strategy Compliance Inquiry Strategy Response Policies and Usage Contribu.on Distribu.on Audi.ng Obliga.ons Fulfillment Processes Teams Core Team Extended (OSRB) Team Tools Audi.ng Code Project Inventory Linkages Code BoM Binary Linguis.c Management Management Analysis Inspec.on Difference Analysis Review Educa.on Formal Guidelines & Brown Bag Invited Employee Training Prac.ces Seminars Speakers Orienta.on Automa.on Usage e-‐Form Contribu.on Audi.ng Templates Workflow e-‐Form e-‐Form Messaging Internal External Internal External Web Portal Web Portal The Linux Founda.on Confiden.al 13

What compliance process should we have in place? The Linux Founda.on Conﬁden.al 14

Sample End-‐to-‐End Compliance Process The Linux Founda.on Conﬁden.al 15

What are some of the best prac-ces can we learn from? The Linux Founda.on Conﬁden.al 16

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-ﬁca-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 Conﬁden.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 •  If you iden-fies GPL-‐licensed results discuss with Engineering. source code (for instance) integrated in a proprietary component, you should report to •  Inspect and resolve each file or Engineering and request snippet flagged by the scanning correc-on. tool. Ø  Re-‐scan the code to verify •  Iden-fy if your engineers made •  In prepara-on of the legal review, any code modifica-ons. provide Legal with all informa-on Ø  Use tools to iden.fy code changes, who you discovered on the licensing of made them and when the specific component. Ø  Document all changes to open source Ø  For FOSS components, that includes modules 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 Conﬁden.al 24

No-ces •  Wriên offer •  Be clear in the language of •  License no-ce and text the wriên offer and inclusive of all FOSS included •  Copyright no-ce in your product. •  A^ribu-on no-ce •  Etc. •  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 Incoming Acknowledge Inquiry Inform Investigate Report These steps are taken Rectify only if a viola.on was found Improve Close InquiryThe Linux Founda.on Conﬁden.al 27

Open Compliance Program compliance.linuxfounda-on.org The Linux Founda.on Conﬁden.al 28

Goals of the Open Compliance Program•  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 complianceThe Linux Founda.on Conﬁden.al 29

All program elements are focused on the opera-onal side of compliance The Linux Founda.on Conﬁden.al 30

Open Compliance Summit – Oct 24-‐25 hnp://www.linuxfounda.on.org/events The Linux Founda.on Conﬁden.al 31

Closing The Linux Founda.on Conﬁden.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êr and more efficient compliance. Ibrahim@LinuxFounda-on.org compliance.linuxfounda-on.org The Linux Founda.on Confiden.al 33

Q & A Compliance.LinuxFounda-on.org Ibrahim Haddad, Ph.D. Director, Technology & Alliances Ibrahim@LinuxFounda-on.org The Linux Founda.on Conﬁden.al 34

Getting the Automotive Industry on the Right Side of Open Source Compliance

by Ibrahim Haddad on Sep 18, 2012

Accessibility

Categories

Upload Details

Usage Rights

Statistics

Getting the Automotive Industry on the Right Side of Open Source Compliance Presentation Transcript