Skip to content
OrionHub Developer tooling and cloud development
Section
open-source
Kind
Editorial
Reading time
3 min
Updated
8 September 2026

Choosing a License for Your Project: A Decision Path, Not a Table

Open source licensing is about more than making software available. It's a choice about what permission and obligations will travel with the software, and to whom. So it requires choices that often looks more like a tall-tale decision tree than a decision matrix.

The Open Source Initiative defines an open source license as one that complies with its Open Source Definition and "allow[s] software to be freely used, modified, and shared." But the OSD itself is more than a checklist of permissions. It places restrictions to ensure that license "must be technology-neutral".

We know the real differentiator is granting the user the baseline permissions required for software to be even considered open source: that source code be included or made available, that distributed source and compiled forms both be allowed, that derivative works be allowed, that use not be restricted by field of endeavor, that they not be specific to a product, that they not restrict other software, and that they be technology-neutral.

So in those terms, all the licenses under discussion in discussions make the cutoff. It is definitions that come into play. Take copyleft licenses. Those are marked by a special condition: that any derivative work must also be distributed as open source. GPL-3.0 does this, while the Apache 2.0 does not. Both meet the OSD, but choice of one over the other creates different obligations for the user.

A license confines each user's choices. The SSPL-1.0, for example, forces users running your project to provide the source code to the software they offer your program as a service - this is not typically required of open-source licensing. A license with those terms is considered source-available, but not open source in many eyes.

So far, open source is defined by obligations and permissions that travel downstream, so the choice of license is really a question about how you want to constrain the user's distribution.

If you must have changes returned to the community, or if you think companies will embed it, then you might lean towards copyleft licenses. If you don't need that requirement, or when you are using dependencies that force compatibility with an existing license, then permissive licensing might be enough.

Other questions matter too. Do you need an explicit patent grant with the copyright permission? Open source licenses such as Apache 2.0, GPL 3.0, and Eclipse 2.0 do include explicit patent grants.

Do you want to seek commercial revenue? Then you may want to dual license, with a codebase that can be open source or bought for exclusive or proprietary uses.

Do you have a reason that the dependency licenses force on you, or that your project's architecture requires, that means you must pick a compatible license? Most open source licenses are compatible, but there are some trouble-spots.

At each of these moments, you are answering questions about your project's goals, your community's needs, and your own business model. But ultimately, you are making choices that will determine which permissions and obligations travel downstream, and why.

It is this cascade of choices - shaped by legal requirements and open source norms, but ultimately inflected by your maintainer's choice - that determines the license, not any objective "best" choice. Nor is there a magical outcome of choosing a license from the library with the biggest maintainer-mandated attribution box check on GitHub.

The line they draw is:

Source-available licenses are better termed open core or reciprocity licenses, if they create restrictions beyond what the Open Source Definition allows. This license requires that any software, modified or not, that uses the program must also use this license.

Copyleft licenses use legal restrictions on the way the code is extended and shared. A well-known example is the GNU General Public License, GPL.

Permissive licenses impose fewer or no restrictions, and are sometimes called non-copyleft licenses.