Never mind if you are just lazy or want to focus on creating innovations by the use of already established shortcuts, open-source libraries usually speed up and facilitate the development of software products in the day-to-day work of developers (ranging from, e.g. image processing library, data filtering library, big data analysis, full-stack frameworks to machine learning). Millions of open-source code components are downloaded every year off the Internet to help modern software development. Hence, there is no doubt that the open-source ecosystem has far removed from the group of enthusiasts who are struggling against the predatory restrictions of commercial software, and for many, it became mainstream. The best proof of this is the fact that some of today’s most used technologies are based on open-source code (IoT, Healthcare, AI, Android).
However, the fact that open-source software (hereinafter: OSS) is free does not mean that its use may not cost you a certain price. In fact, if you use an open-source library against their license, there is a chance you might eventually have to pay, as “there’s no such thing as a free lunch”.
Okay, let’s start from the beginning, so we could get to the directions that should be certainly taken into account.
The Difference Between Proprietary and OSS Licenses
The software, which represents the “author’s original creation”, is protected by copyright. The author or copyright holder decides who has the right to install and copy a computer program, has the right to use or sell it, publicly communicate, modify and improve it. Essentially, commercial software (software for commercial use such as sales) can be both proprietary software and OSS. However, the differences between them are crucial.
When it comes to the proprietary software, licenses buy certain rights, that is, licenses define exactly what the user is restricted from doing and allowed to do with the software. First of all, the license should specify the answer to which code the user has access to – whether they have access only to the object code or have access to the source code as well. The rule is that the user can always access the machine code, while the access to the source code must be specially negotiated and not characteristic for, e.g., SaaS (Software As a Service) or for programs that are widely used and can be customized by users (e.g., Microsoft Office). In addition, the license agreement defines where can the users install the software, how many times can they install it, and whether they can copy it, modify and distribute it.
In short, the commercial software license starts with restrictions and then explicitly lists exceptions of what can be done with such software.
A typical example of proprietary software is Microsoft, which involves the purchase of several additional software licenses, such as Microsoft Windows operating system, IIS web server, Microsoft SQL Server database, and ASP.NET programming language.
With open-source software, copyright is turned “upside-down”.
While licenses list what is allowed within them, the OSS licenses only list restrictions meaning that the starting point is the fact that the user has a whole range of rights, and only the conditions under which these rights can be exercised are precisely defined. The following four criteria are the basis of open source definition:
- The freedom to use the source code
- The freedom to study the source code
- The freedom to modify and improve the source code
- The freedom to distribute the source code (infers copying)
Therefore, the OSS license guarantees these freedoms without any compensation to the author–owner of the code. Also, unlike the proprietary license, the OSS license automatically implies access to the source code.
Typical examples of a combination of OSS technologies are Linux operating system, Apache Web server, MySQL database, and PHP programming language.
Nevertheless, however great the fact that such technologies can be obtained for free, there are a number of different licenses in the open-source world, and therefore a certain number of restrictions that you need to beware of. The key is to understand the differences between the licenses.
What Types of OSS Licenses Are There?
Every OSS license has certain requirements for both the use of open-source code and its modification. The “Open-Source Initiative” organization contains a list of OSS licenses, which must go through the approval process, as they must comply with all open-source definition requirements. There are over 70 OSS licenses, but the 10 most popular ones are applied in 90% of cases.
If we would simplify the explanation of the OSS licenses as much as possible, the rough division would be to:
- Restrictive or prohibitive (copyleft) licenses
- Permitting or permissive (non-copyleft) licenses
Restrictive or copyleft licenses guarantee all users the aforementioned four freedoms free of charge, provided that this open-source code or any program that is created using this open-source code guarantees the same terms to its users. In other words, if OSS is protected by a restrictive license, you cannot restrict further users from using that code or its modifications. The four freedoms are forever embedded in this open-source code.
The substance of restrictive licenses is that the source code is publicly available, so that other developers can study, modify and improve it, and that such improved software remains free and accessible to the entire world and future developers with the same goals. If there was no copyleft, or if there would be no restrictions to such software being commercialized, the derivatives of this software would become very quickly unavailable to everyone, and users of these derivatives would have no more an option to use such a code freely, to copy, distribute, modify and improve it The intention is for a restrictive license to motivate developers who are not exclusively profit-oriented, to promote various software solutions. Certain important programs (for example, the GNU C ++ compiler) were created exclusively thanks to them.
The most famous restrictive license is the GNU General Public License (GNU GPL or just GPL) compiled by Richard Stallman. For example, Linux operating systems are based on GPL licenses. Furthermore, if you were to write the code and publish it under the GNU GPL license, another developer who modifies your code and wants to distribute it would have to do it solely under the GNU GPL license. In other words, both the original and the new code must be open-source. Otherwise, another developer may violate your copyright.
On the other hand, permissive open-source licenses provide software users with the unlimited freedom to use, study, and modify software, and contain minimum redistribution requirements for this software. If OSS you use is under the permissive license, you can also use the source code as part of the closed-source software, or software protected with a proprietary software license.
One of the most popular permissive licenses are BSD, MIT, and Apache. For instance, the known software packages that use one of the MIT license versions include Expat, Ruby on Rails, Node.js, jQuery, etc.
However, bear in mind that this division is not black and white. There are also licenses that are between restrictive and permissive. For example, the GNU Lesser General Public License is in its essence restrictive (like GPL), but allows for the open-source code under this license to be related to proprietary software, which would otherwise not be allowed under the GPL license. Since LGPL is mostly used for libraries, it’s possible that your code contains open-source libraries, without it becoming open-source itself.
However, keep in mind that this does not apply to the change of the library. If its new version exists, it must be published as open-source.
However, the most important for you is to always read the license when using OSS. Additionally, regardless of whether it is a restrictive or a permissive license, both such licenses may have their requirements which you must comply with. For example, the license requires a liability limitation to be entered, or to specify the name of the author to describe changes in the code before its further distribution, and the like.
For comparison purposes, GPL, LGPL, Apache, and BSD require the introduction of liability limitation, while GPL, LGPL, and Apache require code changes to be described prior to its further distribution, which is not the case with BSD.
Which Licenses Could Cause Problems?
Essentially, it is important that each developer pays attention both when using and modifying OSS, as well as when publishing the code under the OSS license. Bearing in mind that someone can sue you only for you not complying with open-source licenses and, in this case, the court could determine that there has been a copyright infringement, each license might potentially be problematic.
However, for the purposes of this article, we will focus on a problem that may arise when combining OSS with proprietary software. Specifically, when you write your own code, if you use open-source code or open-source libraries that are protected by a restrictive license, your software may not be proprietary, but will become OSS.
In other words, OSS restrictive license can “infect” your code.
When is it considered that your code is infected with an OSS license?
To know whether your code has been infected, you have to analyze how OSS and your code are linked. In about 80% of cases, the answer will be obvious, and in 20% this issue will be more complex. Hence, this is a technical matter and it would require that your development team is working with your legal team.
Hence, after identifying parts of OSS in your software, including identifying restrictive licenses that are accordingly applied, this is the first question you should ask:
- Are the OSS sequences embedded in your code? If the answer is yes: your code has been infected with an OSS license.
If the answer is negative, you should ask yourself these follow-up questions:
- Is the link between the OSS sequences and your code’s sequences static? If the answer is yes: your code has been infected with an OSS license.
- Is the link between the OSS sequences and your code’s sequences dynamic? If yes, the final answer depends on the particular case, but the chances are that your code has not been infected.
Please note that, if the purpose of the software that you are developing is exclusively internal, you are not at risk of violating open-source licenses. You are only in danger should you wish to further distribute the software as proprietary to your customers/users, in which case, the aforementioned analysis should be crucial for you.
To-do-list for using OSS
In order to be sure that you do are not violating the OSS license, and that no one can surprise you one day with a lawsuit for copyright infringement, make sure that you can answer all of the following questions affirmatively:
- Prior to using OSS, has each developer read the license and complied with its requirements?
- Are there procedures for using OSS in the company/organization? Is there a person who is responsible for complying with these procedures? Are all levels of our organization familiar with the procedures?
- Is there a list of all the OSS and commercial libraries that are being used? How often is this list updated?
- Are open-source sequences of the code published in accordance with the OSS license requirements?
- Do we send the necessary licenses and notification files as required in the open-source libraries that we use?
In addition, there are automated solutions for identifying OSS sequences in your code, which can significantly save you time and reduce the risk while using OSS.
Although weaknesses of OSS are not the subject of this text, one should bear in mind that certain studies claim that in 2016, 58.1 million open-source components were downloaded off the Internet. Keeping in mind the circulation of these components in new code sequences, it’s not surprising that your code might have one of the identified shortcomings. Therefore, implementation of the aforementioned procedures is not only relevant from the legal aspect but from the technical aspect as well. If you properly keep track of the OSS sequences in your code, this will definitely reduce all potential risks and make you stand out in the market.
Now that you have clearer instructions, it’s up to you to decide.
