Software Licenses: Overview and Recommendations for Developers

Software licensing is quite a tangled tale for startupers, digital product owners, and (shhh!) sometimes to developers and project managers too. Let’s wade through license types, terms and permissions explained in normal-people speak. This article would also give you a few practical tips for dealing with licenses. They should be helpful to everyone involved in software development process.

Disclaimer: as a software R&D shop, Logicify transfers intellectual property, including the code of custom software developed as a part of a project, to the client as a work made for hire. All ideas and know-how belong to the client - per Master Service Agreement signed before the project kicks off. Logicify also contributes to open source by small projects, mostly released under MIT license.

Intellectual property (IP) rights refer to a range of intangible jus of ownership for various creations of human mind: inventions, literary and artistic works. These rights safeguard the creators by giving them certain time-limited control over their goods and services use and distribution. According to the international consensus and World Intellectual Property Organization (WIPO), software is also considered an IP and is thus eligible to copyright protection and licensing.

Copyright LogoCopyright protects creators of software (including documentation for it) from unauthorized copying, modifying, or distributing. In other words, these activities could not take place without the author's permission. A valid copyright license for a software must contain at least one restriction - on copying, producing a derivative work, displaying or distributing it.

Copyleft LogoCopyleft, on the contrary, is a method for making a software free, requiring both the original source and all its modifications (derivatives) to be distributed for free. This helps community of programmers to contribute improvements to free software. The GNU General Public License (GPL), written by Richard Stallman, was the first software copyleft license, which became viral world-wide. A non-profit U.S. organization, Creative Commons, has a similar license called ShareAlike.

Types of Software Licenses

Software could be distributed under various copyright and copyleft licenses. Some of these are just a few lines, some are doctoral thesis long, so it is usually complicated to figure out all innated legal aspects. Let’s group and briefly describe the most popular licenses.

Here is a great web portal that explains the most common software licenses in plain English:

According to copyright law and type of licenses, all software applications are grouped into:

  • proprietary software (with closed source code), which is generally non-free. Its creator or publisher retains the intellectual property rights for it. Such software is, as a rule, distributed with a contract between the owner and user, the so-called end-user license agreement (EULA). It defines the non-negotiable terms under which the software is distributed. Without accepting these terms, end user can not use the software. One of the most widely known proprietary software pieces are Microsoft Windows, macOS, iTunes.
  • free & open source software (FOSS) (with open source code). According to, a software could be called open source in case its source code is publicly available and distributed for free for any field of endeavor. All derived works and modifications of such software should be distributed under the same terms as the original license’s ones.

Sometimes, a piece of software is released under a so-called dual license: proprietary license for commercial use and OSS licence for not-for-profit use. It allows licensor to leverage between contribution to open source community and gaining financial reward.

Somewhat outside of the scope of copyright protection lie unlicensed software (not distributed, non-licensed, used only as an internal business trade secret) and software placed in the public domain (PD). Software in PD is free from any restrictions as all rights for it under copyright were granted to the public at large. As some legal jurisdictions in specific countries do not allow creators to voluntarily place their work in the public domain, there are a few popular alternative PD-equivalent licenses:

  • Creative Commons Zero License (CC0) - also called a "Public License Fallback”
  • Do What the F*** You Want to Public License (WTFPL)
  • the so-called Donationware, a license that gives unlimited privileges for software and derivatives use but requests an optional donation to the author. The most popular one - Beerware - was introduced by Poul-Henning Kamp.
    Similar licenses allow the user to do anything with the licensed material and encourage him/her to share a drink/dish with the author, consume it in author’s honor, or simply hug the author on occasion:

The spectrum of rights granted by various licenses is most vividly shown in the following diagram by Mark Webbink, ex-General Counsel at Red Hat:

Diagram with Spectrum of Rights in Copyright by Webbink.

One of the important differences between proprietary and free & open source software lies in the fact that the former seeks to maximize its monetary value and achieve monopoly. FOSS, on the contrary, maximizes its value by assuring that a monopoly cannot be achieved. According to a widespread belief, supported by Mark H. Webbink, it is the open source that is capable of advancing the art of software. So let’s have a closer look at FOSS licenses.

FOSS Licenses

Free & open source software could be distributed under the following licenses:

Non-protective (permissive) licenses

