Software Licensing: Types and Legal Aspects

For every developer or IT entrepreneur, choosing software components for their project is not only a technical but also a deeply legal decision. Every library, framework or tool you add to your code is distributed under the terms of a certain licence. Ignoring these terms is the way to serious problems: from financial claims to the requirement to open the code of your own commercial product. This article will help you understand the main types of software licences and their consequences for your business.

Section 1: What is a software licence and why is it important?

There is a common illusion in the world of software development: if the code is available for download, then it is free to use. This is one of the most dangerous mistakes that can cost a company its main asset – intellectual property. Every line of code created by someone is protected by copyright by default. And it is the licence that is the legal bridge that allows you to legally use someone else’s work.

1.1 Definition of a licence: it is not the sale of code, but the granting of permission to use it under certain conditions

To understand licensing, it is important to understand the key difference between the physical world and the digital world. When you buy a hammer, you own it, and you can do whatever you want with it. But when you “buy” a programme or download a library, you do not buy the programme code itself. It remains the property of its author. So what is a software licence? It is essentially a permission or contract that an author grants you to use their work under clearly defined terms and conditions.

A licence is a set of rules that answers the following questions:

• Can I use this code in my commercial project?
• Can I copy and distribute this programme?
• Do I have the right to modify the source code?
• If I modify the code, am I obliged to share my changes with the community?
• Do I have to mention the author’s name in my product?

Every clause in the licence agreement is legally binding. By using the software, you automatically agree to all these rules, even if you have not read them. This is why understanding the basics of licensing is a fundamental skill for any developer or IT project manager.

1.2 Two main worlds: proprietary software and open source software (Open Source)

The whole software universe can be conditionally divided into two large “galaxies”, which live by completely different philosophies and licensing rules:

1. Proprietary (proprietary) software. This is software that has a specific owner (a company or a person), and all rights to it belong exclusively to this owner. The source code of such software is usually a trade secret and is not available for viewing or modification. You, as a user, get only the right to use the compiled version of the software under very strict conditions. Classic examples: the Microsoft Windows operating system, the Adobe Photoshop graphic editor, any SaaS platform to which you subscribe. Licences for such software are as restrictive as possible.
2. Open Source Software (OSS). This is software whose source code is publicly available. Anyone can view it, study it, modify it, and distribute it. However, “open” does not mean “without rules”. On the contrary, in the Open Source world there are a huge number of different licences that regulate what exactly you can do with this code. Examples: Linux operating system, Apache web server, PostgreSQL database, React library. The Open Source philosophy is based on the ideas of co-operation, joint development and transparency.

It is important for developers to clearly distinguish between these two worlds, as the use of components from each of them carries completely different legal consequences for the final product.

1.3 Consequences of breach of licence terms: from financial claims to the requirement to open the source code of your own product

“What happens if I just ignore the licence?” – such a question may arise in the mind of a novice developer. The consequences can be catastrophic, especially for a commercial project.

• Financial claims and lawsuits. The owner of the rights to proprietary software may sue you for damages for unlicensed use. The amounts can reach hundreds of thousands of dollars.
• Requirement to open the source code. This is the worst risk when working with Open Source. If you used a component in your commercial, closed product under a “strong” copyleft licence (such as the GNU GPL), the owner of the rights to that component can force you to open the source code of your entire product under the same GPL licence through a court of law. This effectively means the death of your commercial project, as you lose your primary intellectual property.
• Reputational loss. Information that your company is in breach of licence agreements can deal a devastating blow to your reputation in the eyes of customers, partners and investors. No serious investor will invest in a project with a “dirty” intellectual property history.
• The need for urgent replacement of a component. Even if the case does not go to court, if you receive a letter of claim, you will be forced to remove the problematic component from your code and search for a replacement, which will result in significant time and money expenditures.

That’s why software licensing is not a theoretical jurisprudence but quite a practical component of risk management in any IT-business.

Section 2: Main types of software licences

The world of software licences is incredibly diverse. There are hundreds of different licences, each with its own nuances. However, they can all be grouped into a few large categories, an understanding of which will allow you to navigate 99% of the time. Let’s look at these major categories, moving from the most closed to the most open.

2.1 Proprietary (commercial) licences: typical restrictions on copying, modification and distribution

