Open Source and Licenses: What Developers Actually Need to Know

"Open source" is one of those terms that everyone uses and few people define precisely. For some, it means code you can read on GitHub. For others, it means free software. For a company lawyer, it means a set of obligations that can affect how a product is distributed.

Those definitions are not the same, and the difference matters. A public repository without a license is not open source. A project with a license that forbids commercial use is not open source either. The license is what turns source code into open source software.

This guide covers the practical side: what open source actually means, how the major licenses differ, how to choose one for your project, and what you need to do when you use someone else's code.

Disclaimer: this is a technical overview, not legal advice. If a license decision affects your business, talk to a lawyer who understands software licensing.

What open source actually means

The Open Source Initiative (OSI) maintains the Open Source Definition. A license must satisfy its criteria to be called open source. The important ones are:

Free redistribution. You can give the software away, including as part of a larger product.
Source code. The source must be available in a usable form.
Derived works. You can modify the code and distribute your version under the same terms.
Integrity of the author's source. A license may require that modified versions be clearly marked, but it cannot forbid distributing them.
No discrimination. The license cannot exclude people, groups, or fields of use.
Distribution of license. The rights apply to anyone who receives the software without needing a separate agreement.
No additional restrictions. You cannot add terms that limit what the license already allows.
Technology neutrality. The license cannot depend on a specific technology or interface.

The Free Software Foundation describes a similar idea with four freedoms:

Run the program for any purpose.
Study how it works and change it.
Redistribute copies.
Distribute modified versions.

"Free" here means freedom, not price. You are allowed to sell free software. What you cannot do is take away the freedoms the license grants to the people who receive it.

Open source, free software, and source-available

The terms overlap, but they are not identical:

Free software is the older term, associated with the FSF and a philosophy about user freedom.
Open source is the term popularized by the OSI, with an emphasis on development methodology and practical collaboration.
Source-available means you can read the source, but the license may restrict use, modification, or commercial distribution. Source-available is not open source.

A project like Redis changed its license in 2024. The source is still visible, but the new terms are not OSI-approved. That is source-available, not open source. The distinction is not semantic; it changes what you are legally allowed to do.

Why a license is not optional

Copyright applies automatically. The moment you write code, you own it and others have no right to use, copy, modify, or distribute it unless you give them permission.

GitHub's terms allow other users to view and fork public repositories through the platform. That is not the same as an open source license. It does not give them permission to use your code in their product, modify it, or redistribute it elsewhere.

So if you publish code and want other people to use it, add a license. The license file is not bureaucracy; it is the thing that makes your intentions legally real.

Permissive vs copyleft

Most open source licenses fall into two families.

Permissive licenses impose very few conditions. You can use the code in proprietary software, modify it, and distribute binaries without releasing your own source. You usually just need to keep the copyright notice and the license text.

Examples: MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC.

Copyleft licenses require that derivative works remain under the same license. If you distribute a modified version, you must also provide the source under the same terms. This is designed to keep the software open as it travels.

Examples: MPL-2.0, LGPL, GPL, AGPL.

Neither family is "better". Permissive licenses maximize adoption, especially in companies that cannot open their own code. Copyleft licenses protect the commons and ensure improvements come back. The right choice depends on what you want from the project.

The licenses you will actually encounter

MIT

MIT is short, old, and extremely common. It lets anyone use, copy, modify, merge, publish, distribute, sublicense, and sell the software, as long as they include the copyright notice and permission notice.

It has no explicit patent grant, which is one reason some companies prefer Apache-2.0. It also does not grant trademark rights. You cannot use the project's name to endorse your fork.

MIT is a good default for small libraries, tools, and projects where you want maximum adoption with minimum friction.

Apache-2.0

Apache-2.0 is permissive, but more explicit than MIT. It includes:

A patent license from contributors.
A requirement to keep the license and any NOTICE file.
A requirement to state significant changes in modified files.
A trademark clause that does not grant rights to the project's marks.

The patent grant is the main reason large companies prefer it. It reduces the risk of a contributor claiming a patent later.

Apache-2.0 is compatible with GPLv3, but not with GPLv2-only. That compatibility detail matters when you combine code from different projects.

BSD-2-Clause and BSD-3-Clause

