[License-discuss] On dual-licensing

[Henrik Ingo]

I wanted to make some general notes on the term and practice of
"dual-licensing". This is related to the ongoing review of the CAL license,
but this is general enough that license-discuss seemed more appropriate.

Terminology: Nowadays I often see "dual licensing" used broadly,
essentially referring to any practice that I will mention in this email. I
personally only use it in its original meaning: When the exact same
software is available under more than one license, and the recipient can
choose which one they want. Note that this could also be two open source
licenses, such as Apache 2 and GPLv2.



As a business model, the typical setup of course is that one of the
alternatives is a traditional proprietary license, available for a fee,
accounted for with a per server, per copy or per seat license. The open
source license would typically be one from the GPL family. The typical
choice by the customer is to pay for the proprietary license, to avoid
claims that they would need to open source their own source code. There are
also other reasons, such as customers who simply have a blanket policy
against GPLv3 and/or AGPLv3. (Typically because of anti-drm clause and
network copyleft, respectively.)

Companies that used this "classic" dual-licensing model include MySQL,
Sleepycat, Aladdin Ghostscript.

I personally never had any qualms selling MySQL under this licensing model.
The way I see it, if a proprietary software company doesn't want to open
source their code, the second best option is to at least make them pay for
the free software and not let them use it for... well, free. If anything,
they deserve to pay as much as possible, so that it hurts a little. (And in
the database industry that sometimes happens!) The customer could use all
of this software for free, the vendor is not withholding any part of it,
and purely by their own choice they choose not to become part of the open
source community.

Note that in cases where a company has a no-GPL or no-AGPL policy, then
dual licensing is what makes it possible for them to consume such software
at all. Without that option, they would not be able to use it. (Yes, this
is self imposed stupidity, but still reality.) This is why even the FSF has
practiced this kind of dual licensing at times.

Note that sometimes even on the customer side the people involved are eager
to spend their proprietary software company's budget on such a deal. At
least the money is then going to a good cause: more free software.


It is true that especially thanks to MySQL also this practice has a bad
reputation. I've personally heard the global evp of sales say that "if they
use MySQL for commercial use, then they need a commercial license". (Which
is false, obviously.) In the Nordic business culture lying is kinda
disapproved of, so I never personally witnessed a sales meeting where such
a claim was made, but have heard from colleagues that it certainly
happened. Many years before my time MySQL even said this on their website.
Clearly, none of this is in any way ok. I presume that the bad reputation
dual licensing has, is largely because of these historical MySQL activities.


Since about 2005 MySQL, and then many others, started a business model
where the commercially available proprietary software is a superset of the
freely available open source software. I and many others call this "open
core" and specifically I don't call this "dual licensing". In the MySQL
case this was a source of a lot of acrimony internally. Many engineers had
joined MySQL because it was an open source company, and were disappointed
to realize they were assigned to closed source projects. (Usually realizing
this only after they already started to work!) MySQL also marketed
themselves as "the leading open source database", which post-2005 was
becoming an increasingly questionable claim. (Another clearly false claim
was that "we are just like Red Hat".)

As many will remember, its CEO was a vocal advocate for this model as "the
new way to make business with open source". The OSI and wider Open Source
community rejected that claim at the time. Interestingly, the Silicon
Valley bubble seems to periodically raise new generations of entrepreneurs
and investors who "invent" this same idea over and over...

An observation about "open core" in 2020 is that while this is nowadays a
fairly common business (and licensing) model, the modern companies using
this model often don't claim to be "open source companies", let alone
leading such. They are just software companies, or cloud companies, or
whatever. Some of their source code is on Github, because everyone does
that...

I personally like to think that these are the traditional proprietary
software companies that have become more open, rather than open source
companies becoming more closed. (Clearly, in some cases open source
companies did change strategy and became closed. Interestingly in the MySQL
ecosystem there were a lot of startups who started closed source, and in
the end did a "hail mary" throw to open up. That usually didn't help
either, but some of that software did survive the bankrupty of their
creators and continues to live on today.)


Centralizing copyrights in a single entity enables both of the above
business models. It also enables changing from one to the other.

If this helped to clarify the different terminology and licensing
practices, great. Thanks for reading this far.

henrik




-- 
henrik.ingo at avoinelama.fi
+358-40-5697354        skype: henrik.ingo            irc: hingo
www.openlife.cc

My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20200103/91765369/attachment.html>