You find the perfect library on GitHub, use it in a client project, and then plan to sell that application to many customers. Are you allowed to do that, and what do you owe the original authors? The answer sits in the LICENSE file that most people skip.
A license defines what you may do with code: use it, modify it, combine it, distribute it, and sell it. Misreading one can force you to open your own source code or put you in breach of someone else's copyright. This guide explains the licenses PHP and Laravel developers meet most often, how to audit a project's dependencies, and what to check before you sell a product built on other people's code.
Note: this is a practical guide, not legal advice. For high-value contracts or disputes, talk to a lawyer who specializes in intellectual property.
The Basics: Code Always Has an Owner
In most countries software is protected by copyright the moment it is written. Code you find online is not automatically free to use. A license is the owner's written permission and its conditions. Code with no license at all is the riskiest case: by default you have no permission to use it, even if the repository is public.
Two Big Families: Permissive and Copyleft
Permissive licenses (MIT, BSD, Apache 2.0) allow almost any use, including inside closed-source products, as long as you keep the copyright notice. Copyleft licenses (the GPL family) require that derivative works you distribute use the same license and make their source available to recipients.
| License | Commercial use | Inside a closed product | Main obligation |
|---|---|---|---|
| MIT | Yes | Yes | Keep the license text and copyright notice |
| BSD 2-Clause / 3-Clause | Yes | Yes | Keep the notice; 3-clause forbids using contributor names for endorsement |
| Apache 2.0 | Yes | Yes | Keep license and NOTICE file, mark changed files; includes a patent grant |
| LGPL | Yes | Yes, if you only link to the library unchanged | Changes to the library itself must be shared |
| GPL v2 / v3 | Yes | No, when distributed | Distributed derivatives must be GPL with source included |
| AGPL v3 | Yes | No, including network use | Users interacting over a network are entitled to the source |
| Commercial / proprietary | Per terms | Per terms | Whatever the seller's agreement says: projects, resale, support |
MIT: Very Free, With One Condition
MIT lets you use, copy, modify, merge, publish, distribute, sublicense, and sell the software. The only condition is that the copyright and permission notice travel with the code. Laravel itself is MIT-licensed, which is why you can build and sell applications on top of it. The required text looks like this (shortened):
MIT License
Copyright (c) 2026 Owner Name
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
...
A frequent slip is deleting the header or LICENSE file when copying a library into your project. Leave it in place.
GPL: When Do the Obligations Apply?
Many developers believe that touching GPL code makes the whole business open source. In fact GPL obligations are triggered when you distribute a derivative work, for example by selling or handing over the application files. Purely internal use generally does not require you to publish anything.
Web apps add a twist. GPL v2 and v3 do not treat running software on a server for users as distribution. The AGPL closes that gap: if you modify AGPL code and offer it as a network service, users of that service can request the source. If you are building SaaS, watch for AGPL dependencies.
For example, suppose you sell a point-of-sale app's source to clients and it includes a GPL plugin tightly integrated with your code. Those clients are entitled to the complete source under the GPL and may redistribute it. A per-installation licensing model becomes hard to defend.
Apache 2.0: Permissive With Patent Protection
In practice Apache 2.0 is as free as MIT, plus two things. Contributors grant a patent license for their contributions, and you must mark modified files and keep any NOTICE file. Many corporate projects prefer it for that patent clarity.
Commercial Licenses From Source Code Sellers
Code sold on marketplaces usually ships with a custom license. Look for answers to these questions:
- How many projects or domains one license covers.
- Whether it can be used for client work, and whether the client may resell it.
- Whether it may power a subscription SaaS product.
- Whether you may resell the source, original or modified.
- Which third-party assets are bundled, such as paid admin themes or icon sets.
If the terms are vague, ask and get the answer in writing before paying. A broader evaluation framework is in buy or build: choosing ready-to-use source code.
How to Audit Licenses in a Laravel Project
A modern Laravel app can pull in hundreds of Composer and npm packages. You do not need to check them by hand:
# List licenses for every installed PHP package
composer licenses
# JSON output for scripts or CI pipelines
composer licenses --format=json > licenses-php.json
# Summary of npm package licenses (uses the license-checker package)
npx license-checker --summary
- Run the commands and store the output with your project docs.
- Flag GPL, AGPL, and packages with no license ("none" or "UNKNOWN").
- For each flag, decide whether the package ships to customers or is a development-only dependency.
- Replace problem packages with permissive alternatives if your product is closed.
- Create a
THIRD_PARTY_LICENSESfile listing each package, its license, and its notice. - Repeat before every major release.
Common Mistakes
- Shipping GPL code inside a closed product you sell. Swap the library or change the business model.
- Removing original license and copyright text. This breaches MIT, BSD, and Apache terms alike.
- Treating unlicensed code as free. No license means no permission. Ask the author or find an alternative.
- Pasting snippets from Q&A sites without checking terms. Many use Creative Commons licenses that require attribution.
Checklist Before You Sell
- Every major component's license is known and recorded.
- No GPL or AGPL component sits inside a distributed closed product.
- All license texts and notices ship with your package.
- Commercial license terms allow your model: one-off sale, SaaS, or client work.
- Fonts, icons, and images are licensed correctly too.
- Your own product includes a LICENSE describing the buyer's rights.
If you plan to turn code into a subscription service, read turning source code into a SaaS product so your technical and legal choices line up.
