Using Someone Else's Code: License Compliance Guide

Modern software is assembled, not written from scratch. You lean on a web framework, a dozen npm packages, a Python library or two, a UI kit someone shared on GitHub — and each one saved you weeks. That’s the whole point of open source, and using it is not only legal, it’s expected. But “I found it on GitHub” is not the same as “I can do whatever I want with it.” Every one of those dependencies came with a license, and that license is a binding set of conditions you agreed to the moment you shipped code that includes it.

The good news: for indie developers, compliance is usually straightforward once you treat it as a small, repeatable habit instead of a one-time panic before launch. This is a practical, plain-language workflow — how to vet code before you use it, keep track of what you’ve pulled in, sidestep the one trap that actually bites people, and hand over the attribution you legally owe. This is IPSurge, so the focus is on what this means for you, not the philosophy of software freedom.

A gold code-bracket lifted from a communal repository into a personal project folder, still tethered by a license tag, on navy, symbolizing borrowed code that carries conditions — Every dependency you pull in arrives with a license still attached — the tag comes along whether you read it or not.

“Open Source” Doesn’t Mean “Free to Do Anything”

Start with the fact almost everyone gets wrong: source code is protected by copyright automatically, the instant it’s written. By default, nobody else has permission to copy, modify, or redistribute it. An open-source license is how the author grants you those permissions — in exchange for following a few conditions.

Track the cases yourself

Every current AI-copyright ruling — and the ones still being fought — lives in our AI Copyright Ruling Tracker. Filter by your creator type to see, in plain language, how each case affects your rights.

So the license isn’t red tape stapled onto free code; it’s the thing that makes the code usable at all. Skip its conditions and you’re not in a gray area — you’re infringing the author’s copyright, the same as if you’d lifted a photo or a song. That risk is real for solo developers too: if your project gets acquired, audited by a client, or noticed by the original author, non-compliance can mean a takedown, a forced rewrite, a blown deal, or a demand letter. Building compliance in from day one is far cheaper than untangling it later.

Step 1: Find the License Before You Add the Dependency

The single best habit you can build is checking the license before a package goes into your project, not after. It takes seconds. Look for:

A LICENSE or COPYING file in the repository root.
The license field in the project’s manifest — package.json, pyproject.toml, Cargo.toml, the .gemspec, and so on.
A license header in the source files themselves, or a badge in the README.

Then watch for the trap that catches beginners: code with no license at all. A public GitHub repo with no LICENSE file is not “free for the taking” — it’s all rights reserved. Posting code publicly doesn’t waive copyright, so a no-license repo actually gives you fewer rights than an open-source one. Legally, you have no permission to use it in your own project. If you want to, ask the author to add a license (or grant you one in writing). Same goes for that snippet copied straight out of a Stack Overflow answer or a blog post — it carries a license too, and it isn’t automatically yours to ship.

Step 2: Know What Each License Asks of You

You don’t need to memorize dozens of licenses — you need to know which of three buckets a dependency falls into. (For a deeper breakdown of the individual licenses, see our guide to MIT, GPL, and Apache.)

Permissive (MIT, BSD, Apache 2.0): the easy ones. Use commercially, modify, bundle into closed-source products — just keep the copyright and license notice in what you distribute. Apache 2.0 asks a little more (note significant changes, carry the NOTICE file) and adds a helpful patent grant. This bucket is roughly “keep the notice and go build.”
Weak copyleft (LGPL, MPL, EPL): the middle ground. You can generally combine these with proprietary code, but modifications to the licensed library or files themselves must stay open. Fine for most uses — just don’t fork-and-hide the library.
Strong copyleft (GPL, AGPL): the one to handle deliberately. If you distribute software built on this code, you generally must release your entire combined work under the same license, source included. More on the trigger below.

Ninety percent of what an indie dev uses is permissive, and ninety percent of permissive compliance is “don’t strip the notice.” The rest is about spotting the copyleft cases early.

A gold magnifying glass over a code document revealing a hidden license tag, with unchecked folders behind, on navy, symbolizing checking a dependency's license before use — Find the license before you add the package — not after you’ve shipped and someone asks about it.

Step 3: Track Your Whole Dependency Tree

Here’s what makes this harder than reading one license: you don’t have one dependency, you have hundreds. The framework you added pulled in its own dependencies, which pulled in theirs. These transitive dependencies run several layers deep, and each carries its own license. A permissive top-level package can easily sit on top of a copyleft library buried three levels down — and that buried license still applies to you.