These licenses do not protect the code from being used in non-open source apps and apply no restrictions on the derivatives. Some of them, however, require attribution. Permissive licenses have larger compatibility than protective ones, which cannot be blindly combined and mixed.
Here are a few examples of non-protective licenses, which could be safely used for development purposes:

BSD License Logo BSD-family (Berkeley Software Distribution) licenses. These impose minimal restrictions on the use and distribution of software covered by them. Examples of software under these licenses: Django, ReactJS, Scala, Go, Falcon.

MIT License Logo MIT is a license introduced by Massachusetts Institute of Technology, which puts only very limited restriction on reuse and allows it even in proprietary software. MIT-licensed software can be integrated with GPL-licensed software, but not the other way around. Examples of software under this license: Angular, Sass, Bootstrap, JQuery, InfluxDB, NodeJS. Logicify also licensed a few tools we developed under MIT.

Apache License Logo Apache License, written by the Apache Software Foundation, also allows freedom in use and distribution of software under it, with the preservation of copyright notice and disclaimer. Examples of software under this license: Apache products, Android OS, Docker, BeanShell, Kotlin.

Protective (copyleft) licenses

Unlike non-protective ones, protective licenses force the author of derivatives or re-distributor of the software to open the modified code. Such licenses oblige the derivatives of copyleft license to be placed under copyleft too. The most popular copyleft license is GNU General Public License (GPL). It is sometimes referred to as a “viral” license due to its motto: “once free, always free” - having been granted the right to use, modify and redistribute the software under GPL, you must extend the same privileges and terms to others who receive the software from you.
Other examples of copyleft licenses are:

  • Mechanical
  • Eclipse Public License 1.0
  • Mozilla Public License 2.0
  • Open Software Licence 3.0
Cloud Loophole in Copyleft Licenses

There is a minor loophole in the wording of some copyleft licenses, GPL included, about the availability of source code. Under these licenses, source code should be made available for any distributed derivatives. But what if your derivative is offered as SaaS (from the cloud) or using a server-based computing model? In this case, it is, in fact, not being distributed, which means you are not obliged to open the source code of your derivatives. To curb such cases, some copyleft licenses, for instance GNU Affero GPL, stipulate that users who access the software over a network also have a right to get its source code.

Tips on Dealing with Licenses in Software Development

Here are a few tips from Logicify team on how to deal with software licenses. These would be helpful both for product owners and people involved in development (software engineers, DevOps, Project Managers):

  1. Always check the license of software components you install or use in development. Each component can have cascading legal, security or quality implications for the project, so it is crucial to manage every single one attentively.
    While names of most permissive OS licenses usually “ring a bell,” some rarely used ones do not. It would not hurt to quickly check their terms. You could use this resource for this:

  2. Have a means to document what software is in use in your current project. Include software version and license. Keep the list up to date as the project evolves. Ready access to it will help in licensing compliance and managing IT architecture of the project.

  3. Run a license scan if you join a new project where the above practise is not adhered to. There are costly proprietary solutions for this used by large enterprises, yet a startup or SME could use an easier freemium tool - Free Open Source Software Analysis - available at The tool plugs directly into the development workflow to automatically track, manage and remediate OSS and vulnerability issues and proactively flag outdated components.

  4. Beware GPL and other copyleft licenses. Any derivatives of a GPL-covered software are subject to GPL. That is why developers and product owners should be particularly attentive not to select a GPL-covered component for a software product that would later be distributed under a proprietary license.
    If you overlook it or intentionally conceal using GPL-licensed components, you secret could one day be leaked by competitors or investors. Noone wants to have the reputation and company assets damaged, right?

  5. If your product is approaching an important round of funding or other event that requires a due diligence, you’d better work with a license specialist company. They can review your software product, including all its dependencies and tools used, and provide an advice on how to improve it. Source Code Control is a good example of such a company, and Logicify has partnered with it. The report would point out to OSS risks and give an expert assessment of your digital product.

  6. If you release your own software, do not leave it unlicensed.
    Take a few minutes to determine a license that best fits your needs. This way, you’ll ease life for fellow programmers who could find your software useful. Also, always check the licenses of dependencies and components your software links to.

Here is a couple helpful tools to choose a license if you contribute to OSS: and

Here’s a GitHub instructions on licensing your repository:

Let us know if you have any license-related questions or feedback to share:

Related articles


Scroll top