Propriété des données et format fichiers propriétaires?
9 réponses
Root canal
Bonjour
Sous la douche tout à l'heure, je me posais la question
suivante : la loi en France indique que le client est propriétaire de
ses données telles que générées/manipulées par un logiciel, et que,
donc, tout éditeur de logiciel doit pouvoir fournir à un client ses
données sous forme lisible par d'autres logiciels.
Qu'en est-il de la suite Microsoft Office? Microsoft n'ayant pas
documenté ses formats de fichiers (pas suffisamment en tout cas pour
permettre à ses concurrents de garantir une compatibilité à 100%), que
propose Microsoft à ses clients qui ont pour objectif de les quitter
pour un concurrent, OpenOffice ou autre?
Dans le cas des fichiers Word, j'imagine que la réponse est d'écrire
une moulinette pour convertir tous les .DOC en .RTF, mais on sait
qu'en fonction de la complexité des documents, une partie du formatage
est perdue dans la bataille. Et qui des fichiers Excel ou PowerPoint?
Quelqu'un a des infos sur ce sujet? Est-ce qu'un seul ex-client de
Microsoft est allé en justice pour faire respecter ce droit d'accès à
ses données en cas de migration?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
dwarfpower
Je ne crois pas non. La loi dit que le propriétaire des données à le droit de faire du reverse engeneering pour et uniquement pour rendre ses données accessibles à ses autres solutions logicielles et en assurer l'inter opérabilité
Je ne crois pas non. La loi dit que le propriétaire des données à le
droit de faire du reverse engeneering pour et uniquement pour rendre
ses données accessibles à ses autres solutions logicielles et en
assurer l'inter opérabilité
Je ne crois pas non. La loi dit que le propriétaire des données à le droit de faire du reverse engeneering pour et uniquement pour rendre ses données accessibles à ses autres solutions logicielles et en assurer l'inter opérabilité
dwarfpower
CPI L 122-6-1 IV La reproduction du code du logiciel ou la traduction de la forme de ce code n'est pas soumise à l'autorisation de l'auteur lorsque la reproduction ou la traduction au sens du 1º ou du 2º de l'article L. 122-6 est indispensable pour obtenir les informations nécessaires à l'interopérabilité d'un logiciel créé de façon indépendante avec d'autres logiciels, sous réserve que soient réunies les conditions suivantes : 1º Ces actes sont accomplis par la personne ayant le droit d'utiliser un exemplaire du logiciel ou pour son compte par une personne habilitée à cette fin ; 2º Les informations nécessaires à l'interopérabilité n'ont pas déjà été rendues facilement et rapidement accessibles aux personnes mentionnées au 1º ci-dessus ; 3º Et ces actes sont limités aux parties du logiciel d'origine nécessaires à cette interopérabilité. Les informations ainsi obtenues ne peuvent être : 1º Ni utilisées à des fins autres que la réalisation de l'interopérabilité du logiciel créé de façon indépendante ; 2º Ni communiquées à des tiers sauf si cela est nécessaire à l'interopérabilité du logiciel créé de façon indépendante ; 3º Ni utilisées pour la mise au point, la production ou la commercialisation d'un logiciel dont l'expression est substantiellement similaire ou pour tout autre acte portant atteinte au droit d'auteur.
CPI L 122-6-1 IV
La reproduction du code du logiciel ou la traduction de la forme de ce
code n'est pas soumise à l'autorisation de l'auteur lorsque la
reproduction ou la traduction au sens du 1º ou du 2º de l'article L.
122-6 est indispensable pour obtenir les informations nécessaires à
l'interopérabilité d'un logiciel créé de façon indépendante avec
d'autres logiciels, sous réserve que soient réunies les conditions
suivantes :
1º Ces actes sont accomplis par la personne ayant le droit
d'utiliser un exemplaire du logiciel ou pour son compte par une
personne habilitée à cette fin ;
2º Les informations nécessaires à l'interopérabilité n'ont pas
déjà été rendues facilement et rapidement accessibles aux personnes
mentionnées au 1º ci-dessus ;
3º Et ces actes sont limités aux parties du logiciel d'origine
nécessaires à cette interopérabilité.
Les informations ainsi obtenues ne peuvent être :
1º Ni utilisées à des fins autres que la réalisation de
l'interopérabilité du logiciel créé de façon indépendante ;
2º Ni communiquées à des tiers sauf si cela est nécessaire à
l'interopérabilité du logiciel créé de façon indépendante ;
3º Ni utilisées pour la mise au point, la production ou la
commercialisation d'un logiciel dont l'expression est substantiellement
similaire ou pour tout autre acte portant atteinte au droit d'auteur.
CPI L 122-6-1 IV La reproduction du code du logiciel ou la traduction de la forme de ce code n'est pas soumise à l'autorisation de l'auteur lorsque la reproduction ou la traduction au sens du 1º ou du 2º de l'article L. 122-6 est indispensable pour obtenir les informations nécessaires à l'interopérabilité d'un logiciel créé de façon indépendante avec d'autres logiciels, sous réserve que soient réunies les conditions suivantes : 1º Ces actes sont accomplis par la personne ayant le droit d'utiliser un exemplaire du logiciel ou pour son compte par une personne habilitée à cette fin ; 2º Les informations nécessaires à l'interopérabilité n'ont pas déjà été rendues facilement et rapidement accessibles aux personnes mentionnées au 1º ci-dessus ; 3º Et ces actes sont limités aux parties du logiciel d'origine nécessaires à cette interopérabilité. Les informations ainsi obtenues ne peuvent être : 1º Ni utilisées à des fins autres que la réalisation de l'interopérabilité du logiciel créé de façon indépendante ; 2º Ni communiquées à des tiers sauf si cela est nécessaire à l'interopérabilité du logiciel créé de façon indépendante ; 3º Ni utilisées pour la mise au point, la production ou la commercialisation d'un logiciel dont l'expression est substantiellement similaire ou pour tout autre acte portant atteinte au droit d'auteur.
Root canal
On 9 Dec 2005 05:46:42 -0800, "dwarfpower" wrote:
Je ne crois pas non. La loi dit que le propriétaire des données à le droit de faire du reverse engeneering pour et uniquement pour rendre ses données accessibles à ses autres solutions logicielles et en assurer l'inter opérabilité
Non, une loi en France indique que le client est propriétaire des données, et que le fournisseur se doit de les fournir dans une version standard, non propriétaire, dans le but bien sûr t'empêcher un fournisseur de bloquer ses clients d'aller voir ailleurs.
Donc... sachant qu'on perd en formatage en convertissant du DOC en RTF (et sans doute pareil pour Excel et PowerPoint).. il me semble qu'il y a occasion là d'attaquer MS.
On 9 Dec 2005 05:46:42 -0800, "dwarfpower" <sylvain.souche@gmail.com>
wrote:
Je ne crois pas non. La loi dit que le propriétaire des données à le
droit de faire du reverse engeneering pour et uniquement pour rendre
ses données accessibles à ses autres solutions logicielles et en
assurer l'inter opérabilité
Non, une loi en France indique que le client est propriétaire des
données, et que le fournisseur se doit de les fournir dans une version
standard, non propriétaire, dans le but bien sûr t'empêcher un
fournisseur de bloquer ses clients d'aller voir ailleurs.
Donc... sachant qu'on perd en formatage en convertissant du DOC en RTF
(et sans doute pareil pour Excel et PowerPoint).. il me semble qu'il y
a occasion là d'attaquer MS.
Je ne crois pas non. La loi dit que le propriétaire des données à le droit de faire du reverse engeneering pour et uniquement pour rendre ses données accessibles à ses autres solutions logicielles et en assurer l'inter opérabilité
Non, une loi en France indique que le client est propriétaire des données, et que le fournisseur se doit de les fournir dans une version standard, non propriétaire, dans le but bien sûr t'empêcher un fournisseur de bloquer ses clients d'aller voir ailleurs.
Donc... sachant qu'on perd en formatage en convertissant du DOC en RTF (et sans doute pareil pour Excel et PowerPoint).. il me semble qu'il y a occasion là d'attaquer MS.
Moisse
"Root canal" a écrit dans le message de news:
On 9 Dec 2005 05:46:42 -0800, "dwarfpower" wrote:
Je ne crois pas non. La loi dit que le propriétaire des données à le droit de faire du reverse engeneering pour et uniquement pour rendre ses données accessibles à ses autres solutions logicielles et en assurer l'inter opérabilité
Non, une loi en France indique que le client est propriétaire des données, et que le fournisseur se doit de les fournir dans une version standard, non propriétaire, dans le but bien sûr t'empêcher un fournisseur de bloquer ses clients d'aller voir ailleurs.
Donc... sachant qu'on perd en formatage en convertissant du DOC en RTF (et sans doute pareil pour Excel et PowerPoint).. il me semble qu'il y a occasion là d'attaquer MS.
Il n'existe pas de loi imposant cette obligation comme vous la décrivez, déjà parceque cela pré-suppose l'existence d'un standard. Les "standards" ne tombent pas du ciel. On pourrait même affirmer que si le standard est le format le plus courant, c'est le format MS qui est le standard de fait dans beaucoup de domaines. A+
-- Moisse Nospam : sans doute
"Root canal" <root@cisco.com> a écrit dans le message de news:
l05jp1pn3esq3ie8pec81i6cev4lci9vi3@4ax.com...
On 9 Dec 2005 05:46:42 -0800, "dwarfpower" <sylvain.souche@gmail.com>
wrote:
Je ne crois pas non. La loi dit que le propriétaire des données à le
droit de faire du reverse engeneering pour et uniquement pour rendre
ses données accessibles à ses autres solutions logicielles et en
assurer l'inter opérabilité
Non, une loi en France indique que le client est propriétaire des
données, et que le fournisseur se doit de les fournir dans une version
standard, non propriétaire, dans le but bien sûr t'empêcher un
fournisseur de bloquer ses clients d'aller voir ailleurs.
Donc... sachant qu'on perd en formatage en convertissant du DOC en RTF
(et sans doute pareil pour Excel et PowerPoint).. il me semble qu'il y
a occasion là d'attaquer MS.
Il n'existe pas de loi imposant cette obligation comme vous la décrivez,
déjà parceque cela pré-suppose l'existence d'un standard.
Les "standards" ne tombent pas du ciel.
On pourrait même affirmer que si le standard est le format le plus courant,
c'est le format MS qui est le standard de fait dans beaucoup de domaines.
A+
--
Moisse
Nospam : sans doute
moisse@douteifrance.com
Je ne crois pas non. La loi dit que le propriétaire des données à le droit de faire du reverse engeneering pour et uniquement pour rendre ses données accessibles à ses autres solutions logicielles et en assurer l'inter opérabilité
Non, une loi en France indique que le client est propriétaire des données, et que le fournisseur se doit de les fournir dans une version standard, non propriétaire, dans le but bien sûr t'empêcher un fournisseur de bloquer ses clients d'aller voir ailleurs.
Donc... sachant qu'on perd en formatage en convertissant du DOC en RTF (et sans doute pareil pour Excel et PowerPoint).. il me semble qu'il y a occasion là d'attaquer MS.
Il n'existe pas de loi imposant cette obligation comme vous la décrivez, déjà parceque cela pré-suppose l'existence d'un standard. Les "standards" ne tombent pas du ciel. On pourrait même affirmer que si le standard est le format le plus courant, c'est le format MS qui est le standard de fait dans beaucoup de domaines. A+
-- Moisse Nospam : sans doute
dwarfpower
Dans le cas ou un prestataire de service heberge des données d'un client sur ses systemes, les données appartiennent au client qui peut donc les récupérer. Mais dans le cas ou un éditeur met à disposition d'un client un logiciel, je ne crois pas qu'il y ai la moindre obligation quant au format de stockage, sauf celle que j'ai mentionnée
Dans le cas ou un prestataire de service heberge des données d'un
client sur ses systemes, les données appartiennent au client qui peut
donc les récupérer. Mais dans le cas ou un éditeur met à
disposition d'un client un logiciel, je ne crois pas qu'il y ai la
moindre obligation quant au format de stockage, sauf celle que j'ai
mentionnée
Dans le cas ou un prestataire de service heberge des données d'un client sur ses systemes, les données appartiennent au client qui peut donc les récupérer. Mais dans le cas ou un éditeur met à disposition d'un client un logiciel, je ne crois pas qu'il y ai la moindre obligation quant au format de stockage, sauf celle que j'ai mentionnée
Root canal
On Fri, 9 Dec 2005 15:41:57 +0100, "Moisse" wrote:
Il n'existe pas de loi imposant cette obligation comme vous la décrivez, déjà parceque cela pré-suppose l'existence d'un standard.
Je vais vérifier. Un client nous a déjà fait pression pour qu'on extrait les données et qu'on les donnent au format ASCII en expliquant la structure.
On pourrait même affirmer que si le standard est le format le plus courant, c'est le format MS qui est le standard de fait dans beaucoup de domaines.
Sauf que les formats MS ne sont justement pas documentés, donc impossibles à utiliser par un autre éditeur sans perte de données :-)
On Fri, 9 Dec 2005 15:41:57 +0100, "Moisse" <Moisse@douteifrance.com>
wrote:
Il n'existe pas de loi imposant cette obligation comme vous la décrivez,
déjà parceque cela pré-suppose l'existence d'un standard.
Je vais vérifier. Un client nous a déjà fait pression pour qu'on
extrait les données et qu'on les donnent au format ASCII en expliquant
la structure.
On pourrait même affirmer que si le standard est le format le plus courant,
c'est le format MS qui est le standard de fait dans beaucoup de domaines.
Sauf que les formats MS ne sont justement pas documentés, donc
impossibles à utiliser par un autre éditeur sans perte de données :-)
On Fri, 9 Dec 2005 15:41:57 +0100, "Moisse" wrote:
Il n'existe pas de loi imposant cette obligation comme vous la décrivez, déjà parceque cela pré-suppose l'existence d'un standard.
Je vais vérifier. Un client nous a déjà fait pression pour qu'on extrait les données et qu'on les donnent au format ASCII en expliquant la structure.
On pourrait même affirmer que si le standard est le format le plus courant, c'est le format MS qui est le standard de fait dans beaucoup de domaines.
Sauf que les formats MS ne sont justement pas documentés, donc impossibles à utiliser par un autre éditeur sans perte de données :-)
Xavier
"Root canal" a écrit
Je vais vérifier. Un client nous a déjà fait pression pour qu'on extrait les données et qu'on les donnent au format ASCII en expliquant la structure.
On pourrait même affirmer que si le standard est le format le plus courant, c'est le format MS qui est le standard de fait dans beaucoup de domaines.
Sauf que les formats MS ne sont justement pas documentés, donc impossibles à utiliser par un autre éditeur sans perte de données :-)
La loi indique que ce sont les données qui doivent être récupérables. Il suffit alors d'une moulinette sur l'export des données et sur l'import. Mais, à supposer que l'on connaisse les champs d'importation des données, cela suppose bien, au préalable, de disposer d'un module d'exportation des données (en ASCII ou unicode) ou des caractéristiques du format des champs. Ceci étant dit, en bricolant, on peut parvenir à exporter les données dans un fichier en ascii et reconstituer les bons champs par soi-même...
"Root canal" <root@cisco.com> a écrit
Je vais vérifier. Un client nous a déjà fait pression pour qu'on
extrait les données et qu'on les donnent au format ASCII en expliquant
la structure.
On pourrait même affirmer que si le standard est le format le plus
courant,
c'est le format MS qui est le standard de fait dans beaucoup de domaines.
Sauf que les formats MS ne sont justement pas documentés, donc
impossibles à utiliser par un autre éditeur sans perte de données :-)
La loi indique que ce sont les données qui doivent être récupérables. Il
suffit alors d'une moulinette sur l'export des données et sur l'import.
Mais, à supposer que l'on connaisse les champs d'importation des données,
cela suppose bien, au préalable, de disposer d'un module d'exportation des
données (en ASCII ou unicode) ou des caractéristiques du format des champs.
Ceci étant dit, en bricolant, on peut parvenir à exporter les données dans
un fichier en ascii et reconstituer les bons champs par soi-même...
Je vais vérifier. Un client nous a déjà fait pression pour qu'on extrait les données et qu'on les donnent au format ASCII en expliquant la structure.
On pourrait même affirmer que si le standard est le format le plus courant, c'est le format MS qui est le standard de fait dans beaucoup de domaines.
Sauf que les formats MS ne sont justement pas documentés, donc impossibles à utiliser par un autre éditeur sans perte de données :-)
La loi indique que ce sont les données qui doivent être récupérables. Il suffit alors d'une moulinette sur l'export des données et sur l'import. Mais, à supposer que l'on connaisse les champs d'importation des données, cela suppose bien, au préalable, de disposer d'un module d'exportation des données (en ASCII ou unicode) ou des caractéristiques du format des champs. Ceci étant dit, en bricolant, on peut parvenir à exporter les données dans un fichier en ascii et reconstituer les bons champs par soi-même...
Root canal
On Sat, 17 Dec 2005 15:49:54 -0400, "Xavier" wrote:
La loi indique que ce sont les données qui doivent être récupérables.
Et comment fait-on pour exporter du Word dans un format documenté style RTF, sachant qu'actuellement, l'export d'Office est lossy? :-)
On Sat, 17 Dec 2005 15:49:54 -0400, "Xavier"
<xavieranonyme33@hotmail.com> wrote:
La loi indique que ce sont les données qui doivent être récupérables.
Et comment fait-on pour exporter du Word dans un format documenté
style RTF, sachant qu'actuellement, l'export d'Office est lossy? :-)
On Sat, 17 Dec 2005 15:49:54 -0400, "Xavier" wrote:
La loi indique que ce sont les données qui doivent être récupérables.
Et comment fait-on pour exporter du Word dans un format documenté style RTF, sachant qu'actuellement, l'export d'Office est lossy? :-)
Xavier
"Root canal" a écrit dans le message de news:
On Sat, 17 Dec 2005 15:49:54 -0400, "Xavier" wrote:
La loi indique que ce sont les données qui doivent être récupérables.
Et comment fait-on pour exporter du Word dans un format documenté style RTF, sachant qu'actuellement, l'export d'Office est lossy? :-)
On peut recupérer (à x %) le document Word dans OpenOffice dont le code est documenté, modifier les quelques bavures puis faire sa moulinette d'importation selon l'application réceptive (ouverte..évidemment).
D'une autre manière on peut aussi convertir le fichier Word en PDF puis effectuer une étape d'OCR de reconnaissance de caractères avec Omnipage v.15 qui conserve très bien le format et peut enregister sous une trentaine de formats pour réédition.
"Root canal" <root@cisco.com> a écrit dans le message de news:
53hbq1t8oidsh2smdga63jm7efmctk61to@4ax.com...
On Sat, 17 Dec 2005 15:49:54 -0400, "Xavier"
<xavieranonyme33@hotmail.com> wrote:
La loi indique que ce sont les données qui doivent être récupérables.
Et comment fait-on pour exporter du Word dans un format documenté
style RTF, sachant qu'actuellement, l'export d'Office est lossy? :-)
On peut recupérer (à x %) le document Word dans OpenOffice dont le code est
documenté, modifier les quelques bavures puis faire sa moulinette
d'importation selon l'application réceptive (ouverte..évidemment).
D'une autre manière on peut aussi convertir le fichier Word en PDF puis
effectuer une étape d'OCR de reconnaissance de caractères avec Omnipage v.15
qui conserve très bien le format et peut enregister sous une trentaine de
formats pour réédition.
On Sat, 17 Dec 2005 15:49:54 -0400, "Xavier" wrote:
La loi indique que ce sont les données qui doivent être récupérables.
Et comment fait-on pour exporter du Word dans un format documenté style RTF, sachant qu'actuellement, l'export d'Office est lossy? :-)
On peut recupérer (à x %) le document Word dans OpenOffice dont le code est documenté, modifier les quelques bavures puis faire sa moulinette d'importation selon l'application réceptive (ouverte..évidemment).
D'une autre manière on peut aussi convertir le fichier Word en PDF puis effectuer une étape d'OCR de reconnaissance de caractères avec Omnipage v.15 qui conserve très bien le format et peut enregister sous une trentaine de formats pour réédition.
