Open Source process in ECI Share process of establishing the OS process in ECI
- 1. Open Source process in ECI Navah Felberg April 2012
- 2. Presentation Objectives Apr-2012 2 Share process of establishing the OS process in ECI Data collection Mapping requirements Benchmarking Selecting the optimal process for ECI Setting implementation plan
- 3. Background Apr-2012 3 ECI needs to protect itself from illegal use of OS To avoid legal claims To enable future options of going public / due diligence Customer requirements to see OS lists As a result, ECI needs a defined Open- Source process Process package needs to include policy, procedure, supporting tools and training material
- 4. Assumptions Apr-2012 4 WW trend shows increasing use of OS OS is good for the company’s TTM & Quality As long as we don’t risk publishing proprietary code As long as we follow publication license rules Tools Main contribution of tools is to reduce risk of not complying with license terms
- 5. Work Process Apr-2012 5 Defined work process is strongly affected by the 2 following dilemmas: Selecting working model centralized vs. distributed Selecting supporting tools OS scanning tool OS code management tool Combination of both Area of no dilemma: good process needs a balanced combination of both
- 6. Process Steps Apr-2012 6 Approval process for using OS code OS policy OS DB management Approval process for releasing versions with OS code Implementing license rules Testing / verification Release decision New
- 7. Starting Point Apr-2012 7 Existing Open Source OS included in purchased Operating System packages (VxWorks, Linux) Only some of it documented Very partial and outdated Code screening OEM OS not checked / negotiated Step #1 Working on awareness of SW Engineers Establishing OS DB (excel) with known uses of OS in various product lines Low comprehension as to the risks and lack of knowledge in terms of understanding license implications
- 8. Step #2 Apr-2012 8 Benchmarking Company A IL Company B IL Company A US Company B US Official company policy √ √ √ X distribute vs. corp. function corp. function corp. function corp. function individual initiative OS Trustee profile SW Eng background SW Eng background SW Eng background SW Eng members of OS communities members of OS communities OS Trustee R&R approve use of OS package approve use of OS package signoff per release use of scanning tools BlackDuck Protex BlackDuck Protex ? X req by HQ req by HQ scanning by SW team scanning at release level use of DB management tools none none X long response time for approval infringements found at release are too late to handle does not guarantee legal integrity does not scale
- 9. Process suggestion Apr-2012 9 Notes: • Flow without R&R • Per OS request OEM agreement declaration form ECI dev application new OSS? application form flow* approved? upload OSS to DB send notifications + instructions & license restrictions upload project data to DB No upload as Reject OSS to DB suggest alternatives publish instructions / restrictions Periodical monitoring Yes
- 10. application request OSS #1 notifications + instructions & license restrictions im plem entation of liecense rules per OSS new OSS? application form flow * approved? upload OSS to DB upload project data to DB No upload as Reject OSS to DB suggest alternatives publish instructions / restrictions Periodical m onitoring Yes Process suggestion – version view Apr-2012 application processing per OSS application request OSS #n notifications + instructions & license restrictions im plem entation of liecense rules per OSS new OSS ? application form flow * approved? upload OSS to DB upload project data to DB No upload as Reject OSS to DB suggest alternatives publish instructions / restrictions Periodical m onitoring Yes application processing per OSS application request OSS #2 notifications + instructions & license restrictions im plem entation of liecense rules per OSS new OS S? application form flow* approved? upload OSS to DB upload project data to DB No upload as Reject OSS to DB suggest alternatives publish instructions / restrictions P eriodical m onitoring Yes application processing per OSS verification of above im plem entation per RELEASE
- 11. Process implementation assumptions Apr-2012 11 Assumption for Starting point: Appointing OS trustees acc to chosen model All relevant personnel is trained All product lines are re-tested to create clean baseline.
- 12. Process adoption options Apr-2012 12 Model #1: Centralized approval authority Model #2 Distributed OS trustees
- 13. Process adoption options - comparison Apr-2012 13 no tools* Goal centralized distributed ** acc to products keeping standard policy High expertise High expertise easier to enforce open to interpretation adhering to process - requesting approval more formal - may be skipped, bottleneck approvers close to SW developers / designers adhering to process - clean release all OS was approved more formal - may be skipped OS trustees close to SW developers / designers implementing license rules bottleneck, may have contradictions between the license conditions open to interpretation due to non uniform policy, may have contradictions between the license conditions Managing OEM OS OEM statement recording only No effective way to handle / supervise OEMS * but with baseline scanning ** Open question: if distributed - how distributed?
- 14. mitigated Goal centralized distributed acc to products keeping standard policy High Expertise High Expertise easier to enforce policy integrated into approval tools adhering to process code screening to immune against missing approvals, code management to support scale approvers close to SW developers / designers adhering to process - clean release all OS was approved use of code screening to immune against missing approvals approvers close to SW developers / designers implementing license rules bottleneck at release Interpretation solved by integrating policy into approval tools, contradictions between licenses may still exist Managing OEM OS OEM code is part of scanning No effective way to handle / supervise OEMS Process adoption options - comparison Apr-2012 14 BlackDuck scanning tool + DB management BlackDuck Code Center OS DB management
- 15. Process adoption options - tools Apr-2012 15 Quotes for: Baseline scanning Annual scanning Ongoing scan OS DB management tools
- 16. Tools - ROI Apr-2012 16 Option 1: Comparing 2 situations with no legal risks / implications: (dev_costs) – (OS_tools_cost) where dev_costs = resources (MH) saved by using OS OS_tools_cost = OS management + scanning tools …tool (almost) always wins….
- 17. On one hand - not enough info on claims to evaluate risk of claims ROI – cont. Apr-2012 17 Option 2: Analyzing cost of tools vs. risks of penalties Penalties are 2folds: Risk of legal claim Risk when going public On the other hand – giant war starting out…
- 18. Selecting working mode centralized or distributed Recommendations Apr-2012 18 Benefits: High expertise required OEM only covered in this model Experience of all benchmarks
- 19. Recommendations Apr-2012 19 Selecting supporting tools Optimal solution: Scanning + Code Management, with annual subscription, xxxK Alternatively - Implementing by phases Phase 1: new updated baseline scan Phase 2: OS DB management Evaluating OS DB tool vs. SharePoint application Phase 3: yearly scan Reminder – the only way to truly handle OEMs
- 20. Status Apr-2012 20 Rewriting Policy – final stages Nominating OS Trustees completed Communicated Trustees training: basic knowledge of licenses & license implications, new policy draft, etc. Updated SharePoint OS DB on Intranet - completed Working on External SharePoint OS DB Checking alternatives for supporting tools Updating affected procedures & docs – over the OS process (NPI, release, OEM) – in process
- 21. Main Challenges – nominating OS Trustees Apr-2012 21 Lega l resp onsi bility In unknown knowledge domain Getting people to accept responsibility
- 22. Future Plans Apr-2012 22 Training: training kit for new employees training kit for OS Trustee training records new employees – signature issue OEM OS DB management debates
- 23. May 1, 2025 Work process - Summary 23 Initial objective: Update OS procedure Estimated time: 1 month
- 24. Work process - Summary Apr-2012 24 Final delivery: Update OS policy, OS procedures, effected procedures Creating internal and external database Recommendations for testing and verification Preparing training kits
- 25. Last but not least Apr-2012 25 Remember: There may be many interpretations as to correct handling of specific licenses The most important thing is to be able to prove good faith in handling the open source issue This can be achieved by having a policy, a procedure, DB, and audit evidence.