Skip to content

535 040 361511 275 531

Book an IT review
Book a free IT review

Ongoing IT support under subscription

Growing the business

Business systems

Data and AI

Our apps

Who we help
Before you decide
office@nexait.pl

Open source licences in business: MIT, GPL, AGPL and licences with restrictions

A free application is not an application without conditions. The MIT, Apache, GPL and AGPL licences differ in the obligations they place on a company, and some licences with published source code only look open.

The NexaIT team2 October 20266 min read

Graphic: types of software licence, from permissive to licences with restrictions

A company that runs an open source application on its own server usually does not pay for the licence. That does not mean the licence does not apply to it. Every licence sets out what you may do with the program, and some of them impose obligations only in specific situations: when you change the code, when you pass the program on, or when you make a modified version available over a network.

This text sets out the basics. It is not legal advice. For an unusual use, such as embedding someone else's code in your own product, consult a lawyer about the licence.

What “open source” means under the OSI definition

The term "open source" has a specific definition. The Open Source Initiative describes it in ten criteria. One of them states plainly that a licence must not restrict use of the program in a specific field of endeavour, for example in business.

This criterion matters to companies. A licence that prohibits commercial use of the program, or providing services around it, may come with public source code, but it does not meet the open source definition. Vendors of such licences often say so themselves and use other names, such as "fair-code" or "source available".

Permissive licences: MIT and Apache 2.0

The MIT licence grants the right to use, copy, modify and distribute the program without restriction, on one condition: the copyright notice and the licence text must be included with copies of the program.

Apache 2.0 works in a similar way but adds two things that matter to companies. Each contributor grants a licence to their patents related to their contribution. The licence also requires notices of changes in modified files and inclusion of the NOTICE file, if the project has one.

For a company that runs such a program on its own server, both licences mean minimal obligations in practice. They need more attention when the code is built into your own product, because then the licence information has to be included in the distribution.

Copyleft licences: GPL

GPL is a copyleft licence. You may use, change and sell the program. The Free Software Foundation states in its FAQ that the right to sell copies is part of the definition of free software.

The condition applies to distribution. If a company passes a modified version of the program to others, it must make its source code available under the same licence. The same FAQ explains, however, that the GPL does not require you to release changes an organisation uses internally. A company can modify the program and use it in-house without releasing the changes outside.

AGPL: copyleft over the network too

Web applications are not usually handed to users as files. They run on a server, and the user opens them in a browser. That is why the GNU AGPL was created; its section 13 extends copyleft to use over a network.

If you modify a program licensed under the AGPL, the modified version must prominently offer all users who interact with it remotely the opportunity to receive the source code. The obligation applies to modifications of the code. Simply running an unmodified application and configuring it in the admin panel is not yet a change to the program.

Many popular business applications, such as helpdesk systems, password managers and wikis, are licensed under the AGPL. For a business that deploys them without changing the code, the licence creates no additional obligations. If you plan to change the code, decide before deployment how you will make the code of the modified version available.

Open core: a free core and paid modules

Some projects publish the core under an open source licence and selected code directories under the vendor's commercial licence. These usually contain features important to companies: sign-in through a domain directory, single sign-on, an extended audit log.

This is a fair model, as long as you know about it before deployment. The problem arises when someone runs an installation image containing both kinds of code and uses the paid features without a licence. Before choosing, check which features are in the free version, and do not enable the others without an agreement with the vendor.

Licences with public source code that are not open source

Several well-known licences come with public code but restrict how it may be used. Three examples we come across most often:

  • Sustainable Use Licence. It is used by n8n, whose uses we cover in our post on n8n automations. The licence allows you to use the program for the business's internal purposes. The vendor's FAQ permits paid creation, deployment and maintenance of workflows for clients, but does not allow n8n to be offered as a service in which clients build workflows themselves.
  • Business Source Licence 1.1. Created by MariaDB. It restricts production use beyond what an additional use grant from the licensor allows, and after the change date, at the latest four years after a given version is released, the code moves to a specified open licence.
  • Licences with a branding clause. The Open WebUI licence prohibits changing the program's branding, except for the cases described in its text. You may use the program, but you may not sell it under your own name.

None of them is "worse" in itself. Each of them, however, needs to be read before deployment, because whether a commercial licence is needed depends on how you use the program.

What to watch out for with software licences in a business

  1. Program edition. The same application can have a free edition, a subscription edition and a development edition the vendor does not recommend for production. The licence is checked for a specific edition and a specific installation file.
  2. Who buys the licence. If the deployment requires a paid edition, the licence should be bought by the company that uses it. Then everything stays with that company after a change of service provider.
  3. Changes to the code. Configuration and integration through an API are usually not modifications of the program. Changes to code under the GPL or AGPL require a decision on how you will make the code available if you pass the program on or make it available over a network.
  4. Names and logos. A licence for the code grants no rights to trademarks. A product's name does not go into your own service names or domains.
  5. A written list. A list of applications with their licence, edition and date checked makes an audit easier, as well as a conversation with a business partner who asks about the software in your company.

How we check the licences of open source applications

In the catalogue of applications we deploy on clients' servers, each entry shows the licence with a link to its text and the main limits of the free edition. Licences that do not meet the open source definition are marked separately. Details are on the page about deploying and maintaining open source applications and in the application catalogue.

Frequently asked questions

Can we use open source applications in our business?

Yes. The open source definition rules out restricting fields of use, including business. Restrictions may come with licences that only make the code available, which is why we always check whether a licence meets the definition.

Can an IT company charge for deploying an application licensed under the AGPL?

Yes. The AGPL does not prohibit paid services. Its conditions concern making the code of a modified version available to users who interact with it over a network.

Do we have to publish our changes to a GPL program?

No, if you only use them within your organisation. The obligation to make the code available arises when you pass the modified version outside.

Sources

As of 2 October 2026.

Read more in the same topic.

Free · 60 minutes online · no obligation

You want to check this out at home in your company?

  1. You talk to an engineerOnline, by video call. Not with a salesperson. We don't install or change anything.
  2. We check 8 areasBackups, access, network, email, server, licences, protection and KSeF readiness.
  3. You get a scorecardThree priorities on one page, emailed after the meeting. Yours to use however you like.
Choose a time in the calendar

+48 535 040 361+48 511 275 531

office@nexait.plMessage us on WhatsApp

We don't use a contact form, but we answer the phone and reply to emails and WhatsApp messages during working hours.