After analyzing the numerous benefits offered by open source technology in our previous article, we will now focus our attention on the potential drawbacks that you should be aware of when OSS is used in a business setting. Being fully cognizant of those is crucial when you have to provide legal advice to key stakeholders. In fact, knowing how to navigate through some of the complexities that we will outline below could save your client or your employer significant amounts of money and prevent loss of valuable assets.
In our previous article we clarified that access to the source code together with the 4 fundamental freedoms is the essence that provides the unique benefits of the OSS licensing model and makes it a viable alternative to the traditional proprietary licensing model. However, when applying the open source principles directly a risk exists that the 4 freedoms and the access to source code might be lost when a downstream distribution occurs. As we already know, a recipient of the code has the freedom to modify an OSS product and then further distribute that modified version. In such a scenario, it is not difficult to imagine that this recipient may decide to license the modified version as a proprietary product and thus strip it of the 4 freedoms and make it closed source software for all potential downstream users. Obviously, this would contradict some of the core ideas behind free and open source software.
In order to avoid such a scenario, the copyleft mechanism was developed. Copyleft is a licensing mechanism which guarantees that the software will remain free and open source when a downstream distribution occurs. It ensures that anyone who redistributes OSS, irrespective of the fact if this is done with or without modification, has to further pass along the 4 freedoms and the access to the source code to any subsequent users. Thus, it would be impossible for a middleman in the distribution chain to strip the copylefted software of the 4 fundamental freedoms or make it closed source.
In practical terms, the main condition that the copyleft mechanism imposes on a potential distributor is that when a copylefted OSS product is further distributed, the license to be employed should be the same or compatible (i.e. equally protective) with the initial copyleft license. It is important to note here that the copyleft mechanism and ensuing obligations only apply when software is conveyed externally, i.e. outside of an organization.
There are two types of copyleft licenses – strong copyleft and weak copyleft. The effect of strong copyleft is that when an OSS component is included in a composed work with other software components, these other components will also have to be distributed under the same or compatible strong copyleft license with full access to their source code. This impact has caused some to label the phenomenon as the “viral effect” of strong copyleft. This is a crucial point for any commercial software development project in view of the strategies that should be considered and employed. The practical advice is that there should be clarity at the outset which exact OSS components will be used in the project, under what licenses they come and how this would impact the distribution of the developed product as well as the status of any pre-existing IP rights. It could very well be the case that the use of a single strong copylefted OSS component might prevent the distribution of the whole product under a proprietary license. Furthermore, it could result in having to provide full access to the source code so that even the source code of all proprietary components within the composed work will have to be revealed. Typical examples of strong copyleft licenses are GNU GPL in its three versions, Affero GPL and the European Union Public license.
Unlike strong copyleft, the “viral effect” under weak copyleft is limited only to the open source component and does not spread beyond. This makes it possible that other components are added or linked to the weak copylefted OSS component without them being affected. Therefore, these other components could still be redistributed under a different OSS license or even under a proprietary license as closed source software. Typical examples of weak copyleft licenses are the Lesser General Public License (LGPL), the Mozilla Public License and Eclipse Public License.
Depending on the point of view, copyleft can be seen as a drawback or as an advantage. However, from the perspective of a commercial enterprise that is developing proprietary software and still wants to reap the benefits of certain OSS solutions, copyleft can certainly introduce some dangerous side effects. Therefore, when proprietary software is developed as part of a commercial for-profit project, heightened attention should be given to the potential inclusion of any copylefted OSS components. The viral effect of those could effectively turn the whole commercial product into open source software. The easiest solution which altogether removes that risk would be to not consider any copylefted code at all and to look for alternative solutions with equivalent functionalities that are licensed under a permissive OSS license. If the development team still insists on the use of the copylefted code then certain technical solutions will have to be put in place in order to mitigate the risk of the viral effect. The most prudent way for the proprietary elements to not be affected by the strong copyleft of the OSS components would be to have strong separation between the two modules so that they are deemed to be two separate works. For this to take place, it will have to be ensured on a technical level that the OSS components and the proprietary components communicate at arm’s length and that they are not combined in a way that would effectively turn them into a single program.
Some practical guidance to have in mind is that if the modules are included in the same executable file, they would be treated as a combined work. Additionally, if the modules are designed to run linked together in a shared address space, then this would also lead to a conclusion that they form a combined work. By contrast, when communication mechanisms, such as pipes, sockets and command-line arguments are used between the modules, they normally would be deemed to be separate programs.
Another significant drawback that you should be aware of is that OSS licenses usually include a waiver of warranties and liabilities as the open source software is provided on an “as-is” basis. Some of those disclaimers are very broad – they exclude any liability of the copyright holders or software contributors for direct, indirect, incidental, special or consequential damages under any theory of liability. Such an approach is not unexpected since the end users receive the software without having to pay any license fees. Still, there is a way to mitigate this drawback and navigate through the restrictions. It is not uncommon that some commercial open source vendors could undertake additional obligations for certain types of warranty, indemnity or limited liability and respectively charge a fee based on some of these additional obligations. This would be fitting in the case of enterprise open source software that is used by large companies and where certain enterprise features are added on top of the open source core. On the other hand, community open source software that is used by home users or small businesses will lack such additional coverage.
The lack of fast and steady technical support is another challenge when it comes to OSS products. You will not have the comfort of 24×7 ongoing support services that can usually be provided by commercial vendors for proprietary software. In an open source scenario you will rely on the voluntary support from the members of the open source community that are driving the respective project and not on a dedicated support team that abides strictly to a service level agreement. Therefore, open source software may not be a good fit for a business critical system where an enterprise needs very high levels of availability and optimal response and resolution times in case of any potential incidents or errors. This drawback can be somehow mitigated by the efforts of commercial open source vendors, some of who provide professional support services for a fee but this will apply for a limited number of OSS solutions.
An additional detriment you should be aware of is the fact that by picking an open source product you become dependent on the development and progress (or lack of such) of the underlying OSS project. And it is not uncommon that some of those projects fall apart or the developers simply abandon the project. In such a situation you could be left with a piece of software that will have no updates or upgrades. Such an outcome may force you to invest in an in-house team of programmers who will then have to study the specific source code and eventually try to maintain it. The best mitigation strategy against such risks is to make a detailed prior assessment of the viability of the open source project before deciding to embrace the software it develops.
Furthermore, some OSS solutions can be less user friendly as compared to proprietary software. This is often caused by the level of intuitiveness of the graphical user interfaces that are being employed as the focus there is more on functionality and less on ease of use.
Finally, despite the fact that there are generally no licensing fees for OSS, there can be many other potential hidden costs down the road. Such additional costs will be generated as a result of the need for provision of support and maintenance services by third parties as explained above. Additional costs can be generated for the installation and configuration of the OSS solution, for training of the personnel that will have to work with it and also for any necessary integration with existing software systems or for required modifications and customizations. In order to prevent such unpleasant surprises, you should focus at the outset on the TCO (total cost of ownership) of the OSS product. This approach, together with the assessment of the viability of the underlying project, will guide you in deciding which OSS solution to pick or alternatively, whether a proprietary product may turn out to be cheaper and safer for you in the long run.
You must be logged in to post a comment.