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.i...@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.i...@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@lists.opensource.org > http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org _______________________________________________ License-discuss mailing list License-discuss@lists.opensource.org http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
