Je ne pense pas: la capture se fait forcément en entrelacé qui est le format de l'enregistrement sur la VHS. Par contre, on doit pouvoir ajouter toutes sortes de filtres, y compris de désentrelacement. Je ne sais pas ou cela se trouve dans VLC, peut-être dans le menu Vidéo?
Les Thinkpad chez Lenovo arrivaient à rentrer un clavier avec peu de concessions de ce genre sur leurs machines 12" (par exemple, le X200 que j'ai chez moi). Effectivement ce sont des machines coûteuses si on les achète neuves, mais il n'y a pas de raisons que ça ne sois pas possible sur une machine moins chère?
Les 4 flèches font 2/3 de la hauteur d'une touche normale, et il y a un pavé avec les touches home/end/page up/page down séparé, comme ceci:
Quand tu utilises un cable S-Video, c'est le magnétoscope qui sépare les canaux de luminance et chrominance qui sont de toutes façons enregistrés ensemble sur la bande. Quand tu utilises un câble composite, c'est fait par le PC. Il est possible que ton PC sache faire ça mieux que ton magnétoscope, et du coup, le résultat peut très bien être meilleur, suffisament pour compenser les pertes dues au transport des 2 infos sur un seul fil dans le câble composite.
C'est un des problèmes réglés par le PAE. Quand il faut absolument tout faire rentrer dans des adresses 32 bits, y compris les adresses physiques, on ne peut avoir que 4Go d'espace mémoire.
Avec PAE, les adresses logiques (donc les pointeurs vus par les applications) sont toujours en 32 bits, par contre les adresses physiques sont en 64 bits. Du coup, on peut mapper toute la RAM (même s'il y a 4Go ou plus) plus les périphériques sans problème. Ensuite, chaque application dispose d'une ou plusieurs fenêtres qui permettent de voir des morceaux de cet espace (la RAM qu'elles ont allouées, les périphériques auxquels elles ont le droit d'accéder). Et du coup, toute la RAM peut être utilisée, du moment qu'elle est partagée entre plusieurs applications (ce qui est quand même souvent le cas).
Sur x86 on a fait de l'adressage segment:offset pendant longtemps (avec donc des adresses logiques 32 bits, des adresses physiques 20 bits, puis plus tard 32 bits, et des registres d'une largeur de 16 bits). Ce n'est qu'à partir du 386 qu'une gestion un peu plus "moderne" de la mémoire a commencé à apparaître, avec des registres 32 bits et un espace mémoire également 32 bits.
Concrètement, il y a des pointeurs "near" (pointant dans le "même" segment), et des pointeurs "far" (pointant sur un segment spécifique). Avec différents modèles d'allocation de la mémoire aux applications (toute l'application dans un seul segment, un segment de code + un segment de données, plusieurs segments de chaque).
C'est pas des plus confortable, mais ça peut marcher.
Pour Haiku, c'est en train de changer dourcement. On a peu de resources et on se concentre sur la version 32 bits (et gcc2!) pour le moment car c'est la seule compatible avec BeOS. Dès qu'on aura le support des applications 32bits sur un noyau 64, on n'hésitera pas à passer plus sérieusement au 64bit.
C'est donc un cas particulier lié à un héritage historique et des contraintes de compatiblité.
(et pour MenuetOS, il vaut peut être mieux regarder du côté du fork KolibriOS qui semble un peu plus actif et impliqué dans le libre en général).
On peut aussi citer AROS et ReactOS mais j'ai la flemme d'aller voir où en est leur support du 64-bits :)
Le PAE permet au noyau de l'OS de gérer plus de 4Go de RAM, tout en exposant à chaque application un espace de 4Go. Donc, pour les applications qui n'ont pas besoin de 4Go dans un seul process, c'est transparent et ça marche très bien (et côté noyau, franchement, on est plus à un truc moche près…).
L'espace RAM en plus peut aussi être utilisé avec un adressage 64bit par exemple pour des caches disque ou d'autres trucs dont le noyau aurait besoin.
Après, de nos jours, l'intérêt est discutable et je ne vois pas de raison de ne pas tout mettre en 64bit.
Une ISA qui reflète trop le fonctionnement interne du CPU a un autre problème: ça devient compliqué d'implémenter la même ISA avec une architecture interne différente. Et quand on voit la durée de vie de l'ISA du x86, ou encore plus longue du jeu d'instruction du 8051 de chez Intel, il vaut mieux faire un truc qui laisse un peu de liberté du côté du design du CPU.
(au moins il y a une "traduction" en français de la composition, avec des liens détaillant chaque ingrédient).
de toutes façons cela semble normal qu'une entreprise cherche à faire des profits. Il reste plus qu'à leur prouver qu'il y a un marché pour le bicarbonate de soude goût citron! Et à vérifier ce qu'il y a vraiment dans les agréments pour le bicarbonate de cuisine/cosmétique pour être sur de ce qu'on achète et s'il faut se méfier des produits qui n'ont pas cet agrément (par exemple je vois que Starwax propose les deux: http://www.starwax.fr/produit/les-indispensables/bicarbonate-soude / http://www.starwax.fr/produit/les-indispensables/bicarbonate-soude-alimentaire [mais pas encore la version au citron!])
Sans installation de logiciels, il y a aussi des clients XMPP qui se lancent dans un navigateur web sans rien installer. J'utilisais il y a quelque temps https://jwchat.org/, on a peut-être fait mieux depuis?
Chez moi c'est IceWM pour le WM et Gentoo pour le gestionnqire de fichier (pas la distrib, l'autre).
Petite astuce: il existe un outil xdg-open qui trouve une application par défaut en fonction du type de fichier. Je l'utilise comme action par défaut pour le double clic dans Gentoo, je suppose qu'on peut faire pareil dans ROX. Comme ça il ne reste plus qu'à paramétrer les cas particuliers.
Sous BeOS et Haiku, ce genre d'infos sont stockées dans des xattrs au niveau du système de fichiers. ça évite de "pourrir" le fichier lui-même avec des tags bizarres.
Nouveau, c'est pour écrire un driver pour un GPU existant, pas pour refaire un GPU.
Il ne faut pas croire qu'un FPGA ou un DSP sont des trucs magiques pour avoir un système super rapide. D'abord, ça ne fait que du numérique, alors qu'une bonne partie du travail pour un modem GSM/GPRS/3G/4G est analogique (démodulation, traitement du signal, etc). Et même avec un FPGA, il va être compliqué de faire un truc qui mouline assez vite pour traiter toutes les données.
En plus de ça, on ne peut pas se mettre à faire du GSM comme ça, il faut passer toutes les homologations pour avoir le droit de se connecter au réseau (sinon, le modem est blacklisté et se fera jeter par les antennes relais).
Faire la rétro ingénierie d'une puce existante n'a pas d'intérêt, les specs des réseaux de téléphonie mobile sont connues et il "suffit" de les implémenter. Mais, c'est énormément de travail. Et, le temps que tu aies fini ton petit modem GSM, tout le monde est déjà passé à la 4G et tu as 3 générations de retard. Mais bon, il faut bien commencer quelque part.
Dès qu'on touche un peu au matériel, ça devient compliqué d'avoir quelque chose de purement communautaire. Il faut comprendre que pour ce genre de matériel, on travaille avec des équipements qui coûtent le prix d'une maison. Il faut pas attendre qu'un Richard Stallman du GSM se lance là dedans sur ses fonds propres. ça ne pourra se faire que si une entreprise le décide.
Une fois la solution libre publiée, il reste encore le problème de la produire. Est-ce qu'on peut faire confiance aux fondeurs d'ASICs pour ne pas trafiquer le design et y insérer un mouchard? Est-ce qu'on peut vraiement forker le design pour en faire une version améliorée, ou est-ce que les coûts sont trop élevés pour que ça soit raisonnable? Le libre ne réglera pas tous les problèmes du côté du matériel.
En fait c'est pour uniformiser avec les autres sytèmes à la pomme:
- iOS: pour les iBidules (iPhone, iPad)
- macOS: pour les macBidules (macBook, mac pro, etc.)
- watchOS: pour les montres (iWatch, ah zut ça commence par un i?)
Les nouveaux systèmes d'exploitation, iOS en version 10 et OS X qui serait à l'occasion renommé… MacOS ! Un nom dans lequel on peut voir, outre l'aspect "retour aux sources" (qui renoue avec la glorieuse époque de l'invention du premier système à interface graphique pilotée à la souris)
Même pas, le système des Macintosh à l'époque s'appellait… "system". Ce n'est qu'à partir de la version 7.6 qu'on a commencé à parler de MacOS, donc vers 1997. Pas l'époque la plus glorieuse pour Apple, qui a ce moment là essayait de vendre son OS à UMAX et Daystar Digital, tout en en essayant de ne pas avoir trop de BeOS sur leurs propres machines
D'ailleurs, il ne faut pas confondre la GPL de GNU avec celle d'Affero (souvent appelée AGPL pour éviter les confusions). Donc, c'est important de protéger le nom, qui peut sinon être repris avec une license complètement différente. Protéger le contenu de la license, par contre, ça n'a d'intérêt que pour limiter la prolifération des licences (du genre "je prend la GPL mais je rajoute une exception qui rend mon truc incompatible avec la GPL d'origine").
Après vérification, c'est 3 ans seulement (oups). C'est la section 3b de la licence (pour la GPL2, j'ai pas vérifié la GPL3):
b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange;
Et il y a deux cas ou ce n'est pas nécessaire:
- Si on distribue directement les sources avec le logiciel,
- Ou, si on redistribue a titre non-commercial, dans ce cas on peut "faire suivre" l'offre de récupération du code que l'on a soi-même reçu.
Ça ne pose pas trop de problèmes quand on met un logiciel en téléchargement sur internet (il suffit dans ce cas de mettre un lien vers les sources juste à côté du lien vers le binaire). C'est plus pénible quand par exemple on veut vendre un CD d'installation d'une distribution Linux contenant du code sous GPL (et pas forcément les sources qui vont avec, faute de place).
Tout ça, sans parler du fait que la licence GPL est effectivement compliquée à lire, et surtout, contraignante aussi pour ceux qui décide de diffuser du code sous GPL (essayez un jour, pour voir). Il faut diffuser le code source (bon ok, ça ça va), mais aussi, il faut être prêt à donner le code source de n'importe quelle version précise du logiciel à toute personne qui le demande, et ce, jusqu'à 10 ans après la diffusion de la dite version.
Ce genre de restrictions, ça devient très vite compliqué à gérer, aussi bien quand on est un particulier et qu'on a juste envie de partager un bout de code, que quand on est une entreprise ou une association et qu'on veut se lancer dans le libre. Juste pour savoir ce qu'on a le droit de faire ou pas, il faut embaucher un juriste. Du coup, la solution la moins coûteuse, c'est de prendre une licence plus facile à lire. A moins d'être la FSF et d'avoir une armée de juriste rompus à ce genre d'exercice. Mais dans le monde du libre, c'est rare.
Un autre aspect, c'est que ça me paraît difficile de "vendre" du logiciel comme étant libre, mais d'expliquer qu'il y a des conditions d'utilisations aussi longues que le CLUF de Windows. Même si elles sont peut être moins restrictives, il faut les lire pour le savoir, et je ne pense pas que ça soit quelque chose qu'on peut demander à tous les utilisateurs. Comme le dit le journal: avez-vous lu votre licence?
Finalement, une licence courte et facile à lire, c'est une très bonne arme contre le FUD, non?
C'est une très bonne nouvelle que quelqu'un se penche enfin sur le travail collaboratif et le suivi de modifications avec KiCad. Même en l'utilisant tout seul pour quelques modestes projets open hardware, c'est quelque chose dont j'aurais bien besoin (mais pas assez pour avoir commencé à développer quelque chose).
[^] # Re: désentrelacement ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Numérisation de cassettes VHS avec VLC. Évalué à 4.
Je ne pense pas: la capture se fait forcément en entrelacé qui est le format de l'enregistrement sur la VHS. Par contre, on doit pouvoir ajouter toutes sortes de filtres, y compris de désentrelacement. Je ne sais pas ou cela se trouve dans VLC, peut-être dans le menu Vidéo?
[^] # Re: Touches directionnelles
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Retour d'expérience Achat PC portable LDLC SK1-I3-4-S1. Évalué à 8.
Les Thinkpad chez Lenovo arrivaient à rentrer un clavier avec peu de concessions de ce genre sur leurs machines 12" (par exemple, le X200 que j'ai chez moi). Effectivement ce sont des machines coûteuses si on les achète neuves, mais il n'y a pas de raisons que ça ne sois pas possible sur une machine moins chère?
Les 4 flèches font 2/3 de la hauteur d'une touche normale, et il y a un pavé avec les touches home/end/page up/page down séparé, comme ceci:
# S-Video
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Numérisation de cassettes VHS avec VLC. Évalué à 10.
Quand tu utilises un cable S-Video, c'est le magnétoscope qui sépare les canaux de luminance et chrominance qui sont de toutes façons enregistrés ensemble sur la bande. Quand tu utilises un câble composite, c'est fait par le PC. Il est possible que ton PC sache faire ça mieux que ton magnétoscope, et du coup, le résultat peut très bien être meilleur, suffisament pour compenser les pertes dues au transport des 2 infos sur un seul fil dans le câble composite.
[^] # Re: movim: grand potentiel mais très mauvais nom choisi
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Movim 0.10 - Holmes. Évalué à 3.
C'est pas les premiers à choisir leur nom n'importe comment:
https://wiki.debian.org/WhyTheName
[^] # Re: Rien à voir
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal x86 ou x86_64 ?. Évalué à 2.
C'est un des problèmes réglés par le PAE. Quand il faut absolument tout faire rentrer dans des adresses 32 bits, y compris les adresses physiques, on ne peut avoir que 4Go d'espace mémoire.
Avec PAE, les adresses logiques (donc les pointeurs vus par les applications) sont toujours en 32 bits, par contre les adresses physiques sont en 64 bits. Du coup, on peut mapper toute la RAM (même s'il y a 4Go ou plus) plus les périphériques sans problème. Ensuite, chaque application dispose d'une ou plusieurs fenêtres qui permettent de voir des morceaux de cet espace (la RAM qu'elles ont allouées, les périphériques auxquels elles ont le droit d'accéder). Et du coup, toute la RAM peut être utilisée, du moment qu'elle est partagée entre plusieurs applications (ce qui est quand même souvent le cas).
[^] # Re: Se tenir au courant ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal x86 ou x86_64 ?. Évalué à 3.
Sur x86 on a fait de l'adressage segment:offset pendant longtemps (avec donc des adresses logiques 32 bits, des adresses physiques 20 bits, puis plus tard 32 bits, et des registres d'une largeur de 16 bits). Ce n'est qu'à partir du 386 qu'une gestion un peu plus "moderne" de la mémoire a commencé à apparaître, avec des registres 32 bits et un espace mémoire également 32 bits.
Concrètement, il y a des pointeurs "near" (pointant dans le "même" segment), et des pointeurs "far" (pointant sur un segment spécifique). Avec différents modèles d'allocation de la mémoire aux applications (toute l'application dans un seul segment, un segment de code + un segment de données, plusieurs segments de chaque).
C'est pas des plus confortable, mais ça peut marcher.
[^] # Re: Du 64 bits dans les systèmes libres
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal x86 ou x86_64 ?. Évalué à 5.
Pour Haiku, c'est en train de changer dourcement. On a peu de resources et on se concentre sur la version 32 bits (et gcc2!) pour le moment car c'est la seule compatible avec BeOS. Dès qu'on aura le support des applications 32bits sur un noyau 64, on n'hésitera pas à passer plus sérieusement au 64bit.
C'est donc un cas particulier lié à un héritage historique et des contraintes de compatiblité.
(et pour MenuetOS, il vaut peut être mieux regarder du côté du fork KolibriOS qui semble un peu plus actif et impliqué dans le libre en général).
On peut aussi citer AROS et ReactOS mais j'ai la flemme d'aller voir où en est leur support du 64-bits :)
[^] # Re: Correction
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal x86 ou x86_64 ?. Évalué à 7.
Je comprend pas bien…
Le PAE permet au noyau de l'OS de gérer plus de 4Go de RAM, tout en exposant à chaque application un espace de 4Go. Donc, pour les applications qui n'ont pas besoin de 4Go dans un seul process, c'est transparent et ça marche très bien (et côté noyau, franchement, on est plus à un truc moche près…).
L'espace RAM en plus peut aussi être utilisé avec un adressage 64bit par exemple pour des caches disque ou d'autres trucs dont le noyau aurait besoin.
Après, de nos jours, l'intérêt est discutable et je ne vois pas de raison de ne pas tout mettre en 64bit.
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Le Top 500 des supercalculateurs de juin 2016. Évalué à 2.
Une ISA qui reflète trop le fonctionnement interne du CPU a un autre problème: ça devient compliqué d'implémenter la même ISA avec une architecture interne différente. Et quand on voit la durée de vie de l'ISA du x86, ou encore plus longue du jeu d'instruction du 8051 de chez Intel, il vaut mieux faire un truc qui laisse un peu de liberté du côté du design du CPU.
[^] # Re: Education
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Retour sur le « No poo ». Évalué à 1.
Si je me rappelle bien, ce documentaire sort (un peu?) Weleda du lot. Mais les recettes de shampoing chez eux ont l'air quand même un peu plus compliquées que celle du Journal:
https://www.weleda.fr/product/s/shampooing-usage-frequent-au-millet
(au moins il y a une "traduction" en français de la composition, avec des liens détaillant chaque ingrédient).
de toutes façons cela semble normal qu'une entreprise cherche à faire des profits. Il reste plus qu'à leur prouver qu'il y a un marché pour le bicarbonate de soude goût citron! Et à vérifier ce qu'il y a vraiment dans les agréments pour le bicarbonate de cuisine/cosmétique pour être sur de ce qu'on achète et s'il faut se méfier des produits qui n'ont pas cet agrément (par exemple je vois que Starwax propose les deux: http://www.starwax.fr/produit/les-indispensables/bicarbonate-soude / http://www.starwax.fr/produit/les-indispensables/bicarbonate-soude-alimentaire [mais pas encore la version au citron!])
[^] # Re: Complément d'information
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Retour sur le « No poo ». Évalué à 4.
Oui mais y'en a un qui est naturel, et l'autre chimique!
[^] # Re: pas xmpp mais
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Meta chat. Évalué à 3.
Sans installation de logiciels, il y a aussi des clients XMPP qui se lancent dans un navigateur web sans rien installer. J'utilisais il y a quelque temps https://jwchat.org/, on a peut-être fait mieux depuis?
[^] # Re: Slackwariens/puristes complètement déconnectés de la réalité
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Slackware 14.2. Évalué à 2.
Chez moi c'est IceWM pour le WM et Gentoo pour le gestionnqire de fichier (pas la distrib, l'autre).
Petite astuce: il existe un outil xdg-open qui trouve une application par défaut en fonction du type de fichier. Je l'utilise comme action par défaut pour le double clic dans Gentoo, je suppose qu'on peut faire pareil dans ROX. Comme ça il ne reste plus qu'à paramétrer les cas particuliers.
[^] # Re: On n'arrête pas le progrès
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal dl.center : partage de fichier entre périphérique. Évalué à 3.
http://michel.buze.perso.neuf.fr/lavache/chevalier_laspales_le_train_pour_pau.htm
[^] # Re: pour un nouvel élan vers la gloire médiatique
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal A l'heure où Owncloud, CozyCloud et NextCloud font du bruit, Tracim continue son bonhomme de chemin. Évalué à 3.
XKCD
^WCommitStrip pertinent: http://www.commitstrip.com/fr/2016/06/20/coder-bingo/[^] # BeOS le faisait il y a 15 ans!
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Playtag : paramètres de lecture audio/vidéo en métadonnées. Évalué à 2.
Sous BeOS et Haiku, ce genre d'infos sont stockées dans des xattrs au niveau du système de fichiers. ça évite de "pourrir" le fichier lui-même avec des tags bizarres.
[^] # Re: Moi aussi
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Baseband GSM libre: aucun progrès ?. Évalué à 7.
Nouveau, c'est pour écrire un driver pour un GPU existant, pas pour refaire un GPU.
Il ne faut pas croire qu'un FPGA ou un DSP sont des trucs magiques pour avoir un système super rapide. D'abord, ça ne fait que du numérique, alors qu'une bonne partie du travail pour un modem GSM/GPRS/3G/4G est analogique (démodulation, traitement du signal, etc). Et même avec un FPGA, il va être compliqué de faire un truc qui mouline assez vite pour traiter toutes les données.
En plus de ça, on ne peut pas se mettre à faire du GSM comme ça, il faut passer toutes les homologations pour avoir le droit de se connecter au réseau (sinon, le modem est blacklisté et se fera jeter par les antennes relais).
Faire la rétro ingénierie d'une puce existante n'a pas d'intérêt, les specs des réseaux de téléphonie mobile sont connues et il "suffit" de les implémenter. Mais, c'est énormément de travail. Et, le temps que tu aies fini ton petit modem GSM, tout le monde est déjà passé à la 4G et tu as 3 générations de retard. Mais bon, il faut bien commencer quelque part.
Dès qu'on touche un peu au matériel, ça devient compliqué d'avoir quelque chose de purement communautaire. Il faut comprendre que pour ce genre de matériel, on travaille avec des équipements qui coûtent le prix d'une maison. Il faut pas attendre qu'un Richard Stallman du GSM se lance là dedans sur ses fonds propres. ça ne pourra se faire que si une entreprise le décide.
Une fois la solution libre publiée, il reste encore le problème de la produire. Est-ce qu'on peut faire confiance aux fondeurs d'ASICs pour ne pas trafiquer le design et y insérer un mouchard? Est-ce qu'on peut vraiement forker le design pour en faire une version améliorée, ou est-ce que les coûts sont trop élevés pour que ça soit raisonnable? Le libre ne réglera pas tous les problèmes du côté du matériel.
[^] # Re: Nomenclature
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Du neuf, enfin !. Évalué à 2.
En fait c'est pour uniformiser avec les autres sytèmes à la pomme:
- iOS: pour les iBidules (iPhone, iPad)
- macOS: pour les macBidules (macBook, mac pro, etc.)
- watchOS: pour les montres (iWatch, ah zut ça commence par un i?)
# MacOS, glorieuse époque?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Du neuf, enfin !. Évalué à 5.
Même pas, le système des Macintosh à l'époque s'appellait… "system". Ce n'est qu'à partir de la version 7.6 qu'on a commencé à parler de MacOS, donc vers 1997. Pas l'époque la plus glorieuse pour Apple, qui a ce moment là essayait de vendre son OS à UMAX et Daystar Digital, tout en en essayant de ne pas avoir trop de BeOS sur leurs propres machines
[^] # Re: wtf
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal DMOZ resurgit. Évalué à 3.
En fait ça s'écrit MORPEUG mais ça se prononce MEUPORG. Ou alors c'est l'inverse?
[^] # Re: Bug ferme chez tmux
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 2.
Il faut utiliser mosh!
[^] # Re: Les licenses courtes
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Choisir une licence : facile à comprendre ?. Évalué à 4.
D'ailleurs, il ne faut pas confondre la GPL de GNU avec celle d'Affero (souvent appelée AGPL pour éviter les confusions). Donc, c'est important de protéger le nom, qui peut sinon être repris avec une license complètement différente. Protéger le contenu de la license, par contre, ça n'a d'intérêt que pour limiter la prolifération des licences (du genre "je prend la GPL mais je rajoute une exception qui rend mon truc incompatible avec la GPL d'origine").
[^] # Re: Les licenses courtes
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Choisir une licence : facile à comprendre ?. Évalué à 4.
Après vérification, c'est 3 ans seulement (oups). C'est la section 3b de la licence (pour la GPL2, j'ai pas vérifié la GPL3):
Et il y a deux cas ou ce n'est pas nécessaire:
- Si on distribue directement les sources avec le logiciel,
- Ou, si on redistribue a titre non-commercial, dans ce cas on peut "faire suivre" l'offre de récupération du code que l'on a soi-même reçu.
Ça ne pose pas trop de problèmes quand on met un logiciel en téléchargement sur internet (il suffit dans ce cas de mettre un lien vers les sources juste à côté du lien vers le binaire). C'est plus pénible quand par exemple on veut vendre un CD d'installation d'une distribution Linux contenant du code sous GPL (et pas forcément les sources qui vont avec, faute de place).
[^] # Re: Les licenses courtes
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Choisir une licence : facile à comprendre ?. Évalué à 5.
Tout ça, sans parler du fait que la licence GPL est effectivement compliquée à lire, et surtout, contraignante aussi pour ceux qui décide de diffuser du code sous GPL (essayez un jour, pour voir). Il faut diffuser le code source (bon ok, ça ça va), mais aussi, il faut être prêt à donner le code source de n'importe quelle version précise du logiciel à toute personne qui le demande, et ce, jusqu'à 10 ans après la diffusion de la dite version.
Ce genre de restrictions, ça devient très vite compliqué à gérer, aussi bien quand on est un particulier et qu'on a juste envie de partager un bout de code, que quand on est une entreprise ou une association et qu'on veut se lancer dans le libre. Juste pour savoir ce qu'on a le droit de faire ou pas, il faut embaucher un juriste. Du coup, la solution la moins coûteuse, c'est de prendre une licence plus facile à lire. A moins d'être la FSF et d'avoir une armée de juriste rompus à ce genre d'exercice. Mais dans le monde du libre, c'est rare.
Un autre aspect, c'est que ça me paraît difficile de "vendre" du logiciel comme étant libre, mais d'expliquer qu'il y a des conditions d'utilisations aussi longues que le CLUF de Windows. Même si elles sont peut être moins restrictives, il faut les lire pour le savoir, et je ne pense pas que ça soit quelque chose qu'on peut demander à tous les utilisateurs. Comme le dit le journal: avez-vous lu votre licence?
Finalement, une licence courte et facile à lire, c'est une très bonne arme contre le FUD, non?
# KiCad collaboratif
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le matériel libre où en sommes nous ?. Évalué à 5.
C'est une très bonne nouvelle que quelqu'un se penche enfin sur le travail collaboratif et le suivi de modifications avec KiCad. Même en l'utilisant tout seul pour quelques modestes projets open hardware, c'est quelque chose dont j'aurais bien besoin (mais pas assez pour avoir commencé à développer quelque chose).
Merci!