What is open core licensing (and what isn’t) UPDATED

This is an updated version of a post that was originally published in July 2009. It has been updated in response to ongoing confusion about open core licensing.

There has been a significant amount of interest in the open core licensing strategy since Andrew Lampitt articulated it and its benefits for combining open source and closed source licensing.

There remains considerable confusion about exactly what the open core licensing strategy is, however, which is strange since the term arrived fully packaged with a specific definition, courtesy of Andrew. Recently I have begun to wonder whether many of the people that use the term open core regularly have even read Andrew’s post.

I feel somewhat responsible for this given that our Open Source is Not a Business Model report was partly responsible for the increased use of the term open core, and since I remembered that it was this post about commercial open source strategies that prompted Andrew to define open core in the first place.

Additionally, since business models related to open source are evolving constantly, I thought it was worth revisiting the definition of open core and putting it in some context.

What is open core?
According to Andrew’s original post it is a licensing strategy whereby a vendor combines proprietary code with open source code, where “the commercial license is a super-set of the open source product, i.e., it offers premium product features that you will not see in the GPL license”.

At first Andrew was very specific about the use of the GPL license and a development model dominated by a single vendor. However, it quickly became clear that a company like EnterpriseDB, which provides proprietary extensions on top of the community-developed, BSD-licensed PostgreSQL database, also fits the general model.

Therefore, Andrew clarified that there were Vendor Controlled (VC) and Community Controlled (CC) variants on open core.

Incidentally, Andrew did not create the open core strategy. As he himself admitted, he “invented nothing, just articulated it”. Credit goes to Barry Klawans and Paul Doscher (Jaspersoft co-founders), as Andrew noted.

In fact our research indicates that the formation of companies using the open core licensing strategy had already peaked by the time the term was coined – but more on that another day.

What isn’t open core
Sometimes it is easier to define what something is by explaining what it isn’t. Open core is a commercial open source strategy, but just as “all of Alma Cogan is dead, but only some of the class of dead people are Alma Cogan”, not all commercial open source strategies are open core (and more specifically, given recent statements, not all strategies that involve copyright agreements are open core – more on that another day as well).

So, to clear up some apparent confusion:

  • Red Hat’s strategy is not open core

Red Hat reserves support and features for paying customers, but it does not do so using closed source licensing (a prerequisite of open core). Instead Red Hat gives away the source code but withholds the compiled, binary version for paying customers.

(N.B. Beware companies claiming to be following “The Red Hat model” as they invariably aren’t – most often I find they mean that they use a subscription revenue model. Very few companies have copied Red Hat’s model for a variety of reasons – a subject I’ll leave for another post.)

  • Dual licensing is not open core

In fact, as Andrew Lampitt explained in his definition, open core is a variant of dual licensing (or proprietary relicesing, as some like to call it, or indeed “selling exceptions”). The important thing to note is that in the dual license strategy a single code base is available under an open source or closed license, while with open core the closed source licensed code is a superset of the open source code. Both result in closed source software, but only in the open core strategy is the closed source version functionally different from the open source version.

  • The MySQL strategy is not open core (yet)

One of the reasons for the confusion is that MySQL originally started out with a dual license model but changed over time to the subscription revenue model, and flirted with open core. At this point the strategy for MySQL remains dual licensing. It remains to be seen whether the MySQL Server code for Enterprise Edition 5.5 will be different from Community Edition with the inclusion of MySQL Enterprise Backup (which would make it open core) or if the new capabilities will be delivered as a subscription service.

  • Subscription strategies are not open core

