The Slur “Open Core”: Toward More Diligent Analysis

Saturday 5 March 2011 by Bradley M. Kuhn

I certainly deserve some of the blame, and for that I certainly apologize: the phrase “Open Core” has apparently become a slur word, used by those who wish to discredit the position of someone else without presenting facts. I've done my best when using the term to also give facts that backed up the claim, but even so, I finally abandoned the term back in November 2010, and I hope you will too.

The story, from my point of view, began seventeen months ago, when I felt that “Open Core” was a definable term and that behavior was a dangerous practice. I gave it the clear definition that I felt reflected problematic behavior, as I wrote at the time:

Like most buzzwords, Open Core has no real agreed-upon meaning. I'm using it to describe a business model whereby some middleware-ish system is released by a single, for-profit entity copyright holder, who requires copyright-assigned changes back to the company, and that company sells proprietary add-ons and applications that use the framework.

Later — shortly after I pointed out Mark Shuttleworth's fascination with and leanings towards this practice — I realized that it was better to use the preexisting, tried-and-true term for the practice: “proprietary relicensing”. I've been pretty consistent in avoiding the term “Open Core” since then. I called on Shuttleworth to adopt the FSF's recommendations to show Canonical, Ltd. isn't seeking proprietary relicensing and left the whole thing at that. (Shuttleworth, of course, has refused to even respond, BTW.)

Sadly, it was too late: I'd help create a monster. A few weeks later, Alexandre Oliva (whose positions on the issue of proprietary software inside the kernel named Linux I definitely agree with) took it a step too far and called the kernel named Linux an “Open Core” project. Obviously, Linux developers don't and can't engage in proprietary relicensing; some just engage in a “look the other way” mentality with regard to proprietary components inside Linux. At the time, I said that the term “Open Core” was clearly just too confusing to analyze a real-world licensing situation.

So, I just stopped calling things “Open Core”. My concerns currently are regarding the practice of collecting copyright assignments to copyleft software and engaging in proprietary relicensing activity, and I've focused on advocating against that specific practice. That's what I've criticized Canonical, Ltd. for doing — both with their existing copyright assignment policies and with their effort to extend those policies community-wide with the manipulatively named “Project Harmony”.

Shuttleworth, for his part, is now making use the slur phrase I'd inadvertently help create. Specifically, a few days ago, Shuttleworth accused Fedora of being an “Open Core” product.

I've often said that Fedora is primarily a Red Hat corporate project (and it's among the reasons that I run Debian rather than Fedora). However, since “Open Core” clearly still has no agreed-upon meaning, when I read what Shuttleworth said, I considered the question of whether his claim had any merit (using the “Open Core” definition I used myself before I abandoned the term). Put simply, I asked myself the question: Does Red Hat engaged in “proprietary relicensing of copyleft software with mandatory copyright assignment or non-copyleft CLA“ with Fedora?.

Fact is, despite having serious reservations about how the RHEL business model works, I have no evidence to show that Red Hat requires copyright assignment or a mandatory non-copyleft CLA on copyleft projects on any products other than Cygwin. So, if Shuttleworth had said: Cygwin is Red Hat's Open Core product, I would still encourage him that we should all now drop the term “Open Core”, but I would also agree with him that Cygwin is a proprietary-relicensed product and that we should urge Red Hat to abandon that practice. (Update: It's also been noted by Fontana on identi.ca (although the statement was subsequently deleted by the user) that some JBoss projects require permissive CLAs but licenses back out under LGPL, so that would be another example.)

But does Fedora require contributors to assign copyright or do non-copyleft licensing? I can't find the evidence, but there are some confusing facts. Fedora has a Contributor Licensing Agreement (CLA), which, in §1(D), clearly allows contributors to chose their own license. If the contributor accepts all the defaults on the existing Fedora CLA, the contributor gives a permissive license to the contribution (even for copyleft projects). Fortunately, though, the author can easily copyleft a work under the agreement, and it is still accepted by Fedora. (Contrast this with Canonical, Ltd.'s mandatory copyright assignment form, which explicitly demands Canonical, Ltd.'s power for proprietary relicensing.)

