How to Make Money As An Open Source Software Developer
Did you know that it is possible to make money as a developer of open source software?
Many software developers are unaware that money can be made with open source licensing. The conventional wisdom is that open source licensing precludes profit making. Thankfully, it turns out this is incorrect. It is quite possible to make money from the development and release of open source software. We at Segev LLP with offices in Vancouver, BC and USA can help you.
The mistaken view regarding the commercial viability of releasing software under an open source license likely arises from a misunderstanding of the purpose of open source licensing. The purpose of open source licensing isn’t free software, but is rather software freedom. The reality is that, not only is it possible to make money by releasing software under an open source license, it can actually be a lucrative business strategy – just ask Oracle, a commercially successful technology company that is also a contributor to the open source community with its MySQL software.
The Money Making Strategies
So how is it done? There are two main strategies for deriving revenues from open source software:
- Providing Supplementary Services: The first strategy involves selling supplementary services to complement the open source software product, such as training, installation, extended documentation, warranty coverage, or customization of the software.
- Dual Licensing: The second strategy is known as “versioning”, “multi-licensing”, or “dual licensing”. For ease of reading, in this blog post I’ll refer to this approach as “dual licensing.” Dual licensing involves licensing software under both an open source license and a proprietary (i.e. commercial) license.
Although this blog post will focus on the second strategy, these two strategies are not mutually exclusive and may complement each other in many circumstances.
Dual Licensing
There is a common misconception that releasing software under an open source license is an all-in proposition. The thinking is that once you have licensed your software under an open source license, you are precluded from also licensing that same software under a proprietary license. In actuality, the owner of the copyright in a piece of software can release their software under as many licenses as they please (provided they have not entered into a software agreement to the contrary). Consequently, a software developer can obtain the best of both worlds by distributing their software under an open source license and a proprietary license – that is, by dual licensing.
Benefits of Dual Licensing
Dual licensing allows software developers to improve the quality of their software with the contributions and insights of the open source community while also deriving revenue from customers who have purchased a proprietary license for their software. (The question of how to leverage those contributions will have to wait for another blog post – stay tuned.) Sun Microsystems, the developer of MySQL, describes the advantage of dual licensing as follows: “Thanks to our commercial customers, we can afford to develop and improve the product at a fast pace… And thanks to the huge user community, MySQL undergoes rigorous battle-testing.” Dual licensing is also a potent tool in establishing a product as an industry standard and reaping the associated benefits that come with market dominance. By providing an open source licensing option, software developers can rapidly drive adoption by word-of-mouth marketing and hinder potential competitors, all while improving their software and enjoying the good PR that comes with being an open source vendor. Once the market has been penetrated, other software developers who wish to incorporate the now industry standard product into their own commercial offerings may be willing to pay a substantial license fee for that right. But dual licensing doesn’t just benefit the developer – licensees can also be beneficiaries of dual licensing. For example, often licensees find that the terms and conditions of open source licenses are too restrictive for their intended commercial uses of a software product. Dual licensing provides the licensee the opportunity to remove those restrictions by paying a fee for a proprietary license. Consider a software developer who wants to incorporate GPL licensed code into their commercial software product. For anyone familiar with the GPL, they would know that this is a problem. Although code licensed under the GPL may be incorporated into a larger program, the GPL (being a reciprocal license) requires that any further distributions of that larger program must also be distributed under the GPL license. This is why some refer to GPL code as being viral – once the GPL code has been incorporated into software, it “infects” the source code of the entire software requiring it all to be subject to the requirements of the GPL. For certain commercial software developers, GPL’s requirements are a non-starter. GPL requires, among other things, that downstream recipients of the GPL licensed software be provided the right to access and modify the source code of the software without paying a license fee. This is obviously an unattractive proposition for those software developers who want their derivative works (i.e. the larger program) to remain proprietary closed source commercial products. Dual licensing provides a solution for these developers: the software developer may pay a fee to obtain the same code under a proprietary license that allows for incorporation of the code into proprietary closed source software. With a proprietary license, the licensee may then charge a license fee to customers of their proprietary software (i.e. the derivative work), and may prohibit them from accessing or modifying the source code of that proprietary software.
Which Open Source License To Use
Typically, to achieve the desired benefits of dual licensing, software vendors release their software under a copyleft license (also known as a reciprocal or restrictive open source license), such as the GPL or AGPL. Permissive licenses, such as the BSD or MIT licenses, miss the mark because they do not require downstream recipients of the open source code who have incorporated that code into their own derivative works to license their derivative works under the same open source license. As a result, where code is licensed under a permissive license, the recipient of the code would be free to include the open source code in a proprietary closed source product, thereby eliminating the need to purchase a commercial license from the upstream software vendor. Permissive licenses like the MIT license can be contrasted with a license like the GPL which requires that larger programs which incorporate GPL code may only be distributed under the license terms of the GPL (or another compatible copyleft license). As discussed above, among other things, this means the larger program, if distributed, must be distributed with its source code freely available to be accessed and modified. Consequently, if a developer desires to include the code in a proprietary derivative work, the developer will have to purchase from the licensor of the code an appropriate proprietary license that allows for incorporation of the code in a larger commercial software application. Although the GPL is superior to permissive licenses for dual licensing, it is not perfect. The GPL has a critical shortcoming: the GPL’s obligations are triggered by distributions of the software, not by access or use of the software. If there is no further distribution of the GPL code, there is no requirement to also license the larger software application under the GPL even if the GPL code has been incorporated in the larger software application. Consequently, the vendor of the larger software application might have no reason to purchase a commercial license to the code embedded in their application if the vendor will not be distributing their application. In practice, this problem arises when GPL code is incorporated into cloud hosted software that is accessible via the internet, i.e. Software-as-as-Service (SaaS). SaaS offerings typically do not involve “distributions” of software and therefore providers of SaaS offerings that incorporate GPL code are, for the most part, not obligated to release the source code of their SaaS offering or otherwise comply with the restrictions of the GPL when granting online access to their cloud hosted software. (That said, the terms of the GPL are complex and some exceptions may apply.) The Affero GPL (AGPL) open source license attempts to remedy this loophole by extending the restrictions of the GPL to cloud hosted software. Given the popularity of SaaS, closing this loophole by licensing code under the AGPL may be wise for any developer who intends to use a dual licensing strategy.
Who Is Dual Licensing Best For?
Dual licensing is best for software developers who intend for their code to be embedded into larger software applications. Downstream recipients of code are less likely to require a commercial license that relieves them of copyleft restrictions if they will not be incorporating the code into a larger software application. That said, there may be other reasons why a customer may choose a proprietary license. An upgraded version of the software might be released only under a proprietary license or the proprietary license might provide the customer with better contractual terms, such as warranties, support, or protection from license termination. It is also preferable, although not strictly necessary, that the developer wholly owns their code. At the very least, the developer’s code cannot incorporate third party copyleft (e.g. GPL) code, since the terms of the copyleft license would prohibit distributing the developer’s code under a proprietary license. Incorporation of code licensed under a permissive license (such as the BSD or MIT license), however, is not incompatible with dual licensing.
Implementing an Open Source Strategy
Whether you decide to sell supplementary services to complement your open source software or pursue dual licensing, the implementation of your strategy will require careful contract drafting and knowledgeable legal guidance. For assistance implementing an open source strategy, feel free to contact the author of this article at [email protected] or visit our Vancouver office call 604-629-5401.
Disclaimer:
The above blog post is provided for informational purposes only and has not been tailored to your specific circumstances. This blog post does not constitute legal advice or other professional advice and may not be relied upon as such. If you require legal advice, you should contact a qualified lawyer.
