For the past three years, Pivotal has been on the front line of a colossal shift in the enterprise to open source.

Many factors played into Pivotal’s shift to open source, but the root cause is similar to that of our customers: addressing disruptive competition through digital transformation. We posited that releasing key technologies as open source projects would accelerate innovation and adoption of new technology for both ourselves and our customers. We ended up open sourcing millions of lines and 25 years of Pivotal code. We moved Cloud Foundry into the Cloud Foundry Foundation, committed the source code behind our Pivotal Big Data Suite to the Apache Software Foundation, and founded ODPi, a nonprofit committed to simplification and standardization of the Big Data ecosystem.

We went all-in on open source, and fast.

As Pivotal’s lead intellectual property attorney, I was uneasy about this transition. I had been schooled to defend medieval castles, to shore up companies with traditional IP fortifications and moats of patents, trademarks, copyrights and trade secrets. How were we supposed to protect our IP, embrace open source, and most importantly, convince the largest companies in the world that using our open source-based products was better than using equivalent closed-source software?

Looking back, the answer to our legal approach was simple. I found it in our namesake, Pivotal Labs, and the bedrock of our Agile approach.

Define, Build, and Adapt

Agile is a methodology where software development requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. Key Agile concepts include discovery and framing, early testing and delivery, continuous improvement, and adapting quickly.

Applying this method as an overlay to Pivotal’s legal strategy looked something like this:

• Define. The first step was defining our intellectual property and open source strategies. The fundamental questions were what and who were we trying to protect in the shift to open source, and to what degree.
• Build. The second step was building a framework for the consumption of open source software, and the contribution to open source projects. We needed state-of-the-art tools and processes to ensure pristine IP and high development standards.
• Adapt. The third and most important step has been to constantly test, iterate, adjust, and validate steps one and two. Failing fast and adapting became our odd legal bedfellow.

DEFINE | Settling on the Right Governance Model

A conventional IP strategy is relatively simple: determine company X’s business strategy, gather competitive IP intelligence in company X’s space. Then create an IP roadmap that informs areas for innovation and points to areas for IP protection, execute on IP roadmap, and adjust that plan on a periodic basis, as the business strategy changes.

But introduce open source and the principle of sharing source code, and most traditional IP bets are off.

The best enterprise open source strategies demand a collaboration that includes the engineering, business, legal and communities. They start with an exploration of potential open source business models — single vendor open source, services and support, multi-licensed, etc.

From there you truly stray from convention. You decide under which license to give away chunks of your IP. Open source licenses can pose a real threat to IP ownership. There is the potential “viral” impact that copyleft licenses could have on proprietary software (where code freely offered and freely taken might be used to create new, proprietary software). Waiving certain IP rights by simply contributing code to either company-based open source projects or external projects, or the contribution of trademarks to open source communities also impact your IP.

Overcoming the instinct to protect is not easy, but it is essential to do so in an open source-based enterprise. It is therefore crucial to settle on the right governance model under which these projects operate. Pivotal spent a significant amount of time determining the best governance models for our open source projects that would balance the needs of the company with that of open source communities.

Pivotal was also fortunate. From day one we were an amalgam of proprietary and open source assets. We believed deeply in large-scale open source projects like Cloud Foundry and Spring, and closed-source projects like Pivotal Cloud Foundry®, Pivotal Greenplum, and more.

The rapid adoption and use of our homegrown Cloud Foundry project by some of the biggest cloud developers and technologists was only possible through open source. Securing Cloud Foundry’s place as the “Linux of the Cloud” meant booting it up as the Cloud Foundry Foundation open source community. That bet — on the value of a community to expand both open source and commercial value — has paid off handsomely.

Our move to open the core of the Pivotal Big Data Suite was another important chapter for us in open source. Here we faced the biggest gravitational pull to protect a substantial and successful commercial big data codebase. Not only were we licensing out the IP (patents, copyrights, and trademarks) crown jewels of our data portfolio, we changed the entire way our data teams developed and licensed software.

We were able to accomplish this feat at a massive scale (Greenplum alone had some two million lines of code) through a “balanced” team of legal, business, sales, and engineering folks that made decisions and proceeded in lockstep.

