Free Does Not Always Mean Open Source

You find a useful library, open the repository, and see the source code right there. It is tempting to assume you can use it however you want.

That assumption is where many licensing problems start.

Software can be free to download, visible on GitHub, or even marketed as “open” without being open source. The difference matters when the code ends up in a product, a client project, or a public repository.

This article explains the practical side of open-source licensing: what the common labels actually mean, where license obligations begin, and how to avoid turning a small dependency into a large compliance task.

A License Is a Permission Slip

By default, the person or company that creates software owns the copyright in it. Copyright gives them control over copying, modifying, and distributing the work.

A license is the permission that relaxes some of those default rights. It tells you what you may do with the software and what you need to do in return.

That is an important shift in perspective. A license is not just legal text attached to a repository. It is the reason you are allowed to copy the code into your project in the first place.

For software teams, three rights come up repeatedly:

Copying the software, such as adding a dependency to a project or container image.
Modifying it, such as fixing a bug or adding a feature.
Distributing it, such as shipping a mobile app, a desktop application, or an SDK.

Different licenses grant those rights under different conditions.

Free, Source-Available, and Open Source Are Different Things

The word free is overloaded. It can mean free of charge, or it can mean freedom to use, study, modify, and share software. Those are not the same promise.

Freeware

Freeware costs nothing to use, but it is usually proprietary. You may be allowed to install it, while the source code remains closed and redistribution or modification remains restricted.

Adobe Acrobat Reader is a familiar type of example: free to download does not mean open source.

Source-available software

Source-available software lets you inspect the code, but its license places limits on use, redistribution, or commercial hosting. The Elastic License and the Business Source License are common examples.

Source visibility is useful for audits and learning, but visibility alone does not grant open-source rights.

A public repository with no license

This one catches developers surprisingly often. A repository without a license is not automatically open source. The code is still protected by default copyright, which means you do not have clear permission to copy, modify, or distribute it.

If there is no license, treat the code as “look, do not use” until you receive permission.

Open source

Open-source licenses satisfy the Open Source Definition. In practical terms, they allow people to use, study, modify, and redistribute the software. The definition also prevents discrimination against users or fields of work.

That is why a license that says “non-commercial use only” is not an open-source license, even when the code is publicly available.

The License Spectrum: How Much Do You Give Back?

Think of licenses by asking one question: If you use this code and share what you build, how much of your own code do you have to share too?

Permissive licenses

MIT, BSD-3-Clause, and Apache-2.0 are permissive licenses. They generally allow commercial use, modification, and redistribution, including inside proprietary products.

Their obligations are light. You normally preserve copyright and license notices, and Apache-2.0 also asks you to retain relevant NOTICE information and mark modified files where appropriate.

These licenses are popular because they make reuse easy. Apache-2.0 is especially common in companies because it includes an explicit patent grant.

Weak copyleft licenses

Weak copyleft asks you to share changes back, but only within a defined boundary.

MPL-2.0 usually keeps the requirement at the file level: modified MPL-covered files remain under MPL.
LGPL focuses on libraries: an application can usually use an LGPL library while remaining proprietary, provided the LGPL conditions are respected.

The details matter here. For example, static linking, relinking rights, and modified library code can change what you need to provide. “It is only a library” is not enough analysis on its own.

Strong copyleft licenses

GPL licenses require distributed derivative works to be licensed under the GPL as well. If GPL-covered code becomes part of a program you distribute, the source and corresponding license rights for that combined work may need to be provided to the public.

This is not a reason to avoid GPL. It is a design choice that protects the freedom of downstream users. It simply needs to fit the way you plan to ship the software.

When Do the Obligations Apply?

This is the part that is easy to oversimplify.

For many open-source licenses, the main trigger is distribution: giving a copy of the software to someone outside the organization. Shipping an app to customers, publishing an npm package are all forms of distribution.

Running GPL software on your own servers is usually different. Your users interact with the service, but they do not receive a copy of the server-side program. That is why AGPL exists.

Two examples make this clearer:

You use a GPL tool internally to process reports. You do not distribute the tool or a derivative of it. The usual source-sharing obligation is not triggered just by internal use.
You include GPL code in a desktop product that customers download. Distribution has happened, so the GPL obligations become relevant to that product.

The difficult question is often whether two pieces of code form one derivative work. Linking, embedding, plugins, processes, and communication boundaries can all matter. License text, project guidance, and legal advice are worth consulting when a commercial product depends on that answer.

Contributing Code: CLA, DCO, and Copyright Assignment

Using open-source code is one side of the relationship. Contributing code is the other.

Projects need to know that contributors have the right to submit their changes. They usually handle this in one of three ways:

Contributor License Agreement (CLA): An agreement that gives the project certain rights to use your contribution. Many CLAs let you keep ownership of your code, though the exact terms vary. Projects may have separate individual and corporate CLAs.
Developer Certificate of Origin (DCO): A lightweight per-commit statement. Running git commit -s adds a Signed-off-by line that confirms you wrote the change or are entitled to submit it.
Copyright assignment: Ownership of the contribution is transferred to the project or another organization. Some projects use this model to simplify future relicensing and enforcement.

Always check a repository’s CONTRIBUTING.md before opening a pull request. A technically excellent contribution can still be blocked by missing sign-off or CLA requirements.

Make Compliance Part of Development

License compliance does not need to be a late-stage legal panic. It works best as a normal engineering habit.

Start with a few practical steps:

Read the license before adding a dependency, especially when it is not a familiar permissive license.
Keep third-party notices and license texts when you distribute software.
Record dependencies in an SBOM (software bill of materials) so you know what is inside your application.
Use standard SPDX identifiers such as MIT, Apache-2.0, and GPL-3.0-only instead of vague labels or changing URLs.
Review transitive dependencies as well. The package you install may bring many other packages with it.

An SBOM is simply an ingredient list for software. It helps security, procurement, and legal teams answer the same basic question: what did we ship?

Tools can identify licenses at scale, but they do not replace judgment. A scanner can flag GPL-3.0; it cannot tell you whether your architecture creates a derivative work or whether a particular exception applies.

Before You Add the Next Dependency

Open source is built on permission and trust. The license is how a project gives you permission, and respecting it is how the ecosystem continues to work.

So before running the next install command, take a minute to check three things:

Is this actually open source?
What does its license require when I distribute my product?
Do I have a record of it in our dependency inventory?

That small check is usually far cheaper than untangling a licensing issue after the software is already in production.