Bradley M. Kuhn

• Contact
• Blog  
• Interviews / Articles  
• Software
• Résumé

Does “Open Core” Actually Differ from Proprietary Relicensing?

Tuesday 19 October 2010 by Bradley M. Kuhn

I've been criticized — quite a bit this week, but before that too — for using the term “Open Core” as a shortcut for the phrase “proprietary relicensing⁰ that harms software freedom”. Meanwhile, Matt Aslett points to Andrew Lampitt's “Open Core” definition as canonical. I admit I wasn't aware of Lampitt's definition before, but I dutifully read it when Aslett linked to it, and I quote it here:

[Lampitt] propose[s] the following for the Open Core Licensing business model:

• core is GPL: if you embed the GPL in closed source, you pay a fee
• technical support of GPL product may be offered for a fee (up for debate as to whether it must be offered)
• annual commercial subscription includes: indemnity, technical support, and additional features and/or platform support. (Additional commercial features having viewable or closed source, becoming GPL after timebomb period are both up for debate).
• professional services and training are for a fee.

The amusing fact about this definition is that half the things on it (i.e., technical support, services/training, indemnity, tech support) can be part of any FLOSS business model and do not require the offering company to hold the exclusive right of proprietary relicensing. Meanwhile, the rest of the items on the list are definitely part of what was traditionally called the “proprietary relicensing business“ dating back to the late 1990s: namely, customers can buy their way out of GPL obligations, and a single company can exclusively offer proprietary add-ons. For example, this is precisely what Ximian did with their Microsoft Exchange Connector for Evolution, which predated the first use of the term “Open Core” by nearly a decade. Cygnus also used this model for Cygwin, which has unfortunately continued at Red Hat (although Richard Fontana of Red Hat wants to end the copyright assignment of Cygwin).

In my opinion, mass terminology confusion exists on this point simply because there is a spectrum¹ of behaviors that are all under the banner of “proprietary relicensing”. Moreover, these behaviors get progressively worse for software freedom as you continue down the spectrum. Nearly the entire spectrum consists of activities that are harmful to software freedom (to varying degrees), but the spectrum does begin with a practice that is barely legitimate.

That practice is one that RMS' himself began calling barely legitimate in the early 2000s. RMS specifically and carefully coined his own term for it: selling exceptions to the GPL. This practice is a form of proprietary relicensing that never permits the seller to create their own proprietary fork of the code and always releases all improvements done by the sole proprietary licensee itself to the general public. If this practice is barely legitimate, it stands to reason that anything that goes even just a little bit further crosses the line into illegitimacy.

From that perspective, I view this spectrum of proprietary relicensing thusly: on the narrow benign end of the spectrum we find what RMS calls “exception selling” and on the other end, we find GPL'd demoware that is merely functional enough to convince customers to call up the company to ask to buy more. Everything beyond “selling exceptions” in harmful to software freedom, getting progressively more harmful as you move further down the spectrum. Also, notwithstanding Lampitt's purportedly canonical definition, “Open Core” doesn't really have a well-defined meaning. The best we can say is that “Open Core” must be something beyond “selling exceptions” and therefore lives somewhere outside of the benign areas of “proprietary relicensing”. So, from my point of view, it's not a question of whether or not “Open Core” is a benign use of GPL: it clearly isn't. The only question to be asked is: how bad is it for software freedom, a little or a lot? Furthermore, I don't really care that much how far a company gets into “proprietary relicensing”, because I believe it's already likely to be harmful to software freedom. Thus, focusing debate only on how bad is it? seems to be missing the primary point: we should shun nearly all proprietary relicensing models entirely.

Furthermore, I believe that once a company starts down the path of this proprietary relicensing spectrum, it becomes a slippery slope. I have never seen the benign “exception selling” last for very long in practice. Perhaps a truly ethical company might stick to the principle, and would thus use an additional promise-back as RMS' suggests to prove to the community they will never veer from it. RMS' suggested texts have only been available for less than a month, so more time is needed to see if they are actually adopted. Of course, I call on any company asking for a CLA and/or CAA to adopt RMS' texts, and I will laud any company that does.

But, pragmatically, I admit I'll be (pleasantly) surprised if most CAA/CLA-requesting companies come forward to adopt RMS' suggested texts. We have a long historical list of examples of for-profit corporate CAAs and CLAs being used for more nefarious purposes than selling exceptions, even when that wasn't the original intent. For example², When MySQL AB switched to GPL, they started benignly selling exceptions, but, by the end of their reign, part of their marketing was telling potential “customers” that they'd violated the GPL even when they hadn't — merely to manipulate the customer into buying a proprietary license. Ximian initially had no plans to make proprietary add-ons to Evolution, but nevertheless made use of their copyright assignment to make the Microsoft Exchange Connector. Sourceforge, Inc. (named VA Linux at the time) even went so far as to demand copyright assignments on the Sourceforge code after the fact (writing out changes by developers who refused) so they could move to an “Open Core”-style business model. (Ultimately, Sourceforge.net became merely demoware for a proprietary product.)

In short, handing over copyright assignment to a company gives that company a lot of power, and it's naïve to believe a for-profit company won't use every ounce of that power to make a buck when it's not turning a profit otherwise. Non-profit assignors, for their part, mitigate the situation by making firm promises back regarding what will and won't be done with the code, and also (usually) have well-defined non-profit missions that prevent them from moving in troubling directions. For profit companies don't usually have either.

Without strong assurances in the agreement, like the ones RMS suggests, individual developers simply must assume the worst when assigning copyright and/or giving a broad CLA to a for-profit company. Whether we can ever determine what is or is not “Open Core”, history shows us that for-profit companies with exclusive proprietary relicensing power eventually move away from the (extremely narrow) benign end of the proprietary relicensing spectrum.

---

⁰Most pundits will prefer the term “dual licensing” for what I call “proprietary relicensing”. I urge avoidance of the term “dual licensing”. “Dual licensing” also has a completely orthogonal denotative usage: a Free Software license that has two branches, like jQuery's license of (GPLv2-or-later|MIT). That terminology usage was quite common before even the first “proprietary relicensing” business model was dreamed of, and therefore it only creates confusion to overload that term further.

¹BTW, Lampitt does deserve some credit here. His August 2008 post hints at this spectrum idea of proprietary licensing models. His post doesn't consider the software-freedom implications of the various types, but it seems to me that post was likely ahead of its time for two years ago, and I wish I'd seen it sooner.

²I give here just of a few of the many examples, which actually name names. Although he doesn't name names, Michael Meeks, in his Some Thoughts on Copyright Assignment, gives quite a good laundry list of all the software-freedom-unfriendly things that have historically happened in situations where CAA/CLAs without adequate promises back were used.

Posted on Tuesday 19 October 2010 at 14:17 by Bradley M. Kuhn.

Comment on this post in this identi.ca conversation.