All posts

Can I Use Open Source Software Commercially?

Can open source software be used commercially? Permissive licenses allow it with attribution; copyleft adds source-sharing conditions. What Indian SaaS businesses need to know.

OpenCode
OpenCode4 min read

Short answer: yes, in almost every case. Open source is not "free for personal use only", and most licenses explicitly permit commercial use. What a license actually controls is your obligations, and those differ a lot between the two big families.

Permissive licenses, MIT, Apache 2.0, BSD, are the easiest to build a business on. They let you use, modify, and redistribute the software in any product, including a closed-source commercial one, and sell that product for whatever you want. You do not have to publish your changes. Your only real obligations are keeping the copyright notice and not claiming you wrote it. Apache 2.0 additionally grants a patent license, which is valuable if you distribute software and hold patents. A small Indian software company can take a permissively licensed library, bake it into a product, sell subscriptions, and never open a line of their own code. That is entirely legal and is how a huge share of commercial software works.

Copyleft licenses, GPL, LGPL, and AGPL, are the ones that carry conditions. GPL lets you use and even sell the software commercially, but if you distribute a modified version to others, you must release your modifications under GPL so recipients get the source too. Internal use is safe: if you run GPL software inside your company and never hand it out, no obligation kicks in. LGPL is the library-friendly version; you can link it into a closed product without open-sourcing your application, as long as you share any changes you make to the library itself.

AGPL is the one that surprises Indian SaaS founders most. It adds a network clause: if you run modified AGPL software as a service that people interact with over the internet, the users of that service are entitled to the source. Distribution no longer requires handing over a file, running it counts. So building a hosted product on a modified AGPL database or server without publishing source is a violation.

A concrete example: a Pune startup building an invoicing platform for small businesses. They use an MIT-licensed PDF library for invoices, an Apache-licensed web framework, and an AGPL-licensed search engine they modified to add Hindi and Marathi indexing. The MIT and Apache parts are done, keep the notices. The search engine is the problem; because they modified it and run it as a service, they must publish their changes. Options: publish the modifications, and they lose nothing, since users of the service are not competitors for a search engine they barely touched, or use an unmodified version, or switch to a permissive alternative. Most teams pick the last two without realizing the first one is often fine.

Where people go wrong: assuming GPL bans commercial use (it does not, "commercial" never appears as a ban in the license), assuming code on GitHub is free to use with no license at all (wrong, no license means no permission), and assuming compliance is about money (it is about source). Another common trap is mixing licenses. If you combine GPL code into an MIT project, the combined work may have to ship under GPL, which poisons the permissive posture.

So, for a commercial product: permissive licenses are effectively friction-free with attribution. Copyleft requires you to plan for source sharing if you distribute or, for AGPL, if you run it as a service. Neither prevents you from making money. Read the license before you commit, decide early which family you want in your stack, and revisit when you add dependencies. The full comparison is in our licensing explainer.

open sourcecommercial uselicensingmitgplagpl

Related posts