Although they are a step in that direction. The subscription model provides vendors with a mechanism to distribute value-added features to paying customers. Until now the additional capabilities in MySQL Enterprise (such as Enterprise Monitor) have been delivered as a service via the MySQL Enterprise subscription. Although the code for Enterprise Monitor has not been made available, we would see this strategy as distinct from open core since open core results in a product with a different code base, where as the MySQL Server code in Enterprise and Community is the same. To differentiate from regular support subscriptions I have used the term value-added subscription to refer to this type of subscription. Other examples include Canonical’s Ubuntu Advantage and Nuxeo’s Connect. I would also put Red Hat Network and JBoss Operations Network in this category, although the source code for those value-added services was originally closed, it has now been made available as open source (as previously discussed).

  • Open foundation is not open core

Vendors such as IBM, Cisco, Oracle and SAP (in fact just about every software vendor) include open source code within larger closed source software packages and hardware products. There is a fine line between the two, but as I previously explained while open core involves offering proprietary extensions targeted at a segment of the open source project user base, open foundation involves using open source software to create entirely new products, targeted at a different user base.

  • Microsoft’s open source strategy is not open core

Microsoft is undoubtedly making use of more open source and encouraging open source development on its platforms, but its strategy is by definition not open core since it is extremely unlikely the core will ever be open source. In fact, as previously discussed, Microsoft’s strategy turns the open core strategy on its head by encouraging open source development around a commercial core, and has been described by Microsoft as open edge, and by Andrew Lampitt (more amusingly) as open crust. We have adopted the term open edge to describe this strategy and have seen it adopted by a small number of players beyond Microsoft.

Hybrid licensing strategies for open source monetization

One of the issues that has arisen from the ongoing debate about the open core licensing strategy is the continuing confusion about open core compared to the use of open source components in a larger proprietary product – such as IBM’s use of Apache within WebSphere.

To some people there is no difference between the two (since they both result in products that make use of open source but are not open source), however it is clear to me that while the end result might be the same these are very different strategies that involve different approaches to engaging with open source communities/projects.

While open core has a clear definition there is no agreed term or definition for the latter category.

Over the years we have used a variety of terms to describe it, including “open and closed”, “embedded open source”, “open inside” and “open complement”, while Jack Repenning has referred to it as “open infrastructure”.

Our next categorization of open source-related business strategies is still a work in progress but the current thinking is as follows:

  • There are a variety of complementary strategies employed by vendors to generate revenue from open source software indirectly.
  • The simplest of these is open complement which is selling other products and services that are related to but separate from, and not reliant upon, the open source project.
  • Then there is encouraging open source development on top of proprietary products to retain develop interest in that product. This is known as open edge.
  • Then there is using open source software to create a platform for the provision of SaaS or cloud or social networking services (for example), which I am referring to as open platform.
  • Then there is using open source components as building blocks for a larger proprietary software product, which I am calling an open foundation licensing strategy.

(This categorization is a work in progress, we welcome and encourage any feedback)

Open core and open foundation have different evolutionary lineages: open core is a variation on dual licensing as practiced by the likes of MySQL and Sleepycat that also borrows heavily on the value-added subscription model as practiced by Red Hat and JBoss. Meanwhile open foundation has its roots in the commercialization of BSD, which pre-dates the concepts of open source and free software, as well as Apache.

From a practical perspective, the easiest way to think of the distinction between open core and open foundation is via an example:

PostgreSQL is an independent, community-developed open source project. EnterpriseDB offers extensions to the PostgreSQL core, such as Oracle-compatibility, in the form of Postgres Plus Advanced Server.

PostgreSQL has also been used by many other vendors to create commercial products. For example Greenplum used PostgreSQL as the foundation of its Greenplum Database (for other examples see this post). This allowed the company to build on proven database technology and avoid reinventing the wheel, but it also involved the creation of an entirely new product, rather than extensions to an open source project (the company initially actually started a new project, Bizgres, and created extensions to that but Bizgres was last seen in August 2008).

So while open core involves offering proprietary extensions targeted at a segment of the open source project user base, open foundation involves using open source software to create entirely new products, targeted at a different user base.

The example used above highlights three important points to consider when comparing open core and open foundation strategies:

1/ While open core is most readily associated with vendor-controlled projects it can also be used as a strategy to monetize community-controlled projects.

