Open Source in commercial projects
It is difficult to imagine the modern IT world without Open Source. Open source is basically everywhere. Last year's Synopsys study covering over 1.5 thousand source codes from 17 industries (such as fintech, IoT, telecommunications, aviation) indicated that as many as 98% of them contained Open Source elements. So it is almost certain that it is also part of your projects. And is it really legal?
What is Open Source?
Before we move on to the commercial use of open source software, let's check what it really is.
It turns out that there is no single official and globally accepted definition of Open Source. According to OpenSource.org:
Open Source does not only mean access to the source code. The rules for distributing Open Source software must comply with certain criteria.
The mentioned criteria include: freedom of redistribution, availability of source code, ability to create derivative products, integrity of author's source code, lack of discrimination against specific persons, groups of people or business areas and several others (described in more detail on OpenSource.org ).
To put it simply, Open Source is software made available under a license that guarantees access to the software's source code, modification and redistribution - both in the original and modified versions.
Case Study: available, free and illegal
In the introduction, I suggested that Open Source is certainly present in your project - even if you are not aware of it (even in an innocent form - e.g. libraries, specific programming languages, etc.).
It seems to me that in my case this awareness has always been there, at least partially. I knew, for example, that in one of the projects we implemented, we used open source frameworks as the basis for a new product. Experienced developers and consultants received the task, conducted research on available tools, selected the best ones (Open Source) and started programming.
When the work was basically finished, one of the developers accidentally came across the text of the license on the basis of which the framework was distributed. It turned out that this license did not allow its commercial use. After a deeper analysis of the topic (and the tools we use), we discovered more problems:
- inability to use a given framework for commercial purposes (and we are not implementing our project pro bono...),
- the need to make the product we have created (partly based on Open Source) available for further modification/use (Open Source virality),
- compulsion to inform product users about the use of Open Source.
Of course, given the nature of our project and the contract with the client, it was impossible to meet any of the above licensing requirements. The only way out of this stalemate situation was to appropriately modify the solution, getting rid of tools distributed based on licenses that were unfavorable to us. Generally, the situation was good for us.
Open Source licenses and commercial use
I think that the lesson from the above story should not be reluctance towards Open Source, but rather using it consciously, with knowledge of the license under which it is distributed. Getting to know them is not difficult - the vast majority of Open Source solutions are based on the three most popular types of licenses. Here they are:
Open Source License
WITH
Characteristic
The license allows its holder to freely and free of any fees use the software (including using, copying, modifying, combining, publishing, distributing, sub-licensing, selling) provided that this notice (copyright notice) is included in each copy of the software.
Software distributed in this way is not covered by any warranty on the part of the author and he is not responsible for any consequences arising from its use.
Market share in 2021: 26% (according to whitesourcesoftware.com )
Commercial use
The software can be safely used commercially. Its license is very liberal and obliges the creator only to include its content (information on the rules of using Open Source) in the final product.
Open Source License
Characteristic
As in the case of MIT, the license allows you to reproduce, create derivative works, publicly display, sublicense, distribute as a source or product - in an unlimited manner and free of charge.
The license obliges its holder to provide its content to all persons involved in the product being built (co-authors, users, etc.). It is possible to formulate your own license provisions regarding authorial modifications of the product (and distributing it under different conditions).
Market share in 2021: 28% (according to whitesourcesoftware.com )
Commercial use
The software can be safely used commercially. Its license is very liberal and obliges the creator only to include its content (information on the rules of using Open Source) in the final product.
Open Source License
Characteristic
The license allows for free and unlimited use of the software in an unchanged form.
If used to create another product, that product must be distributed under the same license as the GLP v3 software (if included in it in any way).
Market share in 2021: 10% (according to whitesourcesoftware.com )
Commercial use
The use of the software for commercial purposes is very limited. It is difficult to imagine that we would be interested in distributing a commercial product under an Open Source license.
Customer contract and Open Source
Apart from the issue of Open Source itself and its license provisions, problems with the use of open source software in commercial projects may arise from the provisions of contracts with clients. It turns out that many customers do not formally consent to the use of Open Source by software suppliers .
The following reasons may be behind this:
- the desire to have 100% proprietary code (which is basically impossible to achieve),
- safety considerations,
- restrictions imposed by an external license (they exist regardless of how liberal the license is),
- competition (including reluctance to publish information about the technologies used in the product for fear of competitors).
Before starting work, let's verify the content of the contract with the team - without taking anything for granted. Even if something makes "absolutely no sense" on a common sense basis (e.g. a ban on Open Source), the contract does not necessarily reflect this. Many contracts are based on templates that our companies (and clients) prepared centuries ago. Without regular updating, they are certainly full of such "flowers".
What about this Open Source?
Being aware of the contract on the basis of which we implement our project and familiarizing ourselves with the license terms of the Open Source software we use - these are, in my opinion, two keys to success when it comes to using open source software for commercial purposes.
As for the Open Source licenses themselves: MIT and Apache should not raise our concerns, but in the case of the others (including GPL), it is better to stop for a moment and check their records with lawyers.
