Tu fais une mauvaise interprétation de la section 2: elle indique que les termes protégés (donc OSI, Open Source Initiative et le logo, c'est très clair dans la section 1) peuvent être utilisés sans autorisation de l'OSI dans les contextes ou "open source" désigne une licence approuvée par OSI. En aucun cas elle n'indique que le terme "open source" est protégé.
Concernant la protection de termes du langage courant, c'est en effet possible mais compliqué: par exemple Orange est déposé en tant que marque pour un certain type de produits, et Orange ne pourra donc rien revendiquer si on parle du fruit. Les organismes nationaux ou internationaux de protection des marques sont très regardants lorsqu'une société tente de déposer comme marque une expression du langage courant.
Enfin concernant l'utilisation générale du terme "olympique", il ne s'agit pas d'une protection de marque (même si le logo et un certain nombre de termes comme "Jeux Olympiques" sont protégés comme marque) de mais d'une loi spécifique que chaque pays organisateur de JO (ou peut-être même participant, je ne suis pas certain...) se doit de mettre en place, à la demande du CIO. Il s'agit pour la France de l'article 141-5 du Code du sport.
Tu fais une mauvaise interprétation de la section 2:
Merdouille. Je crois bien que tu aies raison sur ce point. En relisant avec ton interprétation, je me dis que tu as sans doute raison.
Enfin concernant l'utilisation générale du terme "olympique", il ne s'agit pas d'une protection de marque [...]. Il s'agit pour la France de l'article 141-5 du Code du sport.
Effectivement, merci. Je ne savais pas que c'était une loi spécifique. Les termes protégés sont donc : - jeux Olympiques - olympisme - olympiade - le sigle “ JO ”
C'est bien ce que j'ai dit "elles imposent strictement la préservation de la licence est des libertés sur tout dérivé de l'application"
Donc pas de problème pour de la bidouille sur son propre système ou son propre serveur, pas contre si on compte redistribuer, c'est un autre problème.
D'ailleurs pour les modules propriétaires du noyau, c'est exactement cette situation qui s'applique: personne ne peut redistribuer directement des modules noyau propriétaires nvidia sous forme binaire, donc il est nécessaire d'avoir une transformation/compilation pour finaliser l'installation. (vive dkms pour ça)
C'est bien ce que j'ai dit "elles imposent strictement la préservation de la licence est des libertés sur tout dérivé de l'application"
Oui, c'est ce que tu disais, mais je trouvais la formulation imprécise pour quelqu'un qui ne connaitrait pas les subtilités des licences. Comprendre que la notion de "dérivé d'application" désigne aussi une application qui utilise une bibliothèque sous GPL par exemple, ça ne coule pas forcément de source ;)
Le
27/09/2024 à
11h
02
C'est inexact, et le lien que tu as mis vers le OSI Trademark Guidelines l'explique bien: ce qui est copyrigthé c'est Open Source Initiative, OSI et le logo associé. Le terme "open source" ou "sources ouvertes" en français est une expression du langage courant qui ne peut être protégée. Comme l'ont rappelé d'autres intervenants il n'y a pas de définition officielle de ce terme. L'OSI aimerait bien que sa propre interprétation devienne la définition officielle, mais ils n'ont pas plus de légitimité que qui que ce soit pour l'imposer.
Non. Toujours cf mon lien, section 2 (Usage That Does Not Require Written Permission)
the use of the term “Open Source” is used solely in reference to software distributed under OSI Approved Licenses.
[edit] Et les termes du langage courant peuvent être déposé, que ce soit en français ou dans d'autres langue. Windows, Orange, Apple, etc...
Même "olympique" est déposé alors qu'il existe depuis plus de 2500 ans...
Le
27/09/2024 à
10h
16
Effectivement, le choix de la licence est extrêmement important, il va conditionner pas mal d'aspects du cycle de vie et des contributions à un logiciel. C'est un choix à bien peser avant d'envoyer son code sur un dépôt public.
Petit résumé perso pour ceux que ça intéresse:
- Les non-copyleft ont comme (dés)avantage de ne quasi rien imposer aux intermédiaires, ce qui leur permet de refermer le code et de l'intégrer à tout et n'importe quoi. On retrouve énormément de code sous MIT dans des produits commerciaux non-libres publiés pas de grandes entreprises comme IBM, ou même dans les consoles de jeu. C'est approche en fait assez pertinente pour des librairies dont le but est de promouvoir un standard ou un protocole, tant qu'une entité suffisamment lourde ne se met pas à faire de l'embrace&extend.
Un exemple de logiciel qui se porte très bien sous une telle licence: Kubernetes (Licence Apache) . Le simple fait que ce logiciel évolue extrêmement vite rend toute tentative d'embrace&extend propriétaire beaucoup trop risquée et onéreuse.
- les licences copyleft 'permissives' comme la LGPL essayent de pallier à ce problème d'embrace&extend sur les librairies en gardant l'obligation de préserver la licence sur le code de la librairie et que de la librairie, permettant toujours l'inclusion du code dans un logiciel non-libre tant que les modifications du code sous licence libre sont traitées correctement. Le principe est de ne pas permettre à un intermédiaire de retirer les libertés aux futurs utilisateurs.
Un exemple de logiciel qui se porte très bien sous une telle licence: 7-Zip, une librairie de compression/décompression
- les licences copyleft strictes comme la GPL: plus difficiles à manipuler, elles imposent strictement la préservation de la licence est des libertés sur tout dérivé de l'application. On pourrait voir ça comme freedom in - freedom out. L'inconvénient est que l'assemblage de code sous une telle licence avec du code sous une autre licence est souvent problématique si on désire redistribuer le résultat. A donc éviter si on désire développer des librairies ayant vocation à promouvoir un format ou un standard.
Un exemple de logiciel libre qui se porte très bien sous une telle licence: Blender, un logiciel de modélisation 3D, d'animation et d'édition video, ...
- les licences copyleft strictes dans le réseau, comme l'AGPL. ... je ne vais pas mentir, j'ai milité contre lorsque l'AGPL3 était en cours d'écriture ... et je sais maintenant que j'avais tort car elle adresse le problème du SAAS. Donc pour résumer c'est une licence copyleft stricte qui confère le statu d'utilisateur du logiciel non-pas uniquement à la personne ou entité qui tourne le logiciel sur son serveur, mais aussi à celle qui l'utilise via un client. Un logiciel sous une licence de ce type devra permettre à toute personne accédant au logiciel à distance de pouvoir obtenir le code source sous cette même licence. Cela pose généralement peu de problème si on utilise le logiciel tel quel sans faire de changements qu'on veut ou doit garder pour sois.
Un exemple de logiciel libre qui se porte très bien sous une telle licence: ownCloud, une plateforme très populaire de services de stockage et d'outils.
Juste histoire de compléter un petit point, puisqu'il est question de choix de licence. En fonction du type de projet, faire attention aussi à l'aspect contaminant des logiciels à copyleft strict.
Par exemple, l'inclusion d'une bibliothèque sous licence GPL dans un programme impose la GPL pour ledit programme (car ledit programme est alors considéré comme un dérivé de la bibliothèque).
De ce fait, la GPL et assimilés sont rarement utilisés pour les bibliothèques, mais plutôt à destination des programmes. Ce n'est pas simplement un problème de licences incompatibles, c'est un problème de relicensing (si on me permet cet anglicisme).
A noter aussi la possibilité d'inclure des clauses d'exclusion. Par exemple, c'est le cas du noyau Linux, sous GPLv2, où les syscall sont exclus de la GPL (sinon, tout code s'exécutant sous Linux devrait être sous GPL), ainsi que pour les modules (les modules proprio existent, le plus célèbre étant sans doute nvidia).
sinon, +1 pour le reste :)
Le
27/09/2024 à
09h
28
C'est clair, dans la mesure où opensource est un terme déjà établi, ce genre de phrase peut légitimement être considérée comme trompeuse.
Le problème vient du terme open-source. Et ce n'est pas nouveau.
Richard Stallman (père de la FSF et des logiciels libres) le disait déjà il y a de nombreuses années (je ne sais pas de quand date précisément ses propos, mais l'Internet Archive a une version de cet URL depuis 2012).
Cependant, la signification évidente de « logiciel open source » est « vous pouvez regarder le code source. » C'est apparemment ce que comprennent la plupart des gens, à tort (l'expression « source disponible » serait plus explicite si c'était le cas). Ce critère est beaucoup beaucoup plus faible que celui du logiciel libre, et aussi beaucoup plus faible que la définition officielle de l'open source. Il inclut beaucoup de programmes qui ne sont ni libres, ni open source.
Pourquoi les gens font-ils cette erreur d'interprétation ? Parce que c'est la signification naturelle des mots « open source » (source ouverte). Mais le concept pour lequel les défenseurs de l'open source cherchaient un autre nom était une variante de celui de logiciel libre.
La signification évidente d'« open source » n'étant pas celle qu'entendent ses défenseurs, la plupart des gens comprennent mal cette expression. Selon Neal Stephenson, « “Linux est un logiciel open source” signifie simplement que n'importe qui peut obtenir des copies de son code source ». Je ne pense pas qu'il ait délibérément cherché à rejeter ou à remettre en cause la définition officielle. Je pense plutôt qu'il s'est simplement basé sur les conventions de la langue anglaise pour trouver un sens à cette expression. L'état du Kansas a publié une définition similaire : « Utiliser des logiciels open source (OSS). Les logiciels open source sont des logiciels pour lesquels le code est librement et publiquement disponible, bien que les accords de licence spécifiques varient sur ce que l'on peut faire avec ce code. »
Le
27/09/2024 à
08h
15
C'est à dire que j'ai trouvé le tweet très ambigu, limite mensonger. A la limite il aurait présenté ça autrement dans sa com' publique en général, que je n'aurait rien trouvé à redire.
Mais effectivement, il suffit d'aller sur le git et de lire attentivement la licence pour en avoir le coeur net. Mais tout le monde ne prends pas le temps de lire... Je crois que beaucoup, comme moi, ont réagi à chaud sans plus de réflexion.
Honnêtement, je ne vois pas l'ambiguïté, mais c'est sans doute car je connais précisément la définition des termes utilisés.
Dire qu'un code est ouvert ce n'est pas dire que le code est open source. Ce sont deux notions très différentes. Je conçois alors, si on ne connait pas très bien les définitions, qu'on puisse se laisser piéger.
Mais ! Ceux qui réagissent fortement en criant à l'imposture sont sensés connaitre la définition d'open source et ne pas tomber dans le panneau.
Beaucoup ont encore une conception erronée (exemple des premiers commentaires de @augustus ou de @Citan666) pour qui "open source" = "source disponible". On le voit bien, pour eux, pas de scandale.
Ce n'est pas de leur faute. Pour moi, c'est la terminologie même d'open source qui est problématique, car elle véhicule un concept très différent entre la conception "grand public" et la définition spécialisée telle que définie par l'OSI (Open Source Initiative).
Et l'ambiguïté est totale, car on oppose souvent closed source (source non disponible) à open source, ce qui n'est pas le cas. Dans le langage courant, open/close s'oppose bien, mais en réalité, closed source s'oppose à source available.
Le
26/09/2024 à
23h
02
Merci pour ta réponse, j'ai tout compris !
Il me semble que WA a été pas mal imité, notamment sous Linux, il y avait une app qui lui ressemblait comme deux gouttes d'eau, et permettait même d'utiliser les plugins !
Je crois que s'il y a une vraie réponse à ce problème de "faux open source" bien hypocrite, ce serait de développer "from scratch" (ou à partir de sources vraiment libres, telles que celles de mpv ou même pourquoi pas de VLC) un lecteur 100% compatible avec les skins et les plugins WA.
Je crois que c'est la seule manière de lui faire fermer sa grosse boite à camembert, à la firme, NAH ! (je sais, je régresse en maternelle, mais j'ai horreur qu'on se foute de la gueule du monde !)
Je crois que s'il y a une vraie réponse à ce problème de "faux open source" bien hypocrite
Je peux me tromper, mais pour le coup, je n'ai pas vu Winamp claironner que le logiciel était open source. Ce sont les commentateurs qui le font... comme sur Next, avec ce titre "accrocheur" à la limite du putaclic (désolé, je vous aime bien, vous le savez, mais il faut appeler un chat un chat).
Le code de Winamp a été placé sous une licence de type source available. Pourquoi lui reprocher de faire du "faux open source bien hypocrite" ?
Sur X, les réponses à l’annonce sont particulièrement critiques et fustigent la licence. L’éditeur donne l’impression de n’annoncer des sources ouvertes que pour obtenir gratuitement une main d’œuvre, sans respecter l’esprit de l’open source.
Idem qu'au dessus. Winamp n'a jamais dit que le code était open source. Lui reprocher de ne pas respecter l'esprit de l'open source relève donc, pour le coup, de l'hypocrisie.
Sinon, par extension, toute licence non open source (par exemple, la SSPL) est hypocrite.
Le
26/09/2024 à
17h
07
Attention, Open Source est un terme protégé par la Open Source Initiative qui désigne la même chose que le libre (grosso modo, si on fait abstraction des aspects philosophiques). Il ne doit pas être confondu avec les licences dites source available.
Open source = possibilité de lire, modifier, exécuter et distribuer Source available = possibilité de lire
Winamp Classic ne devient donc pas open source (car restriction sur la modification et la diffusion). Il est juste source available.
Je ne connaissais pas NoPhoneSpam, mais par contre ils indiquent que pour Android > 6 cela ferait doublon avec la possibilité de blocage intégrée. Problème, jamais réussi à faire fonctionner ce blocage natif avec des wildcards/préfixes sur mon Android 9: L'âne qui a codé cela n'ayant visiblement pas pensé à le faire, rendant le truc absolument inutile... Un autre pb étant que cette appli ne semble plus maintenue.
Il me semblait que le blocage d'Android ne permettait pas de bloquer les prefix réservés au démarchage, car ils sont trop petits (juste 4 chiffres, et il en fallait 6 je crois). C'est possible maintenant ?
Parce qu'effectivement, sinon, j'utilise NoPhoneSpam. Mais il faut bien penser à le mettre dans les applications à ne pas optimiser, sans quoi, il peut ne plus se déclencher au bout d'un moment...
Évoquant des risques d'espionnage ou de sabotage, l'agence du département du Commerce des États-Unis responsable des questions liées à la sécurité nationale et aux technologies de pointe propose d'interdire l'importation et la vente de véhicules connectés de fabrication chinoise.
Quand je lis ça, je lis entre les lignes et je comprends : nous on le fait déjà, mais on ne veut pas que les autres le fasse.
Le libre met l'accent sur les droits des utilisateurs, pas l'opensource.
Le BSL n'est pas "rétablir l'équilibre" il fait pencher franchement la balance du côté de l'éditeur au détriment et des utilisateurs et des contributeurs. Le BSL ne crée ni un contexte pour la collaboration ni un contexte où une communauté peut maintenir la solution après un changement drastique chez l'éditeur. C'est juste du propriétaire avec des jolies couleurs.
Prenons un cas simple, imaginons à quoi ressemblerait l'écosystème Java si au lieu de choisir la licence GPL, Sun Microsystems avait pris BSL ... à ton avis, quel aurait été l'impact?
Le libre met l'accent sur les droits des utilisateurs, pas l'opensource
Les deux le font. Le libre, par essence même (c'est sa philosophie), l'opensource, c'est plus une conséquence (mais le fait est que cela revient au même au final).
Le BSL n'est pas "rétablir l'équilibre" il fait pencher franchement la balance du côté de l'éditeur au détriment et des utilisateurs et des contributeurs. Le BSL ne crée ni un contexte pour la collaboration ni un contexte où une communauté peut maintenir la solution après un changement drastique chez l'éditeur. C'est juste du propriétaire avec des jolies couleurs.
C'est ta vision. Je l'accepte. Mais ce n'est pas la mienne. La BSL ne change rien pour une grande majorité des utilisateurs.
Prenons un cas simple, imaginons à quoi ressemblerait l'écosystème Java si au lieu de choisir la licence GPL, Sun Microsystems avait pris BSL ... à ton avis, quel aurait été l'impact?
A mon avis ? Pas beaucoup de différence. Java était déjà massivement adopté. Le passage sous GPL s'est fait tardivement (2006).
Même en considérant une application stricte de la licence BSL, les programmes compilés ne seraient pas concernés pour la très grande majorité des acteurs par la clause de non utilisation en production.
La question se poserait par contre pour la machine virtuelle. Soit HotSpot (la VM à l'époque) aurait connu une exception pour l'exécution des programmes (ce que permet la BSL), soit un autre type de licence source avialable aurait été choisi. Ou alors, ceux qui souhaiteraient continuer d'utiliser HotSpot le ferai avec quelques version de retard (et quand on voit les serveurs Java utilisé en production aujourd'hui sur les serveur par exemple, on voit bien que cela n'aurait pas été un frein pour nombre d'entre eux).
L'idée de Sun à ce moment là était de privilégier l'ouverture, pas de contraindre l'utilisation.
Maintenant, je te retourne la question : qu'est-ce qu'une licence de type fair source aurait changé à Java ? Je précise que pour moi, la BSL n'est pas une licence de type fair source. La BSL a une clause de non utilisation en production qui est assez restrictive (même trop à mon gout).
Le
25/09/2024 à
12h
37
Je ne nie pas les apports des entreprises, loin de là, je signale juste le risque que certaines entreprises partent avec le boulot des contributeurs sans aucune contrepartie.
Au passage, dans la grande majorité des cas, les contributeurs sont des entreprises qui payent des devs pour améliorer des fonctions spécifiques d'un programme opensource.
Que les entreprises éditrices veuillent protéger leur travail et leurs revenus, c'est légitime, que les contributeurs veuillent aussi pérenniser leur investissement dans l'amélioration d'un produit tiers, c'est aussi légitime, c'est tout.
L'opensource permet dans une certaine mesure d'organiser un cercle vertueux, ce cercle se fragilise au fur et à mesure que l'équilibre des forces bascule franchement vers l'éditeur du logiciel avec des licences comme le BSL ou le fair-source.
L'opensource permet dans une certaine mesure d'organiser un cercle vertueux, ce cercle se fragilise au fur et à mesure que l'équilibre des forces bascule franchement vers l'éditeur du logiciel avec des licences comme le BSL ou le fair-source.
Justement, sur ce point, je ne suis pas spécialement d'accord (mais, ça, je pense que tu l'as compris ;) ).
Pour moi, l'open-source / libre, en ne s'intéressant qu'à celui qui reçoit le logiciel, ne donne pas les bases nécessaires pour avoir un équilibre des forces et pouvoir obtenir un cercle vertueux (ce qui ne signifie pas que ce n'est pas possible, juste, très difficile).
Les licences comme BSL ou le fair-source sont justement là pour essayer de rétablir un peu l'équilibre. Comment ? En gros, en limitant seulement l'exploitation commerciale (j'ose espérer d'ailleurs que cette notion sera bien définie dans la licence, car cela peut vite être flou).
Le
25/09/2024 à
11h
11
Donc, en gros, ni opensource ni libre, le C dans le nom de la licence est intéressant: avec une licence aussi fermée, où se trouverait la collaboration? Qui aurait envie de contribuer?
Si les termes Fair-Source, BSL et autres n'ont pas une bonne aura dans la communauté, c'est aussi à cause de cette question de la collaboration. Si par exemple on prend MongoDB, ElS, et assez récemment tous les produits hashicorp, on a vu des entreprises qui ont décidé de refermer leurs applications afin de maximiser temporairement leurs profits, mais s'aliénant les contributeurs qui avaient contribué à un bien commun dont soudain on essayait de les déposséder.
Dans le cas de Hashicorp, l'attaque contre la communauté a été particulièrement sournoise: hashicorp a fait disparaître toute trace de son historique opensource: tous les dépôts publics de cette entreprise sur github ont été purgés de leur historique pour que le contenu donne l'impression que la version précédente sous licence opensource n'avait jamais existé et empêcher tout nouveau fork d'être créé depuis leur historique. Et lorsque la communauté à tout de même remonté un fork de Terraform, Hashicorp a commencé à crier au vol de propriété intellectuelle sous prétexte que des nouvelles fonctionnalités de la version BSL avaient été volées et intégrées dans la version opensource (les mainteneurs de la version opensource soutiennent que le contenu en question était déjà dans une autre branche sous licence opensource avant la grande purge, ce qui semble plausible puisque toute référence à ce code et à son cycle de vie ont été purgés par hashicorp)
La leçon générale que la communauté opensource/libre est occupée à tirer de tout ça est que, en tant que contributeur: - il faut se protéger des entreprises qui font du libre ou qui font de l'erzats de libre: ne pas accepter de contributor agreement donnant à l'entreprise le droit de redistribuer les contributions sous une licence non-libre, et si ce n'est pas possible, - il faut garder des preuves concernant le cycle de vie des contributions pour pouvoir faire face à des agressions comme celle de Hashicorp. - si on ne veut pas être traité comme main d’œuvre gratuite, il faut éviter de contribuer à des projets qui ne sont pas basés sur une licences validée par l'OSI et/ou la FSF. - En tant qu'employeur/OSPO , ne pas engager de ressources pour contribuer à des projets sous BSL et autres, c'est de l'investissement perdu.
En tant qu'utilisateur, il faut aussi se protéger, si on va vers de l'opensource, il est important de regarder la communauté des solutions visées: une bonne communauté permettra de retomber sur ses pattes si l'entreprise à l'origine d'un projet provoque volontairement ou involontairement un changement drastique des conditions d'utilisation.
Bien que les faits que tu relates soient vrais, je trouve que tu les présentes de manière très biaisées.
Déjà, en niant les apports que peuvent faire les entreprises en libérant un projet complet, et en mettant en avant les contributions d'un projet. Qu'un projet reçoive 80% de contributions (plutot rare) ou juste 0,01% (très courant), c'est loin d'être la même chose.
Et ça me fait toujours rire quand je lis qu'il s'agit d'une attaque à la communauté, alors que la communauté ne voit pas le pied de nez qu'elle fait à l'entreprise en l'exploitant sans contrepartie, alors que l'entreprise gère 99,9% des coûts, que l'entreprise comptait effectivement sur les contributions (notamment financière) pour pouvoir vivre, et que l'absence d'un modèle viable parce que 99% des utilisateurs profites sans quasiment rien donner en retour l'oblige à changer son business modèle.
Attention : je ne dis pas qu'il n'existe pas des acteurs vertueux dans la communauté, car c'est le cas (et heureusement !). Ils sont juste trop peu nombreux. Je ne dis pas non plus que l'entreprise n'a pas fait d'erreur dans sa stratégie initiale et qu'elle n'attendait pas "trop" de la communauté. Non, je dis que c'est du donnant-donnant, et s'il l'équilibre est rompu ou n'est pas trouvé, il est normal de changer les conditions pour essayer de (re)trouver cet équilibre. Et c'est un peu le souci, ai-je envie de dire, avec les licences libres/open source, qui s'intéressent uniquement à ceux qui reçoivent. Il est, dès lors, difficile de trouver un équilibre, notamment financier, pour les entreprises (mais pas que, c'est vrai aussi pour les développeurs indépendants comme celui de XZ par exemple, qui n'a pas trouvé de business model pour ne serait-ce qu'avoir un salaire pour lui alors que son projet est utilisé sur des centaines de millions de système)
De plus, les attaques que tu mentionnes en donnant Hashicorp en exemple, ne sont pas juste l'apanage des entreprises. Tout projet, avec une licence permissive, peut subir le même sort ! Par exemple, curl (avec sa licence très permissive) pourrait tout à fait subir suivre le même chemin. Cela dépend du bon vouloir de son créateur et mainteneur.
On a vu des développeurs retirer des paquets sur un coup de tête, ou suite en représailles à un conflit (exemple de left-pad sur npm si ma mémoire est bonne), provoquant une mini-paralysie pendant quelques heures de tout un écosystème.
Dans ce que tu décris, tu rejettes entièrement la responsabilité sur l'entreprise et la communauté n'est qu'une pauvre victime, donc il faut se protéger des entreprises. C'est extrêmement réducteur. En fait, dès qu'on utilise des produits open-source, édités par des entreprises ou non, il faut prendre un minimum de précautions, à commencer par faire une copie du code (soit directement, soit disponible via des miroirs. C'est peut être de la parano, mais c'est ce que je fais !)
Pour terminer, je rajouterai qu'on a déjà vu par le passé des forks à cause de changement de licence, même d'une licence libre à licence libre (j'ai en tête X.org / XFree86)
Le github annonce bien une licence fair-source pour certains produits comme leur produit éponyme.
Certains projets sont annoncés comme open-source, car ils le sont réellement (Apache-2.0).
Non, sérieusement, donne moi des exemples précis montrant cette ambiguïté dont tu parles, car, pour l'instant, après 5min de recherche, je n'en vois pas.
Le
24/09/2024 à
15h
30
Merci, grâce à toi, j'ai vu que l'article avait été modifié et que la réaction de l'April avait été ajouté.
Cela me conforte quand même dans ma position, où pour une bonne frange de la communauté libre/open-source, tout modèle alternatif est à rejeter. Mais bon, dire ça, apparemment, c'est faire preuve d'intolérance...
Une licence dite "fair-source" n'est pas "open-source" ?
En théorie, non, puisqu'une des clauses d'une licence fair source serait justement que le code devienne, à terme, open source au sens OSI du terme
Une licence fair-source est, grosso modo, une licence source available avec promesse à terme d'être open source.
Car pour ceux qui ne serait pas au courant, une licence open source (au sens OSI du terme) ne se limite pas à l'accès au code source, mais confère des droits supplémentaires, notamment de modification et de redistribution.
Le
24/09/2024 à
15h
18
Les nuances peuvent exister, juste elles devraient ne pas commencer à faire semblant d'être ce qu'elles n'ont pas. Il y a des fondations qui ont des principes, des chartes de qualité, il n'est pas correct de faire de la fumée pour faire croire qu'on joue le jeu.
En quoi ici l'usage de fair source fait semblant d'être ce qu'elle n'est pas ?
Le
24/09/2024 à
15h
15
Et le prosecco c'est du champagne...
à mal nommer les choses...
on est d'accord. Open source n'aurait jamais du s'appeler open source. Trop de confusion
Le
24/09/2024 à
13h
33
Le principe privateur "de libertés" est un langage qui marque l'opposition à la suppression des libertés. Quand Stallman, avec d'autres, a créé le mouvement du logiciel libre dans les années 80, c'était en réaction à l'apparition de logiciels propriétaires. Il faut bien se rappeler que dans les années 60/70, les logiciels étaient quasi tous libres, mais vers la fin des années 70, la suppression des libertés commençait à devenir dominante. Le logiciel libre est une réaction à cette privation de liberté.
Pour le reste, tu ne te fera mettre au pilori que si ta communication est en contradiction avec tes actions. Si tu publies ton code source donner de libertés autres que la consultation ou en gardant le contrôle sur le droit d'exécution ou de modification, ne prétend pas avoir "libéré" ton code.
Ceux qui jouent avec les mots pour se prévaloir de qualités qu'ils n'ont pas méritent de se faire dénonce pour imposture. De même, si tu vantes les valeurs de l'opensource, ton engagement pour l'opensource, et quen suite tu fais du "fair source", ne t'étonne pas qu'on ne te donne pas les points de karma.
Ceux qui jouent avec les mots pour se prévaloir de qualités qu'ils n'ont pas méritent de se faire dénonce pour imposture.
Je pense que c'est là que nous sommes en désaccord. C'est un peu comme le débat chiffrer/crypter qui n'a de sens que pour les "initiés". La confrontation langage courant / langage spécialisé, le lambda moyen n'en a cure.
Pour beaucoup de non informaticiens (en tout cas, autour de moi) : - logiciel libre = gratuit - logiciel open source = source disponible - logiciel libre != logiciel open source
Le
24/09/2024 à
12h
47
C'est MongoDB qui a changé de licence, pas MariaDB... et tout ce qu'ils ont réeussi à faire, s'est se faire oublier, plus personne ne les considère pour de nouveaux projets... et ElasticSearch est à nouveau sous licence libre grâce à l'AGPL (une de ces licences paraît-il d'extrémistes de la FSF)
Il est évident qu'avoir une activité commerciale dans le logiciel serveur est devenu beaucoup plus précaire avec la montée en puissance des GAFAM qui contrôlent les plateformes cloud public. Il faut pouvoir réussir à encore motiver les utilisateurs à acquérir du support tout en devant se battre contre des Amazon, Microsoft, Google et autres qui souvent fournissent des services SAAS avec un support minimal, voire uniquement sur papier.
L'industrie est devenue beaucoup plus violente, et ceux qui ne font pas d'opensource n'ont pas la garantie non-plus de pouvoir conserver sur la durée un avantage commercial face aux logiciels opensources poussés par les gafam ou surtout les solutions propriétaires dérivées de l'opensource développées par ceux-ci.
Si ElasticSearch est passé sous licence propriétaire, c'est à cause de ce dernier point: Amazon avait siphonné le projet et commençait à le vendre avec sa propre sauce secrète, en passant vers ESL, elasticsearch a bloqué Amazon, mais s'est aliéné les contributeurs tiers, en passant vers AGPL, Elasticsearch a renoué avec sa communauté tout en forçant Amazon à ne plus faire de la concurrence sur le code lui-même.
Merci pour la reprise. Il s'agit bien évidemment de MongoDB, pas de MariaDB (j'ai édité mon commentaire en conséquence).
Quelques précisions :
ElasticSearch est à nouveau sous licence libre grâce à l'AGPL
Tout à fait. De ce que j'ai lu (mais sans vraiment creuser pour recouper), c'est qu'ElasticSearch a été forké par les cloud providers (notamment AWS) pour le faire évoluer en fonction de leurs besoins propres, et donc fournissent maintenant une solution compatible ElasticSearch, mais qui n'est pas ElasticSearch.
ElasticSearch aurait cherché à faire prendre des licences aux clouds provider (d'où l'usage de la SSPL) via un premier changement de licence. Mais cela n'a pas marché, car la solution a été forkée. Du coup, maintenant que le fork a été fait, et que les cloud providers utilisent leur propre solution, ils ont de nouveau changé de stratégie pour repasser sur une licence libre, adaptée aux spécificités du Web (et donc des SAAS).
une de ces licences paraît-il d'extrémistes de la FSF
Précision : c'est toi qui a employé le terme d'extrémiste (et je l'ai repris dans un de mes commentaires pour te répondre, j'avoue). Je me contente de dire que la vision de la FSF est très binaire : ou la licence est libre, ou la licence est privatrice. Aucune nuance entre les deux.
Le
24/09/2024 à
11h
51
"Non. Ce que je demande, c'est que les gens qui ont des principes tolère des principes différents avec des appellations différentes."
Le seul qui soit intolérant ici, c'est toi, tu ne cesse de dépeindre le monde opensource comme des extrémistes.
Et franchement renseigne toi un peu sur ces sujets, car tu continues à tout mélanger, comme par exemple:
"n'est pas fermé quant à l'usage de logiciel non open source (contrairement au principe du libre, notamment les licences GPL)."
Tu fais référence à quoi? Tu parles d'utilisation ou de redistribution? Tu pense que les libristes ont un problème à utiliser des logiciels sous licence non-gpl? Un peu de précision...
Le seul qui soit intolérant ici, c'est toi, tu ne cesse de dépeindre le monde opensource comme des extrémistes.
Bah écoute, si tu le prends comme ça, je pense que je vais arrêter la notre conversation.
Si, pour toi, le fait de dire que ce soit bien qu'il existe des notions intermédiaires entre les libres/open-source et les licences propriétaires, et critiquer la position du CNLL ou de l'OpenUK qui fustige la confusion que l'existence même de "fair source" entrainerait, alors oui, je suis intolérant.
Tu fais référence à quoi? Tu parles d'utilisation ou de redistribution? Tu pense que les libristes ont un problème à utiliser des logiciels sous licence non-gpl? Un peu de précision...
On est dans un contexte commercial, donc je parle ici de redistribution.
Maintenant, je suis peut être "extrémiste", mais : - FSF : On appelle logiciel privateur, ou logiciel non libre, un logiciel qui ne respecte pas la liberté des utilisateurs et leur communauté.. Autrement dit : tout logiciel non libre est privateur (un logiciel comme ElasticSearch est donc tout autant privateur pour la FSF que Windows par exemple). - L'OSI est très loin d'être aussi extrêmiste, puisqu'il se contente de dire qu'une licence qui ne respecte pas l'open source definition n'est pas open-source. Par contre, et comme je le disais dans un autre commentaire, le terme "open source" me parait très mal choisi, car ne se réfère au final qu'à la règle 2 sur les 10 règles permettant de qualifier une licence comme étant open source.
Aujourd'hui, si on dit qu'on ouvre le code source ou qu'on libère le code source, sans pour autant que cela soit une licence libre / open source, alors on se fait mettre au pilori par une partie de la communauté (cas de Sentry avec codedev en 2023 par exemple) en étant accusé d'openwashing. En effet, Open source est un terme déposé par l'OSI. Mais qu'en est-il des termes dérivés ? Opening the source par exemple ? Dans le langage courant, c'est ouvrir les sources, pas licencier sous une licence open-source. Et pourtant, ça suffit pour être accuser d'openwashing.
Alors, quand je vois le débat sur "fair source" et la notion de fair de la part de défenseur de l'open-source, alors qu'on a exactement la même problématique entre open source et la notion d'ouverture, j'ai vraiment l'impression que c'est l'hôpital qui se fout de la charité.
Le
24/09/2024 à
11h
19
Et concrètement, comment cette bascule d'ouverture du code se réalise??
Il y a un minuteur dans gitlab?? Qui nous dit que lors de la liquidation de la société que le compte Gitlab ne serait pas supprimé??
La valeur de cette société est dans son logiciel à l'instant t. Dans son domaine, un logiciel vieux de 2 ans possède peu de valeur. Qui va s'amuser à vérifier si les sources vielles de 2 ans sont réellement ce que la boîte affirme?? (pour compatibilité entre du matériel et du logiciel des sources vielles de 2 ans je ne dis pas, mais ce n'est pas le marché de cette boîte).
Ca va dépendre de la licence. Cela pourrait être un critère temporel (au bout de 2 ans par exemple, avec l'horodatage des commits), ou la sortie d'une nouvelle version x.y.z qui "libère" les versions x.y-1.*
Liste non exhaustive, cela va s'en dire ;)
Le
24/09/2024 à
11h
15
Sinon, au passage:
"Les licences libres présentent certains avantages indéniables, mais sont très mauvaises pour la viabilité commerciale d'un produit."
Est un peu gratuit et léger comme affirmation, il y a plein de contre-exemples. Adhérer à de l'opensource ou du libre nécessite de réfléchir à l'adéquation de ces licences et du discours pour un projet spécifique et pour l'entreprise, si ce n'est pas des modèles qui marchent bien pour tout, ils peuvent marcher dans de nombreux cas.
Léger comme affirmation ? Il suffit pourtant de voir des projets open-source très répandus et utilisés, maintenus par un seul développeur, et qui n'ont jamais réussi à trouver un business model ne serait-ce que pour pouvoir travailler à temps partiel dessus, comme XZ.
Même de plus gros projet ont des difficultés, et par exemple, Mozilla fermerait sans doute ses portes sans le partenariat qu'il a avec Google et qui lui fourni 90% de ses revenus.
Ce n'est pas pour rien non plus que des projets comme MariaDB MongoDB ou Elastic Search ont changé de licence pour passer à du libre vers du non-libre.
Il y a bien sur des projets qui ont réussi à trouver un business modèle viable. Mais il en existe beaucoup d'autres qui n'y arrive pas non plus.
Et ce n'est pas étonnant dans un sens, puisque les licences libres/open-source s'intéressent à celui qui reçoit le code, pas à celui qui le donne. De facto, même si par principe ce n'est pas interdit par les licences, il est très difficile de vendre le logiciel en lui-même. Il faut, par exemple, fournir du service autour, encore faut-il que le logiciel s'y prête.
Ou encore le double-licensing, où le produit open-source est un produit d'appel et le produit commercial contient les fonctionnalités les plus avancées. On y retrouve des logiciels comme nginx, gitlab, etc. Mais là encore, il faut que le logiciel s'y prête.
[edit] Correction suite à la remarque de judicieuse de ragoutoutou sur la confusion MongoDB/MariaDB
Le
24/09/2024 à
10h
54
Sentry communique énormément sur les valeurs de l'opensource et puis mélange le terme "fair source" au mix... ça a un petit côté enfumage...
Pour le reste, tu mélanges tout, le monde opensource n'est pas manichéen, le mouvement opensource s'est éloigné très fort du discours politique du libre pour mieux fonctionner justement avec les entreprises commerciales. L'opensource relève plus d'un modèle de collaboration (et non de distribution comme radoté par Sentry dans son blog). Par contre il ne faut pas s'attendre d'eux qu'ils cautionnent l'enfumage de sentry, ni le modèle proposé.
Le libre de son côté ne va pas non-plus cautionner un logiciel non-libre par essence.
Ce que tu sembles demander, c'est que des gens qui ont des principes et les défendent deviennent soudainement "raisonnables" ...
Pourquoi ne pas exiger des végétariens qu'ils rajoutent une dose minimale de viande dans leur alimentation pour soutenir l’élevage tant qu'on y est, ou que les homosexuels aient au moins une relation hétéro par mois.
Pour le reste, tu mélanges tout, le monde opensource n'est pas manichéen, le mouvement opensource s'est éloigné très fort du discours politique du libre pour mieux fonctionner justement avec les entreprises commerciales.
Je ne mélange rien du tout. L'open source ne s'est jamais éloigné du libre, car ils ont, depuis le début, une conception différente, mais qui s'exprime, grosso modo, de la même manière.
Dans un sens, tu as raison lorsque tu dis que l'open-source relève de la collaboration, car l'open-source se focalise sur des considérations techniques et n'est pas fermé quant à l'usage de logiciel non open source (contrairement au principe du libre, notamment les licences GPL).
Ce que tu sembles demander, c'est que des gens qui ont des principes et les défendent deviennent soudainement "raisonnables" ...
Non. Ce que je demande, c'est que les gens qui ont des principes tolère des principes différents avec des appellations différentes.
Pourquoi ne pas exiger des végétariens qu'ils rajoutent une dose minimale de viande dans leur alimentation pour soutenir l’élevage tant qu'on y est, ou que les homosexuels aient au moins une relation hétéro par mois.
Comparaison foireuse. Ici, on est plutôt sur des végétariens qui refuseraient l'existence même du terme flexitarien, car cela ajouterait, d'après eux, de la confusion (ou l'existence du terme bisexuel pour continuer sur ton analogie avec les homosexuels).
Le
24/09/2024 à
10h
43
Je pense que ragoutoutou faisait référence à ce genre de phénomène :
Sentry a aussi racheté Codecov fin 2022 et, en aout 2023, a utilisé le terme d' « open source » pour qualifier son code qui était sous Business Source License aussi, récoltant les critiques de la communauté car cette licence n'est pas approuvée par l'Open Source Initiative (OSI).
Donc Sentry a bien essayé de faire passer du code pour de l'open source alors que ça n'en était pas. Ici le terme fair source est donc effectivement plus approprié, plus clair et sûrement plus intéressant que du code en source fermée.
Dans ce cas, je comprends mieux, et cela reste quand même une polémique pour pas grand chose. Les sources de codecov avant n'étaient pas disponible et ont été rendu disponible en 2023. Si l'usage du terme "open source" est impropre (je le concède volontiers), cela n'en est pas moins une volonté d'ouverture.
C'est quand même à l'opposé de certaines sociétés qui ont changé la licence de leur logiciel pour passer d'open source vers une licence source available (comme Elastic Search ou MariaDB par exemple) et ont donc plutôt un esprit de fermeture.
Note : pour ma part, je trouve que le terme "open source" est mal choisi par l'OSI, car ne véhicule pas toutes les idées qui y sont liées. Pour beaucoup de non professionnel, open source = source disponible. Les libertés liées à la modification et à la diffusion n'apparaissent pas. Mais ça, c'est un avis très personnel, et je fais avec ^^
Le
24/09/2024 à
10h
11
Non, la réaction du monde OpenSource ou Libre est normale, Sentry essaye d'enfumer le monde et de se faire passer pour ce qu'il n'est pas, ce n'est pas une question d'extrémisme, c'est une question de protéger son identité et de ne pas accepter qu'un acteur ne puisse se prévaloir de valeurs ou de qualités qu'il ne possède pas dans les faits. Soi ça adhère aux quatre libertés et c'est du libre, soit ça n'adhère pas et ce n'est pas du libre; soit correspond aux 10 points de la définition de l'opensource et c'est de l'opensource, soit cela n'en est pas.
Il est normal que ces groupes protègent leurs appellations.
Ben non, Sentry n'essaie pas de se faire passer pour du libre ou de l'open-source justement. Sentry utilise une terminologie qui n'utilise ni free, ni open source.
Le monde open-source a une vision très manichéenne où soit c'est libre, soit c'est privateur.
Sauf que les éditeurs de logiciels et développeur sont libres de choisir la licence qu'ils souhaitent. Les licences libres présentent certains avantages indéniables, mais sont très mauvaises pour la viabilité commerciale d'un produit.
Les licences de types source available et fair source permettent d'ajouter des nuances de type propriétaire entre le libre et le privateur, là où le libre souhaite dire que propriétaire = privateur.
Le
24/09/2024 à
09h
23
On peut aussi se poser la question de l'utilisation du terme « fair ». Un code qui n'est pas dans une licence « fair code » serait-il injuste ?
On peut se poser exactement la même question avec la notion d'open-source ou de libre.
En fait, pendant longtemps, les licences de logiciels se classaient dans 2 catégories : - licences libres ou open-source : qui respecte les 4 libertés fondamentales - licences propriétaires ou privatrices : licences qui ne sont pas libres / open-source.
On constate alors qu'une seule catégorie avait réellement une définition, et l'autre étant définie "par opposition".
Il suffisait alors d'avoir une licence avec restriction pour qu'elle soit considérée comme privatrice (comme la SSPL).
Depuis quelques années, nous avons maintenant aussi le source available, qui permet de désigner un code ouvert au sens propre du terme (=source disponible).
La notion de fair source rajoute un pont supplémentaire entre le source available et le libre, et protège également les utilisateurs en cas de défaillance de l'entreprise, puisque le code basculera automatiquement sur une licence libre au bout d'un certains laps de temps, sécurisant la modification et la distribution du code après une liquidation d'une entreprise ou l'arrêt d'un produit par exemple (cf. les exemples plus ou moins récent au sujet de la domotique !)
Maintenant, l'avis de la FSF ou du CNLL, ne m'étonne guère, puisque pour eux, le saint graal est le libre / open-source et toute licence non libre est de facto propriétaire.
Ah ben ça je ne savais pas, donc non seulement j'ai eu la chance que ce soit un cadeau ( la boite changeait les bécanes tous les 3 ans et avait oublié de reprendre celui-çi) et en plus le SSD n'était pas soudé ( j'ai ouvert sans savoir) Et en plus si ça ramène du pop-corn
Oui ram et disque dur sont soudés. Donc les machines ne sont plus du tout évolutives (enfin je ne sais pas pour les tout derniers modèles mais pendant longtemps c'était comme ca)
Le
24/09/2024 à
16h
35
Chanceux ! Maintenant, on ne peut même plus mettre un plus gros SSD... (soudé à la carte mère).
Et je pense qu'on peut rajouter Clearview AI. Ca va bien les faire ch* je pense.
Par contre, ce qui serait bien, c'est une coopération entre les différents organismes en charge des différentes règlementations, afin de permettre de faire payer les amendes (c'est justement le cas Clearview qui me fait penser à ça)
Allez, reprenons ensemble l'ensemble des chiffres.
19kg de CO2 par jour ça fait moins de 7 tCO2 par an. Moins que l'empreinte carbone d'un français tout seul. C'est ridicule, C'est sensé être ça la catastrophe climaticide ? il n'y a pas une erreur de calcul quelque part ?
La métrique global dépend du nombre d'utilisation. Une faible utilisation donne donc de faibles émissions. Rapporté au nombre de requête, c'est 3Wh / requête.
Si on extrapole les chiffres, cela fait près de 500MWh / an, soit la production d'une petite centrale nucléaire. Toujours rien ?
Même çà c'est que dalle. On parle d'une construction unique qui ressert ensuite des (dizaines, centaines de) millions de fois. 300 tCO2 pour ça c'est donné.
Et si on parlait du biais du survivant ? Pour un modèle publié, combien y-a-t-il eu de modèles entrainé et mis à la benne car inefficace ?
Penses-tu sincèrement que les modèles sont obtenus du premier coup ? Un modèle peut nécessiter de nombreux essais. Pour avoir fait un peu d'IA, la création de la topologie d'un modèle, ce sont de nombreux paramètres ajustables (nombre de couches, tailles des couches, fonction d'activation, etc.) et ce sont souvent des essais/erreurs qui permettent de choisir ensuite le "meilleur" modèle.
Pour un modèle publié, on peut donc avoir des milliers de modèles non publiés. On atteint donc plutôt l'ordre de 300MtEqCO2 par an. Soit la moitié des émissions d'un pays comme la France.
Et ça, c'est pour UN seul modèle. Rajoute Google, Apple, Meta, etc. qui ont chacun leur modèle et cela devient vraiment loin d'être négligeable.
Qui plus est, avec Apple qui déploie des IA dans ses smartphones, Microsoft qui pousse de plus en plus Copilot, etc. l'usage des modèles ne vas faire que croitre d'ici les prochaines années.
aucune banque ne vous demandera JAMAIS [...] la confirmation d'une opération via votre application bancaire.
Je viens juste d'effectuer un virement à partir du site web (site que je n'utilise pratiquement pas, utilisant l'appli), et on m'a demandé confirmation sur l'appli...
J'aurais peut être du plus précis sur le contexte, même si cela me semblait évident... Pour une opération dont vous êtes à l'origine, oui, on peut avoir une confirmation à donner (le cas du virement par le web, je l'ai déjà eu).
Mais un conseiller ne vous appellera jamais sans avoir été sollicité pour vous demander un code ou une confirmation via l'application bancaire. Jamais. Un conseiller qui fait ça, c'est pas votre conseiller, c'est un escroc.
Le
20/09/2024 à
15h
34
Je suis pas a une adresse par service, mais j'en ai pas mal déjà. Gestion similaire. Ma banque m'envoi pas de mail, sauf pour me dire d'aller sur son service de messagerie car j'ai un truc a aller voir, mais sans lien de connexion. Du coup, quand je reçoit autre chose, forcément c'est du fake. Pareil que toi pour les messages sur la mauvaise adresse, en ce moment mon compte iCloud est plein 10 fois par jours ... sur la mauvaise adresse
Pour l'entourage, j'ai du expliquer a ma mère qu'elle n'avait pas de compte iCloud et donc que le mail c'était poubelle, elle était a deux doigts de cliquer
Mon plus beau truc ça reste pour le moment le fraudeur qui appel une amie pour se faire passer pour le service fraude de sa banque et qui appels avec les bonnes infos et affiche le numéros de tel du service fraude lors de l'appel (facile à faire). Il a juste pas eu de bol qu'on soit ensemble a ce moment là en train de prendre un verre et que je connaisse le fonctionnement de ce genre de services et un peu le monde du paiement Ma pote a flippé après m'avoir passé le gars qui a voulu me parler quand j'ai dit au gars qu'ils racontait que de la merde sur tel ou tel sujet
Ce serait bien que côté Next vous envisagiez de faire un article sur les règles de base contre le phising & Co, notamment quand le fraudeur se fait passer pour une banque ou un gros établissement bien établit. Dans le cas de la banque, le service fraude ne refusera jamais de se faire rappeler depuis le numéro composé dans l'appli de la banque, qui a très peu de chance d'être un fake.
Dans le cas de la banque, le service fraude ne refusera jamais de se faire rappeler depuis le numéro composé dans l'appli de la banque, qui a très peu de chance d'être un fake.
Tout à fait. Et pour rappel : aucune banque ne vous demandera JAMAIS de lui communiquer un numéro que vous allez recevoir par SMS ou la confirmation d'une opération via votre application bancaire.
Toute tentative de ce genre est une arnaque. Et pour les attaques les plus poussées (comme dans le cas que tu décris avec affichage du "bon numéro") : prévenir sa banque malgré tout, par écrit, de préférence, car cela laisse des traces, afin de se protéger. Et la banque peut mettre un warning sur le compte pour accroitre la surveillance de transactions qui paraitraient frauduleuses (virement important et/ou vers l'étranger par exemple).
Pour rappel, en cas de fraude, la banque est tenue de prouver la négligence de son client, sans quoi, elle doit rembourser les sommes en question.
Je comprends le désir de la communauté quant à cette libération.
Néanmoins, et face à un géant comme Oracle (dont les vertus en terme de marque et droits d'auteurs ne sont plus à démontrer tousse tousse), j'ai envie de dire méfiance ! Il serait bien capable de trouver un moyen de rentabiliser cela, d'une manière ou d'autre, et que cette demande ne se retourne, in fine, contre la communauté.
Le coût pour Youtube n'est pas le même : les séries NetFlix sont payées intégralement par ton abonnement ; alors que sur Youtube, la production est financée en grande partie par la prostitution les partenariats avec NordVPN & co., pas tant que ça par la monétisation.
C'est pas pour défendre Youtube, mais les coûts sont très différents.
Netflix produit effectivement des oeuvres, et paie pour pouvoir ajouter des oeuvres dont il n'a pas les droits.
Youtube, de son côté, ne paie pas grand chose pour la création d'oeuvre, mais : - comme il est hébergeur, doit mettre en place une équipe de modération - c'est une grande plateforme au sens DMA du terme (donc a des obligations supplémentaires) - doit payer/trouver des accords avec les ayants droits (pas une mince affaire) - doit gérer les demandes de signalement et de retrait - doit supporter des coûts de stockage bien plus élevé que Netflix (ben oui, les vidéos de chaton, ça pèse) - dispose de fonctionnalités qui doivent aussi peser en terme d'infrastructure, comme les lives youtube, où il n'y a pas de limite max quant on nombre d'utilisateur connecté (de limite codé en dur je veux dire, peut être que 100 millions d'utilisateur sur le même live, il aurait du mal ^^) - est un grand utilisateur d'IA (les sous-titres automatique ne se font pas tout seul) - fait énormément de transcodage pour proposer les vidéos dans des formats/résolutions différentes (netflix aussi, mais le nombre de vidéo sur Youtube est bien plus important, et Youtube doit le faire en temps quasi réel après le dépôt d'une vidéo) - etc.
Bref, comparer les 2 en se concentrant que sur ce qu'il y a de commun, c'est comme comparer le prix d'une trottinette et d'un vélo, parce que les deux ont des roues et permettent de se déplacer, alors que les usages sont radicalement différents.
Pour résumer la position de Spotify, Meta, etc. en quelques mots facile à comprendre pour le béotien moyen, voici comment comprendre l'argumentation.
Pour une décision qui les freine (cas de la lettre ouverte) - l’IA générative pourrait accroitre le PIB mondial de 10 %. Les citoyens européens pourraient « être privés de cette croissance ». => on veut notre part du gâteau - L’Union européenne risque également de passer à côté d’autres innovations, « comme l'assistant d'IA Meta, qui est en passe de devenir l'assistant d'IA le plus utilisé au monde d'ici à la fin de l'année ». => au cas où vous n'auriez pas compris le message subliminal précédant : on veut notre part du gâteau
Pour une décision qui les arrange (cas du DMA, DSA, etc. pour Spotify contre Apple par exemple) - c'est super, on va pouvoir payer moins cher, et donc engranger plus de bénéfice.
En résumé : non, ils ne sont pas philanthropique, contrairement à ce que laisse penser la lettre ouverte. Ils veulent toujours plus d'argent.
Note : je n'ai rien contre le fait qu'une entreprise gagne de l'argent. Au contraire (je suis chef d'entreprise). Mais cet argumentaire déguisé soupoudré d'altruisme et de générosité en disant c'est pour votre bien plutôt que d'avoir que 'c'est pour le bien de nos bénéfices me donne des envies de régurgitation.
En Europe, l'article 22 du RGPD est sensé nous protégé de décisions fondées exclusivement sur un traitement automatisé produisant des effets juridiques nous concernant ou nous affectant de manière significative (et je pense que des allocations entre dans cette catégorie).
Certains verront cela comme un frein. D'autres, comme un garde-fou.
En bref, ça me fait penser à la célèbre phrase "science sans conscience n'est que ruine de l'âme".
En théorie, non. En pratique, "parfois" certains produits sont mieux supportés dans zigbee2mqtt que directement via le plugin zigbee. Ex ici avec le Lixee Zlinky_TIC qui est un poil plus complexe à configurer directement via zha (le plugin zigbee officiel de homeasistant) que via zigbee2mqtt: GitHub J'ai aussi eu le soucis avec un distributeur de croquette qui ne permet pas via zha de configurer un planning "interne" (donc si homeassistant plante, plus de croquettes pour le chat ) mais via zigbee2mqtt tu peux lui passer les commandes pour le faire. En soit, donc non pour un seul système domotique, ce n'est pas indispensable mais ça simplifie parfois grandement la vie... Et sous homeassistant, l'installation de zigbee2mqtt est entièrement automatisée, ça insstalle le broker mqtt "mosquitto" qui est très léger
Ok, merci pour le retour :)
J'ai un home assistant à la maison, et les problèmes que j'ai rencontré jusqu'à présent, c'est plutôt au niveau de la gestion de la clé Zigbee que la communication avec les différents appareils.
Le plugin Zha ne fonctionne pas correctement avec ma clé (une ConBee II sous la forme d'un module pour Raspberry, pas en dongle USB, firmware à jour). Je suis obligé de passer par Deconz pour la clé (j'aurais bien voulu m'en passer, pour faire une couche en moins).
Le
20/09/2024 à
15h
44
La clé ne fait que la gestion du protocole zigbee effectievement, zigbee2MQTT c'est juste pour bridger les infos vers le broker mqtt et permettre par ex d'utiliser le module linky avec plusieurs systémes domotiques. https://www.zigbee2mqtt.io/ zigbee2mqtt peut être un container (sur lequel la clé est donc connectée) ou autre.
Oki, donc si on n'a qu'un seul système domotique, pas besoin du MQTT ? On peut se contenter du Zigbee tout seul.
Le
20/09/2024 à
15h
00
Qu'utilises-tu comme produits ? Ça m’intéresse de voir et ça pourrait faire l’objet d’un comparatif effectivement :)
Je ne suis pas sur d'avoir compris le montage.
Le module, c'est sur le Linky (ça c'est bon). La clé, c'est sur une carte genre raspeberry afin de récupérer les données via Zigbee et de les diffuser en MQTT ensuite.
Mais du coup, si c'est le raspeberry même qui traite les info (par exemple avec Home Assitant ou Jeedom), pas besoin d'avoir une clé Zigbee2MQTT. Une simple clé Zigbee suffit non ?
Libre et opensource c'est pas la même chose Pas opensource = pas (facilement) vérifiable. En opensource, il n'y a pas besoin de croire, il n'y a que la vérité du code.
Tu sembles confondre open source et source available.
Car en pratique, libre = open source (aux nuances philosophiques près)
Si tu fais une recherche sur Next, tu trouvera pleins d'articles expliquant leur fonctionnement. Il n'y a aucune raison qui ferait que les utilisateurs de passkeys soient enfermés puisque c'est un standard partagé par beaucoup d'entreprises et de projets open-source. Je ne connais aucun mal à l'adoption des passkeys, y'a que du bon, c'est comme le cochon.
Je crois que tu n'as pas compris la problématique soulevé par eophea.
Le mécanisme utilisant des passkeys repose en réalité sur 2 clés : une publique, et une privée.
La clé privée est sensée être dans une enclave sécurisée dont elle ne sort pas. C'est le dispositif lui-même qui résout le challenge avec la clé privée, mais la clé privée ne quitte pas le dispositif (qui peut être virtuel, mais c'est un autre sujet).
Dès lors, parler de synchronisation, cela signifie que la clé privée peut sortir pour être dupliquée.
L'interrogation de eophea est donc tout à fait légitime (et je la partage).
Oui oui il y a bien des gens IRL qui parlent comme ça en entreprise, par exemple dans les systèmes d'informations RH. Et ils sont déjà en écriture inclusive pour les plus extrêmes (mais il ne font pas long feu)
Je travaille dans l'info depuis près de 15 ans (de manière professionnel j'entend).
Quand je regarde des vidéos de dev ou des podcasts, parfois c'est un tel franglais qu'il m'arrive de ne rien piger. Les termes je les connais pourtant, mais le mix français-anglais me déconcentre tellement que j'en perds le fil...
Tu peux t'investir dans le libre sans être ingénieur informaticien. Voilà donc bien une réponse débile.
Tu peux... - Financer directement avec des sous grâce aux dons. - T'approprier les outils en investissant de ton temps à les maîtriser et en comprendre les limitations. - Proposer des évolutions sur les gestionnaires de ticket, ou voter pour les existantes, afin de remonter tes besoins, même si évidemment aucune garantie qu'ils soient priorisés. - Proposer des modèles quand c'est pertinent (type LibreOffice), promouvoir l'outil dans ta sphère professionnelle ou personnelle par présentations, vidéos, blogs, ou encore enrichir une documentation communautaire... - Enfin, et c'est là le seul point qui requiert effectivement un minimum de bagage technique ou investissement "hors métier" pour être efficace, remonter des bugs.
Je le répète. Chacun choisit son enfer, et choisir un outil uniquement pour ses bénéfices immédiats, c'est stupide. À fortiori dans un monde où même les non-informaticiens qui n'en ont rien à foutre de l'informatique ont malgré tout un minimum de culture de la douille entre les systèmes par abonnements dans tous les sens et les scandales sur la sécurité ou les arnaques, dans un monde où à peu près quiconque de sensé se préoccupe du long terme et donc cherche à faire des choix qui favorisent le soutenable.
Tu peux t'investir dans le libre sans être ingénieur informaticien. Voilà donc bien une réponse débile.
Avant de traiter ma réponse de débile, sache que s'investir dans le libre, c'est différent de contribuer au libre (ce que tu décris).
Dans le cas qui nous occupe, à savoir intervenir sur la pile audio, c'est loin d'être à la portée de tout le monde, et nécessite une réelle implication qui dépasse, et de loin, la "simple contribution".
Pour l'instant, on n'avait pas envisagé YouTube, mais si c'est une demande forte on peut regarder
YouTube est malheureusement une plateforme incontournable aujourd'hui.
Si l'objectif du podcast c'est aussi de faire connaître Next, il faut qu'il soit trouvable facilement pour tout le monde (et pas seulement pour le lectorat déjà existant).
Cela peut devenir un mécanisme d'acquisition pour de nouveaux lecteurs "payants"
2779 commentaires
Winamp Classic devient open source, mais pas trop
26/09/2024
Le 27/09/2024 à 12h 29
Effectivement, merci. Je ne savais pas que c'était une loi spécifique. Les termes protégés sont donc :
- jeux Olympiques
- olympisme
- olympiade
- le sigle “ JO ”
et hors usage commun :
- olympique
- olympien
- olympienne
Le 27/09/2024 à 11h 08
Le 27/09/2024 à 11h 02
Et les termes du langage courant peuvent être déposé, que ce soit en français ou dans d'autres langue. Windows, Orange, Apple, etc...
Même "olympique" est déposé alors qu'il existe depuis plus de 2500 ans...
Le 27/09/2024 à 10h 16
Par exemple, l'inclusion d'une bibliothèque sous licence GPL dans un programme impose la GPL pour ledit programme (car ledit programme est alors considéré comme un dérivé de la bibliothèque).
De ce fait, la GPL et assimilés sont rarement utilisés pour les bibliothèques, mais plutôt à destination des programmes. Ce n'est pas simplement un problème de licences incompatibles, c'est un problème de relicensing (si on me permet cet anglicisme).
A noter aussi la possibilité d'inclure des clauses d'exclusion. Par exemple, c'est le cas du noyau Linux, sous GPLv2, où les syscall sont exclus de la GPL (sinon, tout code s'exécutant sous Linux devrait être sous GPL), ainsi que pour les modules (les modules proprio existent, le plus célèbre étant sans doute nvidia).
sinon, +1 pour le reste :)
Le 27/09/2024 à 09h 28
Richard Stallman (père de la FSF et des logiciels libres) le disait déjà il y a de nombreuses années (je ne sais pas de quand date précisément ses propos, mais l'Internet Archive a une version de cet URL depuis 2012).
Le 27/09/2024 à 08h 15
Dire qu'un code est ouvert ce n'est pas dire que le code est open source. Ce sont deux notions très différentes. Je conçois alors, si on ne connait pas très bien les définitions, qu'on puisse se laisser piéger.
Mais ! Ceux qui réagissent fortement en criant à l'imposture sont sensés connaitre la définition d'open source et ne pas tomber dans le panneau.
Beaucoup ont encore une conception erronée (exemple des premiers commentaires de @augustus ou de @Citan666) pour qui "open source" = "source disponible". On le voit bien, pour eux, pas de scandale.
Ce n'est pas de leur faute. Pour moi, c'est la terminologie même d'open source qui est problématique, car elle véhicule un concept très différent entre la conception "grand public" et la définition spécialisée telle que définie par l'OSI (Open Source Initiative).
Et l'ambiguïté est totale, car on oppose souvent closed source (source non disponible) à open source, ce qui n'est pas le cas. Dans le langage courant, open/close s'oppose bien, mais en réalité, closed source s'oppose à source available.
Le 26/09/2024 à 23h 02
Le code de Winamp a été placé sous une licence de type source available. Pourquoi lui reprocher de faire du "faux open source bien hypocrite" ?
Idem qu'au dessus. Winamp n'a jamais dit que le code était open source. Lui reprocher de ne pas respecter l'esprit de l'open source relève donc, pour le coup, de l'hypocrisie.
Sinon, par extension, toute licence non open source (par exemple, la SSPL) est hypocrite.
Le 26/09/2024 à 17h 07
Attention, Open Source est un terme protégé par la Open Source Initiative qui désigne la même chose que le libre (grosso modo, si on fait abstraction des aspects philosophiques). Il ne doit pas être confondu avec les licences dites source available.Open source = possibilité de lire, modifier, exécuter et distribuer
Source available = possibilité de lire
Winamp Classic ne devient donc pas open source (car restriction sur la modification et la diffusion). Il est juste source available.
edit]
Cela dit, cette confusion autour de open source montre à quel point ce terme est vraiment très mal choisi.
[edit 2] Pour les plus curieux, [la définition d'open source d'après l'Open Source Initiative.
Démarchage téléphonique : 200 400 euros d’amende pour Clearnet
26/09/2024
Le 26/09/2024 à 13h 33
Parce qu'effectivement, sinon, j'utilise NoPhoneSpam. Mais il faut bien penser à le mettre dans les applications à ne pas optimiser, sans quoi, il peut ne plus se déclencher au bout d'un moment...
Les États-Unis veulent interdire l’importation et la vente de véhicules connectés chinois
25/09/2024
Le 25/09/2024 à 17h 38
Quand je lis ça, je lis entre les lignes et je comprends : nous on le fait déjà, mais on ne veut pas que les autres le fasse.Entre fermer et partager le code, est-ce « fair » ?
24/09/2024
Le 25/09/2024 à 15h 33
C'est ta vision. Je l'accepte. Mais ce n'est pas la mienne. La BSL ne change rien pour une grande majorité des utilisateurs.
A mon avis ? Pas beaucoup de différence. Java était déjà massivement adopté. Le passage sous GPL s'est fait tardivement (2006).
Même en considérant une application stricte de la licence BSL, les programmes compilés ne seraient pas concernés pour la très grande majorité des acteurs par la clause de non utilisation en production.
La question se poserait par contre pour la machine virtuelle. Soit HotSpot (la VM à l'époque) aurait connu une exception pour l'exécution des programmes (ce que permet la BSL), soit un autre type de licence source avialable aurait été choisi. Ou alors, ceux qui souhaiteraient continuer d'utiliser HotSpot le ferai avec quelques version de retard (et quand on voit les serveurs Java utilisé en production aujourd'hui sur les serveur par exemple, on voit bien que cela n'aurait pas été un frein pour nombre d'entre eux).
L'idée de Sun à ce moment là était de privilégier l'ouverture, pas de contraindre l'utilisation.
Maintenant, je te retourne la question : qu'est-ce qu'une licence de type fair source aurait changé à Java ? Je précise que pour moi, la BSL n'est pas une licence de type fair source. La BSL a une clause de non utilisation en production qui est assez restrictive (même trop à mon gout).
Le 25/09/2024 à 12h 37
Pour moi, l'open-source / libre, en ne s'intéressant qu'à celui qui reçoit le logiciel, ne donne pas les bases nécessaires pour avoir un équilibre des forces et pouvoir obtenir un cercle vertueux (ce qui ne signifie pas que ce n'est pas possible, juste, très difficile).
Les licences comme BSL ou le fair-source sont justement là pour essayer de rétablir un peu l'équilibre. Comment ? En gros, en limitant seulement l'exploitation commerciale (j'ose espérer d'ailleurs que cette notion sera bien définie dans la licence, car cela peut vite être flou).
Le 25/09/2024 à 11h 11
Déjà, en niant les apports que peuvent faire les entreprises en libérant un projet complet, et en mettant en avant les contributions d'un projet. Qu'un projet reçoive 80% de contributions (plutot rare) ou juste 0,01% (très courant), c'est loin d'être la même chose.
Et ça me fait toujours rire quand je lis qu'il s'agit d'une attaque à la communauté, alors que la communauté ne voit pas le pied de nez qu'elle fait à l'entreprise en l'exploitant sans contrepartie, alors que l'entreprise gère 99,9% des coûts, que l'entreprise comptait effectivement sur les contributions (notamment financière) pour pouvoir vivre, et que l'absence d'un modèle viable parce que 99% des utilisateurs profites sans quasiment rien donner en retour l'oblige à changer son business modèle.
Attention : je ne dis pas qu'il n'existe pas des acteurs vertueux dans la communauté, car c'est le cas (et heureusement !). Ils sont juste trop peu nombreux. Je ne dis pas non plus que l'entreprise n'a pas fait d'erreur dans sa stratégie initiale et qu'elle n'attendait pas "trop" de la communauté. Non, je dis que c'est du donnant-donnant, et s'il l'équilibre est rompu ou n'est pas trouvé, il est normal de changer les conditions pour essayer de (re)trouver cet équilibre. Et c'est un peu le souci, ai-je envie de dire, avec les licences libres/open source, qui s'intéressent uniquement à ceux qui reçoivent. Il est, dès lors, difficile de trouver un équilibre, notamment financier, pour les entreprises (mais pas que, c'est vrai aussi pour les développeurs indépendants comme celui de XZ par exemple, qui n'a pas trouvé de business model pour ne serait-ce qu'avoir un salaire pour lui alors que son projet est utilisé sur des centaines de millions de système)
De plus, les attaques que tu mentionnes en donnant Hashicorp en exemple, ne sont pas juste l'apanage des entreprises. Tout projet, avec une licence permissive, peut subir le même sort ! Par exemple, curl (avec sa licence très permissive) pourrait tout à fait subir suivre le même chemin. Cela dépend du bon vouloir de son créateur et mainteneur.
On a vu des développeurs retirer des paquets sur un coup de tête, ou suite en représailles à un conflit (exemple de left-pad sur npm si ma mémoire est bonne), provoquant une mini-paralysie pendant quelques heures de tout un écosystème.
Dans ce que tu décris, tu rejettes entièrement la responsabilité sur l'entreprise et la communauté n'est qu'une pauvre victime, donc il faut se protéger des entreprises. C'est extrêmement réducteur. En fait, dès qu'on utilise des produits open-source, édités par des entreprises ou non, il faut prendre un minimum de précautions, à commencer par faire une copie du code (soit directement, soit disponible via des miroirs. C'est peut être de la parano, mais c'est ce que je fais !)
Pour terminer, je rajouterai qu'on a déjà vu par le passé des forks à cause de changement de licence, même d'une licence libre à licence libre (j'ai en tête X.org / XFree86)
Le 24/09/2024 à 16h 51
Le github annonce bien une licence fair-source pour certains produits comme leur produit éponyme.
Certains projets sont annoncés comme open-source, car ils le sont réellement (Apache-2.0).
Non, sérieusement, donne moi des exemples précis montrant cette ambiguïté dont tu parles, car, pour l'instant, après 5min de recherche, je n'en vois pas.
Le 24/09/2024 à 15h 30
Merci, grâce à toi, j'ai vu que l'article avait été modifié et que la réaction de l'April avait été ajouté.Cela me conforte quand même dans ma position, où pour une bonne frange de la communauté libre/open-source, tout modèle alternatif est à rejeter. Mais bon, dire ça, apparemment, c'est faire preuve d'intolérance...
En théorie, non, puisqu'une des clauses d'une licence fair source serait justement que le code devienne, à terme, open source au sens OSI du terme
Une licence fair-source est, grosso modo, une licence source available avec promesse à terme d'être open source.
Car pour ceux qui ne serait pas au courant, une licence open source (au sens OSI du terme) ne se limite pas à l'accès au code source, mais confère des droits supplémentaires, notamment de modification et de redistribution.
Le 24/09/2024 à 15h 18
Le 24/09/2024 à 15h 15
Le 24/09/2024 à 13h 33
Pour beaucoup de non informaticiens (en tout cas, autour de moi) :
- logiciel libre = gratuit
- logiciel open source = source disponible
- logiciel libre != logiciel open source
Le 24/09/2024 à 12h 47
Quelques précisions :Tout à fait. De ce que j'ai lu (mais sans vraiment creuser pour recouper), c'est qu'ElasticSearch a été forké par les cloud providers (notamment AWS) pour le faire évoluer en fonction de leurs besoins propres, et donc fournissent maintenant une solution compatible ElasticSearch, mais qui n'est pas ElasticSearch.
ElasticSearch aurait cherché à faire prendre des licences aux clouds provider (d'où l'usage de la SSPL) via un premier changement de licence. Mais cela n'a pas marché, car la solution a été forkée. Du coup, maintenant que le fork a été fait, et que les cloud providers utilisent leur propre solution, ils ont de nouveau changé de stratégie pour repasser sur une licence libre, adaptée aux spécificités du Web (et donc des SAAS).
Précision : c'est toi qui a employé le terme d'extrémiste (et je l'ai repris dans un de mes commentaires pour te répondre, j'avoue). Je me contente de dire que la vision de la FSF est très binaire : ou la licence est libre, ou la licence est privatrice. Aucune nuance entre les deux.
Le 24/09/2024 à 11h 51
Si, pour toi, le fait de dire que ce soit bien qu'il existe des notions intermédiaires entre les libres/open-source et les licences propriétaires, et critiquer la position du CNLL ou de l'OpenUK qui fustige la confusion que l'existence même de "fair source" entrainerait, alors oui, je suis intolérant.
On est dans un contexte commercial, donc je parle ici de redistribution.
Maintenant, je suis peut être "extrémiste", mais :
- FSF : On appelle logiciel privateur, ou logiciel non libre, un logiciel qui ne respecte pas la liberté des utilisateurs et leur communauté.. Autrement dit : tout logiciel non libre est privateur (un logiciel comme ElasticSearch est donc tout autant privateur pour la FSF que Windows par exemple).
- L'OSI est très loin d'être aussi extrêmiste, puisqu'il se contente de dire qu'une licence qui ne respecte pas l'open source definition n'est pas open-source. Par contre, et comme je le disais dans un autre commentaire, le terme "open source" me parait très mal choisi, car ne se réfère au final qu'à la règle 2 sur les 10 règles permettant de qualifier une licence comme étant open source.
Aujourd'hui, si on dit qu'on ouvre le code source ou qu'on libère le code source, sans pour autant que cela soit une licence libre / open source, alors on se fait mettre au pilori par une partie de la communauté (cas de Sentry avec codedev en 2023 par exemple) en étant accusé d'openwashing. En effet, Open source est un terme déposé par l'OSI. Mais qu'en est-il des termes dérivés ? Opening the source par exemple ? Dans le langage courant, c'est ouvrir les sources, pas licencier sous une licence open-source. Et pourtant, ça suffit pour être accuser d'openwashing.
Alors, quand je vois le débat sur "fair source" et la notion de fair de la part de défenseur de l'open-source, alors qu'on a exactement la même problématique entre open source et la notion d'ouverture, j'ai vraiment l'impression que c'est l'hôpital qui se fout de la charité.
Le 24/09/2024 à 11h 19
Liste non exhaustive, cela va s'en dire ;)
Le 24/09/2024 à 11h 15
Même de plus gros projet ont des difficultés, et par exemple, Mozilla fermerait sans doute ses portes sans le partenariat qu'il a avec Google et qui lui fourni 90% de ses revenus.
Ce n'est pas pour rien non plus que des projets comme
MariaDBMongoDB ou Elastic Search ont changé de licence pour passer à du libre vers du non-libre.Il y a bien sur des projets qui ont réussi à trouver un business modèle viable. Mais il en existe beaucoup d'autres qui n'y arrive pas non plus.
Et ce n'est pas étonnant dans un sens, puisque les licences libres/open-source s'intéressent à celui qui reçoit le code, pas à celui qui le donne. De facto, même si par principe ce n'est pas interdit par les licences, il est très difficile de vendre le logiciel en lui-même. Il faut, par exemple, fournir du service autour, encore faut-il que le logiciel s'y prête.
Ou encore le double-licensing, où le produit open-source est un produit d'appel et le produit commercial contient les fonctionnalités les plus avancées. On y retrouve des logiciels comme nginx, gitlab, etc. Mais là encore, il faut que le logiciel s'y prête.
[edit]
Correction suite à la remarque de judicieuse de ragoutoutou sur la confusion MongoDB/MariaDB
Le 24/09/2024 à 10h 54
Dans un sens, tu as raison lorsque tu dis que l'open-source relève de la collaboration, car l'open-source se focalise sur des considérations techniques et n'est pas fermé quant à l'usage de logiciel non open source (contrairement au principe du libre, notamment les licences GPL).
Non. Ce que je demande, c'est que les gens qui ont des principes tolère des principes différents avec des appellations différentes.
Comparaison foireuse. Ici, on est plutôt sur des végétariens qui refuseraient l'existence même du terme flexitarien, car cela ajouterait, d'après eux, de la confusion (ou l'existence du terme bisexuel pour continuer sur ton analogie avec les homosexuels).
Le 24/09/2024 à 10h 43
C'est quand même à l'opposé de certaines sociétés qui ont changé la licence de leur logiciel pour passer d'open source vers une licence source available (comme Elastic Search ou MariaDB par exemple) et ont donc plutôt un esprit de fermeture.
Note : pour ma part, je trouve que le terme "open source" est mal choisi par l'OSI, car ne véhicule pas toutes les idées qui y sont liées. Pour beaucoup de non professionnel, open source = source disponible. Les libertés liées à la modification et à la diffusion n'apparaissent pas. Mais ça, c'est un avis très personnel, et je fais avec ^^
Le 24/09/2024 à 10h 11
Le monde open-source a une vision très manichéenne où soit c'est libre, soit c'est privateur.
Sauf que les éditeurs de logiciels et développeur sont libres de choisir la licence qu'ils souhaitent. Les licences libres présentent certains avantages indéniables, mais sont très mauvaises pour la viabilité commerciale d'un produit.
Les licences de types source available et fair source permettent d'ajouter des nuances de type propriétaire entre le libre et le privateur, là où le libre souhaite dire que propriétaire = privateur.
Le 24/09/2024 à 09h 23
On peut se poser exactement la même question avec la notion d'open-source ou de libre.En fait, pendant longtemps, les licences de logiciels se classaient dans 2 catégories :
- licences libres ou open-source : qui respecte les 4 libertés fondamentales
- licences propriétaires ou privatrices : licences qui ne sont pas libres / open-source.
On constate alors qu'une seule catégorie avait réellement une définition, et l'autre étant définie "par opposition".
Il suffisait alors d'avoir une licence avec restriction pour qu'elle soit considérée comme privatrice (comme la SSPL).
Depuis quelques années, nous avons maintenant aussi le source available, qui permet de désigner un code ouvert au sens propre du terme (=source disponible).
La notion de fair source rajoute un pont supplémentaire entre le source available et le libre, et protège également les utilisateurs en cas de défaillance de l'entreprise, puisque le code basculera automatiquement sur une licence libre au bout d'un certains laps de temps, sécurisant la modification et la distribution du code après une liquidation d'une entreprise ou l'arrêt d'un produit par exemple (cf. les exemples plus ou moins récent au sujet de la domotique !)
Maintenant, l'avis de la FSF ou du CNLL, ne m'étonne guère, puisque pour eux, le saint graal est le libre / open-source et toute licence non libre est de facto propriétaire.
#LIDD : booter Linux sur un CPU 4004 de 1971, c’est possible… en plus de 4 jours
25/09/2024
Le 25/09/2024 à 09h 08
Au delà de l'aspect technique (qui relève ici de la prouesse), je préfère le challenge qui consiste à faire tourner Doom. C'est plus ludique ^^Chez Apple, toute une série de Mac deviennent obsolètes ou anciens
24/09/2024
Le 24/09/2024 à 18h 35
Le 24/09/2024 à 16h 35
Chanceux ! Maintenant, on ne peut même plus mettre un plus gros SSD... (soudé à la carte mère).La Federal Trade Commission recommande l’adoption d’une version états-unienne du RGPD
24/09/2024
Le 24/09/2024 à 16h 29
Par contre, ce qui serait bien, c'est une coopération entre les différents organismes en charge des différentes règlementations, afin de permettre de faire payer les amendes (c'est justement le cas Clearview qui me fait penser à ça)
Le 24/09/2024 à 15h 41
Moi, c'est surtout Musk que j'entends !Pour faire face aux besoins énergétiques de l’IA, Microsoft se tourne elle aussi vers le nucléaire
24/09/2024
Le 24/09/2024 à 16h 25
Et les dossiers de Musk ? Les X-Files
La vérité est ailleurs...
[Édito] L’intelligence artificielle est-elle intelligente ou artificielle ?
23/09/2024
Le 24/09/2024 à 15h 32
En fait, c'est simple. L'IA, ce n'est pas de l'intelligence artificielle, mais de l'idiotie assistée.Don't be an iDiot
IA : un impact environnemental conséquent mais toujours difficile à mesurer
23/09/2024
Le 24/09/2024 à 10h 01
Allez, reprenons ensemble l'ensemble des chiffres.La métrique global dépend du nombre d'utilisation. Une faible utilisation donne donc de faibles émissions. Rapporté au nombre de requête, c'est 3Wh / requête.
ChatGPT répond à 1,5 milliards de requête par jour en 2023.
Si on extrapole les chiffres, cela fait près de 500MWh / an, soit la production d'une petite centrale nucléaire. Toujours rien ?
Et si on parlait du biais du survivant ? Pour un modèle publié, combien y-a-t-il eu de modèles entrainé et mis à la benne car inefficace ?
Penses-tu sincèrement que les modèles sont obtenus du premier coup ? Un modèle peut nécessiter de nombreux essais. Pour avoir fait un peu d'IA, la création de la topologie d'un modèle, ce sont de nombreux paramètres ajustables (nombre de couches, tailles des couches, fonction d'activation, etc.) et ce sont souvent des essais/erreurs qui permettent de choisir ensuite le "meilleur" modèle.
Pour un modèle publié, on peut donc avoir des milliers de modèles non publiés. On atteint donc plutôt l'ordre de 300MtEqCO2 par an. Soit la moitié des émissions d'un pays comme la France.
Et ça, c'est pour UN seul modèle. Rajoute Google, Apple, Meta, etc. qui ont chacun leur modèle et cela devient vraiment loin d'être négligeable.
Qui plus est, avec Apple qui déploie des IA dans ses smartphones, Microsoft qui pousse de plus en plus Copilot, etc. l'usage des modèles ne vas faire que croitre d'ici les prochaines années.
RED by SFR informe ses clients d’une nouvelle fuite, avec une ribambelle de données
19/09/2024
Le 24/09/2024 à 07h 57
Mais un conseiller ne vous appellera jamais sans avoir été sollicité pour vous demander un code ou une confirmation via l'application bancaire. Jamais. Un conseiller qui fait ça, c'est pas votre conseiller, c'est un escroc.
Le 20/09/2024 à 15h 34
Toute tentative de ce genre est une arnaque. Et pour les attaques les plus poussées (comme dans le cas que tu décris avec affichage du "bon numéro") : prévenir sa banque malgré tout, par écrit, de préférence, car cela laisse des traces, afin de se protéger. Et la banque peut mettre un warning sur le compte pour accroitre la surveillance de transactions qui paraitraient frauduleuses (virement important et/ou vers l'étranger par exemple).
Pour rappel, en cas de fraude, la banque est tenue de prouver la négligence de son client, sans quoi, elle doit rembourser les sommes en question.
La communauté demande (encore) à Oracle de libérer la marque JavaScript
23/09/2024
Le 23/09/2024 à 16h 49
Je comprends le désir de la communauté quant à cette libération.Néanmoins, et face à un géant comme Oracle (dont les vertus en terme de marque et droits d'auteurs ne sont plus à démontrer tousse tousse), j'ai envie de dire méfiance ! Il serait bien capable de trouver un moyen de rentabiliser cela, d'une manière ou d'autre, et que cette demande ne se retourne, in fine, contre la communauté.
Le prix de YouTube Premium s’envole dans certains pays
23/09/2024
Le 23/09/2024 à 14h 07
Netflix produit effectivement des oeuvres, et paie pour pouvoir ajouter des oeuvres dont il n'a pas les droits.
Youtube, de son côté, ne paie pas grand chose pour la création d'oeuvre, mais :
- comme il est hébergeur, doit mettre en place une équipe de modération
- c'est une grande plateforme au sens DMA du terme (donc a des obligations supplémentaires)
- doit payer/trouver des accords avec les ayants droits (pas une mince affaire)
- doit gérer les demandes de signalement et de retrait
- doit supporter des coûts de stockage bien plus élevé que Netflix (ben oui, les vidéos de chaton, ça pèse)
- dispose de fonctionnalités qui doivent aussi peser en terme d'infrastructure, comme les lives youtube, où il n'y a pas de limite max quant on nombre d'utilisateur connecté (de limite codé en dur je veux dire, peut être que 100 millions d'utilisateur sur le même live, il aurait du mal ^^)
- est un grand utilisateur d'IA (les sous-titres automatique ne se font pas tout seul)
- fait énormément de transcodage pour proposer les vidéos dans des formats/résolutions différentes (netflix aussi, mais le nombre de vidéo sur Youtube est bien plus important, et Youtube doit le faire en temps quasi réel après le dépôt d'une vidéo)
- etc.
Bref, comparer les 2 en se concentrant que sur ce qu'il y a de commun, c'est comme comparer le prix d'une trottinette et d'un vélo, parce que les deux ont des roues et permettent de se déplacer, alors que les usages sont radicalement différents.
IA : Meta et Spotify fustigent l’Europe et sa « structure réglementaire fragmentée »
20/09/2024
Le 21/09/2024 à 09h 49
Pour résumer la position de Spotify, Meta, etc. en quelques mots facile à comprendre pour le béotien moyen, voici comment comprendre l'argumentation.Pour une décision qui les freine (cas de la lettre ouverte)
- l’IA générative pourrait accroitre le PIB mondial de 10 %. Les citoyens européens pourraient « être privés de cette croissance ». => on veut notre part du gâteau
- L’Union européenne risque également de passer à côté d’autres innovations, « comme l'assistant d'IA Meta, qui est en passe de devenir l'assistant d'IA le plus utilisé au monde d'ici à la fin de l'année ». => au cas où vous n'auriez pas compris le message subliminal précédant : on veut notre part du gâteau
Pour une décision qui les arrange (cas du DMA, DSA, etc. pour Spotify contre Apple par exemple)
- c'est super, on va pouvoir payer moins cher, et donc engranger plus de bénéfice.
En résumé : non, ils ne sont pas philanthropique, contrairement à ce que laisse penser la lettre ouverte. Ils veulent toujours plus d'argent.
Note : je n'ai rien contre le fait qu'une entreprise gagne de l'argent. Au contraire (je suis chef d'entreprise). Mais cet argumentaire déguisé soupoudré d'altruisme et de générosité en disant c'est pour votre bien plutôt que d'avoir que 'c'est pour le bien de nos bénéfices me donne des envies de régurgitation.
Le 21/09/2024 à 09h 38
Sans aller jusqu'à parler d'armes, l'exemple récent du Nevada suffit.En Europe, l'article 22 du RGPD est sensé nous protégé de décisions fondées exclusivement sur un traitement automatisé produisant des effets juridiques nous concernant ou nous affectant de manière significative (et je pense que des allocations entre dans cette catégorie).
Certains verront cela comme un frein. D'autres, comme un garde-fou.
+1000
#Nextpresso : module TIC Linky et clé Zigbee pour suivre en direct sa consommation électrique
20/09/2024
Le 20/09/2024 à 16h 49
J'ai un home assistant à la maison, et les problèmes que j'ai rencontré jusqu'à présent, c'est plutôt au niveau de la gestion de la clé Zigbee que la communication avec les différents appareils.
Le plugin Zha ne fonctionne pas correctement avec ma clé (une ConBee II sous la forme d'un module pour Raspberry, pas en dongle USB, firmware à jour). Je suis obligé de passer par Deconz pour la clé (j'aurais bien voulu m'en passer, pour faire une couche en moins).
Le 20/09/2024 à 15h 44
Le 20/09/2024 à 15h 00
Le module, c'est sur le Linky (ça c'est bon).
La clé, c'est sur une carte genre raspeberry afin de récupérer les données via Zigbee et de les diffuser en MQTT ensuite.
Mais du coup, si c'est le raspeberry même qui traite les info (par exemple avec Home Assitant ou Jeedom), pas besoin d'avoir une clé Zigbee2MQTT. Une simple clé Zigbee suffit non ?
Sur Linux, Vivaldi sera aussi distribué en Snap
20/09/2024
Le 20/09/2024 à 15h 51
Car en pratique, libre = open source (aux nuances philosophiques près)
Google synchronise enfin les clés d’accès (passkeys) sur tous les appareils
20/09/2024
Le 20/09/2024 à 15h 22
Le mécanisme utilisant des passkeys repose en réalité sur 2 clés : une publique, et une privée.
La clé privée est sensée être dans une enclave sécurisée dont elle ne sort pas. C'est le dispositif lui-même qui résout le challenge avec la clé privée, mais la clé privée ne quitte pas le dispositif (qui peut être virtuel, mais c'est un autre sujet).
Dès lors, parler de synchronisation, cela signifie que la clé privée peut sortir pour être dupliquée.
L'interrogation de eophea est donc tout à fait légitime (et je la partage).
#LIDD : le bullshitron, ou le paroxysme de l’IA disruptive
20/09/2024
Le 20/09/2024 à 15h 03
Quand je regarde des vidéos de dev ou des podcasts, parfois c'est un tel franglais qu'il m'arrive de ne rien piger. Les termes je les connais pourtant, mais le mix français-anglais me déconcentre tellement que j'en perds le fil...
Le 20/09/2024 à 14h 03
En même temps, on est tellement habitué avec nos politiques à cette langue de bois....Le brevet de Ford pour un système publicitaire qui écoute les conversations à bord
12/09/2024
Le 20/09/2024 à 12h 43
Dans le cas qui nous occupe, à savoir intervenir sur la pile audio, c'est loin d'être à la portée de tout le monde, et nécessite une réelle implication qui dépasse, et de loin, la "simple contribution".
My 2 cents.
[Algorithmique] Next lance son premier podcast !
18/09/2024
Le 20/09/2024 à 11h 03
Si l'objectif du podcast c'est aussi de faire connaître Next, il faut qu'il soit trouvable facilement pour tout le monde (et pas seulement pour le lectorat déjà existant).
Cela peut devenir un mécanisme d'acquisition pour de nouveaux lecteurs "payants"
Bernard Arnault interdit à ses employés de parler aux journalistes d’investigation indépendants
18/09/2024
Le 20/09/2024 à 10h 48