J'ai l'impression que quelque chose m'échappe, parce que je ne comprends pas grand chose à ce long journal et je ne comprends pas le contexte dans lequel il a été posté. Mais bon, allons-y malgré tout.
Croyez-moi, les gens biens ne deviennent pas Nazis
Pourquoi je te croirais ? Ton jeu s'appuie-t-il sur des études ? Est-ce si amusant que ça, essayer de classer les gens comme nazis potentiels ?
D'autant que ça fait un peu manichéen tout ça, « les gens biens » ? N'est-on pas toutes et tous le con de quelqu'un d'autre ? C'est quoi, une personne bien ?
Ta dernière ligne codée en ROT13 ne m'avance pas plus et je ne comprends pas pourquoi elle a été codée en ROT13.
Chercher à mettre des gens dans des catégories n'est pas toujours une bonne idée.
Bon, histoire de rendre mon commentaire un peu utile, je peux recommander la série télévisée Un Village Français qui donne un aperçu assez nuancé sur la période de la deuxième guerre mondiale. Je pense qu'elle est plutôt fidèle à la réalité (mais je ne suis pas historien), et en tout cas elle est agréable / divertissante (et pourtant, j'étais partis en mode « Oh non, pas encore un truc sur la deuxième guerre mondiale ! »).
Je vais aller dans ton sens. J'utilise openSUSE Tumbleweed depuis probablement 2-3 ans maintenant. Ça marche super.
Quelques points bloquant pour le grand public :
Ce n'est pas clair quel dépôt il faut utiliser pour installer VLC : Packman ou celui de VLC ? J'utilise Packman après quelques allez-retour, mais il y a ce genre de complications. En temps qu'européen utilisant une distribution européenne, j'aimerais ne pas avoir à me soucier des problèmes causés par les brevets logiciels outre-atlantiques.
Zypper est bien prompt à afficher qu'on a des paquets obsolètes et à proposer des changements de dépôts et on se retrouve à faire des résolutions de dépendances à la main… même quand le paquet qu'on a correspond à une version plus récente. Quand on rentre dans ce genre de situation, ça pète aussi les logithèques du genre "Discover"
Quelques bons points :
c'est stable. J'ai les dernières version des logiciels
et de l'environnement de bureau, et ça ne plante jamais
la résolution de dépendance guidée avec Zypper permet de se tirer facilement de situation qui seraient pénibles avec APT, qui refuse trop souvent d'installer quelque chose de manière plus ou moins compréhensible
on peut installer un tas de logiciels en quelques clics (depuis une page web), même depuis des dépôts qu'on n'a pas encore ajoutés (et qui seront alors ajoutés). Ça marche vraiment, alors qu'avec les liens apt c'est beaucoup plus aléatoire. L'ajout de dépôts ne requiert pas une de faire une dance GPG manuellement, ça se fait tout seul.
il y a des choses que je ne sais pas bien faire en ligne de commande… parce que j'ai surtout de l'expérience avec les distributions Debian et que l'interface graphique fonctionne suffisamment bien, donc c'est plutôt un bon point.
l'ergonomie de Zypper est excellente, certainement meilleure que ce que j'ai pu tester ailleurs (apt, aptitude, dnf, yum, urpmi, pacman)
Comparée à Debian testing / unstable, on a une vraie rolling release : il n'y a pas de gel avant la sortie des nouvelles versions, avec souvent un gros lag pour les versions des environnements de bureau. Comparée à Ubuntu, on n'a pas besoin de s'embêter avec snap. Comparée aux deux, on a un paquet Chromium en version récente qui fonctionne bien.
Les paquets qui ne sont pas dans la distribution officielle sont souvent dans des équivalents des dépôts PPA d'Ubuntu et facilement trouvables sur https://software.opensuse.org/. Ils sont pré-compilés, donc il n'y a pas besoin de les compiler localement, et on a quand même accès aux sources parce que les paquets sont compilés par le système de build d'openSUSE (OBS). On retombe sur les travers d'AUR sur le caractère non supporté mais ça concerne un très petit nombre de paquets sur une installation classique.
Je n'ai jamais trop testé Manjaro (destinée à un plus grand public que Arch, donc ça serait logique de le faire) donc ça va être difficile de comparer, mais je m'attends à ce qu'elle ait quelques points communs avec Arch. Pour l'avoir testée un moment sur le PinePhone, elle paraissait quand même beaucoup moins stable et robuste que Debian sur cet appareil. C'est d'ailleurs ce qui m'a fait passé à Debian. Mais ce n'est pas forcément représentatif.
Dans un monde où openSUSE Tumbleweed serait beaucoup plus populaire, je la conseillerais probablement à des gens moins versés dans l'informatique. Malheureusement, il est quand même probablement plus facile de trouver de l'aide pour des distributions plus populaires et un gros défaut des rolling releases, c'est quand même le poids important de mises à jour (probablement plusieurs giga par mois). Mais si le caractère rolling release est important, alors c'est peut-être bien le meilleur choix effectivement, et pas seulement pour ses outils graphiques excellents.
La question dépasse la GPL et le texte des licences, libres ou non d'ailleurs. C'est une question de droit d'auteur, donc faut regarder la loi. Ça varie d'ailleurs probablement un peu par pays, même si les lois derrières les questions de droits d'auteurs sont relativement compatibles à travers une bonne partie du monde.
Il faudrait donc démontrer que le code produit par l'algorithme puisse être qualifié de travail dérivé, ce qui ne peut se faire qu'au cas par cas
Exactement. Le problème c'est qu'on voudrait plutôt démontrer que le code produit par l'algorithme n'est pas un travail dérivé pour que son utilisation soit sûre. Ce qui est un peu compliqué.
Qui hormis le gens qui ne veulent pas qu'on puisse s'inspirer de leur code dit que c'est illégal (sur bases bancales)?
C'est une tournure malhonnête / de mauvaise foi. Ça ne me dit pas de raisonner si la malhonnêteté est dans l'équation.
des fans de copyleft
Ce n'est pas qu'une histoire de copyleft, tu le dis toi-même, les licences permissives requièrent également l'attribution.
confiances aux avocats
Oui, on peut espérer qu'ils font bien leur boulot, et il n'y a pas de raison de croire que ça n'est pas le cas. Le droit n'est pas une science exacte cela dit, je serais intéressé par des avis complémentaires d'autres avocats.
Parce que les auteurs de ce code n'ont pas dit "Quiconque a la liberté de lire le code", donc ils n'ont pas le droit et donc ne le font pas (autrement que ce pour quoi les utilisateurs ont signé, donc de la gestion de repo).
Bon point, le fair use ne peut pas s'appliquer sur du code que tu n'es pas censé lire. (😅). Ils pourraient le faire sur leur propre code par contre.
Pour le reste, tu pars du principe qu'une utilisation comme celle de GitHub est bien fair use, et que c'est bien équivalent à lire du code en tant qu'humain et s'en inspirer / apprendre dans le sens d'un humain. En présupposant ce principe tout ton discours est cohérent, mais il ne semble pas que cela fasse consensus. Je serais plus prudent / humble dans les affirmations. La question n'est pas si évidente.
Donc :
juste que des auteurs n'ont pas compris qu'ils donnaient à tous ceux qui ont l'URL la liberté de lire.
Je pense qu'ils ont compris ça, mais qu'ils ne sont pas du même avis que toi sur la question. Au final tu as peut-être raison et on peut espérer pour GitHub qu'ils ont bien étudié la question avec leurs avocats, perso pour le moment je préfère rester prudent et autant respecter cette position différente de la tienne.
(bon dans le cas de Copilot pour le moment ça recrache bel et bien du code donc pour moi c'est mort, mais on peut espérer pour eux qu'ils vont corriger ça… si c'est possible).
Est-ce qu'on peut imaginer que ça repompe des façon de coder d'un autre projet ? Toute une organisation ? Une classe ou une lib ?
Je ne m'y connais pas assez pour pouvoir affirmer que ce n'est pas intrinsèque à la technique (je suis ouvert à l'idée qu'une telle IA puisse éviter ça).
Peut-être que les cas où ça a été observé, les gens ont bidouillé et poussé l'IA à recracher du code tel quel, mais ça veut dire que rien ne garantit qu'elle ne le fait pas, et que ça pourrait aussi bien arriver dans un cas normal d'utilisation sans qu'on s'en rende compte.
Au final c'est cohérent : s'il n'y a pas besoin de respecter la GPL, il n'y a besoin de respecter aucune licence. Il n'y a donc pas de raison de se limiter aux licences libres.
En fait, il n'y a même pas besoin de se limiter au code disponible publiquement, ils auraient aussi bien pu également entraîner leur IA sur leur code privé et sur le code privé de leurs clients. Pourquoi ne le font-il pas ? Ça aurait un intérêt pour pouvoir reproduire leur travail à partir des mêmes données mais je ne suis pas certain qu'ils soient dans cette démarche : ils auraient ouvert le code de Copilot sinon.
Peut-être qu'ils ne le font pas parce qu'ils ont peur que leur IA recrache du code non public / confidentiel tel quel ? Oui, à leur place j'aurais peur de ça je crois. Du coup, on prend le risque de ne pas respecter les licences mais pas celui de mettre de fuiter des trucs confidentiels. Ou que leurs clients ne soient pas contents ? Deux poids, deux mesures ?
Assistons-nous finalement à une instance de si c'est gratuit, c'est vous le produit¹ avec GitHub ?
Que de questions.
¹: à noter que cette phrase s'applique mal dans beaucoup de cas, je ne suis pas particulièrement fan de cette phrase sans contexte
J'ai une analyse différente (il y a certainement un peu de vrai dans les deux analyses cela dit).
Je pense que le permissif est majoritaire parce que les entreprises sont plus intéressées par l'efficacité de l'open source que les libertés des utilisateurs. Au contraire, elles veulent pouvoir faire des produits finaux propriétaires, donc le copyleft ça ne le fait pas.
Pour ces boites, c'est ok de collaborer sur les outils de base : ça réduit les coûts, mais ce n'est pas là où est la valeur "bancable" : ça, c'est le produit final à destination de l'utilisateur final. Donc open source copyfree, c'est tout naturel.
Les indépendants et les boites qui s'intéressent réellement aux libertés des utilisateurs finaux ne font pas le poids en nombre et c'est pour ça qu'on voit peu de copyleft aujourd'hui en proportion.
Pourquoi ne pas avoir adopté la MPL ?
Parce que le fait que la licence que je choisi soit connue est bien plus important pour moi (et mes utilisateurs) que le copyleft.
Je trouve ça dommage. La MPL a l'air d'être ton idéal et elle semble compatible avec ton business. Elle a quand même sa part de notoriété (« c'est ce qu'ils utilisent chez Mozilla ») ; ce n'est pas non plus la petite licence obscure. J'allais te demander si ça ne te dirait pas de participer à ton échelle à cet idéal que tu as, mais tu sembles résigné, ou avoir finalement changé d'avis (tu ne sembles quand même pas avoir totalement abandonné le copyleft à te lire cela dit), ce que je respecte.
rappel : impossible de mélanger 2 codes copyleft si pas la même licence
C'est vrai, à modérer avec le fait que la plupart des licences copyleft sont justement compatibles avec la GPL parce que les gens ont bien compris ce problème. Le gros contre exemple, c'est la CDDL, intentionnellement incompatible avec la GPL pour empêcher les gens de mélanger ZFS avec Linux. Mais c'était une incompatibilité volontaire ! et la CDDL n'est quand même pas beaucoup utilisé sinon donc c'est plutôt anecdotique.
La zone sombre, c'est l'incompatibilité GPLv2 et GPLv3. C'est un vrai problème parce qu'il y a bel et bien une division, à moduler avec le fait qu'une grande partie des codes sont (L)GPLv2+ donc ça marche souvent quand même.
Exactement. Pour interdire tout ça, il faudrait une licence qui oblige à redistribuer les sources de toute modification privée (ou qui restreint certains usages, peut-être).
C'est ce qu'impose (entre autres) la licence (Open Watcom)[https://en.wikipedia.org/wiki/Sybase_Open_Watcom_Public_License), qui est la licence du compilateur qui sert à compiler le BIOS de VirtualBox. Résultat : elle n'est pas reconnue comme une licence libre par la FSF, les projets Debian, Fedora et un tas d'autres distributions. Elle est, par contre, reconnue comme Open Source par l'OSI.
Non, c'est très logique : à tout moment, l'utilisateur a accès aux sources et à tous les droits que garantissent un logiciel libre et c'est ce qui m'importe.
L'utilisateur ici c'est la boite.
Perso, en tant qu'utilisateur d'un logiciel libre sous GPL, je peux me faire une adaptation que je garde pour moi même sans la distribuer. C'est une liberté importante. Par contre, si je redistribue le binaire produit, il faut que je fournisse les sources aussi pour conférer aux prochains utilisateurs les mêmes droits.
Idem, si la boite fait une adaptation, elle a le droit de ne pas la redistribuer. Mais sort un jour son produit adapté en binaire, il faudra qu'elle sorte les sources aussi.
J'ai l'impression que je ne suis pas très clair sur cet aspect ?
j'aurai bien aimé faire du copyleft "correct" (je pense notamment à la MPL) mais les pro-GPL m'ont poussé dans les bras du permissif à force de faire la pub sur du copyleft "fort"
Pourquoi ne pas avoir adopté la MPL ?
Après, sur les libertés, il faut bien séparer liberté des utilisateurs et liberté des développeurs. C'est la première qui m'intéresse en premier. Les licences non-copyleft donnent plus de liberté aux développeurs, mais ce n'est pas ça que je recherche perso.
je pense que les gens adeptes du copyleft et de la GPL ont surtout peur que leur code leur échappe.
Non, pour moi il s'agit surtout de faire mon maximum pour que le travail que je produis finit dans des logiciels dont les utilisateurs bénéficient des droits qui définissent le logiciel libre et qu'ils puissent en conséquence avoir le contrôle sur leur informatique.
Avec comme hypothèse de base que le logiciel propriétaire ne leur permet pas ce contrôle et que ce contrôle est souhaitable (même s'ils ne l'utilisent pas à chaque fois, mais c'est vrai pour tous les droits).
Faire du permissif c'est pour moi prendre le risque que mon code finisse dans un logiciel dont les utilisateurs ne peuvent pas avoir le contrôle.
À noter que je vois le libre comme une condition nécessaire à ce contrôle, mais pas suffisante.
Pour moi c'est acceptable qu'une boite se serve de mon code en interne et qu'elle ne redistribue pas ses modifs pourvu que les clients de cette boite ou n'importe qui d'extérieur à la boite n'y soit pas exposé (c'est ce qu'essaie de faire la AGPL pour les outils qui tournent sur un serveur). Parce qu'ici, l'utilisateur c'est la boite. Bien sûr, ce serait gentil et cool que les modifs soient redistribuées mais je ne voudrais pas l'imposer.
La viralité rassure, car du coup, on se dit que si quelqu’un fork, on pourra toujours récupérer les modifications si ça nous intéresse. Mais est-ce vraiment le cas ?
Cela me chagrine d'autant plus que ces décisions coïncident avec l'arrivée en mainteneur de Tantacrul, déjà responsable sur Musescore, et dont j'apprécie assez les vidéos
Je ressens exactement la même chose et recommande les mêmes vidéos.
Posté par raphj .
En réponse au lien Télémétrie (?) Audacity.
Évalué à 4.
Dernière modification le 05 juillet 2021 à 08:08.
la GPL interdit d'interdire de tuer
c'est plutôt qu'elle n'interdit aucun usage.
Je ne pense pas que l'intention de la personne à laquelle tu réponds était mauvaise, parler de FUD me parait un peu sévère. Après, effectivement sur le fond, c'est ça. La loi pose un cadre que la licence ne peut pas dépasser.
Sinon oui, je ne comprends pas bien la direction que prend Audacity. Musescore, qui appartient à la même boite, n'a pas l'air de subir le même traitement.
ça me va très bien que tu apprennes de mon code libre pour faire ce que tu veux. Je préfèrerais que tu ne fasses pas de code proprio mais je ne voudrais pas te l'interdire. Parce qu'on est au niveau du partage de connaissance.
Par contre, ne produit pas d'oeuvre dérivé de mon travail qui est non libre.
Soit je t'ai mal compris, soit toi moi, soit tu caricatures ma position.
Nos peurs sont finalement avérée avec Copilot mais ça ne change pas grand chose à mon avis.
Et en soit, des projets qui ont absorbé ces codes pour divers usages sans l'accord explicite des détenteurs du copyright, ce n'est ni le premier ni le dernier, c'est juste mieux marketé.
Mhm… le Paradoxe du singe savant vient du fait que la séquence générée est vraiment aléatoire. Sur une infinité de temps on aura « presque sûrement » généré le noyau Linux. Mais si on retire l'aspect strictement aléatoire (l'IA n'est pas vraiment aléatoire), c'est foutu ma pauvre Lucette ! Il n'y a plus de garantie que ça va presque sûrement arriver.
Par contre, une question qui m'est venue pendant l'écriture de mon commentaire, c'est : que faire d'un dev qui produit par hasard fortuitement un code suffisamment proche d'un code existant ?
Pour moi il n'est pas coupable, mais il pourrait être condamné s'il n'arrive pas à prouver qu'il n'a jamais vu ce code existant.
Ça doit forcément arriver, en plus, pour des bouts de codes relativement courts…
Normalement, les licences prennent effet sur des bouts de codes non triviaux. Si on « copie » des petits bouts « non significatifs », c'est tout bon, la licence ne s'applique pas.
Où est la limite ? Je ne sais pas. Autant être prudent, du coup.
Pour moi, si cette IA recrache un extrait significatif d'un code (à des renommages / indentations prêt), le développeur risque de produire ce qui pourrait être considéré comme un travail dérivé. Peu importe la techno derrière l'outil. Sauf qu'il ne le sait pas, contrairement à quelqu'un qui copierait directement sans utiliser un outil qui le fait pour lui.
Sinon, si cette IA ne recrache que des extraits non significatifs, c'est ok. Sauf si la somme des extraits sortis par l'IA reconstitue un code existant sur lequel elle s'est appuyée, ou un truc qui y ressemble « suffisamment ». Ou que le développeur fait ressembler l'ensemble à ce code déjà existant. Difficile à savoir aussi.
Après, est-ce très différent d'une personne qui a vu beaucoup de code (propriétaire ou non, GPL ou non) et qui écrit un nouveau code, certainement en s'inspirant de son expérience et de ses lectures passées ? Je ne sais pas non plus.
Dans tous les cas, si l'outil a des chances de recracher un bout de code non significatif existant, c'est juste un outil qui a permis de copier, de manière un peu fancy, sans même s'en rendre compte, et le dev n'a pas trop de manière de prouver qu'il n'a pas intentionnellement copié et qu'il a utilisé ce genre d'outil. C'est certainement lui qui est responsable d'un plagiat « fortuit ».
En tant qu'auteur de logiciels libres, je suis mal à l'aise sur le fait que mon code puisse être utilisé de cette manière pour produire un outil non libre et commercial¹ permettant d'écrire du code non libre. Je voudrais interdire ça. Par contre, je ne peux pas interdire les gens à publier mon code sur GitHub (ce que je ne fais pas moi-même pour le code que je contrôle, et c'est tant mieux), parce que ça demanderait de rendre mon code non libre. Donc je suis niqué, je crois.
J'imagine que les avocats de chez GitHub ont bien bossé sur le sujet mais j'espère quand-même que quelqu'un finira par trouver que ce n'est pas légal de prendre du code pour entrainer une telle IA, sans respecter les licences. Les licences comme la (A)GPL, certes, et c'est ma licence de choix, mais aussi des licences permissives qui requièrent quand-même de mentionner les auteurs.
En tant qu'utilisateur potentiel de l'outil, perso je passe mon tour. Ça me parait trop risqué légalement, et si on sort du cadre légal, je ne suis pas à l'aise avec l'idée vis à vis des auteurs des codes sur lesquels il a été entrainé.
Je trouve l'idée très cool et très intéressante (voire géniale) sur un point de vue scientifique, l'outil concret, un peu moins.
Tout ça est une réaction à chaud, c'est encore trop tôt pour avoir un avis tranché sur tout cas pour le moment.
¹ dans la FAQ du site :
Will there be a paid version?
If the technical preview is successful, our plan is to build a commercial version of GitHub Copilot in the future. We want to use the preview to learn how people use GitHub Copilot and what it takes to operate it at scale.
(et donc si vous l'essayez, vous aidez GitHub à élaborer son outil commercial sans rémunération. On peut voir l'échange comme gagnant-gagnant, ou pas, à chacun de voir)
Posté par raphj .
En réponse au journal Vote électronique.
Évalué à 2.
Dernière modification le 29 juin 2021 à 08:25.
Perso, je trouverais ça très pratique de voter par correspondance. Mais il y a un problème majeur avec ça : on ne peut pas s'assurer que les gens ne votent pas sous la contrainte de quelqu'un d'autre, et de manière confidentielle. Ça ne concerne pas que le vote électronique : c'est vrai aussi pour le vote par courrier. Pour moi, c'est le premier argument contre le vote par correspondance : il est simple à comprendre et puissant.
Une solution intermédiaire serait de pouvoir voter dans n'importe quelle mairie, mais ça veut dire d'introduire des ordinateurs dans toutes les mairies, avec toutes les galères que ça peut entrainer (problèmes de connexions, bugs, plantages, ralentissements…).
Ensuite, bien sûr qu'il faut que le système de vote soit vérifiable, et donc le code accessible, mais ça c'est loin d'être suffisant parce qu'il faudrait théoriquement pouvoir analyser tout le matériel aussi.
Oui, on parle d'un problème présent depuis les débuts de Let's Encrypt si j'ai bien compris, donc depuis cinq-six ans, donc quelques heures de plus…
Après, je comprends qu'on demande à une autorité d'être impeccable niveau temps de réponse et réactivité. J'imagine que dans ce milieu, ça la fout mal que dans un rapport d'incident, tu dises « ouais, ben on a été se coucher et on a étudié l'affaire qui impacte nos XXX millions de certificats actuellement valides le lendemain matin tranquilou bilou ».
Et je comprends aussi que dans ce domaine, on a besoin de gens attachés aux règles et aux procédures et à leur application stricte.
[^] # Re: Pas compris grand chose
Posté par raphj . En réponse au journal Comment reconnaitre un·e Nazi·e potentiel·le ?. Évalué à 7.
Ah oui, effectivement, je n'avais pas la ref. Pourtant j'ai dû la croiser à un moment parce que ça me disait vaguement quelque chose.
Un bon Whoosh en règle je suppose. Bien joué pour le clin d'œil et l'exercice de style du coup.
Rendez-vous à la prochaine illustration de mon ignorance.
[^] # Re: Pas compris grand chose
Posté par raphj . En réponse au journal Comment reconnaitre un·e Nazi·e potentiel·le ?. Évalué à 7.
Ah, ouf, je suis rassuré !
(ou nazi susceptible, peut-être ?!)
[^] # Re: Pas lu plus d'une ligne
Posté par raphj . En réponse au journal Comment reconnaitre un·e Nazi·e potentiel·le ?. Évalué à -2. Dernière modification le 02 août 2021 à 08:22.
Difficile de comprendre quel problème spécifique est soulevé en effet, Single a écrit en substance "c'est mal écrit" sans rentrer dans le détail.
# Pas compris grand chose
Posté par raphj . En réponse au journal Comment reconnaitre un·e Nazi·e potentiel·le ?. Évalué à 10. Dernière modification le 02 août 2021 à 08:12.
J'ai l'impression que quelque chose m'échappe, parce que je ne comprends pas grand chose à ce long journal et je ne comprends pas le contexte dans lequel il a été posté. Mais bon, allons-y malgré tout.
Pourquoi je te croirais ? Ton jeu s'appuie-t-il sur des études ? Est-ce si amusant que ça, essayer de classer les gens comme nazis potentiels ?
D'autant que ça fait un peu manichéen tout ça, « les gens biens » ? N'est-on pas toutes et tous le con de quelqu'un d'autre ? C'est quoi, une personne bien ?
Ta dernière ligne codée en ROT13 ne m'avance pas plus et je ne comprends pas pourquoi elle a été codée en ROT13.
Chercher à mettre des gens dans des catégories n'est pas toujours une bonne idée.
Bon, histoire de rendre mon commentaire un peu utile, je peux recommander la série télévisée Un Village Français qui donne un aperçu assez nuancé sur la période de la deuxième guerre mondiale. Je pense qu'elle est plutôt fidèle à la réalité (mais je ne suis pas historien), et en tout cas elle est agréable / divertissante (et pourtant, j'étais partis en mode « Oh non, pas encore un truc sur la deuxième guerre mondiale ! »).
[^] # Re: La reine ? Grand public ? Vraiment ?
Posté par raphj . En réponse au lien Linux : Manjaro, la reine des distributions rolling release grand public (libre accès dans 1 mois). Évalué à 3. Dernière modification le 29 juillet 2021 à 13:37.
Je vais aller dans ton sens. J'utilise openSUSE Tumbleweed depuis probablement 2-3 ans maintenant. Ça marche super.
Quelques points bloquant pour le grand public :
Quelques bons points :
Comparée à Debian testing / unstable, on a une vraie rolling release : il n'y a pas de gel avant la sortie des nouvelles versions, avec souvent un gros lag pour les versions des environnements de bureau. Comparée à Ubuntu, on n'a pas besoin de s'embêter avec snap. Comparée aux deux, on a un paquet Chromium en version récente qui fonctionne bien.
Par rapport à Arch, beaucoup plus de paquets à la périphérie font partie de la distribution officielle : il n'y pas besoin d'avoir affaire à un dépôt style AUR + un gestionnaire de paquets non supportés et la qualité du packaging est uniforme.
Les paquets qui ne sont pas dans la distribution officielle sont souvent dans des équivalents des dépôts PPA d'Ubuntu et facilement trouvables sur https://software.opensuse.org/. Ils sont pré-compilés, donc il n'y a pas besoin de les compiler localement, et on a quand même accès aux sources parce que les paquets sont compilés par le système de build d'openSUSE (OBS). On retombe sur les travers d'AUR sur le caractère non supporté mais ça concerne un très petit nombre de paquets sur une installation classique.
Enfin, les utilisateurs d'openSUSE ne sont pas particulièrement supposés lire de la doc pour savoir s'ils risquent de péter leur installation en faisant une mise à jour.
Je n'ai jamais trop testé Manjaro (destinée à un plus grand public que Arch, donc ça serait logique de le faire) donc ça va être difficile de comparer, mais je m'attends à ce qu'elle ait quelques points communs avec Arch. Pour l'avoir testée un moment sur le PinePhone, elle paraissait quand même beaucoup moins stable et robuste que Debian sur cet appareil. C'est d'ailleurs ce qui m'a fait passé à Debian. Mais ce n'est pas forcément représentatif.
Dans un monde où openSUSE Tumbleweed serait beaucoup plus populaire, je la conseillerais probablement à des gens moins versés dans l'informatique. Malheureusement, il est quand même probablement plus facile de trouver de l'aide pour des distributions plus populaires et un gros défaut des rolling releases, c'est quand même le poids important de mises à jour (probablement plusieurs giga par mois). Mais si le caractère rolling release est important, alors c'est peut-être bien le meilleur choix effectivement, et pas seulement pour ses outils graphiques excellents.
[^] # Re: Clair depuis le début ?
Posté par raphj . En réponse au lien Github a utilisé tout le contenu public de github pour entrainer Copilot. Évalué à 6. Dernière modification le 08 juillet 2021 à 14:06.
La question dépasse la GPL et le texte des licences, libres ou non d'ailleurs. C'est une question de droit d'auteur, donc faut regarder la loi. Ça varie d'ailleurs probablement un peu par pays, même si les lois derrières les questions de droits d'auteurs sont relativement compatibles à travers une bonne partie du monde.
Exactement. Le problème c'est qu'on voudrait plutôt démontrer que le code produit par l'algorithme n'est pas un travail dérivé pour que son utilisation soit sûre. Ce qui est un peu compliqué.
[^] # Re: Clair depuis le début ?
Posté par raphj . En réponse au lien Github a utilisé tout le contenu public de github pour entrainer Copilot. Évalué à 4. Dernière modification le 08 juillet 2021 à 13:55.
C'est une tournure malhonnête / de mauvaise foi. Ça ne me dit pas de raisonner si la malhonnêteté est dans l'équation.
Ce n'est pas qu'une histoire de copyleft, tu le dis toi-même, les licences permissives requièrent également l'attribution.
Oui, on peut espérer qu'ils font bien leur boulot, et il n'y a pas de raison de croire que ça n'est pas le cas. Le droit n'est pas une science exacte cela dit, je serais intéressé par des avis complémentaires d'autres avocats.
Exactement !
[^] # Re: Clair depuis le début ?
Posté par raphj . En réponse au lien Github a utilisé tout le contenu public de github pour entrainer Copilot. Évalué à 5. Dernière modification le 08 juillet 2021 à 13:21.
Bon point, le fair use ne peut pas s'appliquer sur du code que tu n'es pas censé lire. (😅). Ils pourraient le faire sur leur propre code par contre.
Pour le reste, tu pars du principe qu'une utilisation comme celle de GitHub est bien fair use, et que c'est bien équivalent à lire du code en tant qu'humain et s'en inspirer / apprendre dans le sens d'un humain. En présupposant ce principe tout ton discours est cohérent, mais il ne semble pas que cela fasse consensus. Je serais plus prudent / humble dans les affirmations. La question n'est pas si évidente.
Donc :
Je pense qu'ils ont compris ça, mais qu'ils ne sont pas du même avis que toi sur la question. Au final tu as peut-être raison et on peut espérer pour GitHub qu'ils ont bien étudié la question avec leurs avocats, perso pour le moment je préfère rester prudent et autant respecter cette position différente de la tienne.
(bon dans le cas de Copilot pour le moment ça recrache bel et bien du code donc pour moi c'est mort, mais on peut espérer pour eux qu'ils vont corriger ça… si c'est possible).
[^] # Re: Une réaction rigolote
Posté par raphj . En réponse au lien Github a utilisé tout le contenu public de github pour entrainer Copilot. Évalué à 6.
Je ne m'y connais pas assez pour pouvoir affirmer que ce n'est pas intrinsèque à la technique (je suis ouvert à l'idée qu'une telle IA puisse éviter ça).
Par contre, pour GitHub Copilot, il n'y a pas besoin de l'imaginer, elle le fait : https://twitter.com/mitsuhiko/status/1410886329924194309
Peut-être que les cas où ça a été observé, les gens ont bidouillé et poussé l'IA à recracher du code tel quel, mais ça veut dire que rien ne garantit qu'elle ne le fait pas, et que ça pourrait aussi bien arriver dans un cas normal d'utilisation sans qu'on s'en rende compte.
# Clair depuis le début ?
Posté par raphj . En réponse au lien Github a utilisé tout le contenu public de github pour entrainer Copilot. Évalué à 7. Dernière modification le 08 juillet 2021 à 12:49.
Au final c'est cohérent : s'il n'y a pas besoin de respecter la GPL, il n'y a besoin de respecter aucune licence. Il n'y a donc pas de raison de se limiter aux licences libres.
En fait, il n'y a même pas besoin de se limiter au code disponible publiquement, ils auraient aussi bien pu également entraîner leur IA sur leur code privé et sur le code privé de leurs clients. Pourquoi ne le font-il pas ? Ça aurait un intérêt pour pouvoir reproduire leur travail à partir des mêmes données mais je ne suis pas certain qu'ils soient dans cette démarche : ils auraient ouvert le code de Copilot sinon.
Peut-être qu'ils ne le font pas parce qu'ils ont peur que leur IA recrache du code non public / confidentiel tel quel ? Oui, à leur place j'aurais peur de ça je crois. Du coup, on prend le risque de ne pas respecter les licences mais pas celui de mettre de fuiter des trucs confidentiels. Ou que leurs clients ne soient pas contents ? Deux poids, deux mesures ?
Assistons-nous finalement à une instance de si c'est gratuit, c'est vous le produit¹ avec GitHub ?
Que de questions.
¹: à noter que cette phrase s'applique mal dans beaucoup de cas, je ne suis pas particulièrement fan de cette phrase sans contexte
[^] # Re: Commentaire suivant
Posté par raphj . En réponse au lien John Carmack (ID Software : Doom, Quake, etc), la GPL et la licence BSD. Évalué à 3. Dernière modification le 06 juillet 2021 à 19:29.
J'ai une analyse différente (il y a certainement un peu de vrai dans les deux analyses cela dit).
Je pense que le permissif est majoritaire parce que les entreprises sont plus intéressées par l'efficacité de l'open source que les libertés des utilisateurs. Au contraire, elles veulent pouvoir faire des produits finaux propriétaires, donc le copyleft ça ne le fait pas.
Pour ces boites, c'est ok de collaborer sur les outils de base : ça réduit les coûts, mais ce n'est pas là où est la valeur "bancable" : ça, c'est le produit final à destination de l'utilisateur final. Donc open source copyfree, c'est tout naturel.
Les indépendants et les boites qui s'intéressent réellement aux libertés des utilisateurs finaux ne font pas le poids en nombre et c'est pour ça qu'on voit peu de copyleft aujourd'hui en proportion.
Je trouve ça dommage. La MPL a l'air d'être ton idéal et elle semble compatible avec ton business. Elle a quand même sa part de notoriété (« c'est ce qu'ils utilisent chez Mozilla ») ; ce n'est pas non plus la petite licence obscure. J'allais te demander si ça ne te dirait pas de participer à ton échelle à cet idéal que tu as, mais tu sembles résigné, ou avoir finalement changé d'avis (tu ne sembles quand même pas avoir totalement abandonné le copyleft à te lire cela dit), ce que je respecte.
C'est vrai, à modérer avec le fait que la plupart des licences copyleft sont justement compatibles avec la GPL parce que les gens ont bien compris ce problème. Le gros contre exemple, c'est la CDDL, intentionnellement incompatible avec la GPL pour empêcher les gens de mélanger ZFS avec Linux. Mais c'était une incompatibilité volontaire ! et la CDDL n'est quand même pas beaucoup utilisé sinon donc c'est plutôt anecdotique.
La zone sombre, c'est l'incompatibilité GPLv2 et GPLv3. C'est un vrai problème parce qu'il y a bel et bien une division, à moduler avec le fait qu'une grande partie des codes sont (L)GPLv2+ donc ça marche souvent quand même.
[^] # Re: Commentaire suivant
Posté par raphj . En réponse au lien John Carmack (ID Software : Doom, Quake, etc), la GPL et la licence BSD. Évalué à 4. Dernière modification le 06 juillet 2021 à 18:52.
Exactement. Pour interdire tout ça, il faudrait une licence qui oblige à redistribuer les sources de toute modification privée (ou qui restreint certains usages, peut-être).
C'est ce qu'impose (entre autres) la licence (Open Watcom)[https://en.wikipedia.org/wiki/Sybase_Open_Watcom_Public_License), qui est la licence du compilateur qui sert à compiler le BIOS de VirtualBox. Résultat : elle n'est pas reconnue comme une licence libre par la FSF, les projets Debian, Fedora et un tas d'autres distributions. Elle est, par contre, reconnue comme Open Source par l'OSI.
[^] # Re: Commentaire suivant
Posté par raphj . En réponse au lien John Carmack (ID Software : Doom, Quake, etc), la GPL et la licence BSD. Évalué à 6.
Non, c'est très logique : à tout moment, l'utilisateur a accès aux sources et à tous les droits que garantissent un logiciel libre et c'est ce qui m'importe.
L'utilisateur ici c'est la boite.
Perso, en tant qu'utilisateur d'un logiciel libre sous GPL, je peux me faire une adaptation que je garde pour moi même sans la distribuer. C'est une liberté importante. Par contre, si je redistribue le binaire produit, il faut que je fournisse les sources aussi pour conférer aux prochains utilisateurs les mêmes droits.
Idem, si la boite fait une adaptation, elle a le droit de ne pas la redistribuer. Mais sort un jour son produit adapté en binaire, il faudra qu'elle sorte les sources aussi.
J'ai l'impression que je ne suis pas très clair sur cet aspect ?
[^] # Re: Commentaire suivant
Posté par raphj . En réponse au lien John Carmack (ID Software : Doom, Quake, etc), la GPL et la licence BSD. Évalué à 3. Dernière modification le 06 juillet 2021 à 17:07.
Pourquoi ne pas avoir adopté la MPL ?
Après, sur les libertés, il faut bien séparer liberté des utilisateurs et liberté des développeurs. C'est la première qui m'intéresse en premier. Les licences non-copyleft donnent plus de liberté aux développeurs, mais ce n'est pas ça que je recherche perso.
[^] # Re: Commentaire suivant
Posté par raphj . En réponse au lien John Carmack (ID Software : Doom, Quake, etc), la GPL et la licence BSD. Évalué à 9. Dernière modification le 06 juillet 2021 à 17:02.
Non, pour moi il s'agit surtout de faire mon maximum pour que le travail que je produis finit dans des logiciels dont les utilisateurs bénéficient des droits qui définissent le logiciel libre et qu'ils puissent en conséquence avoir le contrôle sur leur informatique.
Avec comme hypothèse de base que le logiciel propriétaire ne leur permet pas ce contrôle et que ce contrôle est souhaitable (même s'ils ne l'utilisent pas à chaque fois, mais c'est vrai pour tous les droits).
Faire du permissif c'est pour moi prendre le risque que mon code finisse dans un logiciel dont les utilisateurs ne peuvent pas avoir le contrôle.
À noter que je vois le libre comme une condition nécessaire à ce contrôle, mais pas suffisante.
Pour moi c'est acceptable qu'une boite se serve de mon code en interne et qu'elle ne redistribue pas ses modifs pourvu que les clients de cette boite ou n'importe qui d'extérieur à la boite n'y soit pas exposé (c'est ce qu'essaie de faire la AGPL pour les outils qui tournent sur un serveur). Parce qu'ici, l'utilisateur c'est la boite. Bien sûr, ce serait gentil et cool que les modifs soient redistribuées mais je ne voudrais pas l'imposer.
Non. Il peut exister des forks privés.
[^] # Re: surveillance ?
Posté par raphj . En réponse au lien Télémétrie (?) Audacity. Évalué à 4.
Je ressens exactement la même chose et recommande les mêmes vidéos.
[^] # Re: surveillance ?
Posté par raphj . En réponse au lien Télémétrie (?) Audacity. Évalué à 4. Dernière modification le 05 juillet 2021 à 08:08.
c'est plutôt qu'elle n'interdit aucun usage.
Je ne pense pas que l'intention de la personne à laquelle tu réponds était mauvaise, parler de FUD me parait un peu sévère. Après, effectivement sur le fond, c'est ça. La loi pose un cadre que la licence ne peut pas dépasser.
Sinon oui, je ne comprends pas bien la direction que prend Audacity. Musescore, qui appartient à la même boite, n'a pas l'air de subir le même traitement.
[^] # Re: Un sacré merdier ?
Posté par raphj . En réponse au journal GitHub lance copilot, un générateur de code entraîné sur du code GPL. Évalué à 8.
ça me va très bien que tu apprennes de mon code libre pour faire ce que tu veux. Je préfèrerais que tu ne fasses pas de code proprio mais je ne voudrais pas te l'interdire. Parce qu'on est au niveau du partage de connaissance.
Par contre, ne produit pas d'oeuvre dérivé de mon travail qui est non libre.
Soit je t'ai mal compris, soit toi moi, soit tu caricatures ma position.
Nos peurs sont finalement avérée avec Copilot mais ça ne change pas grand chose à mon avis.
https://twitter.com/mitsuhiko/status/1410886329924194309
Copilot regurgitating Quake code, including sweary comments
[^] # Re: Un sacré merdier ?
Posté par raphj . En réponse au journal GitHub lance copilot, un générateur de code entraîné sur du code GPL. Évalué à 3.
Tu as des exemples ? Ça m'intéresse.
[^] # Re: Un sacré merdier ?
Posté par raphj . En réponse au journal GitHub lance copilot, un générateur de code entraîné sur du code GPL. Évalué à 3.
Je comprends la présomption d'innocence, mais que faire si la ressemblance est considérée comme une preuve ?
(à vrai dire, je ne sais pas comment ça se passe en pratique, si ça ce trouve je dis totalement de la merde)
[^] # Re: Un sacré merdier ?
Posté par raphj . En réponse au journal GitHub lance copilot, un générateur de code entraîné sur du code GPL. Évalué à 5. Dernière modification le 01 juillet 2021 à 19:38.
Mhm… le Paradoxe du singe savant vient du fait que la séquence générée est vraiment aléatoire. Sur une infinité de temps on aura « presque sûrement » généré le noyau Linux. Mais si on retire l'aspect strictement aléatoire (l'IA n'est pas vraiment aléatoire), c'est foutu ma pauvre Lucette ! Il n'y a plus de garantie que ça va presque sûrement arriver.
Par contre, une question qui m'est venue pendant l'écriture de mon commentaire, c'est : que faire d'un dev qui produit par hasard fortuitement un code suffisamment proche d'un code existant ?
Pour moi il n'est pas coupable, mais il pourrait être condamné s'il n'arrive pas à prouver qu'il n'a jamais vu ce code existant.
Ça doit forcément arriver, en plus, pour des bouts de codes relativement courts…
# Un sacré merdier ?
Posté par raphj . En réponse au journal GitHub lance copilot, un générateur de code entraîné sur du code GPL. Évalué à 10.
Normalement, les licences prennent effet sur des bouts de codes non triviaux. Si on « copie » des petits bouts « non significatifs », c'est tout bon, la licence ne s'applique pas.
Où est la limite ? Je ne sais pas. Autant être prudent, du coup.
Pour moi, si cette IA recrache un extrait significatif d'un code (à des renommages / indentations prêt), le développeur risque de produire ce qui pourrait être considéré comme un travail dérivé. Peu importe la techno derrière l'outil. Sauf qu'il ne le sait pas, contrairement à quelqu'un qui copierait directement sans utiliser un outil qui le fait pour lui.
Sinon, si cette IA ne recrache que des extraits non significatifs, c'est ok. Sauf si la somme des extraits sortis par l'IA reconstitue un code existant sur lequel elle s'est appuyée, ou un truc qui y ressemble « suffisamment ». Ou que le développeur fait ressembler l'ensemble à ce code déjà existant. Difficile à savoir aussi.
Après, est-ce très différent d'une personne qui a vu beaucoup de code (propriétaire ou non, GPL ou non) et qui écrit un nouveau code, certainement en s'inspirant de son expérience et de ses lectures passées ? Je ne sais pas non plus.
Dans tous les cas, si l'outil a des chances de recracher un bout de code non significatif existant, c'est juste un outil qui a permis de copier, de manière un peu fancy, sans même s'en rendre compte, et le dev n'a pas trop de manière de prouver qu'il n'a pas intentionnellement copié et qu'il a utilisé ce genre d'outil. C'est certainement lui qui est responsable d'un plagiat « fortuit ».
En tant qu'auteur de logiciels libres, je suis mal à l'aise sur le fait que mon code puisse être utilisé de cette manière pour produire un outil non libre et commercial¹ permettant d'écrire du code non libre. Je voudrais interdire ça. Par contre, je ne peux pas interdire les gens à publier mon code sur GitHub (ce que je ne fais pas moi-même pour le code que je contrôle, et c'est tant mieux), parce que ça demanderait de rendre mon code non libre. Donc je suis niqué, je crois.
J'imagine que les avocats de chez GitHub ont bien bossé sur le sujet mais j'espère quand-même que quelqu'un finira par trouver que ce n'est pas légal de prendre du code pour entrainer une telle IA, sans respecter les licences. Les licences comme la (A)GPL, certes, et c'est ma licence de choix, mais aussi des licences permissives qui requièrent quand-même de mentionner les auteurs.
En tant qu'utilisateur potentiel de l'outil, perso je passe mon tour. Ça me parait trop risqué légalement, et si on sort du cadre légal, je ne suis pas à l'aise avec l'idée vis à vis des auteurs des codes sur lesquels il a été entrainé.
Je trouve l'idée très cool et très intéressante (voire géniale) sur un point de vue scientifique, l'outil concret, un peu moins.
Tout ça est une réaction à chaud, c'est encore trop tôt pour avoir un avis tranché sur tout cas pour le moment.
¹ dans la FAQ du site :
(et donc si vous l'essayez, vous aidez GitHub à élaborer son outil commercial sans rémunération. On peut voir l'échange comme gagnant-gagnant, ou pas, à chacun de voir)
# Vote par correspondance
Posté par raphj . En réponse au journal Vote électronique. Évalué à 2. Dernière modification le 29 juin 2021 à 08:25.
Perso, je trouverais ça très pratique de voter par correspondance. Mais il y a un problème majeur avec ça : on ne peut pas s'assurer que les gens ne votent pas sous la contrainte de quelqu'un d'autre, et de manière confidentielle. Ça ne concerne pas que le vote électronique : c'est vrai aussi pour le vote par courrier. Pour moi, c'est le premier argument contre le vote par correspondance : il est simple à comprendre et puissant.
Une solution intermédiaire serait de pouvoir voter dans n'importe quelle mairie, mais ça veut dire d'introduire des ordinateurs dans toutes les mairies, avec toutes les galères que ça peut entrainer (problèmes de connexions, bugs, plantages, ralentissements…).
Ensuite, bien sûr qu'il faut que le système de vote soit vérifiable, et donc le code accessible, mais ça c'est loin d'être suffisant parce qu'il faudrait théoriquement pouvoir analyser tout le matériel aussi.
[^] # Re: Calculatrice "pas bête" pour PC et *phone : Kalgebra
Posté par raphj . En réponse au journal Calculatrice graphique?. Évalué à 2.
J'étais venu pour suggérer KAlgebra effectivement, et GeoGebra :-) (les deux sont dans les dépôts de beaucoup de distributions)
[^] # Re: Résumé
Posté par raphj . En réponse au lien Let's Encrypt: certificate lifetimes 90 days plus one second. Évalué à 4. Dernière modification le 16 juin 2021 à 19:55.
Oui, on parle d'un problème présent depuis les débuts de Let's Encrypt si j'ai bien compris, donc depuis cinq-six ans, donc quelques heures de plus…
Après, je comprends qu'on demande à une autorité d'être impeccable niveau temps de réponse et réactivité. J'imagine que dans ce milieu, ça la fout mal que dans un rapport d'incident, tu dises « ouais, ben on a été se coucher et on a étudié l'affaire qui impacte nos XXX millions de certificats actuellement valides le lendemain matin tranquilou bilou ».
Et je comprends aussi que dans ce domaine, on a besoin de gens attachés aux règles et aux procédures et à leur application stricte.