Un service ce n'est ni propriétaire ni libre, c'est un service.
Je ne suis pas d'accord. Un service c'est du logiciel qui tourne, et ce logiciel peut être libre ou propriétaire. Quel est le différence aujourd'hui entre faire tourner du logiciel dans une page web (que l'exécution se fasse chez le client ou le serveur) et dans un "logiciel lourd" ? Quand j'utilise un logiciel je veux pouvoir l'utiliser librement, étudier son fonctionnement et tester des versions modifiées. Quand j'utilise un service je veux pouvoir l'utiliser librement, étudier son fonctionnement et tester des versions modifiées.
T'es juste en train de dire "oui mais c'est pas grave si je pousse les gens à répondre à leur besoin en utilisant du code qu'on n'a pas le droit de voir, ça se passe à travers un navigateur donc ça va". Ce qui nous fera une belle jambe quand tout se fera à travers un navigateur.
Le passage aux logiciels distribués ajoute une nouvelle problématique d'accès aux données qui était moins forte dans le logiciel tout-client. Et encore, les formats fermés posaient déjà ce problème; selon ton principe de "données mieux que code" il vaut mieux utiliser un logiciel propriétaire qui comprend un format standard qu'un logiciel libre qui utilise son propre format maison (au hasard LaTeX). Je ne dis pas que c'est tout le temps faux, au contraire je pense que dans certaines situations tu as raison, mais il n'empêche que le code reste un point important et que dire "c'est un service donc on s'en fout" est un sacré aveuglement.
Donc avec le logiciel distribué il faut donc demander :
(comme avant) du logiciel libre
(comme avant) des données dans un format ouvert
(nouveau) l'accès facile à ses données pour (comme avant) éviter le verrouillage technologique
(nouveau) le fait que les vilains n'aient pas accès à nos données privées (soit on choisit où les stocker, soit elles sont chiffrées en local)
Le choix de la décentralisation me paraît plutôt être un choix technique indépendant, mais ça reste intéressant (du point de vue de la robustesse et pour faciliter l'ouverture), et qui est au passage une bonne façon de garantir un certain respect des points (2), (3) et (4).
[^] # Re: Bonjour l'infobésiteTM
Posté par gasche . En réponse à la dépêche De tout, de rien, des bookmarks, du bla‐bla #45. Évalué à 3.
Je ne suis pas d'accord. Un service c'est du logiciel qui tourne, et ce logiciel peut être libre ou propriétaire. Quel est le différence aujourd'hui entre faire tourner du logiciel dans une page web (que l'exécution se fasse chez le client ou le serveur) et dans un "logiciel lourd" ? Quand j'utilise un logiciel je veux pouvoir l'utiliser librement, étudier son fonctionnement et tester des versions modifiées. Quand j'utilise un service je veux pouvoir l'utiliser librement, étudier son fonctionnement et tester des versions modifiées.
T'es juste en train de dire "oui mais c'est pas grave si je pousse les gens à répondre à leur besoin en utilisant du code qu'on n'a pas le droit de voir, ça se passe à travers un navigateur donc ça va". Ce qui nous fera une belle jambe quand tout se fera à travers un navigateur.
Le passage aux logiciels distribués ajoute une nouvelle problématique d'accès aux données qui était moins forte dans le logiciel tout-client. Et encore, les formats fermés posaient déjà ce problème; selon ton principe de "données mieux que code" il vaut mieux utiliser un logiciel propriétaire qui comprend un format standard qu'un logiciel libre qui utilise son propre format maison (au hasard LaTeX). Je ne dis pas que c'est tout le temps faux, au contraire je pense que dans certaines situations tu as raison, mais il n'empêche que le code reste un point important et que dire "c'est un service donc on s'en fout" est un sacré aveuglement.
Donc avec le logiciel distribué il faut donc demander :
Le choix de la décentralisation me paraît plutôt être un choix technique indépendant, mais ça reste intéressant (du point de vue de la robustesse et pour faciliter l'ouverture), et qui est au passage une bonne façon de garantir un certain respect des points (2), (3) et (4).