Avais-tu évalué le gestionnaire de paquet Nix pour voir s'il convenait à tes besoins ? À vue de nez, Nix semble moins pensé pour l'intégration au système existant, mais il est peut-être plus poussé sur l'aspect reproductibilité (en particulier les hash d'environnements Nix peuvent être comparés entre machine pour vérifier que la configuration est bien identique).
Note aux modérateurs: serait-il possible de préciser dans le titre qu'il s'agit d'un projet de loi en France, et pas au Québec, au Sénégal ou dans un des autres pays d'où nous viennent des visiteurs francophones ? Je trouve ça important (par respect pour eux) de ne jamais supposer implicitement que c'est de la France qu'il est question, et de le préciser explicitement quand c'est le cas.
C'est assommant de bêtise de lutter contre la fraude en rendant obligatoire la sécurité par l'obscurité. Tu as l'air très pessimiste sur le fait que la loi passera de toute façon sans changement, mais supposons que nous souhaitions alerter nos élus sur le problème. As-tu un lien que nous puissions leur fournir pour leur décrire la situation (qui explique le problème et pointe vers les amendements proposés), autre que cette dépêche LinuxFR ?
Posté par gasche .
En réponse à la dépêche Fim 1.1.0.
Évalué à 10.
Attention, le projet de recherche qui a donné naissance à Unison n'est plus activement développé, mais ça ne veut pas dire que le logiciel lui-même ne l'est pas. Je croise de temps en temps des développeurs Unison qui sont actifs sur la maintenance, implémentent parfois des améliorations, et seraient bien évidemment d'intégrer des contributions externes.
Je trouve que le féminin est plus naturel quand on déplie l'acronyme à l'oral. "La Request for Comments" se dit beaucoup mieux que "Le Request for Comments".
P.S.: le travail de présentation et d'interaction avec le code source des paquets Debian sources.debian.net qui nous permet cette discussion a justement été développée et déployée par l'IRILL, un laboratoire (public) de recherche sur ce qui touche au logiciel libre et à la qualité logicielle. Aucun des auteurs originaux, Matthieu Caneill et Stefano Zacchiroli, n'est affilié INRIA (non pas que j'y attache une quelconque importance), mais l'institut co-finance l'IRILL.
Il y a des faux positifs qui vienent du fait que, pour une raison que j'ignore, la DTD xhtml1-strict porte un copyright partagé contenant INRIA (j'imagine que des chercheurs ont participé à son élaboration):
For further information, see: http://www.w3.org/TR/xhtml1
Copyright (c) 1998-2002 W3C (MIT, INRIA, Keio),
All Rights Reserved.
C'est la seule chaîne avec INRIA dans le paquet erlang, et c'est pareil pour mono (j'ai regardé indépendamment). Malheureusement je ne connais plus assez bien le langage de requête de grep mais je ne crois pas qu'on puisse facilement exclure les lignes qui contiennent aussi la chaîne "W3C" (si quelqu'un trouve je suis preneur).
Si tu regardes les hits pour cimp tu vois que David Tschumperlé était membre de l'équipe Odysée à l'INRIA Sophia-Antipolis:
De toute façon je ne sais pas si distinguer les contributions INRIA et CNRS a vraiment du sens : ce sont deux instituts proches et leurs chercheurs collaborent très souvent (avec un certain nombre d'équipes mixtes etc). INRIA se veut peut-être un peu plus appliqué (donc statistiquement il est normal que les retombées logicielles soient "plutôt INRIA"), mais je ne connais peu de gens qui serait très heureux à l'INRIA et malheureux au CNRS ou inversement, plutôt qu'un choix c'est souvent que les gens vont là où ils trouvent un poste (en tout cas dans le contexte de recrutement actuel, c'était peut-être différent avant).
En fait il faut faire Copryright.*(inria|INRIA), et là on a 210 paquets qui semblent pertinent. Par exemple ocaml apparaît dans cette nouvelle recherche mais n'était pas inclus dans l'ancienne.
Par ailleurs il faut faire une distinction entre ce que dit la loi et ce qui nous semble juste. Malheureusement ce n'est pas toujours la même chose.
Dans l'absolu je suis de l'avis qu'il faudrait toujours laisser aux auteurs le choix. Le fait qu'une entité utilise une relation de pouvoir pour imposer systématiquement des choix aux auteurs ne me semble pas juste. Par contre, le fait que le salaire vienne en contrepartie d'un droit d'exploitation semble juste (mais la question de savoir si ce droit d'exploitation est exclusif ou non est délicate).
Dans le cadre de la recherche malheureusement il y a des cas où des directives venant de l'employeur peuvent avoir un effet bénéfique à un moment donné. Par exemple l'INRIA demande depuis 2013 à ses chercheurs de mettre toutes leurs publications en libre accès sur la plateforme d'archivage HAL. Cela va à l'encontre du principe selon lequel chaque auteur devrait être libre de choisir le mode de diffusion de ses articles, mais c'est quand même une décision qui a eu un impact positif sur l'intérêt commun. Dans le cas des articles scientifiques il y a peu d'oppositions personnelles à la mise en libre-accès, c'est plutôt la flemme d'enregistrer un article dans une interface parfois lourde, et l'existence de demande de cession de droits tout à fait immorales venant des éditeurs scientifiques—on peut à la rigueur dire que cette demande entérine une position d'ensemble du code des chercheurs et enseignants-chercheurs et protège les chercheurs individuellement des pressions contraires des éditeurs.
Maintenant aurait-on intérêt à essayer d'obtenir des organismes de recherche des décisions fermes sur les licences des logiciels produites par leurs employé-e-s ? Bien sûr je serais content d'une directive imposant aux chercheu-r-se-s de produire du logiciel libre (mon opinion est que tout le logiciel produit par la recherche publique devrait être libre), mais ça me semble une pente très dangereuse, car rien ne garantit que l'année suivante, après le changement de gouvernement ou à la direction de l'organisme, on ne se retrouve pas avec une obligation de licence propriétaire et dépôt de brevet automatique (une idée tout à fait réaliste si on prend connaissance du guide de l'intelligence économique pour la recherche divulgué par le gouvernement, tout à fait hostile au logiciel libre).
Je pense donc qu'il est plus sûr et plus sage de laisser les chercheurs décider individuellement le régime de divulgation de leurs œuvres—en accord avec leur employeur.
Je voulais dire que la licence était un choix qui venait de l'auteur (avec lequel j'imagine que l'employeur est d'accord), et que le principe que les auteurs d'une œuvre puissent choisir la licence qu'ils souhaitent est un des tenants de base du logiciel libre. (C'était une remarque abstraite sans considérer le statut de l'auteur dans ce cas précis.)
La législation est assez compliquée sur la question de qui détient les droits quand un employé crée une œuvre. Par exemple le régime légal des journalistes précise explicitement qu'ils ont les droits d'auteur pleins sur les articles qu'ils écrivent (en contrepartie de leur salaire ils cèdent à leur employeur un droit d'exploitation temporaire). Le code de la propriété intellectuelle accorde les droits d'auteurs pleins aux auteurs d'une œuvre de l'esprit même quand ils sont salariés, sauf dans le cas du logiciel qui est une exception spécifique (à mon avis ça vient d'une vision industrielle de la programmation où les salariés sont des perçus comme des ouvriers interchangeables et non des créateurs). Le régime des fonctionnaires du public accorde automatiquement les droits d'exploitation à l'employeur, sauf dans le cas qui ne sont pas soumises "au contrôle hiérarchique"—donc pas dans le cas des enseignants et enseignants-chercheurs. Pour les chercheurs et enseignants-chercheurs, donc, les œuvres de l'esprit sont entièrement la propriété de l'employé, sauf le logiciel sur lequel la situation est peu claire, mais a priori l'auteur a les droits moraux et l'employeur les droits d'exploitation (automatiquement).
Dans le cas concret de Compcert, les headers de licences mentionnent clairement un "copyright INRIA", mais le choix de licence vient de l'auteur.
Je trouve que ta remarque sur l'INRIA tombe un peu à plat, car dans le cas de Compcert (ainsi que dans le cas de tous les logiciels produits par des équipes INRIA dont j'ai personnellement connaissance, et qui sont en très grande majorité des logiciels libres) c'est l'auteur du logiciel qui a choisi la licence. Il me semble normal et légitime que les auteurs soient libres de choisir la licence qui leur semble adaptée (même si en l'occurrence je déplore ce choix), et tu y vois un rôle de l'institut employeur qui n'est pas présent en réalité.
Il existe un compilateur C qui est garanti "quasiment sans bug", c'est Compcert, un compilateur prouvé correct : il vient avec une preuve formelle, vérifiée par ordinateur, que si le compilateur produit un fichier assembleur alors celui-là a la même sémantique que le programme C de départ. Malheureusement, ce n'est pas du logiciel libre (restriction à un usage non-commercial), en tout cas pour l'instant.
Je trouve que ta réponse est un peu passé à côté de mon message. Je ne fais pas la pub pour un outil de frontend particulier (Krita ou Gimp sont deux logiciels que je respecte, il se trouve qu'il y a une vidéo bien faite de démonstration d'un outil pour Krita, mais comme G'MIC se branche aux deux il ne manque sans doute qu'un peu de travail d'interface côté GIMP pour s'en servir aussi), mais plutôt pour le fait de développer ces outils semi-automatisés dans les logiciels libres.
J'ai déjà vu des étudiant-e-es en animation 2D travailler (avec des outils libres ou non) et ils utilisaient étonamment peu d'algorithmes de ce genre pour les aider. C'était surtout du travail manuel assez chiant, quand on voit que les algorithmes existant peuvent coloriser des vidéos à la volée avec très peu de frames annotées au départ¹. Je ne doute pas que des outils propriétaires avancés (que ces étudiant-e-s n'utilisaient pas) fassent des choses de ce genre pour les professionnels, mais où sont les outils équivalents faciles d'accès dans les logiciels libres ?
¹: Les exemples sur les films sont très impressionnants mais je pense que c'est plus difficile à faire pour l'animation (non-vectorielle) parce que tu as beaucoup moins de frames (moins de continuité d'une frame à la suivante), et beaucoup moins d'arrêtes nettes dans chaque frame. Il y a donc sans doute un besoin de développement d'heuristiques spécifiques, ou d'utiliser au préalable des techniques d'interpolation.
Tu dis que tu as fait des plugins d'aide à la colorisation, c'est la première fois que j'en entends parler. Où sont les tutoriels sur comment s'en servir ? Tes plugins permettent-ils aussi de détecter automatiquement les zones à remplir ? Une rapide recherche sur des tutoriels pour GIMP donne 123, trois tutoriels où la sélection des zones à colorer est faite manuellement—le travail que l'algorithme permet d'éviter dans 90% des cas.
Je pense que pour que les outils de création artistique libres prospèrent, une collaboration entre utilisateurs et programmeurs est cruciale. En cela ton attention aux workflows et à leur diversité est louable—je suis convaincu que c'est le bon état d'esprit pour faire avancer le libre dans ce domaine.
David Tschumperlé a écrit sur LinuxFR pour la sortie de la nouvelle version de G'MIC, qui contient en particulier un algorithme de colorisation assistée par ordinateur qui a été très bien intégré à Krita.
Pour rappel, l'algorithme fonctionne à partir d'un ensemble de points dont l'animateur fixe la couleur, en essayant de "propager" les couleurs données dans les zones adjacentes de l'image, en supposant que les changements de couleurs se situeront au niveau des arrêtes vives de l'imagine initiale. Ce n'est donc que semi-automatique puisque le coloriste ajoute des points de contrôle au fur et à mesure, en observant le résultat en direct. Pour une vidéo de démonstration, voir l'article de David Revoy.
Je pense qu'il serait possible, techniquement pas trop difficile (mais je ne suis pas expert) et très intéressant d'étendre cet outil à une animation plutôt qu'une simple image 2D. (L'idée est que la couleur peut aussi être propagée aux frames précédentes et suivantes tant que la position des objets reste assez proche pour que l'algorithme puisse tracer l'évolution des arrêtes vives dans le temps.) Je ne sais pas si les développeur-euse-s de G'MIC ont déjà été en contact avec des animat-eur-rice-s (en tout cas je n'ai pas entendu parler de transformation exploitant l'axe temporel pour l'instant). Ce travail centré sur les outils libres serait sans doute une excellente occasion d'entrer en contact avec eux, d'exposer vos besoins et peut-être de repartir avec un nouvel outil fort utile.
Ces slides sont très intéressants, et je serais curieux d'avoir un retour sur les contributions aux logiciels diffusés depuis 2008. Les slides mentionnent l'intérêt d'avoir des contributions en retour, est-ce que ça se passe réellement dans la pratique ?
Aider à la traduction est une très bonne façon de contribuer à un logiciel. J'avais crowd-sourcé la traduction de certains logiciels KDE (plus petits) avec des amis il y a quelque années, c'est très facile de se lancer et il y a une équipe de traduction qui est prête à aider pour la relecture, indiquer les conventions de traduction, etc.
Gros avantage par rapport aux typescript, atscript et autres articulations: ça n'est ni un nouveau langage, ni un système d'annotations à rajouter au code. Ça fonctionne avec du javascript absolument standard.
Flow est un projet intéressant (en plus c'est codé en OCaml) mais ceci n'est pas exact: Flow permet d'ajouter des annotations et demande donc de re-traduire le code vers du Javascript valide.
Et comment tu fais pour tracer des populations sans tracer les individus ?
En fait on sait faire, c'est le concept de Differential Privacy. Plus précisément, à partir d'un acteur supposé de confiance qui trace les individus, on peut laisser d'autres acteurs (auxquels on ne fait pas confiance) accéder à des données sur les populations, avec juste assez d'imprécision pour les empêcher de pouvoir en déduire des informations précises sur les individus.
C'est tout à fait utilisable pour de l'analytics web, mais il reste un maillon de la chaîne auquel on doit faire confiance (celui qui collecte les données en premier lieu). Je pense que ce maillon est décentralisable/fédérable, mais évidemment si c'est Google qui le fait il est un peu difficile de faire confiance.
La techno en elle-même c'est juste du Java où tout a changé de nom… C'est aussi lourd, aussi pourri.
Je ne suis pas d'accord avec cette simplification abusive d'une grosse quantité de travail de language design fournie par Microsoft. Je connais mieux F# que C# et (même si c'est globalement un import dans le monde Microsoft du langage OCaml déjà existant) il y a du bon travail et des choses intéressantes dedans.
Je ne comprends pas ton acharnement. J'aurais certes pu écrire "Microsoft annonce la libération de …", et ça aurait été un meilleur titre car plus exact. J'aurais fait cette modification maintenant si c'était possible, mais LinuxFr ne permet pas d'éditer ses messages ou ses journaux.
Mais qu'est-ce que ça change en pratique ? D'une part, je trouve normal qu'une telle libération prenne du temps et se fasse progressivement (cela implique entre autre le changement d'outil de gestion de versions d'un gros logiciel, et ces opérations sont toujours compliquées et longues), et d'autre part je ne vois pas de raison d'attendre la fin de la libération pour faire cette annonce (et, dans mon cas, la retransmettre). Il n'y a pas là de volonté de nuire et, à part que des gens vont rester sur leur faim quelques mois de plus (comme moi qui voulait aller regarder le runtime), je ne vois pas où est le mal.
J'ai oublié de commenter le point (2): ce n'est pas forcément une bonne idée de modifier une feature existante, à moins de pouvoir s'assurer que tous les utilisateurs de la feature seront satisfaits. Si tu veux que ton changement soit accepté, il me semble beaucoup naturel de faire de ton besoin un mode d'affichage des temps supplémentaire.
# Nix ?
Posté par gasche . En réponse à la dépêche Sortie de HomeLinux, version 1.0.0. Évalué à 10.
Avais-tu évalué le gestionnaire de paquet Nix pour voir s'il convenait à tes besoins ? À vue de nez, Nix semble moins pensé pour l'intégration au système existant, mais il est peut-être plus poussé sur l'aspect reproductibilité (en particulier les hash d'environnements Nix peuvent être comparés entre machine pour vérifier que la configuration est bien identique).
# Projet de loi *française* des finances
Posté par gasche . En réponse à la dépêche Projet de loi de finances FR 2016 : interdiction des logiciels libres de comptabilité et de caisse. Évalué à 10.
Note aux modérateurs: serait-il possible de préciser dans le titre qu'il s'agit d'un projet de loi en France, et pas au Québec, au Sénégal ou dans un des autres pays d'où nous viennent des visiteurs francophones ? Je trouve ça important (par respect pour eux) de ne jamais supposer implicitement que c'est de la France qu'il est question, et de le préciser explicitement quand c'est le cas.
# Édifiant
Posté par gasche . En réponse à la dépêche Projet de loi de finances FR 2016 : interdiction des logiciels libres de comptabilité et de caisse. Évalué à 10.
C'est assommant de bêtise de lutter contre la fraude en rendant obligatoire la sécurité par l'obscurité. Tu as l'air très pessimiste sur le fait que la loi passera de toute façon sans changement, mais supposons que nous souhaitions alerter nos élus sur le problème. As-tu un lien que nous puissions leur fournir pour leur décrire la situation (qui explique le problème et pointe vers les amendements proposés), autre que cette dépêche LinuxFR ?
[^] # Re: unison
Posté par gasche . En réponse à la dépêche Fim 1.1.0. Évalué à 10.
Attention, le projet de recherche qui a donné naissance à Unison n'est plus activement développé, mais ça ne veut pas dire que le logiciel lui-même ne l'est pas. Je croise de temps en temps des développeurs Unison qui sont actifs sur la maintenance, implémentent parfois des améliorations, et seraient bien évidemment d'intégrer des contributions externes.
[^] # Re: Lutte contre l’obsolescence programmée, ossification du net et priorité FOSS
Posté par gasche . En réponse à la dépêche Consultation « République numérique », soutenez les propositions de vos organisations préférées. Évalué à 4.
Merci pour cette proposition, je l'ai trouvée très intéressante et on voit qu'elle est issue d'un gros travail de préparation.
[^] # Re: Liens
Posté par gasche . En réponse à la dépêche Consultation « République numérique », soutenez les propositions de vos organisations préférées. Évalué à 4.
J'ai aussi trouvé la proposition Protection des consommateurs, lutte contre l’obsolescence programmée et encouragement de l’innovation extrêmement intéressante. L'argumentation, sous la forme de "soit vous assurez un bon niveau de protection face aux bugs et failles de sécurité, soit vous ouvrez assez vos produits pour que les utilisateurs puissent le faire eux-mêmes" est intelligente.
[^] # Re: La titre
Posté par gasche . En réponse à la dépêche Publication de la RFC « DNS et vie privée ». Évalué à 4. Dernière modification le 14 septembre 2015 à 10:52.
Je trouve que le féminin est plus naturel quand on déplie l'acronyme à l'oral. "La Request for Comments" se dit beaucoup mieux que "Le Request for Comments".
# Image
Posté par gasche . En réponse à la dépêche Retour sur la conférence donnée par Richard Stallman le 12 mai 2015 à Brest.. Évalué à 3.
Cet article est clairement une publicité masquée, conçue les fabricants d'appareils photo.
[^] # Re: Compilateur sans bugs
Posté par gasche . En réponse à la dépêche OpenBSD 5.7 « Blues Brothers ». Évalué à 3.
P.S.: le travail de présentation et d'interaction avec le code source des paquets Debian sources.debian.net qui nous permet cette discussion a justement été développée et déployée par l'IRILL, un laboratoire (public) de recherche sur ce qui touche au logiciel libre et à la qualité logicielle. Aucun des auteurs originaux, Matthieu Caneill et Stefano Zacchiroli, n'est affilié INRIA (non pas que j'y attache une quelconque importance), mais l'institut co-finance l'IRILL.
[^] # Re: Compilateur sans bugs
Posté par gasche . En réponse à la dépêche OpenBSD 5.7 « Blues Brothers ». Évalué à 2. Dernière modification le 04 mai 2015 à 17:43.
Il y a des faux positifs qui vienent du fait que, pour une raison que j'ignore, la DTD xhtml1-strict porte un copyright partagé contenant INRIA (j'imagine que des chercheurs ont participé à son élaboration):
C'est la seule chaîne avec INRIA dans le paquet
erlang, et c'est pareil pourmono(j'ai regardé indépendamment). Malheureusement je ne connais plus assez bien le langage de requête degrepmais je ne crois pas qu'on puisse facilement exclure les lignes qui contiennent aussi la chaîne "W3C" (si quelqu'un trouve je suis preneur).Si tu regardes les hits pour cimp tu vois que David Tschumperlé était membre de l'équipe Odysée à l'INRIA Sophia-Antipolis:
De toute façon je ne sais pas si distinguer les contributions INRIA et CNRS a vraiment du sens : ce sont deux instituts proches et leurs chercheurs collaborent très souvent (avec un certain nombre d'équipes mixtes etc). INRIA se veut peut-être un peu plus appliqué (donc statistiquement il est normal que les retombées logicielles soient "plutôt INRIA"), mais je ne connais peu de gens qui serait très heureux à l'INRIA et malheureux au CNRS ou inversement, plutôt qu'un choix c'est souvent que les gens vont là où ils trouvent un poste (en tout cas dans le contexte de recrutement actuel, c'était peut-être différent avant).
[^] # Re: Compilateur sans bugs
Posté par gasche . En réponse à la dépêche OpenBSD 5.7 « Blues Brothers ». Évalué à 4.
En fait il faut faire Copryright.*(inria|INRIA), et là on a 210 paquets qui semblent pertinent. Par exemple
ocamlapparaît dans cette nouvelle recherche mais n'était pas inclus dans l'ancienne.[^] # Re: Compilateur sans bugs
Posté par gasche . En réponse à la dépêche OpenBSD 5.7 « Blues Brothers ». Évalué à 2.
Chercher "Copyright.*inria" est assez efficace. Au total on trouve 58 paquets concernés, ce qui me semble assez impressionnant.
[^] # Re: Compilateur sans bugs
Posté par gasche . En réponse à la dépêche OpenBSD 5.7 « Blues Brothers ». Évalué à 5.
Par ailleurs il faut faire une distinction entre ce que dit la loi et ce qui nous semble juste. Malheureusement ce n'est pas toujours la même chose.
Dans l'absolu je suis de l'avis qu'il faudrait toujours laisser aux auteurs le choix. Le fait qu'une entité utilise une relation de pouvoir pour imposer systématiquement des choix aux auteurs ne me semble pas juste. Par contre, le fait que le salaire vienne en contrepartie d'un droit d'exploitation semble juste (mais la question de savoir si ce droit d'exploitation est exclusif ou non est délicate).
Dans le cadre de la recherche malheureusement il y a des cas où des directives venant de l'employeur peuvent avoir un effet bénéfique à un moment donné. Par exemple l'INRIA demande depuis 2013 à ses chercheurs de mettre toutes leurs publications en libre accès sur la plateforme d'archivage HAL. Cela va à l'encontre du principe selon lequel chaque auteur devrait être libre de choisir le mode de diffusion de ses articles, mais c'est quand même une décision qui a eu un impact positif sur l'intérêt commun. Dans le cas des articles scientifiques il y a peu d'oppositions personnelles à la mise en libre-accès, c'est plutôt la flemme d'enregistrer un article dans une interface parfois lourde, et l'existence de demande de cession de droits tout à fait immorales venant des éditeurs scientifiques—on peut à la rigueur dire que cette demande entérine une position d'ensemble du code des chercheurs et enseignants-chercheurs et protège les chercheurs individuellement des pressions contraires des éditeurs.
Maintenant aurait-on intérêt à essayer d'obtenir des organismes de recherche des décisions fermes sur les licences des logiciels produites par leurs employé-e-s ? Bien sûr je serais content d'une directive imposant aux chercheu-r-se-s de produire du logiciel libre (mon opinion est que tout le logiciel produit par la recherche publique devrait être libre), mais ça me semble une pente très dangereuse, car rien ne garantit que l'année suivante, après le changement de gouvernement ou à la direction de l'organisme, on ne se retrouve pas avec une obligation de licence propriétaire et dépôt de brevet automatique (une idée tout à fait réaliste si on prend connaissance du guide de l'intelligence économique pour la recherche divulgué par le gouvernement, tout à fait hostile au logiciel libre).
Je pense donc qu'il est plus sûr et plus sage de laisser les chercheurs décider individuellement le régime de divulgation de leurs œuvres—en accord avec leur employeur.
[^] # Re: Compilateur sans bugs
Posté par gasche . En réponse à la dépêche OpenBSD 5.7 « Blues Brothers ». Évalué à 6.
Je voulais dire que la licence était un choix qui venait de l'auteur (avec lequel j'imagine que l'employeur est d'accord), et que le principe que les auteurs d'une œuvre puissent choisir la licence qu'ils souhaitent est un des tenants de base du logiciel libre. (C'était une remarque abstraite sans considérer le statut de l'auteur dans ce cas précis.)
La législation est assez compliquée sur la question de qui détient les droits quand un employé crée une œuvre. Par exemple le régime légal des journalistes précise explicitement qu'ils ont les droits d'auteur pleins sur les articles qu'ils écrivent (en contrepartie de leur salaire ils cèdent à leur employeur un droit d'exploitation temporaire). Le code de la propriété intellectuelle accorde les droits d'auteurs pleins aux auteurs d'une œuvre de l'esprit même quand ils sont salariés, sauf dans le cas du logiciel qui est une exception spécifique (à mon avis ça vient d'une vision industrielle de la programmation où les salariés sont des perçus comme des ouvriers interchangeables et non des créateurs). Le régime des fonctionnaires du public accorde automatiquement les droits d'exploitation à l'employeur, sauf dans le cas qui ne sont pas soumises "au contrôle hiérarchique"—donc pas dans le cas des enseignants et enseignants-chercheurs. Pour les chercheurs et enseignants-chercheurs, donc, les œuvres de l'esprit sont entièrement la propriété de l'employé, sauf le logiciel sur lequel la situation est peu claire, mais a priori l'auteur a les droits moraux et l'employeur les droits d'exploitation (automatiquement).
Dans le cas concret de Compcert, les headers de licences mentionnent clairement un "copyright INRIA", mais le choix de licence vient de l'auteur.
[^] # Re: Compilateur sans bugs
Posté par gasche . En réponse à la dépêche OpenBSD 5.7 « Blues Brothers ». Évalué à 4.
Je trouve que ta remarque sur l'INRIA tombe un peu à plat, car dans le cas de Compcert (ainsi que dans le cas de tous les logiciels produits par des équipes INRIA dont j'ai personnellement connaissance, et qui sont en très grande majorité des logiciels libres) c'est l'auteur du logiciel qui a choisi la licence. Il me semble normal et légitime que les auteurs soient libres de choisir la licence qui leur semble adaptée (même si en l'occurrence je déplore ce choix), et tu y vois un rôle de l'institut employeur qui n'est pas présent en réalité.
# Compilateur sans bugs
Posté par gasche . En réponse à la dépêche OpenBSD 5.7 « Blues Brothers ». Évalué à 10.
Il existe un compilateur C qui est garanti "quasiment sans bug", c'est Compcert, un compilateur prouvé correct : il vient avec une preuve formelle, vérifiée par ordinateur, que si le compilateur produit un fichier assembleur alors celui-là a la même sémantique que le programme C de départ. Malheureusement, ce n'est pas du logiciel libre (restriction à un usage non-commercial), en tout cas pour l'instant.
[^] # Re: Colorisation d'une animation
Posté par gasche . En réponse à la dépêche "ZeMarmot", premier film d'animation réalisé entièrement avec des Logiciels Libres. Évalué à 3.
Je trouve que ta réponse est un peu passé à côté de mon message. Je ne fais pas la pub pour un outil de frontend particulier (Krita ou Gimp sont deux logiciels que je respecte, il se trouve qu'il y a une vidéo bien faite de démonstration d'un outil pour Krita, mais comme G'MIC se branche aux deux il ne manque sans doute qu'un peu de travail d'interface côté GIMP pour s'en servir aussi), mais plutôt pour le fait de développer ces outils semi-automatisés dans les logiciels libres.
J'ai déjà vu des étudiant-e-es en animation 2D travailler (avec des outils libres ou non) et ils utilisaient étonamment peu d'algorithmes de ce genre pour les aider. C'était surtout du travail manuel assez chiant, quand on voit que les algorithmes existant peuvent coloriser des vidéos à la volée avec très peu de frames annotées au départ¹. Je ne doute pas que des outils propriétaires avancés (que ces étudiant-e-s n'utilisaient pas) fassent des choses de ce genre pour les professionnels, mais où sont les outils équivalents faciles d'accès dans les logiciels libres ?
¹: Les exemples sur les films sont très impressionnants mais je pense que c'est plus difficile à faire pour l'animation (non-vectorielle) parce que tu as beaucoup moins de frames (moins de continuité d'une frame à la suivante), et beaucoup moins d'arrêtes nettes dans chaque frame. Il y a donc sans doute un besoin de développement d'heuristiques spécifiques, ou d'utiliser au préalable des techniques d'interpolation.
Tu dis que tu as fait des plugins d'aide à la colorisation, c'est la première fois que j'en entends parler. Où sont les tutoriels sur comment s'en servir ? Tes plugins permettent-ils aussi de détecter automatiquement les zones à remplir ? Une rapide recherche sur des tutoriels pour GIMP donne 1 2 3, trois tutoriels où la sélection des zones à colorer est faite manuellement—le travail que l'algorithme permet d'éviter dans 90% des cas.
Je pense que pour que les outils de création artistique libres prospèrent, une collaboration entre utilisateurs et programmeurs est cruciale. En cela ton attention aux workflows et à leur diversité est louable—je suis convaincu que c'est le bon état d'esprit pour faire avancer le libre dans ce domaine.
# Colorisation d'une animation
Posté par gasche . En réponse à la dépêche "ZeMarmot", premier film d'animation réalisé entièrement avec des Logiciels Libres. Évalué à 4.
David Tschumperlé a écrit sur LinuxFR pour la sortie de la nouvelle version de G'MIC, qui contient en particulier un algorithme de colorisation assistée par ordinateur qui a été très bien intégré à Krita.
Pour rappel, l'algorithme fonctionne à partir d'un ensemble de points dont l'animateur fixe la couleur, en essayant de "propager" les couleurs données dans les zones adjacentes de l'image, en supposant que les changements de couleurs se situeront au niveau des arrêtes vives de l'imagine initiale. Ce n'est donc que semi-automatique puisque le coloriste ajoute des points de contrôle au fur et à mesure, en observant le résultat en direct. Pour une vidéo de démonstration, voir l'article de David Revoy.
Je pense qu'il serait possible, techniquement pas trop difficile (mais je ne suis pas expert) et très intéressant d'étendre cet outil à une animation plutôt qu'une simple image 2D. (L'idée est que la couleur peut aussi être propagée aux frames précédentes et suivantes tant que la position des objets reste assez proche pour que l'algorithme puisse tracer l'évolution des arrêtes vives dans le temps.) Je ne sais pas si les développeur-euse-s de G'MIC ont déjà été en contact avec des animat-eur-rice-s (en tout cas je n'ai pas entendu parler de transformation exploitant l'axe temporel pour l'instant). Ce travail centré sur les outils libres serait sans doute une excellente occasion d'entrer en contact avec eux, d'exposer vos besoins et peut-être de repartir avec un nouvel outil fort utile.
Bref, allez parler aux gens de G'MIC !
[^] # Re: existant en grande entreprise
Posté par gasche . En réponse au journal Besoin d'arguments pour obtenir une station de travail sous GNU/Linux ?. Évalué à 3.
Ces slides sont très intéressants, et je serais curieux d'avoir un retour sur les contributions aux logiciels diffusés depuis 2008. Les slides mentionnent l'intérêt d'avoir des contributions en retour, est-ce que ça se passe réellement dans la pratique ?
[^] # Re: Il ne lui manque que…
Posté par gasche . En réponse à la dépêche Remplacement de Photoshop par Krita dans une université parisienne. Évalué à 4. Dernière modification le 17 janvier 2015 à 16:47.
Aider à la traduction est une très bonne façon de contribuer à un logiciel. J'avais crowd-sourcé la traduction de certains logiciels KDE (plus petits) avec des amis il y a quelque années, c'est très facile de se lancer et il y a une équipe de traduction qui est prête à aider pour la relecture, indiquer les conventions de traduction, etc.
[^] # Re: Tout vient à point à qui sait attendre
Posté par gasche . En réponse au journal J'ai testé pour vous : la création d'un jeu pour Firefox OS. Évalué à 4. Dernière modification le 02 décembre 2014 à 11:02.
Flow est un projet intéressant (en plus c'est codé en OCaml) mais ceci n'est pas exact: Flow permet d'ajouter des annotations et demande donc de re-traduire le code vers du Javascript valide.
[^] # Re: DNT
Posté par gasche . En réponse au journal Yandex, Baidu et Yahoo, un point commun ?. Évalué à 2.
En fait on sait faire, c'est le concept de Differential Privacy. Plus précisément, à partir d'un acteur supposé de confiance qui trace les individus, on peut laisser d'autres acteurs (auxquels on ne fait pas confiance) accéder à des données sur les populations, avec juste assez d'imprécision pour les empêcher de pouvoir en déduire des informations précises sur les individus.
C'est tout à fait utilisable pour de l'analytics web, mais il reste un maillon de la chaîne auquel on doit faire confiance (celui qui collecte les données en premier lieu). Je pense que ce maillon est décentralisable/fédérable, mais évidemment si c'est Google qui le fait il est un peu difficile de faire confiance.
[^] # Re: RotFL
Posté par gasche . En réponse à la dépêche Microsoft libère le cœur de .NET et cible GNU/Linux. Évalué à 9.
Je ne suis pas d'accord avec cette simplification abusive d'une grosse quantité de travail de language design fournie par Microsoft. Je connais mieux F# que C# et (même si c'est globalement un import dans le monde Microsoft du langage OCaml déjà existant) il y a du bon travail et des choses intéressantes dedans.
[^] # Re: are you reading?
Posté par gasche . En réponse au journal Microsoft libère les sources du cœur de .NET sur github, et ouvre son processus de développement. Évalué à 5.
Je ne comprends pas ton acharnement. J'aurais certes pu écrire "Microsoft annonce la libération de …", et ça aurait été un meilleur titre car plus exact. J'aurais fait cette modification maintenant si c'était possible, mais LinuxFr ne permet pas d'éditer ses messages ou ses journaux.
Mais qu'est-ce que ça change en pratique ? D'une part, je trouve normal qu'une telle libération prenne du temps et se fasse progressivement (cela implique entre autre le changement d'outil de gestion de versions d'un gros logiciel, et ces opérations sont toujours compliquées et longues), et d'autre part je ne vois pas de raison d'attendre la fin de la libération pour faire cette annonce (et, dans mon cas, la retransmettre). Il n'y a pas là de volonté de nuire et, à part que des gens vont rester sur leur faim quelques mois de plus (comme moi qui voulait aller regarder le runtime), je ne vois pas où est le mal.
[^] # Re: "Demande de feature" et "patch" c'est très différent
Posté par gasche . En réponse à la dépêche Modeste contribution à Audacity sur l'affichage des temps. Évalué à 4.
J'ai oublié de commenter le point (2): ce n'est pas forcément une bonne idée de modifier une feature existante, à moins de pouvoir s'assurer que tous les utilisateurs de la feature seront satisfaits. Si tu veux que ton changement soit accepté, il me semble beaucoup naturel de faire de ton besoin un mode d'affichage des temps supplémentaire.