BSD licenses are permissive and similar to MIT. The two-clause version requires keeping the copyright notice and disclaimer. The three-clause version adds a "no endorsement" clause: you cannot use the names of the authors or contributors to promote your derivative without permission.

They are common in operating systems, networking code, and projects that want a simple permissive license with explicit disclaimer language.

ISC

ISC is functionally similar to MIT but shorter and simpler. It is common in small utilities and in projects maintained by people who prefer minimal legal text.

MPL-2.0

The Mozilla Public License 2.0 is a middle ground. It is copyleft at the file level: if you modify an MPL-covered file and distribute it, that file must remain under MPL. You can combine it with proprietary files in a larger work, as long as the MPL files stay MPL.

MPL 2.0 also includes a patent grant and is compatible with GPLv2-or-later, LGPL, and AGPL through its secondary license mechanism.

It is a good choice for libraries or applications where you want improvements to the core shared, but you do not want to force every file in a larger product to be open.

LGPL

The Lesser General Public License is a weak copyleft license designed for libraries. You can link a proprietary application against an LGPL library, provided you allow users to replace or relink the library and you share any modifications you make to the library itself.

LGPL 2.1 and LGPL 3.0 differ in details, especially around installation information and combined works. If you are embedding an LGPL library in a device or a proprietary product, read the specific version carefully.

GPL-2.0 and GPL-3.0

The GNU General Public License is the best-known strong copyleft license. If you distribute a derivative work, you must license the whole work under the GPL and provide the corresponding source code.

GPLv3 adds several things over GPLv2:

An explicit patent grant.
Anti-tivoization rules for consumer devices.
Compatibility with Apache-2.0.
Stronger language around installation and user rights.

GPLv2-only and GPLv3 are not compatible with each other. A project that says "GPL-2.0-only" cannot simply take GPLv3 code. A project that says "GPL-2.0-or-later" gives you the option to use GPLv3 terms.

The GPL does not forbid selling software. It forbids distributing binaries without also providing the source and the same freedoms to recipients.

AGPL-3.0

The Affero GPL is GPLv3 plus a network clause. If you modify the software and let users interact with it over a network, you must offer them the corresponding source.

This closes the "SaaS loophole" where a company modifies GPL software, runs it as a service, and never distributes binaries. If you are building a hosted product on AGPL code, the obligation can apply to you.

Public domain dedications

Some projects try to waive copyright entirely:

Unlicense is an OSI-approved public domain dedication.
0BSD is an OSI-approved permissive license with no attribution requirement.
CC0 is a public domain dedication from Creative Commons. It is widely used for data and content, but it is not OSI-approved and is not recommended for software by the FSF.

Public domain dedications are simple, but they can be awkward in jurisdictions that do not allow authors to give up certain moral rights. A permissive license is often the safer choice.

Creative Commons licenses

Creative Commons licenses are designed for creative works, not software. CC BY and CC BY-SA are common for documentation, articles, images, and datasets.

Do not use CC licenses for code. They do not address patents, source distribution, or linking in the way software licenses do. If you want a permissive content license, CC BY 4.0 is a reasonable choice. If you want share-alike, use CC BY-SA 4.0.

CC licenses with NC (non-commercial) or ND (no derivatives) are not open source and are not free software. They restrict use in ways the OSI definition does not allow.

Source-available is not open source

Several companies now publish source under licenses that look open but are not OSI-approved. Common examples:

SSPL (Server Side Public License): requires service providers to release the source of their entire service stack. It is not OSI-approved.
Elastic License 2.0: restricts offering the software as a managed service and removing license key functionality.
BSL 1.1 (Business Source License): restricts production use until a change date, after which it converts to an open source license.
Commons Clause: not a standalone license, but an additional restriction often attached to a permissive license to prohibit selling the software.

These licenses can be legitimate business choices. They are just not open source. If your company policy says "open source only", source-available dependencies need a separate review.

Quick comparison

License	Family	Can use in proprietary product?	Must share modifications?	Patent grant
MIT	Permissive	Yes	No	No explicit grant
Apache-2.0	Permissive	Yes	No	Yes
BSD-3-Clause	Permissive	Yes	No	No explicit grant
ISC	Permissive	Yes	No	No explicit grant
MPL-2.0	Weak copyleft	Yes, with conditions	Yes, for MPL files	Yes
LGPL-3.0	Weak copyleft	Yes, with conditions	Yes, for the library	Yes
GPL-3.0	Strong copyleft	Yes, but derivative must be GPL	Yes, whole work	Yes
AGPL-3.0	Strong copyleft	Yes, but network use triggers source offer	Yes, whole work	Yes
Unlicense / 0BSD	Public domain-ish	Yes	No	No

