[License-discuss] On dual-licensing

Sun Jan 5 00:31:15 UTC 2020

On 02.01.20 15:30, Henrik Ingo wrote:
> 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,

Thanks for taking the plunge!

In my book, dual licensing is an IP licensing strategy and open core is an
IP
modularity strategy. I wouldn't really call them a business model, but they
are some of the strategies that one can use to create a business model.

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

I think "single entity" is the key issue, and why I call this type of
business
model the "single-vendor open source business model". The novel feature of
this model based on open source is to ensure that the company remains the
single (sole) vendor behind a product based on the open source.

I have a short talk on this available here:

https://dirkriehle.com/2019/12/17/single-vendor-open-source-firms-and-intellectual-property-strategies-video/

Enjoy! Dirk

PS: Regarding terminology, as I see people use it: Dual licensing = two
licenses, triple licensing = three licenses, two or more licenses = multi
licensing

On Thu, Jan 2, 2020 at 3:31 PM Henrik Ingo <henrik.ingo at avoinelama.fi>
wrote:

> 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
> _______________________________________________
> License-discuss mailing list
> License-discuss at lists.opensource.org
>
> http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20200104/56c66e51/attachment.html>