2/ Open core strategies can be used in conjunction with complementary strategies. In the Greenplum example the company’s relationship with Bizgres was open core, while the relationship with PostgreSQL was open foundation. Similarly there is an open core relationship between Actuate’s BIRT products and the Eclipse BIRT project, and an open complement relationship between Actuate 10 and the Eclipse BIRT project. Meanwhile there is an open core relationship between Day Software’s CRX content repository and the Apache Jackrabbit and Sling projects, and a open foundation relationship between CQ5 and Jackrabbit, Felix and Sling – as well as the numerous other Apache projects that Day contributes to.

3/ Open core and open foundation are licensing strategies used as part of a larger business strategy for engaging with and commercializing open source software, which highlights the futility in trying to pigeon-hole companies as “open core vendors” or “open source vendors”.

Finally it is worth thinking about the different tensions that the open core and open foundation strategies create with their respective communities.

As Jorg Janke notes, “looking for an income stream as an open source vendor always results in some sort of conflict with the community. So, you have to pick the community you want to ‘offend’.”

With a vendor-controlled open core strategy the community is a user community, and as we have previously discussed the conflict is in deciding what features belong in the core and what features don’t.

With an open foundation strategy the community is the open source project developer community, and the conflict lies in deciding what features and resources to contribute to that project.

A community-controlled open core strategy arguable results in conflict with both the user and developer communities, although since the vendor does not own or control the project the relationship is much more comparable to the open foundation strategy.

We will be writing more about other strategies for generating revenue from open source software, in a follow-up to our Open Source is Not a Business Model report, which is due to be published latter this year. It will provide more context for the economic motivators and issues involved in the various models, as well as updated research on which vendors are following which strategies, and why, as well as a survey to uncover what software users make of it all. The report will be freely available to CAOS subscribers. For more details of the CAOS research practice, and to apply for trial access, click here.

Please break our open source business strategy model

UPDATE An updated version of the business strategy framework can be found here. UPDATE

Last week I presented “From support services to software services – the evolution of open source business strategies” at the OSBC event in San Francisco.

The presentation was effectively a work in progress update on our research into the various strategies employed by technology vendors to generate revenue from open source software.

It included a partial explanation of my theory that those strategies do not exist in isolation, but are steps on an evolutionary process, and also introduced our model for visualizing the core elements of an open source-related business strategy.

I provided a number of examples of how the model could be used to compare the strategies of various open source businesses. Here, for example, is the visualization of MySQL’s strategy.

I was pleased with the response to the presentation, not least the number of people who asked us to send them the slide so they could fill it in for their company and send it back to us.

This is definitely something we would like to do in the future but before we do I would like to ensure we have dealt with any problems related to the model. For now I would be more interested in hearing from companies that feel their strategy is NOT covered by the model.

As Jack Repenning has pointed out, the model does not offer the granularity to express some of the nuances of the various “open complement “ strategies where open source code is not monetized directly but via complementary products (and in my own presentation I had to go beyond the model to discuss “open inside” – building proprietary products on open foundations, and “open edge” – using open source to drive innovation on top of a closed platform).

My initial feeling is that there will always be a level of detail that cannot be expressed in a simplified model such as this, although if I can build them in I will.

The development model category also needs some tinkering, not least to cover “gated community” approaches.

Additionally, of course, the model is not great when it comes to multi-product companies (although multiple models can be used to explain a larger strategy).

So anyway, if you think your company does not fit our model, do please tell us how. To help you understand how the model works, here’s a quick user guide and glossary of terms.

Revenue triggers:
These are the things that paying customers actually pay money for (apart from advertising which is an indirect relationship). They should be pretty self-explanatory. When we refer to “support services” we mean support, training, consulting, implementation services etc. “Software services” refers to SaaS and cloud delivery. Vendors can have multiple revenue triggers for a single product.

Software license:

