Pareil pour une image (type logo, affiche ou autre dessin réalisé avec un éditeur d'image), il faut non seulement l'image sans perte, mais aussi les différents calques pour la même raison.
Ben justement, comment tu définis la source quand il n'y a pas ça ? Par exemple :
Je fais une image très complexe en n'utilisant qu'un seul calque au lieu de plusieurs -> on ne peut pas décomposer l'image
je dessine sur papier, ensuite je scanne, au lieu de dessiner avec inkscape sur tablette graphique -> on n'a pas accès à l'historique de mes coups de crayon
j'utilise inkscape mais je dessine un truc en ne levant le crayon qu'une ou deux fois alors que je pourrais l'avoir fait en levant le crayon bien plus souvent -> difficile de décomposer le dessin
je prends une photo d'un tableau
etc.
Je pense que pour l'art il n'y a pas de définition universelle d'une source et il ne peut pas y en avoir. C'est donc à chaque projet de définir clairement ce qu'est une source, et de s'y tenir (de n'accepter que des fichiers qui ont une source correspondant à la définition donnée). Évidemment si la définition de "source" est faible (ex: fichiers flac pour la musique, png lossless pour une image) on aura l'avantage de pouvoir piocher dans une grande quantité de fichiers, au détriment de peu de liberté, si la définition de source est moyenne (ex: pistes séparées/fichier tracker pour de la musique, calques/fichier xcf pour une image) ou forte (ex: partition/fichier midi pour musique, fichier de travail inkscape pour l'image) on aura plus de liberté, mais une quantité de fichiers plus restreinte à notre disposition. Les projets "de base" (ex: jeux) auraient une définition de source "forte" afin de maximiser la liberté des utilisateurs, et les projets de projets (ex: distros) auraient une définition de source "faible" pour accepter le plus de projets possibles.
Après je pense que le fichier lossless est la limite basse à ne pas dépasser dans la définition d'une source, en tout cas pour la musique et les graphismes. Il existe peut-être des types de données où il est impossible d'obtenir un fichier lossless, mais dans l'ensemble ça me semble être LE critère indiscutable pour les sources artistiques.
Xonotic est un bon exemple pour ça. Ils ont une licence et une seule, quelqu’un se pointe sur le forum, montre une musique qu’il a composé en pensant à Xonotic, un développeur se pointe et dit « woaw, c’est cool, si tu la mets en GPLv2 on peut l’intégrer », le musicien répond « sérieux, ma musique dans Xonotic ? ok pour la licence alors ! ». Voilà, c’est fait.
Je pense que c'est quand même important de prévoir l'intégration au jeu (et donc la liberté) en amont du travail à réaliser. Par exemple dans les musiques de Xonotic, si on considère que les fichiers lossless sont les sources, tu as des musiques dont les sources sont dispo (celles qui ont été réalisées pour être intégrées au jeu, par exemple via un concours) et des musiques sans sources (celles qui ont été ajoutées après avoir été découvertes, ou celles qui sont issues de nexuiz).
Après on peut aussi prévoir la liberté sans forcément prévoir l'intégration au jeu, par exemple avec des plateformes comme opengameart dans lesquelles les développeurs de jeux libres peuvent piocher (malheureusement en réalité il n'est pas nécessaire de publier les sources sur OGA, mais c'est pour l'exemple).
Unvanquished est libre si au moins une seule carte est libre, les textures qu’utilise cette carte sont libres et que tous les sons et les modèles sont libres.
J'espère au moins que les objectifs du projet contiennent "fournir un set de maps conséquent". C'est l'une des raisons principales pour lesquelles Xonotic n'est pas une 1.0 : les devs considèrent que le nombre maps est trop faible pour que Xonotic soit un jeu complet. Il existe certes un nombre incalculable de maps non-officielles (plusieurs centaines je crois) mais celles-ci ne sont pas intégrées au jeu, soit parce que non-libres, soit parce que la qualité n'est pas suffisante.
Je dis ça parce qu'il y a une vraie différence entre Xonotic/Nexuiz/OA avec leurs centaines de maps non-libres, mais avec lesquels on peut déjà s'amuser pendant une bonne éternité et demie avec les quelques dizaines de maps libres incluses dans le projet, et des projets comme cube2 qui dispose d'un petit paquet de données libres contenant une map de démonstration qui est loin de fournir une expérience de jeu satisfaisante (voir le paquet cube2-data dans Debian).
Le ponpon étant cette musique avec le readme qui invalide sa licence… Wat? On sait qu’on a le droit de distribuer, mais le contrat est invalide.
Oui ça arrive souvent dans le monde de l'art mais aussi du logiciel : des gens qui publient sous une licence libre et qui écrivent à côté que c'est pas sous licence libre. Des projets comme debian recommandent de clarifier la situation ou de ne pas accepter l'œuvre en cas de situation ambigue comme celle-ci, même dans des cas où la licence libre prévaut.
Ensuite le truc important :
Si le gars fait un modèle et se prend un platane en sortie de route ou bien devient ermite avant d’avoir fait les textures, on doit pouvoir garder ce qu’on a déjà…
[…]
Ce contributeur n’est pas un contributeur extérieur (qui vient, qui publie un truc et qui disparaît) c’est juste que ce point n’est pas encore complètement tiré au clair. L’avantage c’est que ça compte comme un seul cas : c’est 7 modèles pas libre ou 7 modèles libres, d’un seul coup. Ensuite il reste deux personnes, ces deux cas ne sont pas libres tout simplement parce que je n’ai pas encore reçu de réponse de leur part. Les 30~40 autres modèles sont déjà en CC By-SA 3.0.
En fait il ya deux façon de gérer les objectifs d'un projet : A) les conditions doivent être vraies dès le début et B) les conditions qui doivent être vraies à la fin du projet. Souvent les projets libres mettent la liberté en A) et la qualité artistique ou technique en B).
Pour la plupart des jeux libres, wesnoth, 0ad, etc. on le voit bien : les fichiers sont restés libres depuis le début, et le jeu s'est construit petit à petit (si on regarde les screenshots on voit bien l'augmentation progressive dans la qualité des graphismes par exemple).
Unvanquished fait partie de ces rares jeux qui ont mis la qualité artistique en A) et la liberté en B). C'est un pari risqué, en témoignent les deux exemples cités plus haut : si on n'arrive pas à obtenir la licence, on perd tout.
Note: Unvanquished n'est pas le seul dans ce cas, il y a d'autres projets qui ont tenté le coup de poker d'intégrer des assets non-libres pour les faire libérer ensuite (UFO:AI, Red Eclipse, M.A.R.S….), et même l'inverse, des projets qui ont commencé libres et ont intégré des assets non-libres ensuite (freegish, Zero-K…) et dont on ne sait pas à l'heure actuelle s'ils seront libérés un jour.
Cependant il est important de noter que mettre l'art en A) et la qualité artistique ou technique en B) peut être très dangereux aussi. Par exemple, freedoom entre dans cette catégorie, l'objectif était que l'art soit libre dès le début (en réalité un contributeur a introduit des fichiers non-libres dans les versions antérieures à la 0.7, il s'agissait d'un vandalisme indépendant de la volonté des développeurs, et ces versions ne sont plus distribuées aujourd'hui), et que les maps soient vanilla-compatibles à la fin du projet. Et alors que les développeurs commencent à s'intéresser à la vanilla-compatibilité, crac, il s'avère qu'on ne peut pas l'assurer sans refaire toutes les maps. (Pour rappel le problème a été résolu en changeant l'objectif en "quasi-vanilla-compatibilité".)
Du coup je pose la question : qu'est-ce qui est le mieux ? Être intransigeant sur la liberté et avancer petit à petit vers l'objectif de qualité attendu ? Ou demander de la qualité dès le début et essayer d'atteindre la liberté ensuite ?
Enfin la seule question vraiment importante dans tout mon commentaire :
remplacer les effets sonores.
Comment qu'on fait ?
Est-ce qu'il faut aller sur opengameart et trouver un fichier de son qui fait la même longueur que le fichier qu'on veut remplacer et qui sonne à peu près pareil ? Ou c'est plus compliqué ?
J'ai toujours pensé que les devs de unvanquished n'étaient pas très chauds pour libérer les données, mais tu sembles dire le contraire en indiquant que faire un jeu libre est l'objectif du projet. Dans mes souvenirs, le projet était prêt à accepter à peu près n'importe quoi comme données tant que c'était redistribuable et que ça collait à la ligne artistique du projet. Quitte à rendre le jeu très difficile voire impossible à libérer par la suite (la probabilité de tomber sur des remplacements libres de qualité équivalente étant très faible pour certains fichiers). Bref de ma lucarne ça ressemblait vraiment à "YOLO, on prend tout ce qui vient et qui a l'air cool, si c'est libre tant mieux sinon osef tant que ça reste gratuit".
Est-ce que tu peux nous donner plus d'infos sur le projet de libération des données, ton rôle au sein de celui-ci, et les différences de point de vue des membres sur le sujet, s'il y en a eu, et comment elles ont été gérées ?
Palladium, c'est aujourd'hui Secure Boot, rien de plus.
Non Palladium ça aurait été bien plus que Secure Boot, ça aurait été toute une chaîne dont Restricted Boot aurait été l'un des maillons. L'idée c'était de tout certifier : t'as une clé dans le hardware qui vérifie le firmware de la carte mère, qui elle même contient une clé qui vérifie le bootloader, qui lui même vérifie le kernel, qui lui-même vérifie l'OS qui tourne dessus, etc. Et du coup t'as toute une chaîne de trucs signés du hardware aux fichiers DRMisés de l'utilisateur.
Le truc qui s'en rapproche le plus aujourd'hui c'est les smartphones : le hardware vérifie le bootloader, qui lui-même vérifie le kernel. Je ne pense pas que la chaîne de vérification aille plus loin que le kernel, mais ça viendra sûrement un jour.
Il y a aussi Alt-# qui commente la commande que tu es en train de taper et passe à la ligne suivante. La commande est alors stockée dans l'historique (précédée par #) sans être exécutée.
Une vraie personne intelligente aurai retenu le mot de passe root, installé un keylogger, un proxy et un mineur de bitcoin, changé deux trois binaires dans /bin et /sbin, et obtenu une topologie complète du réseau de la boite pour une utilisation future. Et aurait fait des propositions d'améliorations bidon. Tout ça en une heure et demie.
Là tu as juste réussi prouver que tu étais l'archétype du guignol moyen, sans ambition, sans avenir, incapable de saisir les opportunités qui lui sont offertes. Pas étonnant qu'il n'ait pas voulu de toi !
[^] # Re: C'est de la daube.
Posté par eingousef . En réponse au sondage Que pensez-vous des liseuses ?. Évalué à 10.
C'est là qu'on se dit que
c est pas exhaustif comme liste
*splash!*
[^] # Re: Libération des données
Posté par eingousef . En réponse au journal Comment je suis devenu chef de projet. Évalué à 5.
Ben justement, comment tu définis la source quand il n'y a pas ça ? Par exemple :
Je pense que pour l'art il n'y a pas de définition universelle d'une source et il ne peut pas y en avoir. C'est donc à chaque projet de définir clairement ce qu'est une source, et de s'y tenir (de n'accepter que des fichiers qui ont une source correspondant à la définition donnée). Évidemment si la définition de "source" est faible (ex: fichiers flac pour la musique, png lossless pour une image) on aura l'avantage de pouvoir piocher dans une grande quantité de fichiers, au détriment de peu de liberté, si la définition de source est moyenne (ex: pistes séparées/fichier tracker pour de la musique, calques/fichier xcf pour une image) ou forte (ex: partition/fichier midi pour musique, fichier de travail inkscape pour l'image) on aura plus de liberté, mais une quantité de fichiers plus restreinte à notre disposition. Les projets "de base" (ex: jeux) auraient une définition de source "forte" afin de maximiser la liberté des utilisateurs, et les projets de projets (ex: distros) auraient une définition de source "faible" pour accepter le plus de projets possibles.
Après je pense que le fichier lossless est la limite basse à ne pas dépasser dans la définition d'une source, en tout cas pour la musique et les graphismes. Il existe peut-être des types de données où il est impossible d'obtenir un fichier lossless, mais dans l'ensemble ça me semble être LE critère indiscutable pour les sources artistiques.
*splash!*
[^] # Re: Libération des données
Posté par eingousef . En réponse au journal Comment je suis devenu chef de projet. Évalué à 2.
Je commence par les broutilles :
Je pense que c'est quand même important de prévoir l'intégration au jeu (et donc la liberté) en amont du travail à réaliser. Par exemple dans les musiques de Xonotic, si on considère que les fichiers lossless sont les sources, tu as des musiques dont les sources sont dispo (celles qui ont été réalisées pour être intégrées au jeu, par exemple via un concours) et des musiques sans sources (celles qui ont été ajoutées après avoir été découvertes, ou celles qui sont issues de nexuiz).
Après on peut aussi prévoir la liberté sans forcément prévoir l'intégration au jeu, par exemple avec des plateformes comme opengameart dans lesquelles les développeurs de jeux libres peuvent piocher (malheureusement en réalité il n'est pas nécessaire de publier les sources sur OGA, mais c'est pour l'exemple).
J'espère au moins que les objectifs du projet contiennent "fournir un set de maps conséquent". C'est l'une des raisons principales pour lesquelles Xonotic n'est pas une 1.0 : les devs considèrent que le nombre maps est trop faible pour que Xonotic soit un jeu complet. Il existe certes un nombre incalculable de maps non-officielles (plusieurs centaines je crois) mais celles-ci ne sont pas intégrées au jeu, soit parce que non-libres, soit parce que la qualité n'est pas suffisante.
Je dis ça parce qu'il y a une vraie différence entre Xonotic/Nexuiz/OA avec leurs centaines de maps non-libres, mais avec lesquels on peut déjà s'amuser pendant une bonne éternité et demie avec les quelques dizaines de maps libres incluses dans le projet, et des projets comme cube2 qui dispose d'un petit paquet de données libres contenant une map de démonstration qui est loin de fournir une expérience de jeu satisfaisante (voir le paquet cube2-data dans Debian).
Oui ça arrive souvent dans le monde de l'art mais aussi du logiciel : des gens qui publient sous une licence libre et qui écrivent à côté que c'est pas sous licence libre. Des projets comme debian recommandent de clarifier la situation ou de ne pas accepter l'œuvre en cas de situation ambigue comme celle-ci, même dans des cas où la licence libre prévaut.
Ensuite le truc important :
En fait il ya deux façon de gérer les objectifs d'un projet : A) les conditions doivent être vraies dès le début et B) les conditions qui doivent être vraies à la fin du projet. Souvent les projets libres mettent la liberté en A) et la qualité artistique ou technique en B).
Pour la plupart des jeux libres, wesnoth, 0ad, etc. on le voit bien : les fichiers sont restés libres depuis le début, et le jeu s'est construit petit à petit (si on regarde les screenshots on voit bien l'augmentation progressive dans la qualité des graphismes par exemple).
Unvanquished fait partie de ces rares jeux qui ont mis la qualité artistique en A) et la liberté en B). C'est un pari risqué, en témoignent les deux exemples cités plus haut : si on n'arrive pas à obtenir la licence, on perd tout.
Note: Unvanquished n'est pas le seul dans ce cas, il y a d'autres projets qui ont tenté le coup de poker d'intégrer des assets non-libres pour les faire libérer ensuite (UFO:AI, Red Eclipse, M.A.R.S….), et même l'inverse, des projets qui ont commencé libres et ont intégré des assets non-libres ensuite (freegish, Zero-K…) et dont on ne sait pas à l'heure actuelle s'ils seront libérés un jour.
Cependant il est important de noter que mettre l'art en A) et la qualité artistique ou technique en B) peut être très dangereux aussi. Par exemple, freedoom entre dans cette catégorie, l'objectif était que l'art soit libre dès le début (en réalité un contributeur a introduit des fichiers non-libres dans les versions antérieures à la 0.7, il s'agissait d'un vandalisme indépendant de la volonté des développeurs, et ces versions ne sont plus distribuées aujourd'hui), et que les maps soient vanilla-compatibles à la fin du projet. Et alors que les développeurs commencent à s'intéresser à la vanilla-compatibilité, crac, il s'avère qu'on ne peut pas l'assurer sans refaire toutes les maps. (Pour rappel le problème a été résolu en changeant l'objectif en "quasi-vanilla-compatibilité".)
Du coup je pose la question : qu'est-ce qui est le mieux ? Être intransigeant sur la liberté et avancer petit à petit vers l'objectif de qualité attendu ? Ou demander de la qualité dès le début et essayer d'atteindre la liberté ensuite ?
Enfin la seule question vraiment importante dans tout mon commentaire :
Comment qu'on fait ?
Est-ce qu'il faut aller sur opengameart et trouver un fichier de son qui fait la même longueur que le fichier qu'on veut remplacer et qui sonne à peu près pareil ? Ou c'est plus compliqué ?
*splash!*
[^] # Re: Inintéressant
Posté par eingousef . En réponse au journal C'est pas moi qui le dit (journal bookmark). Évalué à 9. Dernière modification le 10 octobre 2017 à 15:07.
Arrêtez de passer du coca light :o
*splash!*
# Libération des données
Posté par eingousef . En réponse au journal Comment je suis devenu chef de projet. Évalué à 4.
J'ai toujours pensé que les devs de unvanquished n'étaient pas très chauds pour libérer les données, mais tu sembles dire le contraire en indiquant que faire un jeu libre est l'objectif du projet. Dans mes souvenirs, le projet était prêt à accepter à peu près n'importe quoi comme données tant que c'était redistribuable et que ça collait à la ligne artistique du projet. Quitte à rendre le jeu très difficile voire impossible à libérer par la suite (la probabilité de tomber sur des remplacements libres de qualité équivalente étant très faible pour certains fichiers). Bref de ma lucarne ça ressemblait vraiment à "YOLO, on prend tout ce qui vient et qui a l'air cool, si c'est libre tant mieux sinon osef tant que ça reste gratuit".
Est-ce que tu peux nous donner plus d'infos sur le projet de libération des données, ton rôle au sein de celui-ci, et les différences de point de vue des membres sur le sujet, s'il y en a eu, et comment elles ont été gérées ?
*splash!*
# Bravo !
Posté par eingousef . En réponse à la dépêche Libération du jeu Planète Blupi. Évalué à 10.
Tant que les boites ne comprennent pas qu'un jeu qui ne rapporte plus est mieux libre que mort, il faudrait un gars comme toi chez tous les éditeurs.
Dommage pour les codes sources perdus, mais bravo pour tout le reste !
Longue vie aux jeux libres !
*splash!*
[^] # Re: Bullshit !
Posté par eingousef . En réponse au journal [Jeu] Parser de l'écriture inclusive.. Évalué à 8.
Il vaut mieux se manger un bon plat de moules< P:
*splash!*
[^] # Re: Diablo un roguelike?
Posté par eingousef . En réponse à la dépêche À propos de Boohu, un nouveau jeu roguelike, et puis de quelques autres. Évalué à 2.
T'as vu ils ont rajouté un level dans la version git cet été.
*splash!*
[^] # Re: Tu as démontré qu'il y a un gros problème
Posté par eingousef . En réponse au journal Configurer l'extension wallabag pour firefox.. Évalué à 2.
sa concernent patte houle monde comme même
*splash!*
[^] # Re: Correction
Posté par eingousef . En réponse au journal 6,9 % de Linux sur le bureau et autres chiffres surprenants de NetMarketShare. Évalué à 10.
Moi sur 100 personnes je me rends compte que je ne connais même pas 100 personnes.
*splash!*
[^] # Re: Diablo un roguelike?
Posté par eingousef . En réponse à la dépêche À propos de Boohu, un nouveau jeu roguelike, et puis de quelques autres. Évalué à 2.
Et Flare c'est quoi ?
*splash!*
[^] # Re: Ça donne envie
Posté par eingousef . En réponse à la dépêche À propos de Boohu, un nouveau jeu roguelike, et puis de quelques autres. Évalué à 3.
Tu as fait ce graphique avec quel logiciel ? graphviz ?
T'as le code source dispo s'il y en a un ?
*splash!*
# Comprends pas
Posté par eingousef . En réponse à la dépêche Inauguration d'un « bureau ouvert » à l’Assemblée nationale française. Évalué à 10.
Je croyais qu'un "bureau ouvert", à l'assemblée nationale, c'était un l'équivalent d'un "mur de feu" ?
*splash!*
[^] # Re: Nom ?
Posté par eingousef . En réponse à la dépêche Weboob sort une nouvelle version qui va vous porter chance. Évalué à 3.
du coup ce serait quoi l'acronyme ?
*splash!*
[^] # Re: Nom ?
Posté par eingousef . En réponse à la dépêche Weboob sort une nouvelle version qui va vous porter chance. Évalué à 9.
Faudrait créer Fingoob (fingers out of the butt)
*splash!*
[^] # Re: Il sers à quoi
Posté par eingousef . En réponse au journal L'EFF quitte le W3C. Évalué à 3.
Non Palladium ça aurait été bien plus que Secure Boot, ça aurait été toute une chaîne dont Restricted Boot aurait été l'un des maillons. L'idée c'était de tout certifier : t'as une clé dans le hardware qui vérifie le firmware de la carte mère, qui elle même contient une clé qui vérifie le bootloader, qui lui même vérifie le kernel, qui lui-même vérifie l'OS qui tourne dessus, etc. Et du coup t'as toute une chaîne de trucs signés du hardware aux fichiers DRMisés de l'utilisateur.
Le truc qui s'en rapproche le plus aujourd'hui c'est les smartphones : le hardware vérifie le bootloader, qui lui-même vérifie le kernel. Je ne pense pas que la chaîne de vérification aille plus loin que le kernel, mais ça viendra sûrement un jour.
*splash!*
[^] # Re: Il sers à quoi
Posté par eingousef . En réponse au journal L'EFF quitte le W3C. Évalué à 5.
Et pourquoi pas ?
*splash!*
[^] # Re: open source ... bof.
Posté par eingousef . En réponse au journal Keybase, un Discord/Slack like Open-Source mais centralisé. Évalué à 3.
https://linuxfr.org/nodes/99378/comments/1480113
*splash!*
[^] # Re: [:saikoi]
Posté par eingousef . En réponse au journal Keybase, un Discord/Slack like Open-Source mais centralisé. Évalué à 2.
Tu veux dire par là que le protocole est fermé ? (j'ai vérifié, celui de mumble est ouvert : la doc est dispo sous licence libre)
*splash!*
[^] # Re: Contenus vis sous-scription seulement?
Posté par eingousef . En réponse à la dépêche Blender 2.79 vient de sortir. Évalué à 3.
Contacte moi via mon login linuxfr chez gmail pouaint comme, j'essayerai de te les filer.
*splash!*
# [:saikoi]
Posté par eingousef . En réponse au journal Keybase, un Discord/Slack like Open-Source mais centralisé. Évalué à 1.
c est quoi la différence avec Mumble
*splash!*
[^] # Re: Et l'indispensable C-o (ou Ctrl+o)
Posté par eingousef . En réponse au journal Bash et les raccourcis clavier. Évalué à 5.
Il y a aussi
Alt-#qui commente la commande que tu es en train de taper et passe à la ligne suivante. La commande est alors stockée dans l'historique (précédée par#) sans être exécutée.*splash!*
[^] # Re: corrélation réchauffement climatique
Posté par eingousef . En réponse au journal Le jour d’après, c’est aujourd’hui. Évalué à 9.
Attache-le à une voiture !
*splash!*
[^] # Re: À mon tour
Posté par eingousef . En réponse au journal Recrutons. D'accord, mais sur quels critères ?. Évalué à 6.
l'erreur de débutant ! Je suis sûr que tu n'avais pas ta cagoule non plus
*splash!*
[^] # Re: À mon tour
Posté par eingousef . En réponse au journal Recrutons. D'accord, mais sur quels critères ?. Évalué à 10.
Une vraie personne intelligente aurai retenu le mot de passe root, installé un keylogger, un proxy et un mineur de bitcoin, changé deux trois binaires dans /bin et /sbin, et obtenu une topologie complète du réseau de la boite pour une utilisation future. Et aurait fait des propositions d'améliorations bidon. Tout ça en une heure et demie.
Là tu as juste réussi prouver que tu étais l'archétype du guignol moyen, sans ambition, sans avenir, incapable de saisir les opportunités qui lui sont offertes. Pas étonnant qu'il n'ait pas voulu de toi !
*splash!*