You cannot audit that by hand, and you shouldn’t try. Use tooling:

Run a license scanner that walks your full tree — license-checker for Node, pip-licenses for Python, cargo-deny for Rust, or a platform like FOSSA for bigger projects. It lists every license in play and flags the risky ones.
Generate an SBOM (software bill of materials) — a machine-readable inventory of everything your software includes. Tools like Syft or your CI pipeline can produce one automatically, and clients increasingly ask for it.
Wire the scan into your build or CI so a surprise GPL/AGPL dependency gets caught the day it appears, not the week you launch.

Treat your license inventory like your dependency lockfile: generated, versioned, and refreshed whenever you add or upgrade packages.

A gold project box branching down through many layers of dependency nodes, one glowing node chained back upward, on navy, symbolizing a buried copyleft dependency deep in the tree — The dependency you chose pulls in dozens you didn’t — and a copyleft license three levels down still counts.

Step 4: Respect the Copyleft Trigger

Strong copyleft is where indie developers get genuinely burned, so it’s worth understanding the mechanic rather than just fearing the acronym.

Distribution is the trigger. The GPL’s obligation to release your source generally kicks in when you distribute the software — ship an app, hand over a binary, sell a downloadable product. Using GPL code purely for yourself, internally, usually triggers nothing. That’s why plenty of GPL tools are fine to run in-house.

The AGPL closes the SaaS loophole. This is the modern gotcha. The Affero GPL extends copyleft to software users interact with over a network. If you run modified AGPL code as a web app or API, you may owe your users the source even though you never shipped them a copy. A lot of popular server-side and database tools are AGPL — check before you build a commercial service on one.

When a scan turns up strong copyleft in something you plan to distribute or host commercially, you have four clean options: comply fully and open your source, keep the use strictly internal, swap in a permissively licensed alternative, or ask the author about a commercial license — many projects dual-license precisely so businesses can pay to skip the share-alike requirement. The mistake is discovering the obligation after launch. Decide on purpose, up front.

Step 5: Ship the Notices You Actually Owe

For the permissive licenses that make up most of your stack, compliance comes down to one concrete deliverable: the attribution has to travel with your product. In practice:

Preserve the original copyright notice and full license text for each dependency. The standard move is to bundle a THIRD-PARTY-LICENSES or NOTICES file, or an in-app “Open Source Licenses” screen, that lists them. Many license-scanner tools can generate this file for you automatically.
Carry forward any NOTICE file from Apache-licensed dependencies, and for Apache code, note any significant changes you made.
Don’t imply the original authors endorse your product — some licenses (like BSD 3-clause) forbid using their names to promote yours without permission.

This is the step people skip because it feels optional. It isn’t — it’s the actual price of a permissive license, and it’s trivial to automate. A generated notices file plus a line in your release checklist covers the vast majority of what you owe.

A gold shipping crate being sealed with a NOTICE tag and copyright label attached and a checkmark above, on navy, symbolizing shipping a product with required license notices — For most permissive licenses, compliance is simple: ship the notices along with the product.

What This Means for You

You don’t need a lawyer for routine open-source use — you need a habit. Here’s the whole workflow in one checklist:

Sort each one into permissive, weak copyleft, or strong copyleft so you know what it asks.
Scan the full tree, not just your direct picks — run a license checker and keep an SBOM current.
Handle strong copyleft on purpose before you distribute or host commercially; watch for AGPL in server-side tools.
Ship the notices — bundle the attributions and license texts with every release.

Bring in a professional when the stakes get real: you’re being acquired or investing heavily, a client audit turns up a copyleft dependency in your product, you got a compliance or infringement notice, or you want to combine copyleft code with proprietary work in a way you’re not sure about. For everyday building, the five steps above will keep you clean.

This article is general information, not legal advice. Open-source license terms are specific, and how they apply — especially around copyleft, linking, network use, and commercial distribution — can turn on the details of how you combine and ship software. For decisions with real money or liability on the line, review the full license text and consult a qualified intellectual-property or technology attorney.

IPSurge helps creators, developers, and small businesses understand and protect their intellectual property — the code, work, and ideas that make them unique.

Sources & further reading:

Using Someone Else’s Code: License Compliance for Indie Developers