These are “closed world” licences. Their main purpose is to protect the intellectual property of the copyright holder as much as possible and to control every aspect of the use of the product. The source code is not available to you, and the rights you get are very limited.

Main features of proprietary licences:

• Prohibition on modification and decompilation: You may not modify the code of the program, or try to “disassemble” (decompile) it to understand how it works.
• Restrictions on copying and distribution: You may not legally make copies of the software and distribute them to friends or colleagues.
• Clear terms of use: The licence may limit the number of devices on which you can install the software, the number of simultaneous users, or even the type of activity (e.g. a non-commercial licence).

Examples of proprietary licences we encounter every day:

• Single User Licence (Perpetual License): You pay once for a programme (e.g. an old version of Microsoft Office) and get the right to use it indefinitely, but usually on one computer.
• Subscription/SaaS: The most popular model today. You pay monthly or annually (e.g. for Adobe Creative Cloud, Figma, Jira) and have access to the latest version of the software as long as your subscription is active.
• OEM licence: A licence that is “tied” to hardware. For example, the Windows operating system that comes with a new laptop.
• Freeware: Programs that you can use for free, but their code remains closed and you are not allowed to modify or sell them (e.g. Skype, Adobe Acrobat Reader).

2.2 Free and Open-Source Software (FOSS) Licences

FOSS (Free and Open-Source Software) is a vast universe of software based on the principles of freedom and openness. “Free” in this context does not mean ” free ” (although most such software is free), but “free” . Afree software licence gives users four fundamental freedoms:

1. Freedom to use the software for any purpose.
2. Freedom to study how the programme works and modify it to suit your needs (you need access to the source code for this).
3. Freedom to distribute copies of the software.
4. Freedom to improve the software and publish your improvements to benefit the whole community.

However, within FOSS there are two major ideological currents that determine exactly how you can exercise these freedoms. These are permissive and copyleft licences.

2.3 Permissive licences: minimal restrictions, allow use in commercial closed projects

These are the simplest and most liberal licences in the Open Source world. Their main idea is “do whatever you want with my code, just mention my name”. They impose minimal restrictions and allow you to use open source code as part of your own, including commercial and proprietary (closed) products.

The basic requirements of permissive licences usually boil down to one thing: you must include the text of the original licence and a copyright notice in your final product.

The most popular permissive licences:

• MIT Licence: The simplest and most popular. Very short and easy to understand. Used in projects like React, Angular, .NET Core.
• Apache Licence 2.0: Slightly more complex than MIT. Additionally provides users with explicit patent protection from code authors. Used in Android, Swift, Kubernetes.
• BSD Licences (2-clause, 3-clause): Similar in spirit to MIT, very liberal.

Permissive licences are favourites of large corporations because they allow them to take the best of the Open Source world without revealing their own commercial developments.

2.4 Copyleft licences: require that derivative products be distributed under the same terms and conditions

Copyleft is an ingenious legal idea that can be described as a “mirror image” of copyright. If copyright says “all rights reserved”, copyleft says “all rights transferred, but on my terms”. The main idea of copyleft is to guarantee that software code that once became free will remain free forever.

The main requirement of copyleft licences: if you create a derivative product based on code under a copyleft licence (i.e. modify it or use it as a significant part of your project), you must distribute your final product under the same copyleft licence. This means that you must also provide access to the source code of your product. This mechanism is sometimes called “viral” because it “infects” with its terms the entire project to which it is added.

2.5 Distinctions between copyleft licences: “strong” (GNU GPL), which covers the whole project, and “weak” (GNU LGPL), which allows linking to commercial code

Copyleft licences come in different “strengths”. Understanding this difference is critical for developers. Here are the main types of software licences in this category:

• “Strong Copyleft” – GNU General Public Licence (GPL). This is the best-known and strictest copyleft licence. Any program that uses GPL-licensed code (even if it is just one library) must be released under the GPL in its entirety. This makes it virtually incompatible with commercial proprietary software development. Examples of GPL-covered software: Linux kernel, WordPress, Git.
• “Weak Copyleft – GNU Lesser General Public Licence (LGPL). This licence was created as a compromise. It allows you to use an LGPL-covered library in your commercial, closed project, but on one condition: you must allow users to replace that LGPL library with another, newer or modified version. This is usually implemented through dynamic linking. In simple words, you can use an LGPL component without exposing your own code, but the LGPL component itself must remain “free” and replaceable.

