Open Source Licensing in Plain Language: Permissive vs Copyleft, and What Commercial Use Requires
Your website, your admin system, and your app almost certainly use open source packages — frameworks, libraries, fonts, icon sets, editor components.
Most business owners have never given it a thought until somebody asks: “Which third-party components are in your product, and has the licensing been verified?” That question turns up in procurement reviews at large customers, in investor due diligence, or when a product is being sold into a particular regulated industry. This guide explains in plain language what open source licenses require, what effect they can have on a commercial product, and what to prepare on the outsourcing and contract side.
To be clear up front: this article covers general principles of assessment and a method for taking inventory. It is not legal advice. How a license applies to a specific case is a question for a lawyer.
Open source does not mean unconditional
“Open source” means the copyright holder has published the source code and permitted others to use, modify, and distribute it under specific license terms. The key point is that it remains a copyrighted work. What you receive is a conditional license, not free material in the public domain.
Common conditions include:
- Retaining the original copyright notice and the full license text
- Indicating in your product which open source components are used
- Noting the fact of modification, where you have modified it
- Releasing your modifications under the same terms, in certain circumstances
Almost nobody notices these conditions while the software is used internally. Once the product is sold externally, or enters somebody else’s review process, they get examined line by line.
The two broad categories, in plain language
There are many license types. In practice, understanding two temperaments will get you most of the way:
| Type | In plain language | Effect on your code | Typical use |
|---|---|---|---|
| Permissive | Take it and use it, just keep my name on it | Usually no additional requirement | Low concern for commercial products |
| Copyleft | I opened mine, so what uses it stays open | May require release under the same terms | Confirm how you are using it first |
Permissive licenses mostly require that the copyright and license notices be retained. Many widely used front-end frameworks and tools fall into this group, and the main obligation in commercial use is not to strip out the author’s name.
Copyleft carries an element of continuation. It is designed so that freedom is passed along, so when you use it in particular ways and then distribute the result, it may require that the relevant code be released under the same terms.
Three points are commonly misunderstood here:
First, copyleft does not mean commercial use is prohibited. Both categories mostly permit commercial use. The difference is whether your own code gets drawn in.
Second, the trigger usually involves distribution. Running something on your own servers without handing the software to anyone may be assessed differently from packaging it into a product and selling it; some terms also account for providing a service over a network. This is exactly where a lawyer needs to look at the specifics.
Third, “using it” covers a range of behaviors. Copying code into your own files, referencing it as a package, and merely using the output it produces (a graphic generated by a tool, for instance) are not the same thing.
One category is routinely overlooked: fonts, icon sets, stock libraries, and sample templates. Each carries its own license terms, and a common restriction is that personal use is permitted while commercial use requires a separate purchase. Being told after launch that your font license does not cover what you are doing is a real occurrence.
The practical effect on a commercial product
Licensing problems rarely surface during development. They tend to be dug up at these moments:
Procurement review at a large customer or a public agency. The vendor is asked for a list of third-party components with licensing details.
Investor or acquirer due diligence. Technical due diligence examines the license compatibility of your dependencies. NETVANA’s software consulting service includes architecture review and technical due diligence, and this kind of inventory is typically one part of it; for what the services cover, see the software services overview.
Delivering the product for the customer to deploy themselves. Once distribution happens, certain obligations genuinely activate.
Changing vendors. The incoming team will inventory the existing dependencies, and without a list they have to start the investigation from nothing.
One more thing to watch is unmaintained packages. License compliance is one side of it; security is the other, since a package nobody maintains will not receive further patches. That is a form of technical debt; for how to assess and handle it, see Technical Debt Explained for Business Owners and Website Security Basics for Businesses.
How to inventory your dependencies
Dependencies in a modern project stack up in layers: the packages you reference directly each bring in more of their own. Counting by hand is impractical, so build a process instead:
One: require the list. Ask your development partner for a complete dependency inventory with package names, versions, and licenses. Most development ecosystems have tooling that generates it automatically.
Two: make the list a deliverable. Deliver it alongside the source code and the deployment documentation, and update it at every release. NETVANA’s practice is that once the project fee is settled, source code, design files, and documentation transfer in full, and the dependency list forms part of that documentation.
Three: establish a habit for adding new packages. Before adding one, confirm at minimum the license type, whether it is actively maintained, and whether it is genuinely needed — pulling in a large package for one small feature adds both licensing and maintenance burden.
Four: record asset licenses in the same place. The license scope and proof of purchase for fonts, icons, stock images, and templates belong in the same document as the code packages.
Four common misconceptions
“Open source means there is no author.” Open source software has an identified copyright holder and specific license terms. It is not unowned; the author has simply chosen the conditions under which to open it.
“We did not modify it, so we are fine.” Some obligations activate on distribution and do not depend on modification at all. Retaining the copyright notice and indicating which components are in use is usually the minimum.
“That is the vendor’s business, not ours.” Once the product is delivered, your company is the one answering for it externally. That is precisely why the dependency list belongs in the deliverables rather than staying with the development team.
“We checked the licenses once.” Dependencies shift as versions update, and new features can pull in new packages. The list should be regenerated at every release rather than archived once the build is done.
What the contract should say when you outsource
Making licensing responsibility explicit is part of the homework when choosing a vendor. At minimum, cover these:
- Third-party component list: named as a deliverable, with an agreed update mechanism
- License compliance representations and liability: the vendor represents that the delivered work does not infringe third-party rights, with an agreed procedure if a dispute arises
- Ownership of asset licenses: whose name the font, stock image, and plugin licenses are bought under, and whether you can continue using them after the project closes
- Source code and copyright ownership: what you own, and whether you may modify it yourself or hand it to another vendor to maintain
- The boundary between custom code and open source components: which parts were built for you and which are borrowed
For a full discussion of these clauses and the other questions to ask when evaluating a vendor, see How to Choose a Software Development Company. The precise wording and legal effect of contract terms should be drafted and confirmed with a lawyer.
Licensing belongs in the selection decision
Licensing is not only a retrospective inventory exercise. It shapes decisions at selection time.
Take content management systems: the four routes — packaged platform, open source system, headless service, custom admin — differ considerably in licensing character, plugin ecosystem, and portability. For the full comparison, see How to Choose a CMS. When deciding whether to rewrite an old system, the licensing and maintenance status of its existing dependencies is one of the inputs; for that reasoning, see Legacy System Modernization.
One useful question to ask yourself: if we had to change vendors one day, or sell this product to somebody else, do I hold enough documentation to explain what this system is made of? If the answer is no, it is time to build the list.
Open source is what lets small teams ship complete products, and that is its value. The price is a basic grasp of what you are using. In most cases what has to be done is not complicated: keep a list, know what is in it, write the responsibilities into the contract, and consult a lawyer on the cases you are unsure about.
If you are not certain which third-party components sit inside your current system, or you are about to build something new and want this settled early, talk to NETVANA about a technical inventory. The software consulting service includes architecture review and technical due diligence, quoted individually rather than sold as a fixed package.
Further reading: for the questions to ask and the clauses to agree before outsourcing, see How to Choose a Software Development Company; for the risk that aging packages carry, see Website Security Basics for Businesses; for how CMS choice relates to licensing character, see How to Choose a CMS; for whether to repair or replace an old system, see Legacy System Modernization; and for where the maintenance contract draws its line, see What Website Maintenance Actually Covers. The license type you pick shapes who actually owns the code once the project wraps up, see Source Code Ownership and Project Handover.
