Si tu veux continuer le boulot avec les amplis, il y a un truc à faire coté amplification active.
Je ne comprends pas pourquoi les amplis sont lié à la source numérique, qui impose ensuite un filtrage passif complexe, alors qu'un ampli peut être très lié à un haut parleur, ce qui facilite sa conception.
En plus, un ampli ne vieillit pas, alors que les sources numériques sont obsolètes en 5 ans (nouvelle version de HDMI, nouveau codec, Bluetooth, radio internet…)
Je suis sûr que des haut parleurs amplifié avec 2 ou 3 modules amplificateurs (genre classe D ou t), un seul transfo par enceinte, qui récupère la sortie d'un ampli (mis sur 16 ohm ou plus) quelconque pourrait avoir un super son.
Le problème est d'avoir à brancher chaque haut parleur à une prise électrique, et de ne pas utiliser du sans fils (pas pérenne).
On a très rarement à écrire ce genre d'algo dans la vrai vie de programmeur. Il s'agit surtout de coller des morceaux entre eux de façon la moins sale possible.
Peux être que la mise en œuvre des design patterns classiques pourrait être une bonne façon d'apprendre.
Quel encodage ? Parce que si ton programme attend du pure ASCII 7 bits, il va faire des trucs marrants avec de l'utf8. Surtout si il interprète les caractères de contrôle.
Le passage à l'UTF8 sur les consoles Linux ne s'est pas fait de façon très joli.
Je ne parlais pas de transmettre la clé pour chaque échange, j'ai du mal m'exprimer.
C'est moi qui proposait cela, car cela a plein d'avantage dont la simplicité.
Reste la possibilité de vérifier après coup le fingerprint, comme tu le dis, mais qui te dis que ton message ne sera pas modifié en cours (principe du MITM)?
Non pas du tout. C'est ton correspondant qui doit te donner son fingerprint par un autre canaux. De ceux point de vue là, cela ne change rien avec la méthode PGP classique.
(rappel : la seule faute est de ne pas avoir nommé l'auteur).
Vu que c'est une licence NC, il fallait aussi son accord. C'est une contre façon comme une autre. C'est juste beaucoup plus toléré dans le domaine de la photo (mention "Droit Réservé").
C'est nickel chez moi sur un nexus 5 avec écran HD. Tu as quoi comme appareil ?
Samsung S2
On peut mais comme je l'ai dit, c'est inutile. C'est juste les geeks qui râlent. Pour les enfants, il est pas plus mal d'un point de vu pédagogique présenter un clavier dans l'ordre alphabétique pour découvrir les lettres.
C'est pas faux. Mais avoir du mal, c'est frustrant.
Le seul cas intéressant pour les brevets était la protection des emplois en France, dans certain cas.
J'ai eu l'exemple d'une boite française qui faisait des super capacité. Le seul moyen de virer les copies chinoise, était de faire jouer le droit des brevets sur les marchés important (Europe, japon et EU).
Normalement on fait du PreserveAspectCrop sauf cas particulier. C'est sur quelle activité que tu as ce problème ?
Sur "envoie la balle à tux" et penalty, c'est juste flou.
sur "clique et dessine", c'est déformé.
Le fond du menu est moche aussi (flou).
On liste les fontes systèmes plus 2 fontes qu'on embarquent, Andika pour le cursif et Opendyslexic. On laisse la possibilité à l'utilisateur d'installer ses fontes et de les choisir. Dès lors on est bien obligé de les montrer toutes.
Oui, mais le widget de choix ne semble pas aligné. Cela fait bizarre.
De plus, si on prends une taille trop grosse, cela dépasse du cadre, par exemple le nom de la font choisi.
On y a pensé mais c'est trop compliqué de gérer l'implantation 'normale' d'un clavier pour chaque langue. On peut dire que cette activité est plus orienté pour le déchiffrage des lettres et le concept de clavier, pas pour apprendre la frappe.
Vous ne pouvez pas juste prendre les 3 lignes de lettre de chaque clavier ? cela pourrait se faire avec uniquement 3 string par clavier.
J'avais pensé à utiliser un couple de clés PGP échangé lors de la connexion entre les amis celui qui crée le canal de conversation, génère une clé publique/privée qui est envoyé via la clé publique de chaque utilisateur pour chiffré les échanges juste pendant cette conversation (ce qui ne retire pas le fait que si la clé est corrompu, l'envoie de la clé de discussion également) mais on peux penser à un échange de ce couple par un autre canal (mail chiffré ou autre) ce qui permet aussi de convier d'autres personnes à une "conférence" sans échanger avec celles-ci ses propres clés.
C'est différent. La crypto asymétrique est connu pour être moins fiable que la symétrique (genre AES en XTS). Ce que tu proposes est différent, tu propose de refaire un échange de clef asymétrique jetable. Cela doit te donner la propriété de forward secrecy une fois la clef privé jeté. C'est pas mal, je pense.
Fait aussi très attention à tes générateurs aléatoires, toute la sécurité repose dessus. Encore une fois, tu peux faire des couches : 128 bits d'entropie minimum par couche (genre /dev/urandom et une toutouille à toi) et le mélange des couches doit aussi être cryptographique et non un simple XOR (genre sha2). Attention à ne jamais dériver les clefs, tout doit être aléatoire.
de plus ce qui devrait pouvoir être fait, c'est de signer sa clé publique "publique" (qui est stockée dans l'application) avec une clé privée qui n'est JAMAIS publiée (utiliser une fois à chaque renouvellement de clé et stocké dans un coffre derrière un pitbull, ou chez la belle mère).
Du coup lors du changement de clé on peut vérifier celle-ci avec la signature de la clé publique "de référence" dont la clé privée est bien cachée.
Ici, le problème est de faire simple. J'aime bien la propriété qui consiste à dire que l'on peut garantir un réseau si >50% des nœuds du réseau sont fiables. En gros, un noeud compromis ne peut tout compromettre. Dans ton cas, cela reviendrait à partager tes informations.
Regardes les protocoles comme celui proposé dans la dépêche qui utilise git et bittorrent. Celui-ci te garanti contre tout modification (un serveur deviendrait membre d'un réseau et ne serait pas isoler). Tu dois même pouvoir rajouter une couche d'authentification en utilisant le réseau bitcoin.
Si on inclue la clef publique dans tout échange de mail entre 2 personnes, et que si la clef est présente, l'échange continu en crypté ?
Si on veut de la vrai sécurité rien n'empèche de vérifier le finger print après coup. De plus, la NSA devrait modifier à la volé tous les messages qui circulent, cela me parait bien lourd.
Si le fichier est en local, on peut imaginer qu'une faille de sécurité du navigateur serait insuffisant pour attraper le fichier en question à distance. Le principe est toujours d'avoir des couches de sécurité qui sont suffisantes et le plus indépendante possible.
D'ailleurs, vu que le seul moyen d'avoir une discussion en PGP sans man in the middle avec une personne connu, est de vérifier le finger print de la clef depuis un autre canal, tu devrais aussi voir pour utiliser une clef symétrique. Les 2 personnes se débrouillent pour se refiler la clef (un fichier image ?).
* avoir pour chacun la dernière clé publique utilisée.
* la clé publique des amis connus ne devrait changée et n'être acceptée QUE si la nouvelle est chiffrée avec l'ancienne etc…
Attention avec ces gestions de clef complexes, c'est facile que l'utilisateur fasse n'importe quoi. Si la clef est compromise, signer avec l'ancienne clef, ne sert à rien.
J'avais pensé, à utiliser une autre clef privé caché qui signe celle qui est effectivement utilisé. Pour gérer le vol de compte, je pense même crypter cette clef privé avec une clef découpé avec sss ( https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing ) ce morceau de clef étant filé à des amis de confiance. Ceux-ci devraient filer le code si besoin. Je l'avais appelé la fuck-you key :) Car, c'est imparable si tu as des amis prudent. Le but est de gérer une sorte de révocation des clefs publiques proprement. PGP gère des grosses listes de clef révoqué, c'est lourd comme mécanisme.
Tu as regardé cryptocat qui est censé être ce qui se fait de mieux ?
Ton architecture me pose quelques problèmes : la communication de message devrait se faire sans passer par le serveur, c'est maintenant possible sur un navigateur (cf Firefox Hello).
Tu ne semble pas proposer de moyen contre les attaques "man in the middle". Cryptocat utilise le principe de forward secrecy. Cela revient avec PGP à conserver les clef publique de tes correspondants, et comprendre pourquoi une clef change.
La passphrase de protection, en local, c'est un peu "léger". Il faudrait ajouter un secret (128 bits) sauvé dans le navigateur (voir un fichier complet ?). Un mot de passe "d'humain", cela se casse trop facilement.
"L'auteur de GCompris que tu vois sur le Play Store c'est moi ;)"
Le problème est que tu es moins connu que ton logiciel. Si l'auteur était la "fondation GCompris" ou équivalent, cela passerait mieux (cf VLC, firefox,…).
Sinon, une petite remarque, il y a parfois des images qui sont déformés dans l'application. On dirait un "zoom fit", surtout pour les images de fond. C'est vraiment très moche (image étiré et gros pixel carré flou).
Pour une application ludique pour enfant, c'est curieux d'avoir un menu option avec 12 000 fonts disponible. Cela fait un peu, "application pour enfant avec papa geek". Je limiterais le choix, avec peut être une font spécial comme opendyslexic.
Les jeux, avec le clavier en "abcdef", c'est moche de ne pas donner de clavier "azerty", j'ai raté une configuration ? Si c'est pour apprendre un clavier, autant prendre un clavier courant.
les caractéristiques revendiquées sont purement logicielles mais comme le brevet précise que le brevet couvre une machine, il est valable.
Je crois quand même que la seul présence d'un ordinateur pour exécuter le code n'est pas suffisant. Mais il y a d'autres mots magiques pour palier à ça.
Aujourd'hui et compte tenu de ce que j'ai vu dans les négociations auxquelles j'ai participé, je pense que le système des brevets est une fumisterie quel que soit le domaine d'application.
Tu peux développer ?
J'ai vu déjà plusieurs problèmes aux systèmes de brevet :
le brevet sur les découvertes en biologie (gène) qui ne sont pas des inventions,
le système de pool de brevet de constructeur pour mettre une barrière élevée à l'entré d'un marché (dans le prix d'un lecteur de DVD, le gros sont des royalties),
les brevets "champs de mines" : un gros acteur fait ce qu'il veut d'un petit, car le petit viole toujours un brevet du gros et est donc forcé de négocier (sauf patent troll qui ne produit rien).
Le principe d'amélioration du brevet qui permet de contourner un brevet existant, il suffit d'avoir un bon juriste
Le fait de pouvoir breveter n'importe quoi; l'état de l'art n'est pas brevetable, mais 2 choses ensemble de l'état de l'art l'est (ex : pont de résistance en diviseur de tension utilisé comme identifiant de batterie de téléphone portable)
Le fait que les offices n'ont aucun intérêt de refuser un brevet
Les vérifieurs de l'OEB n'ont qu'une demi-journée par brevet
A priori, le système de brevet détourne 15% de la R&D US selon une étude qui doit commencer à dater
Le problème principal concerne les politiques. Pour eux, le nombre de brevet déposé est un indicateur d'innovation ! On peut déposer un brevet, ou des dizaines pour la même chose (il y aurait 150 brevets sur la manière d'attachée le teflon sur un poêle Tefal).
Tant que les politiques seront autant ignare en science, on n'en sortira pas. Je croyais que la France était un pays d'ingénieur, mais c'est faux. La technique, c'est sale pour les élites. Les meilleurs vont dans la finance, ou les postes de direction.
" J'en retiens que le logiciel n'est pas brevetable et que les brevets logiciels demeurent illégaux en Europe."
Tout tient dans le en "tant que tel" ("as such") qui ne veut pas dire grand chose en droit. Ou plus exactement, n'est pas traduit pareil, selon les lois.
L'exemple typique sont les math non brevetables. On ne peut pas mettre de brevet sur une formule de compression. Mais si on lui trouve une application : sauver de la bande passante ou diminuer la taille d'un fichier, paf, brevetable. cf les turbo code.
C'est la théorie des mots magiques. Le droit allemand impose la présence des forces de la nature, au moins c'est clair.
Oui, donc pourquoi dire que c'est différent des US ? Dans les faits, c'est juste que cela ne tiendrait pas en justice. Cela veut dire que si tu as 1 M€ et 3 ans devant toi, tu peux aller contre un brevet. Bon courage.
Tu peux relire les liens que j'ai fournis, cela transparaît… Tu n'étais pas là lors des discussions sur les brevets triviaux (barre de progression et autres genre achat en un clic) ?
Si, j'ai même écrit plusieurs article sur le sujet et j'ai manifesté à Bruxelles.
Si tu es au courant, pourquoi dire qu'il y a une différence entre les US et l'UE sur le sujet ? Les textes sont différents, mais dans les faits, l'OEB s'en fout.
Si on fait une recherche "gcompris" sur la playstore, on tombe sur "Jeu educatif GCompris" avec pour auteur une personne. Difficile de savoir si il s'agit de gcompris, ou d'un clone.
Un bon point pour l'absence de demande d'autorisation, autre que le paiement à l'intérieur de l'application.
[^] # Re: ampli ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal QSpeakers, une pièce manquante pour les DIY sous Linux. Évalué à 2.
C'est un choix de conception.
"La première sécurité est la liberté"
# ampli ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal QSpeakers, une pièce manquante pour les DIY sous Linux. Évalué à 4. Dernière modification le 03 mars 2015 à 15:15.
Si tu veux continuer le boulot avec les amplis, il y a un truc à faire coté amplification active.
Je ne comprends pas pourquoi les amplis sont lié à la source numérique, qui impose ensuite un filtrage passif complexe, alors qu'un ampli peut être très lié à un haut parleur, ce qui facilite sa conception.
En plus, un ampli ne vieillit pas, alors que les sources numériques sont obsolètes en 5 ans (nouvelle version de HDMI, nouveau codec, Bluetooth, radio internet…)
Je suis sûr que des haut parleurs amplifié avec 2 ou 3 modules amplificateurs (genre classe D ou t), un seul transfo par enceinte, qui récupère la sortie d'un ampli (mis sur 16 ohm ou plus) quelconque pourrait avoir un super son.
Le problème est d'avoir à brancher chaque haut parleur à une prise électrique, et de ne pas utiliser du sans fils (pas pérenne).
"La première sécurité est la liberté"
[^] # Re: exemple de la vrai vie
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Apprentissage du code par la pratique. Évalué à 2.
https://fr.wikipedia.org/wiki/Patron_de_conception
Ce bouquin est la référence : https://fr.wikipedia.org/wiki/Design_Patterns Il "suffirait" de faire faire implémenter les algos qui sont dedans.
"La première sécurité est la liberté"
# exemple de la vrai vie
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Apprentissage du code par la pratique. Évalué à 10.
On a très rarement à écrire ce genre d'algo dans la vrai vie de programmeur. Il s'agit surtout de coller des morceaux entre eux de façon la moins sale possible.
Peux être que la mise en œuvre des design patterns classiques pourrait être une bonne façon d'apprendre.
"La première sécurité est la liberté"
[^] # Re: Le bon chasseur et le mauvais chasseur
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 2.
Quel encodage ? Parce que si ton programme attend du pure ASCII 7 bits, il va faire des trucs marrants avec de l'utf8. Surtout si il interprète les caractères de contrôle.
Le passage à l'UTF8 sur les consoles Linux ne s'est pas fait de façon très joli.
"La première sécurité est la liberté"
[^] # Re: Annuaire clés publiques
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Try To Listen Me, nouveau site Open Source de communication chiffrée. Évalué à 2.
C'est moi qui proposait cela, car cela a plein d'avantage dont la simplicité.
Non pas du tout. C'est ton correspondant qui doit te donner son fingerprint par un autre canaux. De ceux point de vue là, cela ne change rien avec la méthode PGP classique.
"La première sécurité est la liberté"
[^] # Re: Sympa
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Utilisation de photo sans autorisation. Évalué à 1.
Vu que c'est une licence NC, il fallait aussi son accord. C'est une contre façon comme une autre. C'est juste beaucoup plus toléré dans le domaine de la photo (mention "Droit Réservé").
"La première sécurité est la liberté"
[^] # Re: android
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Comment faire la promotion d'un logiciel libre ?. Évalué à 2.
Samsung S2
C'est pas faux. Mais avoir du mal, c'est frustrant.
"La première sécurité est la liberté"
[^] # Re: Continuer son combat ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Nouvel exemple de brevets logiciels comme freins à l'innovation et la recherche. Évalué à 2.
Le seul cas intéressant pour les brevets était la protection des emplois en France, dans certain cas.
J'ai eu l'exemple d'une boite française qui faisait des super capacité. Le seul moyen de virer les copies chinoise, était de faire jouer le droit des brevets sur les marchés important (Europe, japon et EU).
"La première sécurité est la liberté"
[^] # Re: android
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Comment faire la promotion d'un logiciel libre ?. Évalué à 2.
Sur "envoie la balle à tux" et penalty, c'est juste flou.
sur "clique et dessine", c'est déformé.
Le fond du menu est moche aussi (flou).
Oui, mais le widget de choix ne semble pas aligné. Cela fait bizarre.
De plus, si on prends une taille trop grosse, cela dépasse du cadre, par exemple le nom de la font choisi.
Vous ne pouvez pas juste prendre les 3 lignes de lettre de chaque clavier ? cela pourrait se faire avec uniquement 3 string par clavier.
"La première sécurité est la liberté"
[^] # Re: cryptocat ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Try To Listen Me, nouveau site Open Source de communication chiffrée. Évalué à 3.
C'est différent. La crypto asymétrique est connu pour être moins fiable que la symétrique (genre AES en XTS). Ce que tu proposes est différent, tu propose de refaire un échange de clef asymétrique jetable. Cela doit te donner la propriété de forward secrecy une fois la clef privé jeté. C'est pas mal, je pense.
Fait aussi très attention à tes générateurs aléatoires, toute la sécurité repose dessus. Encore une fois, tu peux faire des couches : 128 bits d'entropie minimum par couche (genre /dev/urandom et une toutouille à toi) et le mélange des couches doit aussi être cryptographique et non un simple XOR (genre sha2). Attention à ne jamais dériver les clefs, tout doit être aléatoire.
Ici, le problème est de faire simple. J'aime bien la propriété qui consiste à dire que l'on peut garantir un réseau si >50% des nœuds du réseau sont fiables. En gros, un noeud compromis ne peut tout compromettre. Dans ton cas, cela reviendrait à partager tes informations.
Regardes les protocoles comme celui proposé dans la dépêche qui utilise git et bittorrent. Celui-ci te garanti contre tout modification (un serveur deviendrait membre d'un réseau et ne serait pas isoler). Tu dois même pouvoir rajouter une couche d'authentification en utilisant le réseau bitcoin.
"La première sécurité est la liberté"
[^] # Re: Annuaire clés publiques
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Try To Listen Me, nouveau site Open Source de communication chiffrée. Évalué à 2.
Si on inclue la clef publique dans tout échange de mail entre 2 personnes, et que si la clef est présente, l'échange continu en crypté ?
Si on veut de la vrai sécurité rien n'empèche de vérifier le finger print après coup. De plus, la NSA devrait modifier à la volé tous les messages qui circulent, cela me parait bien lourd.
"La première sécurité est la liberté"
[^] # Re: cryptocat ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Try To Listen Me, nouveau site Open Source de communication chiffrée. Évalué à 3.
Si le fichier est en local, on peut imaginer qu'une faille de sécurité du navigateur serait insuffisant pour attraper le fichier en question à distance. Le principe est toujours d'avoir des couches de sécurité qui sont suffisantes et le plus indépendante possible.
D'ailleurs, vu que le seul moyen d'avoir une discussion en PGP sans man in the middle avec une personne connu, est de vérifier le finger print de la clef depuis un autre canal, tu devrais aussi voir pour utiliser une clef symétrique. Les 2 personnes se débrouillent pour se refiler la clef (un fichier image ?).
* avoir pour chacun la dernière clé publique utilisée.
* la clé publique des amis connus ne devrait changée et n'être acceptée QUE si la nouvelle est chiffrée avec l'ancienne etc…
Attention avec ces gestions de clef complexes, c'est facile que l'utilisateur fasse n'importe quoi. Si la clef est compromise, signer avec l'ancienne clef, ne sert à rien.
J'avais pensé, à utiliser une autre clef privé caché qui signe celle qui est effectivement utilisé. Pour gérer le vol de compte, je pense même crypter cette clef privé avec une clef découpé avec sss ( https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing ) ce morceau de clef étant filé à des amis de confiance. Ceux-ci devraient filer le code si besoin. Je l'avais appelé la fuck-you key :) Car, c'est imparable si tu as des amis prudent. Le but est de gérer une sorte de révocation des clefs publiques proprement. PGP gère des grosses listes de clef révoqué, c'est lourd comme mécanisme.
"La première sécurité est la liberté"
# cryptocat ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Try To Listen Me, nouveau site Open Source de communication chiffrée. Évalué à 6.
Tu as regardé cryptocat qui est censé être ce qui se fait de mieux ?
Ton architecture me pose quelques problèmes : la communication de message devrait se faire sans passer par le serveur, c'est maintenant possible sur un navigateur (cf Firefox Hello).
Tu ne semble pas proposer de moyen contre les attaques "man in the middle". Cryptocat utilise le principe de forward secrecy. Cela revient avec PGP à conserver les clef publique de tes correspondants, et comprendre pourquoi une clef change.
La passphrase de protection, en local, c'est un peu "léger". Il faudrait ajouter un secret (128 bits) sauvé dans le navigateur (voir un fichier complet ?). Un mot de passe "d'humain", cela se casse trop facilement.
"La première sécurité est la liberté"
[^] # Re: android
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Comment faire la promotion d'un logiciel libre ?. Évalué à 4.
Le problème est que tu es moins connu que ton logiciel. Si l'auteur était la "fondation GCompris" ou équivalent, cela passerait mieux (cf VLC, firefox,…).
Sinon, une petite remarque, il y a parfois des images qui sont déformés dans l'application. On dirait un "zoom fit", surtout pour les images de fond. C'est vraiment très moche (image étiré et gros pixel carré flou).
Pour une application ludique pour enfant, c'est curieux d'avoir un menu option avec 12 000 fonts disponible. Cela fait un peu, "application pour enfant avec papa geek". Je limiterais le choix, avec peut être une font spécial comme opendyslexic.
Les jeux, avec le clavier en "abcdef", c'est moche de ne pas donner de clavier "azerty", j'ai raté une configuration ? Si c'est pour apprendre un clavier, autant prendre un clavier courant.
"La première sécurité est la liberté"
[^] # Re: Continuer son combat ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Nouvel exemple de brevets logiciels comme freins à l'innovation et la recherche. Évalué à 3. Dernière modification le 27 février 2015 à 09:40.
Je crois quand même que la seul présence d'un ordinateur pour exécuter le code n'est pas suffisant. Mais il y a d'autres mots magiques pour palier à ça.
Tu peux développer ?
J'ai vu déjà plusieurs problèmes aux systèmes de brevet :
Le problème principal concerne les politiques. Pour eux, le nombre de brevet déposé est un indicateur d'innovation ! On peut déposer un brevet, ou des dizaines pour la même chose (il y aurait 150 brevets sur la manière d'attachée le teflon sur un poêle Tefal).
Tant que les politiques seront autant ignare en science, on n'en sortira pas. Je croyais que la France était un pays d'ingénieur, mais c'est faux. La technique, c'est sale pour les élites. Les meilleurs vont dans la finance, ou les postes de direction.
"La première sécurité est la liberté"
[^] # Re: Continuer son combat ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Nouvel exemple de brevets logiciels comme freins à l'innovation et la recherche. Évalué à 3.
Tout tient dans le en "tant que tel" ("as such") qui ne veut pas dire grand chose en droit. Ou plus exactement, n'est pas traduit pareil, selon les lois.
L'exemple typique sont les math non brevetables. On ne peut pas mettre de brevet sur une formule de compression. Mais si on lui trouve une application : sauver de la bande passante ou diminuer la taille d'un fichier, paf, brevetable. cf les turbo code.
C'est la théorie des mots magiques. Le droit allemand impose la présence des forces de la nature, au moins c'est clair.
"La première sécurité est la liberté"
[^] # Re: Continuer son combat ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Nouvel exemple de brevets logiciels comme freins à l'innovation et la recherche. Évalué à 3.
Je parle pas de 1M€ pour aller en justice de ma manière général. Mais du cout d'un procès autour des brevets.
"La première sécurité est la liberté"
[^] # Re: Continuer son combat ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Nouvel exemple de brevets logiciels comme freins à l'innovation et la recherche. Évalué à 2.
Oui, donc pourquoi dire que c'est différent des US ? Dans les faits, c'est juste que cela ne tiendrait pas en justice. Cela veut dire que si tu as 1 M€ et 3 ans devant toi, tu peux aller contre un brevet. Bon courage.
"La première sécurité est la liberté"
[^] # Re: Continuer son combat ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Nouvel exemple de brevets logiciels comme freins à l'innovation et la recherche. Évalué à 3.
Si, j'ai même écrit plusieurs article sur le sujet et j'ai manifesté à Bruxelles.
Si tu es au courant, pourquoi dire qu'il y a une différence entre les US et l'UE sur le sujet ? Les textes sont différents, mais dans les faits, l'OEB s'en fout.
"La première sécurité est la liberté"
[^] # Re: Continuer son combat ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Nouvel exemple de brevets logiciels comme freins à l'innovation et la recherche. Évalué à 4.
Tu m'expliques dans ce cas comment il peux exister un porte-feuille de brevets sur le mp3 déposés à l'OEB ?
Le mp3 c'est un algorithme mathématique et un format de fichier. Et pourtant, il y a des dizaines de brevet européenne dessus.
"La première sécurité est la liberté"
[^] # Re: Le bon chasseur et le mauvais chasseur
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 3.
C'est "raw-Text-based protocol" qui n'existe pas.
"La première sécurité est la liberté"
# android
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Comment faire la promotion d'un logiciel libre ?. Évalué à 2.
Si on fait une recherche "gcompris" sur la playstore, on tombe sur "Jeu educatif GCompris" avec pour auteur une personne. Difficile de savoir si il s'agit de gcompris, ou d'un clone.
Un bon point pour l'absence de demande d'autorisation, autre que le paiement à l'intérieur de l'application.
"La première sécurité est la liberté"
[^] # Re: Assis / debout
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Retour d'expérience : bureau assis/debout. Évalué à 2.
Tient, c'est des personnes de Withings, ceux qui font une balance qui marche mal à 150€ (oui,je suis un peu aigri).
"La première sécurité est la liberté"
[^] # Re: Pourquoi s'embêtent-ils ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Effacer le téléchargement d'Internet, Total Wipes a essayé. Évalué à 4.
Ils ne peuvent que contre attaqué en justice pour demande abusive ?
"La première sécurité est la liberté"