Open Source

What does open source mean for AI tools?

Open-source software publishes source code under a license that allows inspection, modification, and (usually) redistribution. For AI tools that means you can read how prompts, logs, and credentials are handled, change the product to fit your stack, and run it without waiting on a vendor’s cloud region.

Open source is not the same as free-as-in-beer, and it is not the same as self-hosted. A project can be Apache-licensed and still push you toward a paid hosted control plane. A proprietary appliance can be self-hosted with a license key. Read the license file and the default telemetry path, not the marketing word “open.”

Why AI teams care

Auditability. Engineers can see the code that touches customer conversations. That matters in healthcare, finance, and legal work where you must explain data handling.

Customization. Closed products limit what you can patch. Open tools let you change auth, retention, model routing, and integrations on your calendar.

No single-vendor kill switch. Proprietary APIs get deprecated. You can pin a git tag, fork, or keep running an old release when a SaaS SKU disappears.

Community speed. Active projects often get security fixes and adapters (LangChain, Kubernetes charts) faster than a closed roadmap admits in public.

Licenses you will actually meet

• MIT — Very permissive. Keep the copyright notice. Commercial use is normal.
• Apache 2.0 — Permissive plus an express patent grant. Common in enterprise-friendly AI infrastructure.
• GPL v3 — Copyleft: distributing a modified binary generally means sharing corresponding source under GPL.
• AGPL v3 — Copyleft that also reaches many network/SaaS deployments. Legal review before you wrap it in an internal product.
• Source-available / BSL / proprietary + “open core” — You can read some code; you may not have the rights you think you have. Treat these as not OSI-open until counsel agrees.

How to evaluate an open-source AI tool

1. License compatibility with how you ship (internal use vs SaaS vs on-prem appliance).
2. Who can merge: a company, a foundation, or a single maintainer with no backup.
3. Release cadence, signed artifacts, and a security contact.
4. Docs for production: Compose/Helm, backups, upgrades, and what phones home.
5. Whether “open” includes the training data, the eval sets, the agent runtime, or only a thin client.
6. Dual licensing: which features sit behind a commercial SKU.

Risks

Unmaintained repos rot. AGPL inside a productized service can force source disclosure you did not budget for. “Open weights” are not the same as an open application. Crash reports and license checks can still exfiltrate traces. Forks without a maintainer plan become your on-call.

Frequently asked questions

If it is on GitHub, is it open source?

Only if the repository has a recognized open-source license and you are using the licensed files. A public repo with “all rights reserved” is not open source.

Can we use Apache 2.0 code in a commercial product?

Usually yes, including closed-source products, as long as you meet notice and NOTICE-file conditions. Confirm with counsel for patent and trademark issues.

Does open source mean we must publish our modifications?

Not under MIT or Apache 2.0 for typical internal or SaaS use. GPL/AGPL are different. Get a license read before you redistribute or offer a network service.

Is open source automatically safer?

No. Visibility helps if someone is reading and patching. An abandoned public repo can be worse than a vendor with a security SLA.

How does this relate to self-hosting?

Open source makes self-hosting possible. It does not operate the cluster for you. See the Self-Hosted tag for deployment and compliance questions.