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.
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)
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.
Quelqu'un se rend compte que Let's Encrypt propose des certificats dont la durée de validité est de 90 jours, mais qu'en fait, la vraie validité est de 90 jours PLUS une seconde.
L'explication grossière, c'est que les certificats ont des champs notBefore et notAfter définis à la seconde près, et que le champ notAfter est calculé en faisant notBefore + 90 jours. Façon classique de faire, mais là ça ne marche pas parce que l'intervalle ]notBefore, notAfter[ est défini comme étant un intervalle ouvert par la norme, ce qui veut dire que le certificat est valide pour toute la seconde de la date notAfter. Pas de bol, les outils de linting / vérification auto étaient configurés pour vérifier que la duré de validité des certificats ne dépassait pas… deux cent et quelques jours. On est loin des 90 jours attendus.
Et du coup, après des années de fonctionnement comme ça sans que personne ne s'en rende compte, une équipe chez Let's Encrypt travaille en pleine nuit, dans l'urgence, pour rectifier le problème en faisant notAfter := notBefore + (90 jours - 1 seconde) pour les nouveaux certificats produits. Une très longue et verbeuse discussion s'en suit avec l'équipe conformité des autorités de certification de Mozilla sur le rapport d'incident chez eux.
Je comprends que c'est, formellement, un problème de sécurité / conformité à résoudre, mais j'ai du mal à voir les implications réelles, et imaginer des cas où ça peut poser problème en pratique, et par conséquent à comprendre pourquoi on fait travailler une équipe de nuit dans l'urgence pour un tel problème qui parait relativement bénin. D'autant qu'à un moment dans cette très longue discussion, une personne se demande « ah mais au fait vous avez pensé aux secondes intercalaires ? » pour que plus tard personne ne sache vraiment si les implémentations garantissent en pratique une granularité aussi fine que la seconde. En parallèle, on sent que les personnes ayant rédigé le rapport sont passablement agacées par le fait que du coup, elles sont obligées de spécifier des paramètres en secondes et plus en heures ou en jour, et plus tard dans les commentaires des gens se demandent si notAfter ne devrait pas être excluant et donc être renommé en un truc du genre before ou quelque chose comme ça.
J'ai l'impression que pour que l'incident pose réellement un problème de sécurité, il faudrait que un certificat affecté ait été volé, et là les attaquants pouvent exploiter le certificat compromis… 1 seconde de plus, à supposer que les implémentations sont aussi fine que ça ? Ou je suis complètement à côté de la plaque ?
Enfin bon, c'est un off-by-one amusant, et c'est un bon exemple de rapport d'incident auprès de l'équipe de conformité CA chez Mozilla facile à comprendre.
Beaucoup de mots pour un décalage d'une seconde (parce que bien sûr ça révèle des problèmes de procédures / vérifs, du coup), c'est là que finalement tu te rends compte que ton autorité de certification n'est probablement pas trop mal si elle en est à ce niveau de problème.
En même temps, pour un humain, ça demanderait des contorsions remarquables, de se mettre entre un miroir et la webcam ou de faire la réunion dos à la webcam (ce qui me semble peu commun et peu commode). Peu pratique. Le chat, lui, peut taper son message incompréhensible dans ta messagerie instantanée ET orienter son postérieur vers la caméra sans trop de difficulté…
La litière du chat remplace avantageusement le collègue qui ne se lave pas, et le chat ne porte pas de chaussette sous ses sandales ni de cravate. Comme toi en télétravail sauf en visio, il ne porte rien.
récemment la barre d'adresse qui grossit. Je m'y suis habitué donc ça ne me perturbe plus, mais je trouve ça toujours autant inutile, et surtout, inutilement différent du reste du monde
En fait je retire ça, Chrome le fait aussi (maintenant ?). Donc c'est la norme.
devoir à nouveau repasser des chemises et prendre une douche tous les jours
Essaie sans ? :-)
Bon ok, je ne parle que des chemises, j'ai laissé la douche dans la citation pour rigoler mais je suggère de continuer à la prendre au moins quand tu as transpiré ou que tu pues des pieds. Sinon, les collègues ne vont pas te remercier.
T-Shirt troués, sandales avec chaussettes, pas de cravatte : au plus proche des client·e·s… tels qu'ils sont dans leur vie familière, sans leurs barrières corporates.
[^] # Re: Clair depuis le début ?
Posté par raphj (site web personnel) . 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 (site web personnel) . 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 (site web personnel) . 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 (site web personnel) . 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 (site web personnel) . 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 (site web personnel) . 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 (site web personnel) . 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 (site web personnel) . 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 (site web personnel) . 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 (site web personnel) . 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 (site web personnel) . 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 (site web personnel) . 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 (site web personnel) . 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 (site web personnel) . 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 (site web personnel) . 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 (site web personnel) . 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 (site web personnel) . 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 (site web personnel) . 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.
# Résumé
Posté par raphj (site web personnel) . En réponse au lien Let's Encrypt: certificate lifetimes 90 days plus one second. Évalué à 10. Dernière modification le 16 juin 2021 à 19:05.
Quelqu'un se rend compte que Let's Encrypt propose des certificats dont la durée de validité est de 90 jours, mais qu'en fait, la vraie validité est de 90 jours PLUS une seconde.
L'explication grossière, c'est que les certificats ont des champs
notBeforeetnotAfterdéfinis à la seconde près, et que le champnotAfterest calculé en faisantnotBefore+ 90 jours. Façon classique de faire, mais là ça ne marche pas parce que l'intervalle]notBefore, notAfter[est défini comme étant un intervalle ouvert par la norme, ce qui veut dire que le certificat est valide pour toute la seconde de la datenotAfter. Pas de bol, les outils de linting / vérification auto étaient configurés pour vérifier que la duré de validité des certificats ne dépassait pas… deux cent et quelques jours. On est loin des 90 jours attendus.Et du coup, après des années de fonctionnement comme ça sans que personne ne s'en rende compte, une équipe chez Let's Encrypt travaille en pleine nuit, dans l'urgence, pour rectifier le problème en faisant
notAfter := notBefore + (90 jours - 1 seconde)pour les nouveaux certificats produits. Une très longue et verbeuse discussion s'en suit avec l'équipe conformité des autorités de certification de Mozilla sur le rapport d'incident chez eux.Je comprends que c'est, formellement, un problème de sécurité / conformité à résoudre, mais j'ai du mal à voir les implications réelles, et imaginer des cas où ça peut poser problème en pratique, et par conséquent à comprendre pourquoi on fait travailler une équipe de nuit dans l'urgence pour un tel problème qui parait relativement bénin. D'autant qu'à un moment dans cette très longue discussion, une personne se demande « ah mais au fait vous avez pensé aux secondes intercalaires ? » pour que plus tard personne ne sache vraiment si les implémentations garantissent en pratique une granularité aussi fine que la seconde. En parallèle, on sent que les personnes ayant rédigé le rapport sont passablement agacées par le fait que du coup, elles sont obligées de spécifier des paramètres en secondes et plus en heures ou en jour, et plus tard dans les commentaires des gens se demandent si
notAfterne devrait pas être excluant et donc être renommé en un truc du genrebeforeou quelque chose comme ça.J'ai l'impression que pour que l'incident pose réellement un problème de sécurité, il faudrait que un certificat affecté ait été volé, et là les attaquants pouvent exploiter le certificat compromis… 1 seconde de plus, à supposer que les implémentations sont aussi fine que ça ? Ou je suis complètement à côté de la plaque ?
Enfin bon, c'est un off-by-one amusant, et c'est un bon exemple de rapport d'incident auprès de l'équipe de conformité CA chez Mozilla facile à comprendre.
Beaucoup de mots pour un décalage d'une seconde (parce que bien sûr ça révèle des problèmes de procédures / vérifs, du coup), c'est là que finalement tu te rends compte que ton autorité de certification n'est probablement pas trop mal si elle en est à ce niveau de problème.
[^] # Re: Si le nouveau look ne vous revient pas
Posté par raphj (site web personnel) . En réponse au lien Nouveautés de Firefox 89. Évalué à 2.
Dans le doute tu peux toujours essayer avec un profil vierge.
[^] # Re: Si le nouveau look ne vous revient pas
Posté par raphj (site web personnel) . En réponse au lien Nouveautés de Firefox 89. Évalué à 2. Dernière modification le 10 juin 2021 à 07:19.
C'est dingue, je n'avais jamais remarqué ce bouton ! Bon, en tout cas j'ai bien un "Copy link" sur Firefox 89 dans ce bouton "…".
[^] # Re: Chemises
Posté par raphj (site web personnel) . En réponse au journal Je veux pas y retourner. Évalué à 5. Dernière modification le 03 juin 2021 à 21:33.
En même temps, pour un humain, ça demanderait des contorsions remarquables, de se mettre entre un miroir et la webcam ou de faire la réunion dos à la webcam (ce qui me semble peu commun et peu commode). Peu pratique. Le chat, lui, peut taper son message incompréhensible dans ta messagerie instantanée ET orienter son postérieur vers la caméra sans trop de difficulté…
[^] # Re: Chemises
Posté par raphj (site web personnel) . En réponse au journal Je veux pas y retourner. Évalué à 3. Dernière modification le 03 juin 2021 à 21:13.
Très correct. Vu sous cet angle… :-)
La litière du chat remplace avantageusement le collègue qui ne se lave pas, et le chat ne porte pas de chaussette sous ses sandales ni de cravate. Comme toi en télétravail sauf en visio, il ne porte rien.
[^] # Re: L'ancienne interface est cachée derrière une option
Posté par raphj (site web personnel) . En réponse au lien Réparer la nouvelle interface inutilisable de firefox 89. Évalué à 2.
En fait je retire ça, Chrome le fait aussi (maintenant ?). Donc c'est la norme.
# Chemises
Posté par raphj (site web personnel) . En réponse au journal Je veux pas y retourner. Évalué à 2. Dernière modification le 03 juin 2021 à 20:56.
Essaie sans ? :-)
Bon ok, je ne parle que des chemises, j'ai laissé la douche dans la citation pour rigoler mais je suggère de continuer à la prendre au moins quand tu as transpiré ou que tu pues des pieds. Sinon, les collègues ne vont pas te remercier.
T-Shirt troués, sandales avec chaussettes, pas de cravatte : au plus proche des client·e·s… tels qu'ils sont dans leur vie familière, sans leurs barrières corporates.