Logiciels libres : modèles économiques, licences et brevets
Verdict : un logiciel libre peut être vendu, mais la valeur ne repose plus seulement sur le droit d’interdire la copie. Les revenus viennent souvent du support, de l’intégration, du développement sur mesure, de la certification, de l’hébergement ou d’une combinaison de licences. Le brevet, lui, ne protège pas le code comme tel : il peut concerner une invention technique mise en oeuvre avec un logiciel.
Sommaire
- Libre ne veut pas dire gratuit
- Cinq familles de revenus autour du code
- Le service devient souvent la valeur rare
- Une licence organise la circulation
- Brevets : code et invention ne se confondent pas
- Choisir un modèle sans mélanger les caisses
- Une combinaison peut être plus solide qu’un modèle unique
- Une archive remise en contexte
La distinction est utile avant de choisir une licence ou de financer un projet. Un logiciel peut être libre et payant, gratuit et non libre, ou libre avec un service facturé autour de lui. Le bon modèle dépend donc de ce qui est réellement livré : du code, une mise à jour, une compétence, une infrastructure ou une solution complète.
Mesure dans la source historique : le sommaire du dossier AFUL daté du 8 juin 2007 contient 5 familles et 14 sous-catégories. Le comptage porte sur les intitulés du sommaire, pas sur une estimation du marché. Le dossier complet est disponible en PDF AFUL sur les modèles économiques du logiciel libre, et sa présentation est conservée sur la page AFUL consacrée aux différents modèles économiques.
Libre ne veut pas dire gratuit
La liberté concerne les droits accordés à l’utilisateur. Le Projet GNU définit quatre libertés essentielles : exécuter le programme, étudier son fonctionnement, le modifier et redistribuer des copies ou des versions modifiées. Ces droits restent compatibles avec un prix de vente, une prestation de support ou une facturation de l’installation.
L’Open Source Definition de l’OSI va dans le même sens sur un point souvent oublié : la licence ne doit pas interdire la vente du logiciel ni son usage commercial. L’accès au code n’est donc pas le modèle économique. C’est le cadre dans lequel les utilisateurs peuvent recevoir, modifier et partager le logiciel.
Cinq familles de revenus autour du code
| Famille | Ce qui est facturé | Question à poser |
|---|---|---|
| Services récurrents | Support, mises à jour, documentation, abonnement ou garantie de service. | Le client paie-t-il une disponibilité et une compétence plutôt qu’une copie ? |
| Mutualisation | Développement financé par plusieurs clients ou par un écosystème qui partage le résultat. | Qui décide des priorités et qui reçoit les améliorations ? |
| Valeur ajoutée | Déploiement, formation, intégration, solution prête à l’emploi ou extension distincte. | La prestation reste-t-elle utile même si le code de base est téléchargeable ? |
| Licences | Licence multiple, droit d’intégration, ou licence différente pour un autre usage. | Quelles obligations s’appliquent à chaque distribution ? |
| Apports indirects | Mécénat, sponsoring, produits dérivés ou financement d’une communauté. | Le financement soutient-il la maintenance au lieu de payer seulement le lancement ? |
Ces familles ne s’excluent pas. Un projet peut publier son code sous licence libre, vendre une offre hébergée, proposer du support et recevoir des contributions. Le choix solide est celui qui rend visible la part financée et la part partagée.
Le service devient souvent la valeur rare
Quand le code peut être copié, la difficulté se déplace vers le temps et la responsabilité nécessaires pour le rendre utile. Installer une solution, migrer des données, former une équipe, corriger une panne ou maintenir une version compatible répond à un besoin que le téléchargement seul ne règle pas.
Le dossier AFUL de 2007 distingue notamment la souscription, le support, les prestations autour du logiciel et la certification de matériel. Cette lecture reste concrète : un client peut financer une réponse rapide, une intégration adaptée à son infrastructure ou la vérification d’un matériel, sans acheter un monopole sur chaque copie du programme.
Ce modèle exige toutefois une promesse précise. Un support payé doit définir son périmètre, une maintenance doit identifier les versions couvertes et une formation doit annoncer le niveau attendu. Le logiciel libre n’efface pas le coût du travail, il permet de séparer ce coût des droits de copie.
Une licence organise la circulation
Une licence libre ne dit pas seulement si le code peut être téléchargé. Elle règle la redistribution, les modifications, l’accès au code source et les mentions à conserver. L’OSI tient une liste des licences approuvées, tandis que le Projet GNU explique les effets du copyleft et la possibilité de vendre des copies d’un programme libre.
Une licence permissive laisse en général davantage de liberté pour combiner le code avec d’autres composants, sous réserve de ses conditions propres. Une licence copyleft impose des obligations de partage lorsqu’une version couverte est redistribuée dans les cas prévus par le texte de licence. Dans les deux cas, lire la licence exacte vaut mieux que résumer le projet par le seul mot libre.
La double licence peut séparer deux marchés : une version libre pour les usages compatibles avec la licence choisie, et une autre licence pour un besoin qui exige des conditions différentes. Ce montage n’est viable que si les droits sont détenus, les versions sont identifiées et les obligations de chaque licence sont compatibles avec la distribution prévue.
Brevets : code et invention ne se confondent pas
Le droit d’auteur protège l’expression du logiciel, notamment son code source. Le brevet répond à une autre question : une invention technique remplit-elle les conditions de protection dans le territoire concerné ? En France, l’INPI distingue le programme d’ordinateur pris isolément de l’invention technique qui inclut un logiciel.
En Europe, l’Office européen des brevets décrit l’effet technique supplémentaire qu’un programme d’ordinateur doit pouvoir produire, une fois mis en oeuvre, pour ne pas être exclu de la brevetabilité en tant que tel. L’invention doit aussi satisfaire les autres critères applicables. Le simple fait d’utiliser un ordinateur, de traiter une information ou de réduire un temps de calcul ne suffit pas automatiquement.
La même exigence de précision vaut pour les licences des images, vidéos et sons : séparez l’autorisation de l’auteur, l’usage prévu et les droits liés à ce qui est représenté.
Pour un projet libre, la question pratique n’est pas seulement : "le code est-il ouvert" ? Elle est aussi : qui détient les droits sur les contributions, quelles dépendances sont intégrées, quelles revendications de brevet touchent le procédé et dans quels pays une distribution est prévue ?
Choisir un modèle sans mélanger les caisses
- Décrire ce qui est vendu. Séparez la copie du logiciel, l’hébergement, le support, le développement spécifique et les données du client.
- Lire la licence choisie. Vérifiez les droits de modification et de redistribution, les mentions obligatoires et les conditions qui s’appliquent à un produit distribué.
- Financer la maintenance. Un don peut lancer un projet ; un contrat de support, une souscription ou une mutualisation peuvent financer la durée.
- Prévoir la sortie. Le client doit savoir récupérer ses données, identifier la version installée et continuer sans dépendance cachée à un prestataire.
- Isoler la question des brevets. Une invention technique et un code source ne se traitent pas avec le même outil juridique. Faites examiner le périmètre avant une distribution commerciale ou un dépôt.
Pour appliquer cette grille à un choix de logiciel, la page Choisir un logiciel selon le besoin, les formats et la sortie des données aide à vérifier les contraintes avant l’installation. Les autres guides de la section Logiciels utiles partent du même principe : décider à partir du résultat attendu, pas du prix affiché seul.
Une combinaison peut être plus solide qu’un modèle unique
Un projet qui dépend d’une seule source de revenus reste fragile, qu’il soit libre ou propriétaire. Le financement peut combiner contribution d’entreprises utilisatrices, prestations, hébergement, support et mécénat. La licence fixe les droits de circulation ; le contrat fixe le service attendu ; la communauté peut améliorer le code sans devenir automatiquement le financeur de chaque besoin particulier.
Le dossier AFUL historique montre cette combinaison avec les exemples de son époque. Les principes restent lisibles dans les libertés du logiciel, la définition de l’OSI et la distinction entre code et invention technique.
Une archive remise en contexte
L’ancienne URL correspondait à un article daté du 5 juin 2007, identifié par son titre et ses liens historiques. Cette reprise conserve la question sur l’économie du logiciel libre, ajoute les distinctions actuelles sur les licences et les brevets, et ne donne pas de nom d’auteur que les éléments disponibles ne permettent pas d’établir.
Pour un dépôt, une compatibilité de licence ou un litige de propriété intellectuelle, faites relire le cas par un professionnel compétent : les règles varient selon le texte de licence, le pays, les contributions et l’invention concernée.