[License-discuss] On dual-licensing

Fri Jan 3 10:59:10 UTC 2020

I'd only make one small change.

Centralizing copyright *licensing* in a single entity enables those
(and additional) business models. I haven't come across many instances
outside of the FSF where contributors are asked to assign their
copyrights to the single entity, generally they are only asked to
provide a perpetual/blah/blah license which allows for infinite
relicensing.

On Thu, Jan 2, 2020 at 6: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