Some companies offer open source code with a proprietary relicensing scheme,[144] in which an open source version of the software is available under the usual open source terms, while a proprietary version is available for a fee.
Why would anyone want a proprietary version, when an open source version is already out there? There are two separate answers, reflecting the two different kinds of proprietary relicensing.
The first kind is about selling exceptions to copyleft requirements, and is typically used with code libraries rather than with standalone applications. The way it works is that the library's owner (i.e., copyright holder), seeing that some of the library's users want to incorporate it into their own proprietary applications, sells them a promise to not enforce the redistribution requirements of the open source version's license. This only works when the open source code is under a copyleft-style license, of course — in practice it is usually the GPL or AGPL.
With this promise in hand, the downstream users can use the library in their proprietary product without worry that they might be forced to share the source code to their full product under the copyleft license. One well-known example of "selling exceptions" is the MySQL database engine, which is distributed under the GPL version 2, but with a proprietary license offering available for many years, first from the Swedish company MySQL AB, and later from Oracle, Inc, which purchased MySQL AB in 2008.
The second kind of proprietary relicensing, sometimes called the freemium or open core model, uses an open source version to drive sales of a presumably fancier proprietary version (see the section called “"Commercial" vs "Proprietary"” for a discussion of some marketing pitfalls to avoid in this situation). Usually the company offering the proprietary version is also the primary maintainer of the open source version, in the sense of supplying most of the developer attention (this is usually inevitable, for reasons we'll get to in a moment). Furthermore, although in theory the company could offer paid support for both the open source and proprietary versions,[145] in practice they almost always offer it only for the proprietary version, because then they can charge two fees: a subscription fee for the software itself and a fee for the support services, with only the latter having any marginal cost to the supplier.
You might be wondering: how can the copyright holder offer the software under a proprietary license if the terms of the GNU GPL stipulate that the code must be available under less restrictive terms? The answer is that the GPL's terms are something the copyright holder imposes on everyone else; the owner is therefore free to decide not to apply those terms to itself. In other words, one always has the right to not sue one's self for copyright infringement. This right is not tied to the GPL or any other open source license; it is simply in the nature of copyright law.
Proprietary relicensing, of both varieties, tends to suffer from several problems.
First, it discourages the normal dynamics of open source projects, because any code contributors from outside the company are now effectively contributing to two distinct entities: the free version of the code and the proprietary version. While the contributor will be comfortable helping the free version, since that's the norm in open source projects, she may feel less enthusiastic about her contributions being useable in a monopolized proprietary product. That is, unlike a straight non-copyleft license by which anyone has the right to use the code as part of a proprietary work, here only one party has that right, and other participants in the project are thus being asked to contribute to an asymmetric result.
This awkwardness is reflected and in some ways amplified by the fact that in a proprietary relicensing scheme, the copyright owner must collect some kind of formal agreement from each contributor (see the section called “Contributor Agreements” earlier in this chapter), in order to have the right to redistribute that contributor's code under a proprietary license. Because such an agreement needs to give the collecting entity special, one-sided rights that a typical open source contributor agreement doesn't include, the process of collecting agreements starkly confronts contributors with the imbalance of the situation, and some of them may decline to sign. (Remember, they don't need to sign a contribution agreement in order to distribute their own changes along with the original code; rather, the company needs the agreement in order to redistribute the contributor's changes under a proprietary license. Asymmetry cuts both ways.)
Historically, many companies that have started out offering a seemingly clear proprietary relicensing option — use our product under open source terms, or buy a proprietary license so you can use it under proprietary terms — have eventually graduated to something closer to a "shakedown" model instead, in which anyone who makes commercially significant use of the code ends up being pressured to purchase a proprietary license as a way of protecting their commercial revenue stream from harassment. The precise legal bases on which this pressure rests differ from case to case, but the overall pattern of behavior has been remarkably consistent.
Naturally, neither the companies initiating these shakedowns nor the parties who are its targets (most of whom eventually capitulate) have anything to gain from going on the record about it, so I can only tell you that I have heard of it informally and off-the-record from multiple sources, at different projects and different companies. One reason I generally advise companies who are serious about open source development to stay away from proprietary relicensing is that, if history is a reliable guide, the temptation to undermine the open source license will be overwhelming to the point of being impossible to resist.
Finally, there is a deep motivational problem for open source projects that operate in the shadow of a proprietarily relicensed version: the sense that most of the salaried development attention is going to the proprietary version anyway, and that therefore spending time contributing to the open source version is a fool's game — that one is just helping a commercial entity free up its own developers to work on features that the open source community will never see. This fear is reasonable on its face, but it also becomes a self-fulfilling prophecy: as more outside developers stay away, the company sees less reason to invest in the open source codebase, because they're not getting a community multiplier effect anyway. Their disengagement in turn discourages outside developers, and so on.
What seems to happen in practice is that companies that offer proprietarily relicensed software do not get truly active development communities with external participants. They get occasional small-scale bug fixes and cleanup patches from the outside, but end up doing most of the hard work themselves. Since this book is about running free software projects, I will just say that in my experience, proprietary relicensing schemes inevitably have a negative effect on the level of community engagement and the level of technical quality on the open source side. If you conclude that for business reasons you want to try it anyway, then I hope this section will at least help you mitigate some of those effects.[146]
[144] This is sometimes also called dual licensing, but that term is ambiguous, as it has historically also referred to releasing open source software under two or more open source licenses simultaneously. I am grateful to Bradley Kuhn for pointing out this ambiguity and suggesting the more accurate term.
[145] In both cases usually hosted as Software-as-a-Service (SaaS), just to be clear.
[146] Sometimes the terms-of-service agreements for online software distribution services — the Apple App Store, for example — effectively force you to use proprietary relicensing if you want to distribute copylefted software. I won't go into detail here, but if you're distributing GPL-licensed or other copylefted code from a place that restricts users from redistributing what they download, you may be in this situation. For more information, see Steven J. Vaughan-Nichols' article No GPL Apps for Apple's App Store (https://www.zdnet.com/article/no-gpl-apps-for-apples-app-store/), Richard Gaywood's followup article The GPL, the App Store, and you (https://www.engadget.com/2011/01/09/the-gpl-the-app-store-and-you/), and Pieter Colpaert's explanation of how the iRail and BeTrains projects used pro forma dual-licensing to get around the problem, About Apple store, GPL’s, VLC and BeTrains (https://bonsansnom.wordpress.com/2011/01/08/about-apple-store-gpls-vlc-and-betrains/). Thanks to reader Nathan Toone for pointing out this problem.