The choice between a permissive licence and a copyleft licence is not just a technical, but a deeply philosophical and business decision for any developer.

Section 3: Practical tips for developers and businesses

Licensing theory is important, but it is even more important to be able to apply this knowledge in practice in your daily work. Inattention to licence terms at the initial stages of a project can turn into a huge legal and financial problem on the eve of release or when attracting investment. Here are some practical tips to help you avoid the most common mistakes.

3.1 How to check the licence of a library or dependency before using it?

The golden rule of a developer: never add a dependency to a project whose licence you don’t know. This should become your professional reflex. Before you write npm install, pip install or composer require, take a few minutes to check. Where do I look for licence information?

• On the repository page (GitHub, GitLab): Most conscientious developers put the licence information right on the main repository page. Look for the “License” section or a file called LICENSE, LICENSE.md or COPYING. This file contains the full text of the licence agreement.
• In package manager files: Sites such as npmjs.com (for JavaScript), pypi.org (for Python) or packagist.org (for PHP) usually have a separate “License” field that specifies the type of licence (e.g. MIT, GPL-3.0).
• In the source code: Sometimes licence information is contained directly in the headers (headers) of source code files.
• Specialised tools: There are automated tools and services (e.g., Snyk, FOSSA, WhiteSource) that can scan your project, identify all dependencies and their licences, and warn about possible conflicts. For large projects, using such tools is a must.

If you cannot find any information about the licence, this is the worst option. By default, such code is proprietary and you have no rights to use it. You should avoid using such “nameless” components.

3.2 The licence compatibility issue: why you can’t mix components with incompatible licences

This is one of the most difficult topics in licensing. You can carefully check the licence of each individual component, but a “licence conflict” can arise when they are combined. Not all licences are compatible with each other.

A classic example of incompatibility: you cannot use code under the Apache 2.0licence in a project that you want to release under the GPL version 2 (GPL-2.0) licence . Although both are Open Source licences, their terms are incompatible. However, code under Apache 2.0 is compatible with GPL version 3 (GPL-3.0).

Another example: you create a commercial product and use two libraries. One is under the MIT permissive licence, and the other is under the “strong” copyleft licence, the GPL. Because of the GPL component, you will be forced to open source your entire product, even though the MIT licence does not require it. A stronger licence dictates its own terms for the whole project.

There are special licence compatibility tables and charts to help developers navigate these complex relationships. Before starting a project, it is important to determine under which final licence you plan to release it, and to select only those components whose licences are compatible with your ultimate goal.

3.3 The importance of keeping records of all used third-party components and their licences in the project

In a small project you can keep 5-10 dependencies in your head. But in a modern Enterprise application, the number of direct and transitive (dependencies of your dependencies) components can reach hundreds and even thousands. It is impossible to track them all manually. Therefore, keeping systematic records is a critical part of development.

What such an accounting (often called Software Bill of Materials, SBOM)should include :

• The name of each third-party component.
• Its version.
• A link to the repository or source.
• Type of licence (e.g. MIT, GPL, Apache 2.0).
• A copy of the text of the licence itself.

Why do I need it?

• For Due Diligence: When you raise investment or sell a company, the buyer’s lawyers will definitely ask you for this list to verify the legal integrity of your product.
• For Condition Compliance: By having such a list, you can easily ensure that you have met all requirements (e.g., adding all required copyright notices to the “About” section of your app).
• For vulnerability management: In addition to licences, SBOM helps you track component versions and react quickly if a critical security vulnerability is found in one of them.

Maintaining such a registry is a sign of a professional and mature approach to development, which protects your business from unexpected legal “surprises” in the future. This is just as important as complying with general IT product requirements such as GDPR, which we discussed earlier.

Conclusions 

Understanding software licences is no longer a highly specialised legal topic, but a fundamental skill for any modern IT specialist, from developer to product manager. The right choice and strict compliance with licence terms protects your project from serious legal risks, ensures its investment attractiveness and is the basis for creating a reliable and legal product.

Always check the licence before adding a new component to your code. Remember that software licensing is only one part of legal hygiene in IT. Equally important is software code copyright, which protects your own code. For more information on how to protect your own code, see our next article “Copyright for software code and online content: protection for developers”.