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

  • 457 views
Uploaded on

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. …

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.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
457
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
2
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • 09/19/12
  • 09/17/10 08/14/11

Transcript

  • 1. 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  
  • 2. 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
  • 3. Compliance  101  The  Linux  Founda.on  Confiden.al 3
  • 4. 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  Confiden.al     4
  • 5. 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  Confiden.al     5
  • 6. 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
  • 7. 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.ons  intellectual  property   and  that  of  its  customers  and  suppliers.  The  Linux  Founda.on  Confiden.al     7
  • 8. 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
  • 9. 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
  • 10. 3  Key  Lessons  •  Ensure  Compliance  Prior  to  Product  Shipment  •  Non-­‐Compliance  is  Expensive  •  Educa-on  and  Training  are  Key  The  Linux  Founda.on  Confiden.al     10
  • 11. Who  is  responsible  for  achieving  compliance?   Documenta-on   Engineering   Supply   IT   Chain   Compliance     Officer   Product   Team   Localiza-on   Legal   OSEC   Corporate     Development  The  Linux  Founda.on  Confiden.al     11
  • 12. How  to  Implement  an  Efficient  and  Light-­‐weight   Compliance  Program?  The  Linux  Founda.on  Confiden.al     12
  • 13. 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
  • 14. What  compliance  process  should  we  have  in  place?    The  Linux  Founda.on  Confiden.al     14
  • 15. Sample  End-­‐to-­‐End  Compliance  Process  The  Linux  Founda.on  Confiden.al 15
  • 16. What  are  some  of  the  best  prac-ces  can  we  learn  from?    The  Linux  Founda.on  Confiden.al     16
  • 17. 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
  • 18. 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
  • 19. 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
  • 20. 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
  • 21. 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
  • 22. 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
  • 23. 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
  • 24. 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
  • 25. No-ces  •  Wri^en  offer     •  Be  clear  in  the  language  of  •  License  no-ce  and  text   the  wri^en  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
  • 26. 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
  • 27. 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  Confiden.al 27
  • 28. Open  Compliance  Program   compliance.linuxfounda-on.org  The  Linux  Founda.on  Confiden.al 28
  • 29. 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  Confiden.al     29
  • 30. All  program  elements  are  focused  on  the   opera-onal  side  of  compliance  The  Linux  Founda.on  Confiden.al 30
  • 31. Open  Compliance  Summit  –  Oct  24-­‐25   hnp://www.linuxfounda.on.org/events  The  Linux  Founda.on  Confiden.al 31
  • 32. Closing  The  Linux  Founda.on  Confiden.al 32
  • 33. •  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.        Ibrahim@LinuxFounda-on.org   compliance.linuxfounda-on.org    The  Linux  Founda.on  Confiden.al 33
  • 34.   Q  &  A   Compliance.LinuxFounda-on.org   Ibrahim  Haddad,  Ph.D.   Director,  Technology  &  Alliances   Ibrahim@LinuxFounda-on.org  The  Linux  Founda.on  Confiden.al 34