While Fedora's current CLA does push people toward permissive licensing of copylefted works, the new draft of the Fedora CLA is much clearer on this point (in §2). In other words, the proposed replacement closes this bug. It thus seems to me Red Hat is looking to make things better, while Canonical, Ltd. hoodwinks us and is manufacturing consent in Project “Harmony” around a proprietary copyright-grab by for-profit corporations. When I line up the two trajectories, Red Hat's slowly getting better, and Canonical, Ltd. is quickly getting worse. Thus, Shuttleworth, sitting in his black pot, clearly has no right say that the slightly brown kettle sitting next to him is black, too.

It could be that Shuttleworth is actually thinking of the RHEL business model itself, which is actually quite different than proprietary relicensing. I do have strong, negative opinions about the RHEL business model; I have long called it the if you like copyleft, your money is no good here business model. It's a GPL-compliant business model merely because the GPL is silent on whether or not you must keep someone as your customer. Red Hat tells RHEL customers that if they chose to engage in their rights under GPL, then their support contract will be canceled. I've often pointed out (although this may be the first time publicly on the Internet) that Red Hat found a bright line of GPL compliance, walked right up to it, and were the first to stake out a business model right on the line. (I've been told, though, that Cygnus experimented with this business model before being acquired by Red Hat.) This practice is, frankly, barely legitimate.

Ironically, RMS and I used to say that Canonical, Ltd.'s new business model of interest — proprietary relicensing (once trailblazed by MySQL AB) — was also barely legitimate. In one literal sense, that's still true: it's legitimate in the sense that it doesn't violate GPL. In the sense of software freedom morality, I think proprietary relicensing harms the Free Software community too much, and that it was therefore a mistake to ever tolerate it.

As for RHEL's business model, I've never liked it, but I'm still unsure (even ten years later since its inception) about its software freedom morality. It doesn't seem as harmful as proprietary relicensing. In proprietary licensing, those mistreated under the model are the small business and individual developers who are pressured to give up their copyleft rights lest their patches be rejected or rewritten. The small entities are left to chose between maintaining a fork or giving over proprietary corporate control of the codebase. In RHEL's business model, by contrast, the mistreated entities are large corporations that are forced to choose between exercising their GPL rights and losing access to the expensive RHEL support. It seems to me that the RHEL model is not immoral, but I definitely find it unfriendly and inappropriate, since it says: if you exercise software freedom, you can't be our customer.

However, when we analyze these models that occupy the zone between license legitimacy and software freedom morality, I think I've learned from the mistake of using slur phrases like “Open Core”. From my point of view, most of these “edge” business models have ill effects on software freedom and community building, and we have to examine their nuances mindfully and gage carefully the level of harm caused. Sometimes, over time, that harm shows itself to be unbearable (as with proprietary relicensing). We must stand against such models and meanwhile continue to question the rest with precise analysis.

Posted on Saturday 5 March 2011 at 15:10 by Bradley M. Kuhn.

Comment on this post in this identi.ca conversation.



Creative Commons License This website and all documents on it are licensed under a Creative Commons Attribution-Share Alike 3.0 United States License .


#include <std/disclaimer.h>
use Standard::Disclaimer;
from standard import disclaimer
SELECT full_text FROM standard WHERE type = 'disclaimer';

Both previously and presently, I have been employed by and/or done work for various organizations that also have views on Free, Libre, and Open Source Software. As should be blatantly obvious, this is my website, not theirs, so please do not assume views and opinions here belong to any such organization. Since I do co-own ebb.org with my wife, it may not be so obvious that these aren't her views and opinions, either.

— bkuhn


ebb ® is a registered service mark of Bradley M. Kuhn.

Bradley M. Kuhn <bkuhn@ebb.org>