bringing commercial software to open source

Bringing Commercial Software to Open SourceAll Things Open - October 19, 2015Roman Shaposhnik, Director of Open SourceCyrus Wadia, Associate General Counsel – Strategic IP

SECTION 1 Overview

SECTION 2 Business & Legal Choices

SECTION 3 Engineering & Community Choices

SECTION 4 Execution

SECTION 5 Case studies

Agenda

0. Pivotal’s 2015 journey

Pivotal Gemfire

Pivotal HAWQ Pivotal Greenplum DB

0. Pivotal’s 2015 journey to 100% open source

Apache Geode (incubating)

Apache HAWQ (incubating) Greenplum DB

1. Overview● Why choose to take your commercial software to open source?● What OSS model will accomplish your goals?● How do you address the weight of existing code and cultural history?● What type of community do you want to create?● What open source license should you attach to the project?● What governance and development models?

1. Overview | Pivotal’s paths to Open Source

Vital Stats: 3.25M Lines of Code; 5 YEARS OF DEVELOPMENT

Vital Stats: 2M Lines of Code; 12 YEARS OF DEVELOPMENT

Vital Stats: 1.3M Lines of Code; 15+ YEARS OF DEVELOPMENT

WHAT Is It?:Open source cloud computing platform as a service

What Is It? : Application Development Platform that

What Is It? Distributed, in-memory database for scale-out applications

What Does It Do: Supports the full application lifecycle, from development, through testing stages, to deployment, in multiple clouds

License Type: Apache 2.0

What Does it Do? helps Developers build simple, portable, fast and JVM-based cloud-native applications


What Does it Do? Features elastic performance, database consistency, and resilient clustering


7

2. Business & Legal Choices | OSS Business Models

1. “Pure” Open Source2. Community Open Source3. Services + Support Open Source4. Subscription Open Source5. Multi-License Open Source

Choice #1Who should “own”

the software?

Company

New OSS Foundation

Existing Foundation

You (+) Choose

Foundation Chooses

You (+) Choose

Foundation Chooses

Choice #2What License SHOULD

you uSe?

Choice #3What Governance/

Development Model?

2. Business & Legal Choices | The Three Big Choices

Choice #1Who should own

software TM & IP?

Company

New OSS Foundation

Existing Foundation

You (+) Choose

Foundation Chooses

You (+) Choose

Foundation Chooses

Choice #2What License SHOULD

you uSe?

Choice #3What Governance/

Development Model?

2. Business & Legal Choices | The Three Big Choices

• Same name between commercial & open source?• Separate brands between commercial & open source

○ Give brand equity to new commercial source or keep?○ Restrictions if separate names owned by separate entities

2. Business & Legal Choices | Choice #1: Who Owns Brand?

• Ownership Determined by the choice of business model○ COMPANY - “Benevolent dictator for life”: If you choose to retain

ownership of the OSS, you determine its course○ Existing OSS Foundation - you step into an existing development

and governance model○ Create a Foundation - you create or collaborate on the development

and governance model

2. Business & Legal Choices | Choice #1: Who Owns IT?

• Company Owns It:○ Advantages - Flexibility, you determine development and

governance models and licensing, fast track to commits, goodwill associated with the OSS project, Easy licensing, and easier adoption

○ Disadvantages - No existing community to tap into, distrust of single-vendor open source

2. Business & Legal Choices | Choice #1: Who Owns IP?

• Existing OSS Foundation Owns It:○ Advantages - Leverage existing big data communities, established development

and governance models, Apache 2.0 license as license of choice○ Disadvantages -ASF is about active communities, not hosting; mostly English,

projects with non-trivial infrastructure requirements, UI-centric projects not doing well, not a place for corporate collaboration, large scale platform projects not a great fit, projects with a lot of patents


• New OSS Foundation Owns It:○ Advantages - Bringing together contributors committed to the growth of a broad,

open ecosystem; more control over development, governance model; scale of project cannot not be accomplished without widespread adoption, rapid innovation

○ Disadvantages - Single vendor baggage, ceding control over your products, enabling your competition


Licenses are a strategic intellectual property weapon and shield consisting of legal tools of copyrights, patents and trademarks

2. Business & Legal Choices | Choice #2: What OSS License?

1. Is it an OSI-approved license?2. Do we want to build a community/encourage adoption?3. What community are we trying to build? 4. Do we want our code used in closed source applications by competitors?5. Do we want to discourage forking?6. What is the public perception of the license we choose?7. What license will be the most efficient/easiest to use?8. What licenses protect our intellectual property?9. How much license reciprocity is required?

10. What protections do we want in place for patent licensing & litigation?11. What legal jurisdictions are we targeting?12. Are there any Project-specific affinities we need to address?

RESTRICTIVEPERMISSIVEGNU General Public

License, v. 2

• Attribution• Copyright

license• Implied patent

license

• Attribution• Copyleft• Copyright license• Implied patent license

