+91 98726 60544 hello@mitstech.co Mon–Sat · 09:00–18:30 IST

Choosing a licence for software you build

IT Strategy By Mits Engineering Team 2 min read
Choosing a licence for software you build

Every piece of software you publish carries a licence, including when you do not choose one — code published with no licence is, in most jurisdictions, all rights reserved, meaning nobody may legally use it. That is rarely the intent, and it is the commonest licensing mistake: a repository made public with the assumption that public means usable, which it does not.

For code you want others to use freely, the permissive family — MIT, BSD, Apache 2.0 — allows use, modification and redistribution including in commercial and closed products, with attribution. Apache 2.0 differs from MIT in one way worth knowing: it includes an express patent grant, which large corporate users often prefer because it reduces their risk. If you want maximum adoption with minimum friction, one of these is the answer, and MIT is the most widely understood.

The copyleft family — GPL, AGPL and relatives — requires that derivative works be released under the same terms. That is a deliberate choice with a strategic effect: it makes your code unusable inside closed commercial products, which either protects a commons or forces commercial users to negotiate a separate licence with you. AGPL extends the obligation to software provided over a network, closing the gap where a company runs modified code as a service without distributing it. Several companies use AGPL precisely as a commercial lever rather than as an ideological position.

The direction matters as much when you are consuming. Copyleft obligations in a dependency can attach to your proprietary product, which is the licence risk that surfaces during acquisition diligence and takes weeks to remediate. Maintaining an inventory of your dependencies and their licences, generated during the build, is what makes that a check rather than an investigation — and it is the single most useful thing to have when a buyer's lawyer asks.

For work you deliver to clients, the licence question is really the assignment question, and it is answered in the contract rather than in a file header. What you want is explicit: everything built specifically for the client is assigned to them, while your pre-existing libraries and general-purpose tooling remain yours, licensed to them perpetually and royalty-free for use in the delivered work. Without that carve-out you either give away your accumulated tooling or quietly breach the agreement.

One caution about the newer source-available licences — the ones restricting commercial competition while publishing the code. They are legitimate commercial instruments and they are not open source, and describing them as such damages trust with exactly the developer audience they are aimed at. If you adopt one, say plainly what it permits and what it does not. Users respond well to a clear commercial licence and badly to being told something is open when it is not.

Need help with this? Explore our Software Development services. Learn more Back to all news

Keep reading

More on IT Strategy