Open Core Software Licenses

This post is an introduction to open core software licenses or open core licensing (OCL).

This is part of a series of articles whose main post is about software licenses.

Definition of Open Core

Open core software contains free and open source software (FOSS) and closed source on different parts of the source code. Technically, open core software is closed source, as any software project containing any closed source code in it must be considered as such.

An organization may release the core-only project under a FOSS license and then a different version with extended functionality under as open core software.

Though some sources describe it as dual licensing, this is not correct as they are two different products, and the open core version uses two licenses in different parts of the source code, but not simultaneously for the whole project.

Disambiguation between the Terms “Open Core” and “Dual Licensing”

Many sources (including Wikipedia in its entry “Open-core model”) confuse open core software with dual license or multi-licensing software, though they are clearly different terms.

In my opinion, the main reason behind this frequent confusion is that all of them involve different licenses (though combined in a different way), and both of them are common practices by companies to make profit from FOSS (or COSS) projects.

The main difference is that the dual license business model usually produces either FOSS or source-available software, while the open core produces what can be technically considered as closed-source software. With these radically different outcomes, it is clear that it is not the same reference.

You can read a definition of multi-licensing and dual license on this post.

Correctness of the Term “Open Core”

The term ‘open core’ was coined by Andrew Lampitt in 2008 in his four-post essay on open-core licensing, according to the book “Open Sources Strategies for the Enterprise” written by Simon Phipps in 2012.

Though the term “open core” is quite extended and used throughout this post and blog, in my opinion it is not the best choice of words.

My arguments against the term “open core” can be summarized as follows:

  • It is misguiding when using the word “open”
  • It is inaccurate, as often people confuse it with “dual licensing”

“Open core” contains, by definition, a source code set that is partially open and partially closed. In fact, the whole project should be technically considered closed source, as the most restrictive license applies to the compound work.

“Openness” is generally considered a positive term in contrast to “closeness”, not only in the software industry but in many aspects of life. The choice of using the word “open” within the term “open core” is not casual, and responds more to marketing reasons than technical.

In my opinion, calling it “open core” is telling half of the truth, and it is a biased term from those that want to show a half-full glass. Applying the same logic, it could be equally correct to call it “closed crust software”, which does not seem a very commercial name.

The misleading term “open core” may be intentionally used to make users (and potential customers) to think their product is somehow FOSS.

As a conclusion, the term “open core” is more a marketing label than a technical denomination, and an alternative term would be more precise.

Alternatives to the the term “Open Core”

The Open Source Initiative (OSI) has referred pejoratively to proprietary software whose owners try to disguise proprietary software as FOSS (e.g. SSPL-licensed software) using the term fauxpen source software, being “fauxpen” a portmanteau of “faux” (false in French) and “open”.

I propose to use a more neutral term to describe software that is FOSS in some parts and proprietary in others.

We could use a term that gives the idea related to light, where there is an lit and visible part (open source) and another one that is dark and concealed (closed source). It would focus on the visibility of its source code, and not in the existence of multiple licenses, so it may remove the ambiguity that makes people confuse the terms “dual licensing” and “open core”.

Terms like shaded source, dim source, hazy source, murky source, etc. seem to be technically correct and intuitive, but commercially it would be unsuccessful because of the second meanings of these terms.

Semi-open source, half-open source or ajar source could also be used.

Midway source and intermediate source seem too vague, as it is not clear to which aspect of source code is referring..

I refrain from bringing an actual use of any of the suggested terms within this text to avoid hindering the understanding of complex subjects by introducing a self-made unfamiliar term. In any case, I explain here the rationale of the proposal of using an alternative term to “open core” and encourage others to use it or any reasonable alternative.

Risks behind Open Core

Some authors and experts, like Simon Phipps, warns about the risks of using open core software.

Though open core may lead people to think it is closer to FOSS than to proprietary software, using open core software actually brings risks that exist in traditional closed source software but not in FOSS.

The most considerable risk of both open core and closed source software is vendor lock-in, where a customer becomes dependent on a particular vendor’s products or services to the extent that it becomes difficult or costly to switch to an alternative.

The practice of developing open core projects instead of pure FOSS may bring displeasure and mistrust within the FOSS community, and could become into reputational damage for the developing company.

Customers and software vendors should consider these risks before choosing an open core solution over an actual FOSS one.

Examples of Open Core Software

Open Core software is one of the most popular business models for Commercial Open Source Software (COSS), and it is adopted by many of the big players of the software industry.

A few examples of open core software:

Open Core ProductFOSS Product (Core)DeveloperProject Benefits
Google AndroidAndroid Open Source Project (AOSP)GoogleRevenues from selling content (Play Store)
Google ChromeChromiumGoogleRevenues from exploiting user data (AdSense)
Visual Studio Code binariesVSCodiumMicrosoftKeeping developers within the Microsoft ecosystem

You might also be interested in…

External References

Leave a Reply

Your email address will not be published. Required fields are marked *