Sign in Start for free
Continuous Integration

What is OSS? An easy-to-read guide for CI/CD teams to OSS

— Nesha Zoric

What is OSS? An easy-to-read guide for CI/CD teams to OSS

Short answer: OSS stands for open source software — software whose source code is published under a licence approved by the Open Source Initiative (OSI). The OSI definition requires that users can read, modify, and redistribute the code without paying for a seat. In 2026 the practical tiers are permissive (MIT, Apache 2.0, BSD), copyleft (GPL, AGPL), and source-available-but-not-OSS (BSL, Elastic Licence, SSPL). The distinction matters for CI/CD because many popular runners switched from OSS to source-available after 2022 — if your legal team cares about licence lineage, check.

OSS refers to open source software The term "open source" originated in the late 1990s. Most people reading this post were not born at that time. The term was coined by the Open Source Initiative (OSI) to distinguish source-available software from the dominant proprietary software model. By 2026, vendors are using the term loosely while lawyers are using it strictly. This guide explains the terminology and the difference between them.

The tooling landscape has changed significantly and this matters for CI/CD teams. Jenkins has always been open source software. The GitHub actions are not open-source software. The actions may/may not be open-source software. Buildkite is not open source but has an open source agent. The complexities of GitLab CE edition as OSS and EE edition as source-available. CircleCI is not open-source. The license terms for Ruby.ci are available on our pricing page. This post is for your procurement team, if they ever asked you: “is this open source?”.

The strict definition

The OSI holds the definitive definition. For software to be termed open source, its licence must meet ten criteria. The Three That Matter the Most

  • Free redistribution. You can give the software away or sell it, no royalty required.
  • Source code must be included. Not "available on request" — included.
  • Derived works must be allowed. You can modify the code and redistribute the modified version.

That would be false. Strict clauses like copyleft, patent grants, and trademark preservation are invariably added higher up by one licence. Each year, OSI website publishes a comprehensive list of accredited licenses that fulfill the ten criteria.

People often confuse "open source" with "free of charge". It absolutely does not Red Hat sells open-source software. A lot of Ruby gems are open-source software and have paid support contracts. OSS is about the license terms, not price.

OSS vs source-available vs proprietary

Three levels in 2026:

Open source (OSI-approved)

MIT, Apache 2.0, BSD, GPL, LGPL, AGPL, MPL. Corporate legal teams well-understand the terms of licenses; they’ve read them a thousand times. Feel free to access, edit, and share the code. There are restrictions (copyleft, patent conditions, etc.) and they are documented.

Source available

Licenses in the BSL category include the Business Source License, Elastic License 2.0, Server Side Public License, Community License, and BSL from MariaDB. The code is now made available. You can't sell this as a managed service to compete with us. As per the OSI definition, these licenses are NOT OSS. In the past ten years, we’ve seen companies move from OSS to source-available. During that time, many such as MongoDB (SSPL), Elastic (ELv2 and SSPL), HashiCorp Terraform (BSL), Redis (SSPL), and MariaDB (BSL on some products) have made this change. The reasons are commercial: they want to stop cloud providers’ reselling of software. Making sense of the world of today shows that “open source” does not mean “look at code and relax”. You must review the license details.

Proprietary

Normal commercial software. The software may be published but may not be published; whether or not it is published, you may not modify or redistribute it SaaS Offering: GitHub Actions, CircleCI, Buildkite, Datadog and PagerDuty.

Licence tiers that matter

If you have 10 minutes to spare, here are the 5 tiers to know of the licence landscape.

Tier Examples What you can do What you cannot
Permissive OSS MIT, Apache 2.0, BSD Anything — commercial use, modify, redistribute, embed in proprietary code Not much. Apache 2.0 requires preserving attribution.
Weak copyleft OSS LGPL, MPL Use in proprietary code if you keep the LGPL/MPL code as a separate linked module Modify the LGPL/MPL code and keep the modifications private
Strong copyleft OSS GPL v2, GPL v3 Use in your own code if your code is also GPL Combine GPL code with proprietary code and distribute
Network copyleft OSS AGPL Use GPL-style, plus must publish source if you offer the software over a network (SaaS) Run as SaaS with proprietary modifications
Source available BSL, ELv2, SSPL Read, run, modify for internal use Offer as a managed service, sell as a competing product

The main takeaway is that using a permissive licensed library is fine by your legal team. If you pay for a binary that uses the GPL, you get nothing. It's a discussion if you statically link a GPL-licensed library into your proprietary code. Running an AGPL-licensed library as a SaaS creates complexity. A bigger discussion. If you sell a BSL-licensed CI runner, you are breaking the law!

Refer to GitLab vs GitHub for a comparison of the two platforms.

Why engineers care in a CI context

Three motivations.

1. You might be shipping OSS without realising

The gems listed in your Gemfile are open-source software. The npm packages mentioned in package-lock.json are Open Source Software. Your Dockerfile’s base image is likely open-source software. In case an SBOM (software bill of materials) is requested by your SOC 2 auditor, you’ll want to know what licenses are in your dependency tree. You can generate that list with a tool like cyclonedx, syft, or GitHub's dependency graph. It is your responsibility to check the list and understand your license compatibility.

2. Your CI tool choice has licence implications

