The nature of a start-up company often dictates that they are devoid of time, money and personnel to develop the necessary software. Using open source / free software (FOSS) can be of great assistance to a start-up, but its use requires that you have the right base of legal knowledge.
Firstly, it must be reminded that FOSS, with all its benefits, can be a pitfall for start-ups or software developers who remain ignorant to the conditions under which FOSS may be deployed. Open source software is still copyrighted and belongs to its author.
You may only use open source software under the license terms as determined by the author of the source code. For example, if you include FOSS in your software which is licensed under GPL (GNU General Public License), then you must bear in mind that section 2 of the GPL v2.0 and section 5 of GPL v3 oblige you to share your software also under the GPL terms.
Thus, if you want to distribute your software which partly uses GPL licensed FOSS, you are obliged to make the source code of your software freely available to all.
The terms of the foregoing and other licenses should not be ignored. As with most open-source licenses, if you do not comply with the license terms your right to use the open-source software becomes void, i.e. you lose the right to use the open-source code. In such case, continuing to use FOSS is effectively infringing the copyrights of its author.
On one hand it gives the copyright owner the right to claim damages against you (which in Estonian case may also include the revenue gained from selling the infringing software) or restrict your right to distribute your software.
On the other hand this is something that always interests potential investors in the course of assessing your company. It is not hard to guess that using open source code, which obliges your own software to be open source or not knowing which code and to what extent open source code has been used in your software, may significantly damage your position in the investment negotiations.
The other side of the coin prescribes that due to the maze of licenses and terms accompanying FOSS, software developers are often scared they might not comply with its licensing terms. Likewise, software developers might be reluctant to use open-source software as they consider open source software incompatible for use in proprietary software, which they want to distribute or sell later on. This is not necessarily true.
Thus I would like to share a couple of points from legal perspective, which you might want to consider when using open-source software:
• Firstly, it is very important to distinguish between “copyleft” licenses (such as GPL as indicated above) and permissive licenses. If you use open source software licensed under permissive licenses, such as Apache, BSD and MIT license, you are not obliged to share the source code of your software upon its distribution.
If you want to know what one or other open source license is all about, we suggest tldrlegal.com, which gives you an overview of different licenses in plain English.
• Bear in mind though that even with permissive licenses certain obligations remain.
For example if you use software distributed under Apache License 2.0 you must enable the recipient of your software access to: (1) a copy of the Apache 2.0 license text; (2) readme or other text file, if the software distributed under Apache license contained such a file; (3) your statement that you have made changes to the original software; (4) notices regarding who owns copyrights, trademarks or patents to the software, if such notice has been included in the original software.
For MIT license you must include points 1 and 4 of the above-indicated elements.
• If you modify the open source software, and do that even to a great extent, it does not relieve you of your obligations arising from the license!
• When we are talking about “copyleft” licenses such as GPL, people often do not differentiate between using the software in-house (i.e. for internal purposes of the start-up) and distributing (selling, licensing etc) of the software.
In fact, GPL or any similar license only requires you to make the source code of your software available if you include it into your own software and distribute such software to customers or third parties. If you are merely using or developing the open-source software for in-house use, then there is absolutely no obligation to release the software.
• Another very important element to consider is – how far can the use of GPL licensed software extend the obligation of relicensing your own software under the same GPL license?
For example, if software licensed under GPL and your own proprietary software are working together in a larger package, could one conclude that these are actually different pieces of software and thus your proprietary software does not have to be licensed under GPL?
The answer is actually very vague and various opinions exist. The creators of the GPL, the Free Software Foundation, are on the opinion that if the larger software package consists partly of your code and partly of software licensed under GPL 2.0 and there is strong communication between the two pieces of software, the whole software must be distributed under GPL license.
Yet, it is actually strongly debatable. One could argue that if the part of the software created by you is not derived from the GPL licensed software but is merely accompanying it as a separate module of code you are not obliged to distribute the whole of your software under the GPL, because in such instance your own code is actually a separate piece software rather than extension of the GPL licensed software.
A case for such notion is presented for example here and here, which can both be adopted in most European intellectual property regimes, including Estonian. The same conclusion can be reached regarding GPL 3.0 license, which text clearly indicates that if there is a compilation consisting of your proprietary software and software licensed under GPL 3.0, then both pieces of software may be used and distributed together, without the need to license your own software under GPL license, if:
(1) your proprietary software is not an extension of the GPL licensed software (your code is a separate module and is not derived from the GPL licensed software),
(2) the software compilation does not restrict to access GPL licensed software under the terms of the GPL license.
There is little to no case law to elaborate further on this topic and the opinions on the matter are theoretical. But the important element to consider is that combining GPL licensed software with your own proprietary software must not necessarily be excluded but it does require you to carry out a previous assessment to minimize potential risks for you and for the investors.
We will soon upload a technical due diligence checklist, which among else helps you ask the important questions in regard of the FOSS used in your software. We strongly suggest you to use it or at least get a grip of the open source software you are using.
If, in a later phase, you attract interest of investor but have not developed any policy regarding your use of open source software nor have any real overview of its use, it constitutes a risk for all parties involved. On the other hand, using FOSS as part of your platform or proprietary software, including not only software shared under permissive license but in certain cases also under GPL, should not be necessarily ruled out at any cost.
As a final note, we at Hedman Lift would like to start further developing this articles section – if you have any legal topics, which you think might be useful for you and other start-ups and which you would like us to write about, please feel free to let us know at firstname.lastname@example.org.
 In addition to the previously provided links, if you are more interested you may check out the following articles:
– Bruce Perens “Combining GPL and Proprietary Software”, accessible at
-Lawrence Rosen „Comments on GPLv3“, accessible at
Hedman Partners« Back to articles