Journey to Establish an Open Source Policy in a Fortune 20 Health Care Company

1© 2016 Express Scripts Holding Company. All Rights Reserved.

Journey to Establish an Open Source Policy in a Fortune 20 Health Care CompanyDamian Ng

Head of Platform Architecture and Technology

All Things Open 2017


About me

• Distinguished Architect, Head of Platform Architecture and Technology at Express Scripts (ESI)

• Leading platform strategy, target state architecture and technology innovation

• Open Source Evangelist of ESI

• Chief Company Pick up Soccer Organizer

• Just help built the first company legal policy

with in house counsel

www.linkedin.com/in/ngdamian/

[email protected]

http://www.linkedin.com/in/ngdamian/


What to Expect Today?


Background

• ESI had a heavy focus on outsourcing.

• ESI has contractual agreements with vendors to cover software rights.

• If developers needed to ingest, ESI handled it ad hoc.

• Generally no company open source contributions.

• No glaring need for an Open Source Policy.

• Major technology transformation in 2016 re-focused ESI on innovation and leveraged open source technology as one of the key avenues to do so.


How did we start?

• Headaches

• So many licenses!

• Legal knowledge of OSS is scarce

• Huge knowledge gap between understanding Open Source and designing an Open Source policy for a Fortune 100 company

• Same license has various implications in different use cases

• Avoid building a huge legal team to support the process

• Our Priorities

No Policy

Ingestion

Contribution

Less urgent, more

complex


Ingestion Policy


What do our developers care?

Where to

Explore?

Legal Risk?

Good Idea?

Software Safe?


Objectives of ESI Ingestion Policy

Encourage

Exploration

Review on High Risk

Areas

100% Compliance

vs. Practicality

Self-Govern


Step #1: Develop Ingestion Matrix

• Build a Legal Review Ingestion Matrix for internal OSS Ingestion

• Handle 8 common consumption scenarios

• Cover top 11 licenses

• Auto-approve most scenarios without further legal review

• Everything else reviewed manually

• Experimentation is automatically green-lighted.

• No written approval is needed for all the green light scenarios, but record for tracking purposes.

• Focus on fixing continued ingestion and new use cases.

✔


License/Use Case Coverage

• Licenses:

• Apache 2.0

• BSD 2

• BSD 3

• CDDL

• Eclipse 1.0

• GPL 2.0

• GPL 3.0

• LGPL 2.1

• LGPL 3.0

• MIT

• MPL 2.0

• Use Cases

• Experimental Testing

• Code/Library that runs on a production server.

• Code/Library that isdistributed to users as a product

• Websites where codeexecutes on client side

• Infrastructure

• Internal Use End User Tool

• Build Tool which incorporatecode


ESI Open Source Ingestion Matrix

Proposed Consumption based on Identified Scenarios

Open Source Licenses

ExperimentaionTesting Scenario #2 Scenario #3 Scenario #4 Scenario #5 Scenario #6 Scenario #7 Scenario #8

License #1

License #2

License #3

License #4

License #5

License #6

License #7

License #8

License #9

License #10

License #11

All Other Licenses

Green Legal/patent has deemed license and proposed consumption is a low risk; no legal/patent review required.

Yellow

Legal/patent has deemed license and proposed consumption is a medium risk; legal/patent review required to determine whether: (i) there is no issue, (ii) there is an issue that can be mitigated, or (iii) there is a significant concern that must be addressed.

Red

Legal/patent has deemed license and proposed consumption is a high risk; legal/patent review required to determine whether: (i) there is an issue that can be mitigated, or (ii) there is a significant concern that must be addressed.


Lesson Learned: Ingestion Matrix

• Surprisingly, most of our ingestion scenarios are “green”

• Native mobile applications causes the most “red”

• It falls almost directly into “distribution” scenario

• Build tools for mobile applications insert code via static linking

• Dependency management and libraries are not your friend

• Need to look up license information for dependencies

• AGPL is definitely not your friend

• Rely on your engineers to provide feedback and updates on product licenses.

Legally Approved Good Technical Ideaor

Secure Software


Step #2: Process Flows for “everything else”• Surprise !! Developers downloading software is one of many

scenarios bringing in Open Source Software into the organization!

• Other Common Scenarios

• Off the Shelf Software

• Vendor Custom Software Development

• Vendor Built Software with Custom Development

• SaaS/Cloud Software

• Vendor/Contractor Developer Usage

• Change of legal position to share Open Source Software liability with vendors.


Sample Process Flow Diagram


Lesson Learned: Process Flows

• More non-developer ingestion when policy first rolled out.

• Dependency management and libraries are not your friend, again.

• But this time vendors/partners need to provide all the information.

• Spend time to diagram the process flows help explain concepts a lot easier.

• Socialize the process with sourcing/procurement!!

• Take a lot longer to roll out the programs/flows than we anticipated


Contribution Policy


Objectives

Contribute Personal

code without

Approval

Visibility and Approval of ESI Code

Contribution

Simplify Process to Contribute post initial approval

Minimize Risk of

unintentionally licensing patents


What do our developers care?

I wrote some code while

employed by ESI, can I

contribute?

What’s the process?

Need a contribution

policy!


Common Mis-conceptions

The code is mine!

If I write my code in non-

company time

If I write my code in my personal

laptopIf the code is not related to my company

business

It’s MINE !!!


Step #1: Who has the right of what?

• We reviewed existing ESI IP assignment agreement signed by employees:

• What does the company own (e.g. business IP, personal IP, etc.)?

• What do employees own?

• What’s the review process to determine rights?

• Discovered gap that did not allow for open source contribution and modify the IP assignment agreement.

Needed to first modify the IP assignment agreement before launching the contribution policy.

The IP agreement must be first signed by employees before executing the policy!!


Step #2: Clear Explanation of IP Ownership• What code do I write?

• Your code IS Company IP if it is ESI business related.

• Where do I write/store the code?

• Company or personal laptop is NOT a factor on whether the code is Company IP.

• When do I write the code?

• Company or personal time is NOT a factor on whether the code is Company IP.

• Code I owned before joining the company?

• That’s all yours.

• Code I owned before joining the Company but continue to develop while at the Company?

• Code before joining the company is all yours.

• Business related code after joining the company is Company IP; personal code is all yours.

Prepare this for your

technology team !


Step #3 Contributing

• Request legal approval for contribution

• Legal review for the following:

• Proprietary nature of code and competitive risk of

contribution

• Business Proprietary vs. common utilities

• New project vs. bug fix

• Estimated LOC

• Upon written approval to contribute, ESI developer can start contributing project code to Open Source.

• Re-evaluate every 6 months; or based on VP approval

• Open Source license is irrelevant

• Minimize company references

• Personal email vs. Company email


Lesson Learned: Contribution Policy

• Our IP assignment did not cover Open Source contribution; take time to adjust it before the policy can be rolled out.

• Try to roll out the policy to align with re-signing of the IP agreement!

• Legal review is required more frequently than anticipated. Developers and even management often have no visibility on potential M&A activities.

• Referencing the company during contribution could be tricky; check with your legal/communication teams.

• Treat company contribution as an edge case.

• Do not attempt to review the actual code.

• Build simplified version of explanation instead of only using legal documents.

• No silver bullet templates to be leveraged.


Thank You !