The table is a summary, not a substitute for reading the license. "With conditions" is doing a lot of work in the copyleft rows.

How to choose a license

Start with the outcome you want.

You want maximum adoption, including by companies. Use MIT or Apache-2.0. Choose Apache-2.0 if patents matter to you or your users. Choose MIT if you want the shortest, most familiar text.

You want improvements to flow back. Use GPL-3.0 for applications, AGPL-3.0 for network services, and LGPL or MPL-2.0 for libraries.

You are building a library that proprietary products will link against. LGPL or MPL-2.0 is usually more practical than GPL. GPL libraries push many companies away entirely.

You are publishing documentation, images, or data. Use CC BY 4.0 or CC BY-SA 4.0. Do not use a software license for prose.

You want to experiment with a commercial model. You can dual-license your own code: copyleft for the community, commercial license for companies that cannot comply. This only works if you own the copyright or have a CLA that allows it.

A simple decision path:

Is it code or content? If content, use CC.
Do you want proprietary derivatives to be allowed? If yes, permissive.
Do you want modifications shared? If yes, copyleft.
Is it a library? Consider LGPL or MPL instead of GPL.
Is it a network service? Consider AGPL.
Are patents a concern? Prefer Apache-2.0 or a license with a patent grant.

Using open source correctly

Using open source does not mean ignoring the license. A practical checklist:

Keep the license text and copyright notices. If you distribute a binary or a copy of the source, include them.
Respect NOTICE files. Apache-2.0 projects may require you to preserve attribution notices.
Do not imply endorsement. You generally cannot use the project's name or logo to promote your product without permission.
Track your dependencies. A license scanner or SBOM tool helps you notice when a transitive dependency changes terms.
Understand distribution. GPL obligations trigger when you distribute software, not when you use it internally. AGPL adds network use.
Do not strip license headers. If you copy code into your project, keep the relevant notices.

Commercial use is allowed by most open source licenses. "Open source" does not mean "non-commercial". It also does not mean "no support" or "no cost"; companies sell support, hosting, and services around open source software all the time.

Common myths

"MIT means I do not need to attribute." No. MIT requires you to include the copyright notice and permission notice. You do not have to advertise the project, but you cannot remove the notice.

"GPL means I cannot sell my product." You can sell it. You just have to provide the source and the same freedoms to your recipients.

"Copyleft is anti-business." Many companies build successful businesses on copyleft software. The obligation is about keeping the code open, not about preventing revenue.

"Open source is less secure." Open source allows more people to inspect the code, but inspection is not guaranteed. Security depends on maintenance, review, and how the project is used.

"I can just change the license later." Only if you own the copyright or have permission from every contributor. This is why many projects use a CLA or a DCO from the start.

If you maintain a project

A few habits make licensing boring, which is the goal:

Add a LICENSE file with the full license text.
Add a short license section to the README.
Use an SPDX identifier in package metadata and, optionally, in source headers:

SPDX-License-Identifier: MIT

Decide whether you mean GPL-2.0-only or GPL-2.0-or-later, and be consistent.
Keep a NOTICE file if you use Apache-2.0 dependencies.
Add contribution rules. A DCO is lightweight; a CLA gives you more flexibility for future relicensing.
If you accept contributions, make sure the inbound license is clear. "Inbound = outbound" is the common default.

If you are maintenance-constrained, choose a license you will not regret in five years. Changing it later is much harder than choosing it carefully now.

Final thoughts

Open source is not a single thing. It is a set of permissions backed by copyright law, and the license is where those permissions live. Understanding the difference between permissive, weak copyleft, strong copyleft, and source-available is enough to avoid most surprises.

For most small projects, MIT or Apache-2.0 is the right answer. For libraries that companies will embed, LGPL or MPL-2.0 is often more realistic than GPL. For services where you want improvements shared, AGPL is the tool designed for that job.

Read the license before you depend on it. Keep the notices when you use code. And if you publish something you want others to use, add a license. A public repository without one is just a public repository.