• Attribution• Weak copyleft• Express patent license• Copyright license• Patent retaliation

• Attribution• Strong copyleft• Broad express patent license• Copyright license• Patent retaliation

• Attribution• Express patent license• Copyright license• Patent retaliation

2. Business & Legal Choices | Choice #2: What OSS License?

• Company Owns It:○ Governance - Empowered engineering leads (gatekeepers); Leads drive

innovation with community/customer feedback + contributions○ Development - DDistributed team, agile processes, public issue

tracking, and a maniacal focus on design/quality

2. Business & Legal Choices | Choice #3: Gov/Dev Model?

• Existing OSS Foundation Owns It:○ ASF Governance - Non-profit corporation, elects a Board of Directors that sets

corporate policy, and delegates ownership of project policies and execution to various officers and PMCs

○ ASF Development -the “Apache Way” is a consensus-based, community driven model with the ethos of merit, consensus, community and charity


• New OSS Foundation Owns It:○ Governance - “Governance by Contribution,” fosters contribution from a broad

community of developers, users, customers, partners, ISVs, while advancing the development of the PaaS at extreme velocity

○ Development - CFF “Dojos” encourage agile engineering, pair programming, daily standups, and public story trackers


3. Engineering & Community Choices | Ensuring IP Cleanliness

1. Accepting Grants of Code as Benevolent Dictatora. CLA/ICLA Process - License Choicesb. Ensuring Chain of Title

2. Initial Grants of Code to an External Foundationa. ASF as example

i. Software Grant Agreementii. Company and Individual

Committers sign Commitment Agreements

a. Pivotal CF as examplei. Software Grant to

Pivotal/accepted CCLAs/ICLASii. Working with your customers

3. Ongoing IP Cleanliness a. Code Scans

1. Scanning your codea. Early prep - knock out easy problemsb. Component license compatibilityc. Security issues

2. Correcting code issuesa. Fixing must-do issues from scan results before posting codeb. Remove customer and personal information often found in commentsc. Appropriate copyright notices in code headersd. Removing features intended for commercial versions

3. Doesn’t have to be perfect, can be work in progress

4. Execution | Readying Code

License Compatibility - APACHE 2.0 EXAMPLE 4. Execution | Readying Code

Fully compatible Limited Compatibility Not Compatible

Apache V2 & V1.1BSD

MIT/X11W3C Software License

Academic Free License 3.0Microsoft Public License

Creative Commons AttributionEclipse Distribution License 1.0

Unicode License Agreement

CDDLCPLEPLIPL

MPL 1.0, 1.1, 2.0OPL

Open Software License 3.0Erlang Public License

Binary Code LicenseGNU GPL 1,2,3

GNU LPGL 2, 2.1, 3Affero GPL 3NPL 1.0, 1.1

QPLSleepycat License

Microsoft Limited Public LicenseCode Project Open License

4. Execution | Developing Your OSS Community

1. How will your engineering process work between open source & commercial versions?2. Who can commit & how are external contributions accepted?3. How are open source users supported?4. How do you maintain relations with your open source community?

5. Case Studies | Sun microsystems (1993 - 2008)

1. Solaris2. Java3. Sun Studio Compilers & Tools

5. Case Studies | Sun microsystems (1993 - 2008)

http://j.mp/sun_open_source



5. Case Studies | Sun microsystems Java AKA OpenJDK (~1998 - 2007)

● Branding: OpenJDK vs. Java● Ownership: Sun (now Oracle)● License: GPL v.2 + linking exception● Governance: single vendor open source

5. Case Studies | Sun microsystems Solaris AKA OpenSolaris AKA IlLumos (2005 - 2007 - 2010)

● Branding: Solaris vs OpenSolaris (vs. Illumos)● Ownership: Sun (now Oracle)● License: CDDL● Governance: single vendor open source (not anymore!)

5. Case Studies | Sun microsystems Fork Yeah! (by Bryan Cantrill)

http://j.mp/fork_yeah



5. Case Studies | Pivotal

● Pivotal GemFire● Pivotal HAWQ● Pivotal Greenplum Database

5. Case Studies | Pivotal Pivotal GemFire

● Branding: Apache Geode (incubating) vs. Pivotal GemFire● Ownership: Apache Software Foundation● License: Apache License v. 2.0● Governance: Apache Software Foundation

5. Case Studies | Pivotal Pivotal HAWQ

● Branding: Apache HAWQ (incubating) vs. Pivotal HDB● Ownership: Apache Software Foundation● License: Apache License v. 2.0● Governance: Apache Software Foundation

5. Case Studies | Pivotal Pivotal Greenplum Database

● Branding: Pivotal Greenplum Database● Ownership: Pivotal● License: Apache License v. 2.0● Governance: BOFL (O stands for Oligarchy)

Q&ARoman Shaposhnik | @rhatrCyrus Wadia | @cyruswadia

bringing commercial software to open source

Technology