Not Quite Open Source: Why Some Businesses are Developing Source Available
Source Available: What is It?
Before we get into the “why” or “why not,” let’s first discuss “what it is.” Source available making the source code available to customers and possibly to users, even while the code falls under a non-open-source license. For example, if a company puts the code for some proprietary, paid software up on a public GitHub repository but changed nothing else about the terms and conditions of the software and granted modification or redistribution rights, this would be considered source available.
How Does That Work?
By default (at least in the United States), code written and uploaded — even without a license and even to a public place — leaves the author as the sole copyright owner and nobody is allowed to copy or redistribute code without their permission.
Most intentional, company-backed source-available software employs one or more of a number of additional, explicit conditions in the software license though. For example, a license may state that:
- The code may not be compiled/used without the author’s consent possibly unless some specific conditions are met
- The code may not be copied or redistributed without the author’s consent (which may preclude things like forks) possibly unless some specific conditions are met
- The code may not be modified without the author’s consent possibly unless some specific conditions are met
- Source code is only provided for specific purposes and use outside of that is prohibited
The meaning and point of this is two-fold. First, that (at least in theory) for authors uploading the source code to their proprietary software, they can retain most if not all of the rights that they have under a private, completely closed source endeavor. In fact, given that many pieces of proprietary software are now distributed with some element of source code (scripts, etc), it’s probably good to have a license that addresses what rights the business wants to retain on that distributed source code anyway. Second, that they can make their source code license as close to or as far away from an an OSI-approved open-source license as they choose. Making the source available is a related but largely an independent endeavor, though they’re often coupled together.
Why consider source available over completely closed?
I’ll be ignoring hosted SaaS software for this article, not because it’s not important but because the tradeoffs and challenges are different. Instead, this article is mostly around the licenses of any software distributed to customers for their own running. One thing you learn quickly when you start setting up a business of selling this type of software is that your customers — or at least their legal teams — don’t trust you. Or maybe a nicer way of phrasing that is that they want protections from various things they’ve seen other software vendors do:
- Software vendors have gone out of business, and if the customer doesn’t have access to the source code, there’s no way for them to patch bugs or get new features added at all to get prolonged value out of their purchase
- Software vendors have built software with security vulnerabilities, leaving customers (or worse, 3rd party attackers) to find security holes, often by exploiting them and thereby exploiting the customer
- Some software vendors have dodgy-to-dangerous development practices. Writing and committing code without peer review, building and sending untested patches to customers and code without any tests (or not enough tests, e.g. maybe no performance evaluation), poor code quality/practices that may make something unmaintainable,
Having source available can help with one or all of these in ways I’ll get to, but let’s first consider what a closed-source/proprietary software company may do for each of these.
A common way for completely closed-source companies deal with (1) is by paying for source code escrow services. There are a lot of companies that offer these services, and you can agree with the customer on what conditions the source code would be released. These may be required in the procurement process of software and having source available software may help to reduce the need for special contracts or financing of these services. While these aren’t incredibly expensive (they can add a few thousand dollars to the cost of the software sale), they can add up, especially for small vendors without much operating capital. Having the source code available can help alleviate the concern and sometimes eliminate this cost for customers or the software vendor.
A common way to deal with (2) is code audits. There are a variety of 3rd party companies which you can pay to find and report back security vulnerabilities in your software. Often these are time-boxed (“I’ll pay you for 100 person-hours to look through my source code and try to find security vulnerabilities”) but if you want the 3rd party company to validate that they can’t find any vulnerabilities in your software at all, there’s usually an additional time element (and fee). Many customers require some security audit to have been done recently in order to buy your software, and sometimes they’re quite choosy about which 3rd party they’ll accept. At $100-300/hr (or more), doing a 100-hour (or more) audit twice a year can add $50k to the cost of doing business as a software vendor. Interestingly, having your source code available can help reduce the time/cost of these audits or let the customer pay for/use whichever security company they care for themselves to shift the cost entirely off the vendor. Certainly, having the source code available can make some security options like hackerone both more effective in finding bugs and more cost effective than paying for a time-boxed security evaluation. Sometimes, having popular source-available code can actually go so far as to help give the customer confidence that security bugs would have come to light much earlier through other 3rd party audits.
A common way to deal with (3) is to ask the software vendor about their development practices, often as part of an RFI/RFP. Some types of compliance require these practices as well, so getting certifications of compliance can also be a way of tackling this problem. Having the software development in the open can help assure the customer that what you say is what’s actually happening, though it may not eliminate the needs for rubber-stamping some of these organizational controls.
One additional benefit of developing source-available can help with for a customer is having an issue tracker that’s tied to the source code for the customer to see, including pull requests. When this is the case, customers may have the option to directly file issues or search for issues that other customers have had that look the same as theirs. They may also actually see an issue getting worked on and how it’s being addressed, increasing the transparency for the customer and potentially even giving them an early mechanism to provide ungated feedback to the vendor’s software development team. Notably, while this is a benefit for some customers, many customers want no part in it — e.g. having any interaction with a public issue tracker may be against their company policy or otherwise undesired.
Arguments for not having source available
The most common argument for not making the source available is a fear that the proprietary licensed source code may be taken, reused, redistributed, and/or modified to not be licensed. As discussed at the top of this blog, that can be prevented at least in theory, but practice is different. A lot of netizens aren’t quite law-abiding and many of the countries they reside in have no ability/resources (or desire) to prosecute over infringement. The reality is that if you make your source code available, you will likely have more people copying the proprietary code. The mitigation here for those companies that decide to go down this route anyway is three-fold:
- Most respectable hosting platforms (GitHub, GitLab, etc) will respond to a DMCA takedown to prevent proliferation, and by virtue of you having your source code available, you have public evidence of your code being the source.
- As the copyright owner, you would likely be able to press charges against the infringer if you desired, though the efficacy of that depends largely on what country your business resides in as well as the infringer. The threat of this happening is significant enough that most legitimate businesses and their employees would not engage in this activity.
- As a business, you should be asking yourself: how many of the users that are willing to do steal/modify your proprietary code would have paid you for your software if you hadn’t made the source available? Usually, the answer is very small, though consumer-focused apps (rather than business-focused software) are likely much higher due to price sensitivity and business models that require large distribution on smaller dollar values.
Another common argument for not making source available is that you may be exposing yourself to additional business risks if your product is immature. For example, having source code available can dilute support-focused value if the code is simple enough for a customer to edit (“I could just fix it myself if I need to”) and if the code quality actually isn’t all that great (or if you’re not testing or doing code reviews properly or other process-related concerns) it’s more likely to become apparent to your customers and prospects.
There are other reasons to not have a source-available platform, including simply having a small enough userbase that it doesn’t matter to any/most of them or that either you or they have concerns by releasing your source code. This blog is intended to be an introduction to simply why some companies may choose to make parts of their code source available to get some of the benefits of open source without the rest of the elements of open source. Some companies are unable to or unfamiliar with teasing these different elements of concern apart.