Le modèle open-core de QoreDB : ce qui est libre, ce qui ne l'est pas

Quand on développe un outil en solo, la question du modèle économique se pose assez vite. QoreDB a démarré comme un projet open source pur. Après quelques mois de développement intensif et une V1 publique, j'ai choisi de passer sur un modèle open-core : une partie du code reste sous Apache 2.0, une partie passe sous BUSL-1.1. Voici ce que ça signifie concrètement, et pourquoi ce choix.

Open-core, pas freemium

L'open-core n'est pas du freemium avec du code en moins. C'est un modèle où le cœur du produit est libre, open source, modifiable, distribuable. Les features avancées, power-user ou typiquement réservées aux équipes, sont commerciales. La distinction est technique et contractuelle - pas juste une limite arbitraire pour forcer une mise à niveau.

Pour QoreDB, la ligne de partage est claire : tout ce qui touche aux fondations (drivers, éditeur SQL, DataGrid, vault, protections de production) est Core. Les outils d'analyse et de comparaison avancés, les exports spécialisés et l'IA passent en Pro.

Le périmètre Core (Apache 2.0)

Le Core couvre tout ce dont un développeur a besoin au quotidien. Les drivers natifs pour PostgreSQL, MySQL, MongoDB, SQLite, Redis, DuckDB, SQL Server et CockroachDB sont tous open source. L'éditeur SQL avec autocomplétion schema-aware, le DataGrid avec virtualisation et édition inline, les transactions, les tunnels SSH, le vault chiffré Argon2, les protections de production (blocage des mutations, détection des requêtes destructrices), la fédération inter-bases via DuckDB, la bibliothèque de requêtes, l'export CSV/JSON/SQL/HTML - tout ça est sous Apache 2.0.

Apache 2.0 signifie : libre de lire, modifier, distribuer, utiliser commercialement, sans condition autre que la mention de la licence d'origine. Aucune restriction d'usage n'est attachée à ces composants.

Le périmètre Premium (BUSL-1.1)

Les features Pro vont au-delà de l'usage quotidien standard. Le Sandbox Mode (tester des modifications sans toucher la base, générer des migrations), le Visual Data Diff (comparer deux résultats côte à côte), le diagramme ER interactif, l'audit log avancé et le profiling de requêtes, les exports XLSX et Parquet, les custom safety rules, et l'assistant IA BYOK (avec clé API personnelle, sans backend QoreDB) - ces composants sont sous Business Source License 1.1.

La principale différence avec Apache 2.0 : une restriction d'usage commercial sans licence achetée. La BUSL inclut une clause de conversion automatique : après 3 à 4 ans, le code passe en Apache 2.0. C'est une licence temporairement restrictive, pas propriétaire indéfiniment. Tout le code Pro sera donc un jour entièrement libre.

Le mécanisme technique du split

Chaque fichier source porte un header SPDX. Les fichiers Core commencent par // SPDX-License-Identifier: Apache-2.0, les fichiers Premium par // SPDX-License-Identifier: BUSL-1.1. Ce n'est pas qu'une déclaration - ça sert à l'outillage de compliance licence et rend l'audit du périmètre trivial.

Côté Rust, les features premium sont gérées via les feature flags Cargo (pro, team, enterprise). Le binaire distribué publiquement est compilé sans ces flags. Le code premium n'est physiquement pas présent dans le build Core - pas juste désactivé, absent. Côté frontend, les composants premium sont wrappés avec un composant LicenseGate qui vérifie le tier de licence au moment du rendu.

La vérification de licence est entièrement offline : une clé Ed25519 signée côté serveur, vérifiée localement avec la clé publique embarquée dans le binaire. Aucune requête réseau au démarrage, aucun serveur de validation à contacter. C'est cohérent avec la philosophie local-first de QoreDB : l'application fonctionne sans connectivité, y compris pour la vérification de droits.

Ce qui ne changera jamais

Une règle s'applique sans exception : aucune feature déjà distribuée gratuitement ne sera jamais reclassée en Premium. Le split a été défini avant la V1 stable publique, et ce qu'Apache 2.0 couvre aujourd'hui restera Apache 2.0. L'open-core ne fonctionne que si les utilisateurs peuvent lui faire confiance sur la durée.

Le modèle open-core de QoreDB répond à un besoin simple : permettre à un projet solo de durer. Le Core reste entier, distribué librement, jamais rogné. Les features Pro financent le développement continu. La ligne de partage est documentée dans le code, auditable par n'importe qui, et la conversion BUSL vers Apache 2.0 est contractuellement garantie. C'est un modèle qui tente d'être honnête avec ses utilisateurs et viable pour son créateur.