For the purposes of this exercise we are interested in whether the company has a preference for permissive or reciprocal licensing for the underlying open source project, or uses both.

End user licensing:
What licensing strategy is applied to the product that customers pay for (as opposed to the project that it is based on)? It could be the same open source license (single open source) or a combination of open source licenses (assembled open source). It could be that the same code is available using open source and commercial licenses (dual licensing) or that commercial extensions are available (open core). Alternatively, a vendor may not monetize the open source project itself, but offer complementary software or hardware products (open complement), or may turn the open source code into a fully proprietary product (closed). Pick one.

Development model:

This requires a two-part response. Is the open source code developed in public, in private, or a combination of the two (public/private)? Pick one.
Is the development effort dominated my employees of a vendor, or the result of true community collaboration, or an aggregate of multiple projects? Pick one.

Who owns the copyright for the open source code? Is it the vendor in question, a foundation, a distributed collection of companies/individuals, or another company (withheld)? Normally this would be a matter of picking one of the four options, although if a portion of the copyright is withheld, that could be used along with one of the other three.

Do your worst.

Microsoft contributes to Linux kernel: a CAOS Theory Q&A

Microsoft has announced that it is to contribute code to the Linux kernel development effort under the GNU General Public License (GPL) v2. What on earth does it all mean? Here’s our take on the situation. With thanks to Jay Lyman for his contribution to the following:

Flying Pig

Q. This is a joke, right?

A. Not at all, although if any announcement is better suited to the image above, we can’t think of one. Microsoft has announced that it is going to contribute code to Linux under the GPLv2.

Q. What code is Microsoft contributing?

A. Microsoft is offering 20,000 lines of its own device drivers to the Linux kernel that will enable Linux to run as a guest on its Hyper-V virtualization technology. Specifically, the contributed loadable kernel modules enable Linux to run in ‘enlightened mode’, giving it efficiencies equivalent to a Windows virtual machine running on Hyper-V.

Q. Why is Microsoft doing this?

A. Red Hat and Novell’s Linux distributions already support enlightened mode, thanks to the development work done by both in partnership with Microsoft. One benefit for Microsoft of contributing to the kernel is that it reduces duplication of effort and the cost of supporting multiple, unique implementations of Linux. Once the code has been accepted into the kernel, Microsoft will use the kernel tree code as the basis for future virtualization integration development.

It also means that community Linux distributions will be able to use the code, which opens up more opportunities for Microsoft in the hosting market, where adoption of community Linux distributions such as Ubuntu, Debian and CentOS is significant. It also therefore slightly strengthens the challenge those community operating systems can make to Red Hat and Novell, which are more direct commercial challengers to Windows.

Make no mistake about it, Microsoft’s contribution is driven by its own interests. While it must serve and respond to enterprise customers that continue to drive the use of multiple operating systems and mixed environments, Microsoft also benefits by differentiating its Hyper-V virtualization technology from virtualization leader VMware. We believe Microsoft sees an opportunity to make virtualization with Windows more Linux-friendly than VMware.

Q. What’s in it for Linux?

A. The interoperability benefits previously reserved for ‘approved’ Microsoft partners will now be available licensed under the GPLv2, and available for all Linux distributions – commercial or community – without the need for a formal partnership.

The contribution of device drivers to the Linux kernel as been a sticking point for the Linux development community in the past as developers have struggled to encourage vendors to contribute driver code to the kernel. Microsoft is therefore setting something of a precedent and could encourage other vendors that have been reticent to contribute their drivers to do so.

The seal of approval Microsoft has given to the GPLv2 is also not to be overlooked. If Microsoft can find a way to contribute to Linux projects, many other organisations may also be encouraged to do so.

Q. I guess Linux is no longer “a cancer” then?

A. Exactly. Back in 2001 Steve Ballmer told the Chicago Sun-Times* “Linux is a cancer that attaches itself in an intellectual property sense to everything it touches. That’s the way that the license works.”

