Does “Open Core” Actually Differ from Proprietary Relicensing?

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/10/19/proprietary-relicensing.html

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
relicensing0
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 spectrum1 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
example2, 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.


0Most
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.

1BTW, 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.

2I 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.