Moreover, we expanded the boundaries we had for IP protections: from protecting only Pivotal to protecting us and the communities we have been part of. The idea of protection has not changed, but its scope has.

BUILD | A Lean Framework for Consumption and Contribution

Pivotal now employs committers, project leads, and contributors to a wide variety of open source projects and community initiatives. When a company’s development efforts are no longer solely proprietary, a clear process for consumption and contribution must take the place of total control over releases.

What I have come to view as table-stakes for open source compliance in the modern enterprise includes:

• Treating open source as a strategic IP asset (just like patents, trademarks, and copyrights)
• Forming a cross-functional team to lead and coordinate multiple interests, including legal, engineering, community, and marketing interests
• Creating or obtaining state-of-the-art code management and tooling
• Managing and training up on OSS incident response
• Educating all teams about the company’s open source support and guidelines

We started small. If I were a piece of code, how would I get out of Pivotal and into open source?

We mapped all possible distributions of our software — contributions to open source, contributor license agreements, and inadvertent disclosure of source code. We subsequently built our contribution policy around that from the ground up. We have a cross-functional Open Source Review Team that reviews all Pivotal contributions to open source, and we make decisions not just based on what we should open source, but on whether and why would we open source.

We learned quickly that balanced teams work: each member brings a unique viewpoint, and the best decisions are made together.

It’s not all roses either. The mechanics of publishing software—including pre-release reviews, code scans, and publishing open source licenses—has been a colossal task, for the communities and codebases to which we’re accountable.

It is also fraught with a healthy potential for human error.

At Pivotal, we benefit from one of the best agile software teams in the world — Pivotal Labs — under our own roof. When we couldn’t find the right tool, Labs built it for us. We provided pre-approved and unapproved lists of software licenses for our developers to help them make decisions on what code to pull into projects, online open source contribution forms, and a wide range of FAQs and other educational materials and training. We developed a tool to automatically scan our code and incoming contributions, and route it to a continuous integration system. With each check-in/commit of source code, code is scanned, deltas are computed on versions, license types are checked, and appropriate change records are made with parallel notifications to teams as necessary.

This automation was borne out of necessity to mirror the rapid pace at which our engineers develop software. I like to call this system “lean OSS compliance,” where we maximize automation and tooling so we can focus our legal efforts on the big picture of what we’re trying to protect. Importantly, this process allowed us to get out of the way of our engineers and their work.

ADAPT | Learn and Adjust to Change

Without fail, systems and tools that we thought were state-of-the-art a year ago would quickly become outdated. Preferred languages change, license types come and go, and personnel turns over, and what we’d previously relied upon turns into quicksand.

We are constantly learning. Responding to issues that crop up frequently can feel like whack-a-mole, but it adds to the cumulative wisdom of our cross-functional team. But seeing issues crop up over-and-over means that the biggest concerns get addressed and fixed faster over time.

The “Obvious Fix” rule was born out of such a need. Our Spring community is one of the most popular open source projects in the world; millions of downloads, millions of lines of code, and 12 years of development, stewarded by a group of dedicated engineers. They had noticed that their largely manual process for collecting contributor license agreements was outmoded.

We streamlined this contribution process by integrating Contributor License Agreements (CLAs) directly into Github’s workflow, thereby making automated checks against our CLA database prior to contribution. We also allowed developers to contribute to any Pivotal open source project, as opposed to specific ones. We further used this as an opportunity to remedy a nettlesome blocker to many simple contributions — having to sign a CLA. We established a list of minor contributions (e.g., spelling errors, grammar mistakes, typos) that could be made without requiring a CLA, because we considered them to be intellectual property that is not independently protectable. That simple change lowered the barrier for new contributors while retaining the integrity of our open source projects and communities.

The Verdict

IP protection is viewed differently by our constituents. Some believe that the idea of intellectual property ownership and control are anathema to the purpose and success of open source software, or that traditional IP protections interfere with the free flow of information and improvement that is implicit in open development.

I disagree that it’s an either/or proposition. Done strategically, conventional IP protection belongs in an open source world.

Patents, trademarks, and copyrights have their rightful place in the best open source-based companies. I’ve seen firsthand how open is a good thing, and produces overwhelmingly positive results with beneficial consequences for the company, our employees, and communities we serve.

And I still get to file for some patents.