Regardless of whether 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 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 the modern software development. So, 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 has now become mainstream. The best proof for this is the fact that some of the today’s most popular 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 does not entail a certain price. In fact, if you use an open source library against their license, there is a chance you might 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 taken into account.

The software, which represents “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, 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 essential.

With 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 – 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 is 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 user install the software, how many times can they install it, whether they can copy it, modify and distribute.

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. In other words, 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 at the core 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 in understanding the differences between licenses.

Each OSS license has special 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.

To utterly simplify the explanation of the OSS licenses, 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 linked to this open source code.

The essence 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. If there were no copyleft, or if there would be no restrictions to such software being commercialized, the derivatives of this software would very quickly become unavailable to everyone, and users of these derivatives would have no more possibility to use such a code freely, to copy, distribute or modify 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. For example, 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 be responsible for violating 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.

The most popular permissive licenses are BSD, MIT and Apache. For example, 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 the division is not entirely black and white. There are also licenses that are between restrictive and permissive. For example, the GNU Lesser General Public License is essentially 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.

In any case, it’s really important that you always read the license when using OSS. Additionally, regardless of whether it is a restrictive or a permissive license, it is important to comply with the requirements specified in such a license. For example, the license requires a liability limitation to be entered, or to specify the name of the author or 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 for code changes to be described prior to its further distribution, which is not the case with BSD.

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.

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. Otherwise, this is a technical matter and it would imply 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 to 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 you are developing is only 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 make sure that you do are not violating the OSS license, and that no one can surprise you with a lawsuit for copyright infringement one day, make sure you 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 it 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?

Nowadays, 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 OSS weaknesses were 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.

Read more: http://zuniclaw.com/en/blog/