À RETENIR
- Pour un jeu commercial fermé, gardez votre code propriétaire et vérifiez chaque bibliothèque utilisée.
- La licence MIT est permissive pour le code, tandis que la GPL impose généralement de partager les modifications.
- Les licences Creative Commons conviennent surtout aux graphismes, musiques et textes, pas au code logiciel.
- Un fichier LICENSE ne transfère pas les droits que vous ne détenez pas déjà.
La variable qui change tout reste votre objectif : vendre un jeu fermé, publier le code ou autoriser les réutilisations communautaires.
De quelle licence votre jeu vidéo indépendant a-t-il besoin ?
Votre jeu a besoin de plusieurs autorisations, car son code, ses images, sa musique et ses données peuvent appartenir à des personnes différentes. Choisir une licence de jeu vidéo consiste donc à organiser ces droits plutôt qu’à sélectionner un seul modèle pour l’ensemble du projet.
Licencier son jeu ou encadrer les éléments utilisés
Une licence indique ce que les autres peuvent faire avec une création : l’exécuter, la copier, la modifier ou la redistribuer. Vous pouvez concéder ces droits aux joueurs tout en conservant la propriété intellectuelle de vos créations.
Si vous publiez sur Steam, itch.io ou une autre boutique, la licence du jeu ne remplace pas les conditions de vente de la plateforme. Elle doit rester compatible avec votre modèle économique et avec les contrats signés par les collaborateurs.
Distinguer le code, les graphismes, la musique et les données
Le code source décrit le fonctionnement du jeu, tandis que les assets regroupent les éléments visuels et sonores. Les scénarios, dialogues, polices, modèles 3D et bases de données peuvent obéir à des règles encore différentes.
Un jeu peut donc combiner un code sous licence MIT, une musique sous licence commerciale et des illustrations dont vous détenez les droits. Cette combinaison doit être documentée dans un tableau interne avant la distribution.
Copyright, droit d’auteur et licence d’utilisation : quelles différences ?
Le droit d’auteur, appelé copyright dans certains pays, désigne les droits attachés à une œuvre. La licence est l’autorisation accordée à d’autres personnes pour utiliser cette œuvre selon des conditions précises.
En France, la protection du droit d’auteur naît en principe de la création originale, sans que le dépôt soit une condition générale. La licence écrite reste utile pour prouver les autorisations accordées et éviter les désaccords entre associés.
Quelles licences libres conviennent au code du jeu ?
| Licence | Usage commercial | Redistribution | Point de vigilance |
|---|---|---|---|
| MIT | Oui | Code source non imposé | Conserver la notice |
| Apache 2.0 | Oui | Code source non imposé | Notices et brevets |
| GPL | Oui | Modifications à partager sous GPL | Effet copyleft |
| AGPL | Oui | Partage renforcé pour les services réseau | Serveur accessible en ligne |
| LGPL | Oui | Partage ciblé de la bibliothèque | Intégration à vérifier |
MIT : simple et permissive
La licence MIT autorise l’utilisation, la modification et la redistribution du code, y compris dans un jeu commercial fermé. Vous devez conserver le texte de la licence et la mention de copyright dans les redistributions concernées.
Elle convient à une petite bibliothèque ou à un outil que vous voulez intégrer sans ouvrir votre propre code. Sa simplicité facilite la lecture des dépendances, mais elle ne fournit pas de garantie particulière sur les brevets.
Apache 2.0 : permissive avec protection des brevets
Apache 2.0 autorise aussi les usages commerciaux et les modifications, avec des obligations de notices plus détaillées. Elle contient en outre une clause de licence de brevets accordée par les contributeurs, sous certaines conditions.
Elle est adaptée à un projet technique qui réutilise des composants distribués par plusieurs développeurs. Vérifiez les fichiers NOTICE et les changements apportés au code avant de publier une version modifiée.
GPL et AGPL : obligation de partager les modifications
La GPL, ou General Public License, permet de vendre un logiciel, mais les versions redistribuées qui relèvent de ses conditions doivent rester accessibles sous GPL avec leur code source correspondant. L’AGPL étend cette logique à certains logiciels utilisés via un réseau.
Ces licences peuvent convenir à un moteur ou à un jeu ouvert, mais elles demandent une analyse attentive de la liaison entre votre code et la bibliothèque. La page de référence de tads.org illustre cette nécessité de distinguer les fichiers du système TADS, le code du jeu et les conditions de redistribution.
LGPL : une solution intermédiaire pour les bibliothèques
La LGPL vise les bibliothèques que l’on souhaite lier à un programme sans imposer automatiquement la même licence à tout le programme. Les modifications apportées à la bibliothèque elle-même restent soumises à ses obligations.
La frontière entre liaison, modification et intégration varie selon la version et la méthode technique. Conservez la licence, fournissez les informations nécessaires et demandez un avis juridique si votre moteur utilise plusieurs composants copyleft.
Quelles licences Creative Commons choisir pour les assets et contenus ?
| Licence | Commercial | Modification | Condition principale |
|---|---|---|---|
| CC0 | Oui | Oui | Aucune attribution obligatoire |
| CC BY | Oui | Oui | Crédit à l’auteur |
| CC BY-SA | Oui | Oui | Partage sous la même licence |
| CC BY-NC | Non pour un usage commercial | Oui | Usage non commercial |
| CC BY-ND | Oui | Non si adapté | Pas de modification |
CC0 : renoncer dans la mesure du possible à ses droits
CC0 permet à l’auteur de renoncer autant que le droit applicable l’autorise à ses droits exclusifs. Vous pouvez généralement intégrer l’asset dans un jeu commercial et le modifier, tout en gardant une trace de sa provenance.
Cette licence ne garantit pas l’absence de droits de marque, de droits à l’image ou de droits sur des éléments représentés. Une texture CC0 montrant un logo identifiable n’autorise pas forcément l’usage de ce logo.
CC BY : autoriser sous condition d’attribution
CC BY autorise la copie, la modification et l’utilisation commerciale, à condition de créditer l’auteur et de signaler les modifications de manière raisonnable. Dans un jeu, le crédit peut apparaître dans les mentions légales, les crédits ou un fichier NOTICE.
Le site officiel de Creative Commons recommande de communiquer le nom de l’auteur, le lien vers la licence et la source lorsque ces informations sont disponibles. Ne supprimez pas ces données d’un asset téléchargé sous CC BY.
CC BY-SA : imposer le partage à l’identique
CC BY-SA autorise l’usage commercial, mais une adaptation doit être partagée sous la même licence ou sous une licence compatible prévue par ses conditions. Cette règle peut entrer en conflit avec un jeu dont les assets et le code restent entièrement fermés.
Elle fonctionne mieux pour une création destinée à être reprise par une communauté. Documentez précisément ce qui constitue l’adaptation, car l’intégration d’une image dans une scène ne produit pas toujours la même analyse qu’une modification de l’image.
Quelles licences Creative Commons éviter pour un jeu commercial ?
Évitez les licences contenant NC, pour Non Commercial, si vous vendez le jeu, affichez des publicités ou l’intégrez à une activité professionnelle. Les licences contenant ND, pour NoDerivatives, interdisent les adaptations et rendent risquée la modification d’un asset.
Creative Commons déconseille aussi d’appliquer ses licences aux logiciels. Pour le code, utilisez plutôt une licence conçue pour les programmes, puis choisissez séparément une licence adaptée aux contenus créatifs.
Comment choisir une licence de jeu vidéo pour son code source ?
- Garder le code propriétaire si votre priorité est de contrôler la distribution et les modifications.
- Publier le code sous licence libre si vous voulez favoriser l’audit, les contributions et la réutilisation.
- Combiner code propriétaire et bibliothèques open source si votre jeu dépend de composants tiers, en respectant leurs obligations.
Garder le code propriétaire
Une licence propriétaire peut autoriser les joueurs à installer et exécuter le jeu sans leur donner le droit de copier ou modifier le code. Elle doit préciser les usages permis, les restrictions et les limites de garantie.
Cette solution protège mieux votre avantage technique, mais elle n’empêche pas la rétro-ingénierie dans tous les territoires. Les droits accordés doivent aussi respecter les exceptions prévues par le droit applicable.
Publier le code sous licence libre
Une licence libre donne des permissions vérifiables au lieu de demander une autorisation au cas par cas. Vous pouvez publier le jeu gratuitement tout en vendant des versions compilées, du support ou du contenu additionnel.
Pour un projet de fiction interactive, un moteur libre et des scripts ouverts facilitent les corrections par la communauté. Des outils comme le tutoriel français d’Inform 7 montrent aussi la différence entre l’outil d’auteur et l’œuvre produite avec cet outil.
Combiner code propriétaire et bibliothèques open source
Vous pouvez garder votre code fermé tout en utilisant des bibliothèques MIT, Apache 2.0 ou parfois LGPL. L’autorisation dépend toutefois de la façon dont chaque composant est lié, modifié ou redistribué.
Générez la liste des dépendances à chaque version et conservez les textes LICENSE correspondants. Un gestionnaire de paquets ne remplace pas cette vérification juridique.
Comment protéger les graphismes, musiques et scénarios ?
Conserver les droits sur ses créations
Conservez les fichiers de travail, les dates de création et les contrats qui identifient les auteurs. Pour un studio, une cession écrite doit préciser les supports, la durée, le territoire et les usages prévus.
Les crédits ne remplacent pas une cession de droits. Ils reconnaissent l’auteur, mais ne vous donnent pas automatiquement l’autorisation de vendre ou modifier son œuvre.
Utiliser des assets sous licence commerciale
Un asset vendu comme utilisable commercialement peut limiter le nombre de projets, la redistribution du fichier source ou l’usage dans des modèles génératifs. Lisez la licence attachée au produit, pas seulement la description de la boutique.
Archivez la facture, la version des conditions et la page du produit au moment de l’achat. Cette trace vous aidera si la licence change après la livraison.
Vérifier les droits des freelances et des collaborateurs
Demandez à chaque intervenant une liste des éléments tiers intégrés à son travail. Le contrat doit distinguer ses créations originales, les ressources préexistantes et les composants soumis à une licence externe.
Cette vérification concerne aussi les musiciens, traducteurs, comédiens et testeurs qui fournissent des textes, voix ou captures utilisées dans la communication du jeu.
Gérer les œuvres générées ou assistées par IA
Un outil d’intelligence artificielle ne vous garantit pas automatiquement une exclusivité ou une absence de contenu litigieux. Vérifiez ses conditions commerciales, la provenance des données annoncée et les règles applicables dans votre territoire avant de distribuer l’élément.
Conservez les prompts, les versions intermédiaires et les retouches humaines. Pour les personnages, logos et visages, une validation humaine et contractuelle réduit les risques qui ne relèvent pas seulement du copyright.
Quels points vérifier avant d’utiliser une licence open source ?
- Autorisation d’usage commercial : repérez les clauses NC et les restrictions de vente.
- Attribution et mentions légales : notez les crédits, notices et liens exigés.
- Redistribution du code source : identifiez les obligations GPL, AGPL ou LGPL.
- Compatibilité entre licences : vérifiez les combinaisons avant de compiler la version finale.
- Marques et personnages : une licence de code ou d’image ne couvre pas automatiquement ces droits.
Quand l’autorisation d’usage commercial est-elle acquise ?
Elle l’est lorsque le texte de la licence autorise clairement l’usage commercial, sans clause contradictoire dans les conditions du fournisseur. Le mot gratuit décrit un prix, pas l’étendue des droits.
Quelle attribution faut-il afficher ?
Reproduisez le nom de l’auteur, le nom de l’œuvre, la licence et l’URL demandée. Placez ces éléments dans les crédits du jeu et dans un fichier NOTICE si l’interface ne permet pas une attribution lisible.
Quand faut-il redistribuer le code source ?
Cette obligation dépend de la licence et de la forme de redistribution. Avec une licence copyleft, préparez le code source correspondant, les scripts de construction et le texte de licence lorsque les conditions l’exigent.
Pourquoi vérifier les marques et personnages ?
Une image libre peut représenter un personnage protégé ou une marque identifiable. La licence de l’image ne transforme pas ces éléments en créations libres d’utilisation.
Quelle licence choisir selon son objectif ?
| Objectif | Code | Assets | Vigilance |
|---|---|---|---|
| Jeu fermé commercial | Propriétaire, MIT ou Apache | Droits détenus ou commercial | NOTICE et dépendances |
| Jeu open source | GPL, MIT ou Apache | CC BY, CC0 ou équivalent | Compatibilité globale |
| Projet communautaire | GPL ou AGPL | CC BY-SA | Contributions et copyleft |
| Prototype ou mod | Selon le moteur | Assets autorisés | Droits du jeu d’origine |
Commercialiser un jeu fermé
Choisissez généralement une licence propriétaire pour votre code et des licences permissives pour les composants tiers. Cette architecture limite les obligations de publication, sans supprimer les obligations d’attribution.
Développer un jeu open source
La MIT ou Apache 2.0 favorise la réutilisation, tandis que la GPL demande que certaines redistributions restent ouvertes. Choisissez selon le niveau de contrôle que vous voulez conserver sur les versions dérivées.
Créer un projet communautaire ou éducatif
Une combinaison GPL pour le code et CC BY-SA pour les contenus encourage les contributions réciproques. Elle demande une organisation claire des apports, des crédits et des versions publiées.
Publier un prototype, un mod ou un jeu avec des assets tiers
Commencez par vérifier la licence du jeu ou du moteur d’origine, car un mod ne peut pas accorder plus de droits que son auteur n’en possède. Pour un prototype public, retirez les assets dont l’autorisation reste incertaine.
Comment rédiger la licence de son jeu indépendant ?
Définir ce que les joueurs peuvent faire
Indiquez si les joueurs peuvent installer, sauvegarder, diffuser des vidéos, modifier les fichiers ou créer des extensions. Séparez les permissions accordées au jeu compilé de celles accordées au code source.
Encadrer la copie, la modification et la redistribution
Précisez les conditions de copie, les crédits requis et la possibilité de vendre une version modifiée. Une formulation courte et cohérente vaut mieux qu’une interdiction générale qui contredit les permissions accordées.
Séparer la licence du jeu, les conditions d’utilisation et la politique de confidentialité
La licence traite des droits sur le logiciel et les contenus. Les conditions d’utilisation encadrent le service, les comptes et le comportement des joueurs, tandis que la politique de confidentialité explique le traitement des données personnelles.
Ajouter les fichiers LICENSE et NOTICE
Placez LICENSE à la racine du dépôt et dans le paquet distribué lorsque c’est pertinent. Utilisez NOTICE pour regrouper les crédits, licences tierces, auteurs et liens, puis affichez un accès lisible depuis le jeu.
Quelles erreurs éviter avant la sortie du jeu ?
- Mélanger des contenus incompatibles sans analyser les obligations de chaque licence.
- Croire qu’un contenu gratuit est libre de droits parce qu’il est téléchargeable.
- Oublier les attributions exigées par CC BY, Apache 2.0 ou certains fournisseurs.
- Distribuer du code sans vérifier ses dépendances et leurs versions exactes.
- Utiliser une marque ou une musique sans autorisation écrite et adaptée au jeu.
Pourquoi les licences incompatibles bloquent-elles une sortie ?
Une licence peut imposer des conditions que votre licence propriétaire ne permet pas de respecter. Le problème apparaît souvent au moment de la redistribution, après plusieurs mois de développement.
Pourquoi un contenu gratuit n’est-il pas forcément réutilisable ?
Un créateur peut offrir un fichier pour un usage personnel tout en interdisant la vente, la modification ou la redistribution. Lisez la licence attachée à l’œuvre et gardez une preuve de l’autorisation.
Quelle méthode rapide pour choisir la bonne licence ?
- Identifier les ayants droit de chaque fichier, y compris les contributions externes.
- Recenser les obligations dans un tableau avec la licence, l’auteur et les usages permis.
- Tester la compatibilité avec la vente, le téléchargement et le partage du jeu.
- Faire relire les conditions par un professionnel du droit si le projet est commercial ou collaboratif.
Comment identifier les ayants droit de chaque élément ?
Faites l’inventaire du dépôt, des dossiers d’assets, des polices, des sons et des services utilisés. Pour chaque élément, notez l’auteur, la source, la version de licence et la preuve d’acquisition.
Comment recenser les obligations dans un tableau ?
Ajoutez des colonnes pour l’usage commercial, la modification, l’attribution, la redistribution du code et les restrictions de marque. Une ligne par dépendance rend l’audit de la version finale beaucoup plus rapide.
Comment tester la compatibilité avec le modèle économique ?
Simulez la vente d’une copie, la publication d’un patch et la distribution d’une version modifiée. Si une licence impose une publication incompatible avec votre stratégie, remplacez le composant ou adaptez le modèle.
Quand demander l’avis d’un professionnel du droit ?
Demandez une relecture avant la sortie si plusieurs studios contribuent, si le jeu collecte des données, si vous utilisez des contenus générés par IA ou si une licence copyleft touche votre architecture. Cette dépense est plus facile à maîtriser avant la commercialisation qu’après un retrait.
Quelles sont les questions fréquentes sur les licences de jeux vidéo ?
Peut-on vendre un jeu utilisant des logiciels open source ?
Oui, une grande partie des licences open source autorise la vente. Vous devez respecter les obligations propres à chaque composant, notamment les notices, l’attribution et, pour certaines licences, la mise à disposition du code source.
Peut-on modifier un jeu sous licence Creative Commons ?
Oui si la licence autorise les adaptations, comme CC0, CC BY ou CC BY-SA. Une licence ND interdit en revanche les œuvres dérivées, tandis qu’une licence NC exclut l’usage commercial.
Peut-on changer la licence d’un jeu déjà publié ?
Vous pouvez changer la licence de vos propres contributions pour les versions futures. Vous ne pouvez pas retirer rétroactivement les droits déjà accordés, ni relicencier les contributions d’autrui sans leur autorisation.
Faut-il déposer son jeu ou enregistrer son copyright ?
Un dépôt n’est généralement pas nécessaire pour que le droit d’auteur existe, mais une preuve datée peut aider à établir la création et la chaîne des droits. Conservez les fichiers sources, contrats, historiques de versions et documents de production dans un espace sécurisé.