Reviewing the statement in the context of today’s announcement demonstrates how much progress Microsoft has made in the intervening years to understand open source licenses. Contribution to Linux, or to any other project under the GPL, would have been unthinkable at the time, and is still barely believable today. The announcement is likely to challenge perceptions of Microsoft’s strategy when it comes to open source, Linux and the most popular open source license.

*The original article is no longer available online. Plenty of references are still available, however.

Q. What does this say about Microsoft’s overall strategy towards open source?

A. The contribution is a significant sign that Microsoft is now prepared to participate with open source projects on their own terms by using the chosen license of that project and making contributions directly to the chosen development forge of that project. Microsoft continues to use its own CodePlex project hosting site for code releases, but if an existing open source project uses SourceForge then Microsoft has acknowledged that the best way to engage with that community is on SourceForge. Don’t expect this to be the last contribution Microsoft does under the GPL.

Microsoft is now becoming more proactive in how it engages with open source under a strategy it describes as ‘Open Edge’ (which we have previously mentioned here and here. Whereas Open Core is used by commercial open source vendors to offer proprietary extensions to open source code, Open Edge is Microsoft’s strategy to encourage open source development and application deployment on top of its suite of commercial software: Windows, Office, Exchange, Sharepoint, SQL Server etc.

The Open Edge strategy is rooted in attempting to ensure Microsoft’s commercial products continue to be relevant to the ecosystem of developers and partners that the company has attracted to its software platform. It is also a continuation of the realization that if customers and developers are going to use open source software, Microsoft is more likely to retain those customers if it helps them use open source on Windows et al.

For more details on Microsoft’s strategy towards open source, its partnerships with open source vendors, and its contributions to open source projects, see The 451 Group’s formal report on the contribution to Linux (the report will shortly be available via this link ).

Q. How is the contribution to the Linux kernel being handled?

A. The contribution is being made via an alliance with the Linux Kernel Driver Project and its maintainer, Greg Kroah-Hartman, who will steward the contribution into the Linux kernel code base. (Greg has a post up about it here).

Q. What are the intellectual property issues?

A. The copyright for the code will remain with Microsoft, with the contributor credit going to its engineering lead, Hank Janssen, group program manager at Microsoft’s Open Source Technology Center.

Q. And patents?

A. If we were putting money on the most likely conspiracy theory to emerge in response to this news it would be that this is a Trojan horse and Microsoft is contributing code to Linux that it will later claim patent rights over. Whether that is even theoretically possible depends on your understanding of the GPLv2.

The GPLv2 contains an implicit patent promise that some would say makes a Trojan horse impossible. However, the FSF obviously thought it necessary to introduce a more explicit patent promise with the GPLv3 to remove any doubt.

Ultimately this is a question for a lawyer, or an eloquence of lawyers (yes it is ironic, apparently). In the meantime, it is our understanding that Microsoft’s understanding is that contributing code using the GPLv2 includes a promise not to charge a royalty for, or assert any patents covering, the code being contributed.

Q. What about Microsoft’s prior claim that Linux infringes its patents?

A. Microsoft really dropped the ball on its communication of the suggestion that free software infringes over 200 of its patents, and tensions with free and open source software advocates are likely to continue to be tested by Linux-related patent agreements, such as the one struck with Melco Holdings last week, which have driven scepticism and mistrust of Microsoft among some key open source supporters.

Absent the company giving up on software patents altogether, we believe that in order to convince those FOSS advocates that it is serious about co-existence, Microsoft needs to find a way to publicly communicate details about those 200+ patents in such a way that is not seen as a threat and would enable open source developers to license, work around, or challenge them. We also believe that the company is aware of this, although finding a solution to the problem will not be easy. But then neither was contributing code to Linux under the GPLv2.

UPDATE – It has subsequently become clear that there were two important questions that were not answered by our Q&A. Those have been covered by an addendum – UPDATE.