Open source
Nothing sits behind an enterprise wall
LibreDB Studio is MIT because it has to go everywhere. What costs money is someone else running it for you — no capability moves across that line to create a reason to upgrade.
The licence
MIT, and what that lets you do
"Open source" is a word several products use for something narrower. This is the unmodified MIT licence over the whole application — so the questions below have short answers.
-
Run it commercially
Inside a company, for paying customers, on infrastructure you bill for. No seat count, no revenue ceiling, no separate commercial licence to buy.
-
Modify and fork it
Change any part of it and ship the result. You are not required to contribute the change back, and nothing in the licence reaches into the code you wrote around it.
-
Embed it in your product
The npm package exists for exactly this. Your product does not inherit the licence — MIT is not copyleft.
-
Redistribute it
Republish it, repackage it, resell it. Keep the copyright notice and the licence text with it; that is the whole obligation.
The one obligation runs the other way: keep the copyright notice and the licence text with any copy you distribute. There is no warranty — that is the other half of the MIT text, and it is the same half every MIT project ships. Read the licence ↗
The commercial line
What costs money is someone else running it
No capability is moved across the line to create a reason to upgrade. The comparison below is licence and feature scope only — the things a community edition elsewhere tends to withhold.
| Capability | LibreDB Studio | Typical community editions |
|---|---|---|
| OIDC single sign-on | in the MIT build | Enterprise, AWS only |
| ER diagrams | in the MIT build | PRO editions |
| AI assistant | in the MIT build | Enterprise |
| MongoDB and Redis | in the MIT build | absent from community driver sets |
License and feature scope only, each line with a primary source — the full table lives on the comparison page.
Contributing
Four ways in
The project takes issues, proposals and pull requests in the open. A code of conduct applies to all of them.
-
Report a bug
Open an issue with the version, the engine, the steps and what you expected instead. Reproduction beats description.
Open an issue ↗ -
Propose a feature
Describe the problem before the solution. A feature request that names the workflow it unblocks gets read differently from one that names a control.
Start a proposal ↗ -
Send a pull request
The contributing guide covers the development setup, the environment variables, the local database, the coding guidelines and the commit convention.
Read CONTRIBUTING ↗ -
Add a database provider
The provider interface is documented end to end, including what a provider must declare it cannot do — capability flags are how the honest-limits claim is kept.
Read the provider guide ↗
Security
Found a vulnerability? Do not open an issue.
Security reports go to the vendor by email, not through the public tracker, so a fix can ship before the details are public. The policy covers what to include, what to expect and the disclosure timeline.
Security updates are provided for the current minor line; older lines are not patched. The policy also documents the known security considerations and publishes a software bill of materials. Read the security policy ↗
The work is funded by the company that publishes it, and by sponsors. Sponsor the project ↗ · Star the repository ↗