If you run your Jenkins self-hosted (MIT/Apache mix across the project), the licence is a non-issue ship whatever you want. Self-hosting GitLab CE (open source under MIT, with some AGPL) allows you to do anything you want. When you self-host GitLab EE, you acknowledge GitLab’s commercial terms, not OSS. When self-hosting a BSL licenced piece of software, please read the BSL carefully most BSLs allow internal use forever but prohibit you from reselling the software or offering a managed service to third-parties.

For a longer comparison, see our articles here.

3. OSS tooling has lineage you should track

A project that used to be OSS five years ago may now be source-available. The canonical example is Redis, which was MIT-licensed from 2009 to 2024, but then switched to a dual-licence with SSPL / RSAL. Your paragraph must be updated in the 2026 architecture document if your 2022 architecture document claims “we use Redis because it is MIT.” The lineage of the codebase is crucial because a licence change will not apply retroactively. As such, the code versions that were released under the old licence stay under the old licence. However, all your upgrades will come under the new terms.

Picking an OSS CI tool in 2026

The practical choice criteria, in order.

  1. Licence that your legal team accepts. For most teams, that is any OSI-approved licence. For regulated teams, it is a specific list.
  2. Active maintenance. OSS projects go dormant. Check the commit cadence, issue response times, and release history before you adopt.
  3. A supported commercial path. If the project has no commercial sponsor, you are on your own when a critical bug appears at 2am. A sponsor is not required but helps.
  4. Compatibility with your runtime. The OSS runner that only ships Linux containers is not useful if your builds need Windows runners.
  5. Pipeline portability. If you want to leave later, how much of the pipeline file is portable? Jenkinsfile (Groovy) is tool-specific. .github/workflows/*.yml is tool-specific. GitLab CI YAML is tool-specific. There is no cross-vendor "pipeline standard"; everyone claims one, nobody has one.

Refer to ci cd tools for devops for a more detailed explanation of comparison axes.

OSS vs free tier — a common conflation

CI providers who host offer free usage. "Free" does not mean "open source". The software is proprietary; the GitHub Actions free tier is a billing thing. It's Microsoft's code that runs whenever you push a commit. You do not get to look at it.

The free tier changes make a difference. In 2023, GitHub made the free-tier limits for public repositories stricter. If your design depended on certain tiers, you would need to redesign it. If you were using an OSS runner, then you were in charge of your compute. Lock-in area is distinct.

A short glossary

  • OSS — open source software, by the OSI definition.
  • OSI — Open Source Initiative, maintains the canonical OSS definition.
  • FOSS — free and open source software. Interchangeable with OSS in casual use.
  • FLOSS — free, libre, and open source software. The Richard Stallman-correct variant.
  • Copyleft — a licence that requires derivative works to use the same licence.
  • Permissive — a licence that allows derivative works to use any licence.
  • Source available — code is published but the licence does not meet OSS criteria.
  • BSL — Business Source Licence. The commonest source-available licence in 2026.

Frequently asked

What does OSS mean?

OSS (Open Source Software) is software whose source code is published under an Open Source Initiative (OSI) approved licence. The license must enable users to access, modify, and share the code.

Is open source the same as free of charge?

Certainly, it is not "Open source" rather it is about license terms not price. Red Hat markets open-source software. Many open source software projects have paid support contracts. Cost and licensing are two different axes.

What is source available software?

Software is source code made public, but whose terms and conditions do not satisfy the OSI's licensing criteria. The BSL, ELv2 and SSPL are common source-available licences. Managed service of the software is usually restricted by these.

What are the most common OSS licences?

MIT, Apache 2.0, BSD, GPL (v2 and v3), LGPL, AGPL and MPL. Apache 2.0 and MIT licenses are the most permissive. GPL and AGPL have strong copyleft. For the complete list, visit the OSI website.

Can I use OSS in commercial software?

Typically, yes, according to the terms of the license. Permissive licenses (such as MIT, Apache 2.0) are those that allow practically anything. Commons licences (CC) do not have this; you can freely combine them with proprietary code. Consult your legal unit or read the license.

Is Jenkins open source?

Certainly. Plugins are licensed under Apache 2.0; Jenkins itself is MIT licensed. Jenkins does not have any licensing restrictions for self-hosting.

Is GitHub Actions open source?

No_CONTEXT The GitHub Actions SaaS is not open. Each action in the registry has slightly different licensing terms – some are Open Source, some not. If you self-host, the runner software itself (actions/runner) is MIT licensed.

What is the Business Source Licence?

The BSL is a source-available license formulated by MariaDB in 2017. The nature of code published under the BSL is such that while the code is readable and runnable for internal use, there are restrictions on commercial use (typically you cannot ‘open it’ or offer it as a managed service to any third party). After a certain time period (usually four years), the code changes to a given OSS licence.

Still stuck

If your CI stack is 100% OSS (Jenkins, self-hosted GitLab CE, self-hosted runners for GitHub Actions), your licence surface is clean. Carry on.

Ruby.ci publishes its licence terms on the pricing page should your legal team care about the licence lineage as you assess self-hosted CI. We utilize OSS for the runner components, while the control plane is subject to commercial terms. We have a ready one-pager. If your procurement team wants a summary of the licence, mention it when you book a benchmark call.