J'ai envoye ca (ca doit etre bourre de fautes, et pourtant j'ai relu)
Bonjour,
Suite a un passage sur votre site je me permet de vous faire part de mon point de vue personel sur les brevets logiciel et le logiciel libre.
Outre les erreurs PHP, un certains nombre d'autres choses m'ont choquees sur votre site :
A) les brevets
I-Critere de brevetabilité :
L'ensemble des criteres de brevetabilite est tres difficilement verifiable dans le cadre particulier des logiciels.
- Nouveaute : La nouveaute pure en informatique est tres rare, l'informatique est un moyen et non un but, de fait l'immense majorite des "nouveautes" de ce domaine ne sont en fait que des transposition vers l'informatique de solutions preexistantes. L'implementation au sein d'un logiciel d'une decouverte mathematique, physique ou statistique est elle une nouveaute ? Le fait de reussir a produire un programme capable de realiser une solution deja connue merite-t-il se label ? De meme dans un systeme extremement dependant des contraintes physique (en l'occurence la puissance des machines cibles), peut on considere comme nouveau l'implementation par une personne (morale ou physique) d'un systeme que tout le monde cherche a developper depuis des annees ? Le jour ou la technologie permettra de faire une "immersion totale" dans un reseau est ce que le premier implementeur aura produit quelquechose de nouveau ? Est-ce que le premier compilateur a avoir utilise un systeme pour optimiser la vitesse d'execution des programmes etait "nouveau", son inventeur aurait-il pu deposer un brevet sur l'optimisation a la compilation ?
- Inventive : Cette definition fait appel a "l'homme du metier", oui mais lequel ? Si j'ecris un programe pour de la creation de modeles graphiques pour architectes qui est l'homme du metier ? Le concepteur du modele dont je me sert pour ecrire le programe, le programeur que je suis, le graphiste qui utilise le produit ou l'architecte qui utilise le resultat ? Il y a fort a parier qu'en matiere d'evidence il y est de tres grosse differences de l'un a l'autre.
Comment evaluer cette notion d'evidence avant de breveter ? Normalement il y a un trio dans la notion d'invention : il y a l'inveteur, l'utilisateur et le beneficiaire. La notion "d'homme du metier" refere le plus souvent a l'utilisateur, en l'occurence : le graphiste. Je peux vous garantir que pour un graphiste lambda rien n'est evident dans un programe, mais la plupart seront, je l'espere, assez honnetes pour admettre qu'ils ne peuvent pas repondre. Reste l'inventeur (qui a tout interet a dire que son invention est inventive) et le beneficiaire (qui a tout interet a dire le contraire pour des raisons financieres) .
- suffisance de description : Une fois de plus le probleme de "l'homme du metier" se pose. De plus quelles sont les conditions necessaires a cette suffisance. Est-ce qu'un brevet de l'entreprise X disant qu'en utilisant une serie de logiciels de l'entreprise X on peut produire l'invention est valable. De plus un certain nombre de langages sont consideres comme des machines de Turing completes (capable de resoudre l'immense majorite des problemes). Suffit-il de dire "mon invention tourne sur une machine de Turing complete" pour que l'on puisse considerer qu'il y ait suffisance de description ? Dans le cas contraire il faut descndre d'un niveau dans la description et la on arrive sur ... le code source!
II-Portée de la protection
Certes tous les brevets sont publies, mais qui a les moyens financiers de faire une recherche d'antecedent sur l'ensemble des modules un peu innovant de son application pour verifier si il peut les utiliser librement. La publication des brevets ne rend pas beaucoup plus facile l'acces aux informations d'antecedence.
A part un nombre tres reduit de "tetes" meme un excellent programeur sera incapable de dire si son code est un cas particulier couvert par un brevet portant sur un sujet beaucoup plus general.J'ai appris tres recemment qu'il existait des liens tres etroits entre la theorie des noeuds et les algorithmes de compression sans perte. Ayant ecris plusieurs systemes de compression je me suis penche sur cette theorie pour voir si il y avait quelque chose a en retirer et je n'ai strictement rien compris. Peut on attendre de l'OEB qu'il soit capable de me dire que mon programme de compression de donnee est en fait un cas particulier d'un programme de recoupement de flux base sur la theorie des noeuds ?
III-Les procedures d'examen
Tout organisme est faillible, d'ailleurs l'OEB a tout mon respect pour avoir su se remettre en cause a un moment crucial, mais au vu des differentes que j'ai fait plus haut est-il seulement possible de mettre en place des procedures "justes".
IV-Europe vs USA
Me semblait-il que l'on pouvait aux USA deposer un concept meme si son implementation n'etait pas realisable de facon evidente , ce qui n'est pas le cas en Europe. S'agit-il d'une legende ?
B)Brevets et logiciels
Les logiciels ne sont pas brevetables en tant que tel, c'est la partie "si sa mise en oeuvre sur un ordinateur produit un effet technique supplémentaire, allant au delà des interactions physiques normales entre programme (logiciel) et ordinateur" de la phrase. Un logiciel ne peut etre brevete que si il participe en tant que module d'une realisation plus importante. En d'autres termes un logiciel dit "grand public" destine a s'installer sur une machine standard est tres difficilement brevetable. Un exemple serait un logiciel de domotique. Ce logiciel produirait "un effet technique supplémentaire" et serait donc brevetable. Mais un traitement de texte ou un lecteur video quel que soit leur complexite ne sont pas brevetable en l'etat. Par contre un traitement de texte capable de reconnaitre la qualite de papier utilise avant l'impression, ou un lecteur video capable d'adapter son rendu a la lumiere ambiente le serait. Ce type de brevet est par ailleurs totalement innofensif aux yeux du libre vu qu'il est quasiment impossible de les enfreindre sans le faire expres. De plus il faut savoir rester beau joueur : si une personne a eu l'idee en premier, c'est a elle que revient le merite.
C)Brevet et concurrence
Si il est vrai qu'un brevet peut servir de tremplin a une PME, le contraire est tout aussi vrai si ce n'est plus, tout du moins aux Etats-Unis. Lorqu'une PME se retrouve dans la ligne de mire d'une grande entreprise, les consequences sont souvent desastreuses. L'example qui me vient en tete est celui de Bleem. Bleem etait un emulateur de PlayStation, la console de jeux troisieme generation de Sony. C'etait ce qu'on apelle un emulateur haut niveau. Sony a assome l'auteur de ce logiciel de proces, perdant a chaque fois mais bloquant a la fois le temps et l'argent de la societe. En Europe cette demarche aurait ete impossible, le logiciel ne produisant pas d'effet technique il aurait ete "de facto" incapable d'enfreindre un brevet (comme quoi il y a des differences).
Il est vrai qu'un brevet peut servir de garantie aux yeux des investisseurs, mais est-ce que le prix a payer n'est pas trop fort ?
La lutte contre Microsoft n'a aucun rapport avec la lutte contre les brevets. Microsoft n'a jamais ou presque fait valoir ces brevets, ils ont par contre assez souvent enfreint les brevets, fait trainer le proces le plus possible avant de racheter la societe qui avait intente le proces(ce qui d'ailleurs remet un peu en question l'affirmation comme quoi le brevet permet aux PME de se defendre contre les entreprises plus grosse).
La lutte contre le brevet logiciel est une lutte qui vise simplement a s'assurer qu'une alternative est toujours possible. Qu'une personne ou une entreprise puisse produire une application sans debourser a l'avance une fortune ne frais de recherche d'antecedent (une autre entaille dans la certitude que les brevets favorisent les PME).
D) Cout de la protection
Les couts que vous evoquez (et dont sont d'ailleurs absents les couts de recherche d'antecedent lesquels sont presque aussi eleves que ceux de depot de brevet a l'heure actuelle) sont effectivement minimes pour une grosse entreprise. Pour une PME ils sont deja plus important, et pour un groupe d'ami qui a eu une idee geniale et qui veulent monter leur structure ils sont tout simplement prohibitifs. Quoi de plus naturel alors que de rendre les specifications du produit publiques et de se focaliser sur un marche de service pur. C'est une des idee forte derriere la philosophie du libre. Si on veut exploiter une idee sans se vendre a une grosse entreprise, le libre est une solution tout a fait raisonnable. Mais pour pouvoir faire cela, il faut que la recherche d'antecedent soit iniutile.
E)Section logiciel libre/Analyse ecconomique
- La logique du modele libre
Le logiciel libre propose d'offrir des logiciels de qualite (le prix n'ayant aucune importance) sur lequel le client a un controle total. On peut parfaitement vendre un logiciel libre, on peut meme le vendre cher et ce sans y associer aucun service. On est juste tenu de fournir le code source et d'authoriser sa distribution. Le libre assure que la personne qui l'utilise ne sera jamais coincee. Elle pourra toujours faire apple a des developpeurs pour faire les modification dont elle a besoin sur son produit, elle pourra toujours exporter ses donnees vers une autre plateforme (la aussi si besoin est en faisant appel a des devoleppeurs), elle pourra a son tour deployer ses applications chez ses clients pour harmoniser leurs echanges et ce sans surcout.
-Une ecconomie negligeant la valeur de la production de l'immatériel
Je passe rapidement sur une comparaison stupide entre la gratuite de l'immateriel et la gratuite du materiel : a la difference des oranges si je donne mon programme, je le possede encore.
L'ecconomie du libre ne neglige en aucun cas la valeur de l'immateriel, c'est meme au contraire une farouche partisanne de cette valeur. Les acteurs du libre esperent bien, pour la plupart, etre payes en amelioration. Une entreprise qui se tourne vers le libre en mettant une application maison sous license libre espere plus que tout que son programme va avoir du succes et qu'elle va pouvoir obtenir (en un temps infiniment plus court que celui auquel elle aurait pu pretendre seule) des corrections de bugs, des ameliorations ergonomiques, de nouvelles fonctionalites et des optimisations. Le fait que les echanges de valeurs ne sont font pas par cheques interposes ne veut absolument pas dire qu'ils sont absent.
(je suis ici oblige ,pour des raisons de logique, a passer directement au point Analyse juridique, je reviendrais sur la partie "les erreurs de ce modele" plus tard)
F)Analyse juridique
-Les contributeurs ne sont pas toujours titulaires des droits qu'ils abandonnent.
Outre le fait que les contributeurs n'abandonnent en rien leur droits(ils ne font que les partager, mais rien ne les empeches de produire leur application sous license fermee a cote), il faut bien faire la difference entre plusieurs choses: un employe qui utilise son temps de travail pour ecrire ou contribuer au logiciel libre sans l'accord de son patron vole celui-ci. Mais cela n'est ni plus ni moins condamnable qu'un employe qui joue au solitaire toute la journee. Cela existe je n'en doute pas mais de la a dire que c'est de la faute du libre il y a un gouffre. Il est par contre tres rare qu'un chercheur puisse ecrire du libre sans l'aval de sa hierarchie. Les projets de recherche sont souvent tres surveilles, proposee par des commites institutionels ou plus rarement par des entreprises, et couvrent plus souvent des preuves de faisabilite que des implementations adaptes. En d'autres termes la plupart des applications issues de la recherche sont a peu pres inutilisables en production. Les autres application sont souvent des commandes d'un client et sont bein entendu devellopees et licensiees suivant les desideratas de ce client.
Pas de reelle inquietude que la decouverte du siecle passe dans le monde du libre au nez a a la barbe de l'etat francais.
-Les licences de type GNU ne respectent pas le formalisme du droit français
Ce serait vrai si il y avait renonciation des droits, ce n'est pas le cas. Rien ne m'empeche si j'ecris un programme de le relacher a la fois sous license GNU et sous license proprietaire. De meme le code que j'apporte a un projet GNU preexistant peut tres bien etre utilise par moi dans un autre projet. La license GPL m'assurre juste que le code que je donne ne peut pas etre reutilise par un tiers dans une application non GNU.
-Les logiciels libres ne respectent pas le droit fiscal
J'imagine que vous limitez une fois d eplus la notion de prix a des especes sonnantes et trebuchantes, et que la valeur qu'une entreprise peut retirer d'un passage au libre (cf plus haut) ne compte pas.Deja cela revient a dire que le fait de ne pas vendre ses logiciels est anormal, en d'autres termes votre raisonement se mord un peu la queue : il faut vendre les logiciels parcequ'il ne faut pas ne pas les vendre.Pas tres godelien tout ca. De plus j'ignore completement quelle est le prix "normal" d'un logiciel. Quand est-il des freewares, des sharewares, des logiciels qui se financent par la publicite, des logiciels a but publicitaire, des produits fournit gratuitement avec l'achat d'un ensemble de logiciels, du code present dans les lessons d'initiations a des langages sur certains sites webs, des exemples etudies en cours par les eleves ? En d'autres termes tous ces produits que l'on peut obtenir sans debourser (et c'est volontaire si je ne dis pas gratuitement) sont-ils aussi illegaux ? De plus ou est le rapport avec la brevetabilite ? Le monde n'est pas en noir et blanc, meme si le libre est dans l'erreur sur certains points cela ne prouve en rien qu'il faille autoriser les brevets.
(je peux maintenant revenir sur ce que je considere comme une conclusion)
-Les erreurs de ce modele
*il s'agit d'un modèle anticoncurrentiel
Aux Etats Unis Sony a fait deposer un brevet sur la partie logicielle qui permet a ses consoles (Playstation 1 et 2) de s'initialiser et de lancer un programe. Le brevet est tourne de telle facon que toute tentative visant a essayer de produire un equivalent est immediatement illegale. On peut donc sous couvert de la loi ameriquaine interdire toute forme de concurrence logicielle(Amusant non? Encore une chose que notre legislation sur les brevets pourtant en tout point similaire ne permet pas). Je ne sais pas si le libre est anticoncurrentiel, j'aurais plutot eu tendance a trouver qu'il mettait tout le monde sur un pied d'egalite, et etait le seul cas possible de l'avenement de la concurrence pure et parfaite. Par contre en ce qui concerne les brevets je sais que ca va contre la concurrence, j'ai des exemples.
*il est contraire à l'esprit d'entreprise
J'aimerais bien connaitre le raisonnement qui vous permet d'affirmer cela. Le nombre d'entreprises qui produisent, utilisent, vendent, exploitent du libre est largement assez grand pour prouver le contraire. Si vous pensez que le libre s'impose par sa gratuite, vous avez tort. Le libre a pris son essor pendant une periode ou les prix des applications etaient deja en chute libre. Si il gagne des part de marches c'est exclusivement grace a sa qualite. Il stimule le marche en offrant une alternative qui evolue.De plus il serait stupide de dire qu'une PME qui est prete a payer quelques 30 000 francs+10 000francs/an pour proteger ses droits reculerait devant l'achat d'une serveur a 6 000 francs. Si vous pensez que le libre aneanti les volontes de creation d'entreprise logicielle, les createurs ayant trop peur de concurrencer un produit "gratuit" (sic), detrompez vous. Premierement la plupart des produits libre ont deja une contrepartie proprietaire (qui souvent se porte bien), deuxiemement c'est la qualite d'un produit qui permet de le vendre, non pas son prix. Un produit "bien fini" et stable rassurera certains responsables des achats et se vendra sans probleme.
*il privilégie les activités de distribution et de prestations annexes, au détriment de la création
Ben voyons, juste parce que le libre estime qu'il ne faut pas vendre la creation, ne veut pas dire que le libre la defavorise. Au contraire c'est un veritable bouillon de culture la dedans. On voit plus souvent les personalites du libre appeler a l'union et a la focalisation que demander la creation de nouveaux projets.
*il entraîne une déresponsabilisation des acteurs
Bon on passe rapidement sur le haut sens des responsabilites qu'ont certains acteurs du monde non libre, pour poser une question : l'ensemble du code etant visible, teste, souvent approuve par un comite, soumis en tests aux utilisateurs, valide, parfois audite intensivement ou est la deresponsabilisation ?
*il va à l'encontre d'une industrie dynamique de conception de logiciels en Europe
J'aime quand l'argumentation affirme de but en blanc la conclusion, comme ca discretement.
*il brade les résultats de la recherche financée par le contribuable
Cf plus haut, c'est hautement improbable. A part dans le cas de professeurs(qui ont devoir de retransmettre leur connaissances) c'est meme pratiquement impossible.
*il est contraire aux principes fiscaux.
Cf plus haut, si c'est le cas il est tres loin d'etre le seul.
Le libre ne conteste pas la propriete, il conteste l'exclusivite, il conteste le verouillage des techniques, il conteste la prise en otage de l'utilisateur par une societe editrice de logiciel, il conteste la brume qui etoure certaines applications etc. Mais pas la propriete. Pas du tout. Comme dit plus haut si j'ai envie de reutiliser le code que j'ai donne au libre dans des applications proprietaires ca ne pose aucun probleme, c'est le reste du monde qui ne peut pas. Preuve s'il en est que la notion de propriete n'a pas disparue.
Voila, tout ca pour mettre au clair un certain nombre de choses.
Oui c'est ca, j'ai pas voulu faire trop long mais comme je ne connaissais pas le titre de la BD francaise j'ai prefere en rester a la citation. Admettons le si votre fournisseur de BD ne comprend pas quand vous lui demandez "who watches the watchemen" une remise en question de vos lieux d'approvisionement est de rigueur.
Tu n'as pas compris ce que je voulais dire
Effectivement j'etais a cote de la plaque, mais il faut reconnaitre que la structure de tes phrases me laisse perplexe par exemple :
On a simplement pu démontrer son existence par des moyens détournés, sans exhiber une solution précise au problème.
Cette phrase sous entend que l'on sait qu'il y a une solution au probleme mais que l'on ne la connait pas. Alors qu'en fait on est absolument pas sur que cette solution existe, voir meme franchement sceptique ce que tu resumes tres bien dans ta phrase de conclusion.
Comme Boubou, tu confonds la prouvabilité d'une propriété (il existe une méthode en temps polynomial) avec l'exhibition d'une solution intéressante en pratique
Non du tout, j'ai suffisament de bouteille pour me mefier comme de la peste des trucs qui marchent vachement bien "sur le papier" cf mes autres postes plus haut. Je ne suis pas sur non plus que Boubou confonde. La discussion portait plus sur la necessite de faire des tests vis a vis d'un modele optimise.
les mathématiques appliquées et l'informatique sont deux disciplines séparées
Tres discutable, si on prend un domaine comme les reseaux de Petri colore ou l'implementation informatique decoule quasi directement du modele mathematique on se rend compte que bien que distinctes ces deux disciplines ne sont pas tres loin l'une de l'autre.
Ok..... mais bon, la on parlait de "trucs qui peuvent contenir des failles de sécurité pour prendre la main sur la machine"
La pile TCP/IP, les systemes de routages et les tunnels sont d'excellents points d'attaques pour prendre le controle des machines ou tout du moins utiliser des fonctionalites d'un reseau a l'insu des admins, donc je ne suis pas vraiment d'accord avec toi quand tu dis que cela ne devrait pas etre pris en compte. C'est l'eternelle question "who watches the watchmen ?" (qui surveille les gardiens, Alan Moore a lire absolument) .
C'est le "pratiquement" qui me gene....
Par pratiquement j'etend que la plupart des failles connues d'OpenBSD necessitent non seulement de la technique mais aussi un peu de chance pour pouvoir etre exploitee. La majorite des failles OpenBSD ne font que retransmettre les droits de l'executeur du demon, donc si on a bien verrouille ces droits on se retrouve avec un service en rideau point barre. Un utilsateur qui n'a pas de login (schell=/dev/null) qui est forcement chroote dans son coin (aucun prog "nuisible" a disposition) a du mal a faire des degats. Comme c'est souvent le cas par defaut a l'install ca limite en plus les erreurs des admins un peu brouillon.
Pour prendre un autre exemple, je vais parler de la Trusted Debian.
Trusted Debian a une voccation de serveur a part entiere, que n'a pas (a mon sens) OpenBSD. De fait TD est beaucoup plus versatile qu'OpenBSD donc beaucoup plus dure a securiser, ce qui augmente son merite. Neamoins personellement meme une TD je la mettrais derriere un OpenBSD (paranoia quand tu nous tient)
Tout ca pour dire que les chroot et autres "trucs pour proteger des programmes mal concus", bah on est jamais sur a 100% que c'est completement incontournable
C'est sur que l'on peut toujours tomber sur une personne plus maline que les autres qui va tomber sur une faille que personne n'avait vu jusque la. C'est d'ailleurs un des enormes avantages du libre (given enough eyeballs, all bugs are shallow , avec assez d'yeux tous les bugs sont evidents), mais malgre tout c'est clair qu'il ne faut pas en profiter pour bacler son propre travail. Cependant il est rassurant de savoir que la plateforme sur laquelle on bosse est solide et que les seuls bugs dont on a a se preocuper sont ceux que l'on pourrait ecrire ou creer par des erreurs de configuration. En d'autres termes je n'arrete pas de faire tres attention a ce que je fais, par contre je ne passe que tres peu de mon temps a controller ce que l'OS fait. Et ca c'est vraiment appreciable.
Or, dans l'install par défaut, de mémoire, tu dois juste avoir un mini-smtpd et un ssh (la faille en question), ce qui limite quand meme beaucoup les risques (et ce qui leur permet d'avoir moins de choses a auditer).
Pas vraiment non, Dans OpemBSD dans l'install par defaut il y a tot ce qu'il faut pour faire un routeur/firewall/proxy NAT/tunnel. C'est le genre d'outils ideal a mettre aux bouts des DMZ quand on trouve que Cisco est trop cher.
De plus tous les demons OpenBSD sont chrootes par defaut. Donc ca limite vachement les problemes. Maintenant c'est clair que sur Apache, Samba ou DNS, ils se prennent les memes failles que les autres, mais vu que la base est quasi indestructible ces failles sont pratiquement inexploitables.
Il faut bien reconnaitre de plus qu'OpenBSD n'a pas vocation a etre installe en workstation ou meme en serveur complet. Linux et FreeBSD font beaucoup mieux le boulot a ce niveau la. Par contre en tandem c'est de la folie, un serveur Apache sur FreeBSD derriere un proxy OpenBSD c'est assez terrible.
Ca dépend. Pour moi, si quelqu'un prouve que P=NP, il y a de fortes chances que la démonstration se fasse autrement qu'en trouvant un moyen "magique" de réduire tous les problèmes... ;)
Ca ne depend pas, il est prouve (mathematiquement) que si un probleme NP complet a une solution polynomiale, alors tous les problemes NP complet ont une solution polynomiale (pour rappel NP ne veu pas dire non polynomial, mais non solvable polynomialement, ie on enpeut pas trouver de solutions par une approche polynomiale, mais la solution peut elle etre polynomiale).
De plus en passant par les algo de reduction dont parle Boubou on peut "extraire" une solution polynomiale a n'importe quel probleme NP complet a partir d'une solution d'un probleme NP complet donne.
En d'autres termes si on trouve un jour une solution polynomiale a un probleme NP complet, tous les problemes NP complet seront resolu dans la foulee avec une solution polynomiale pour chacun.
Demontre moi avec des arguments crédible que l'écriture d'un programme informatique n'est pas un probléme mathématique (OK, c'est aussi un pbs de frics).
Tres simplement : traitement d'un flux de donnees, ou de facon generale tout domaine ou on a pas la maitrise des flux entrants. On peut demontrer que le traitement d'un jeu de donnees prendra un certain temps machine a condition de connaitre suffisament bien le contenu de ce jeu.
Ce qui est beaucoup plus dur c'est d'etre capable de traiter des donnees exterieures dont on se doute qu'elle risquent d'etre incompletes a un moment ou a un autre tout en gardant une coherence de la base interne. La les maths ne peuvent pas vraiment assurer un resultat (meme si l'utilisation d'outils stochastiques permet de debrouisailler pas mal).
Trois examples pour se faire une idee :
1)Traitement de flux boursiers : On recoit des quotes boursieres par satellite en temps reel. Il faut ecrire un programme capable de transformer ces informations ephemeres en un historique complet. En cas de "flambee" boursiere les informations que l'on recoit passent en mode "burst" a savoir une quote qui remonte a jusqu'a il y a 10 minutes puis la liste des variations au coup par coup jusqu'a maintenant. Bien sur si il y a perte d'une information sur les variations d'une action, les variations suivantes sont perdues aussi. Question : Est ce que je peux etre sur que ma base sera "propre" demain en sachant que je peux m'aider d'un fournisseur d'historique externe pour verifier le contenu de ma base ?
Reponse : non, rien ne dit que j'aurais fini le boulot a temps. En utilisant les stochastiques je peux etre raisonablement sur. La seule "bonne" facon de verifier c'est de tester en rejouant par exemple une des journees boursiere les plus chargees.
2)Maintenance serveur : On a un serveur qui doit effectuer un certains nombre de tache la nuit. Ces taches sont pour certainnes paralelisables pour d'autres mutuellement exclusives. Ce sont les taches suivantes
a) - Consolidation base de donnees
b) - Verification et eventuellement recreation des index base
c) - Backup des disques
d) - Mise a jour automatique des versions des applis si besoin
e) - Update des scripts de traitement si besoin
f) - mise a jour des droits utilsateurs si besoin
g) - verification de la synchro applis avec un autre serveur en load balancing, et mise a jour si besoin.
Je sais (parceque j'ai une enorme base et de vieux serveurs) que je ne pourrais pas faire toutes les operations dans la nuit. Il faut pourtant que les serveurs soient "libres" le lendemain.
De plus avant de consolider la base de donnees(a) il faut faire un backup (c)
De meme (b) necessite (a)
(c) n'a pas de prerequis mais prend du temps
(d) necessite (c) et implique (g) et enventuellement (e)
(e) peut necessiter (f) et/ou (d)
(f) implique (a) (ne pas garder en base des utilisateurs qui n'existent plus)
(g) peut necessiter (f)
En sachant que je n'ai pas le droit de faire deux backups du serveur le meme soir (ou alors exceptionellement avec une personne sur site pour changer les bandes) est ce que je peux etre sur que chacune des operations sera effectuee au moins deux fois par semaine ?
Pour les memes raisons que plus haut : non. Une fois de plus le test est la seule methode valide.
3)compression de flux videos. En theorie en compression video on peut atteindre des taux de 1400/1 en pratique on est proche de 500/1. Intel avec son codec Indeo, juste en essayant des equations d'ondes a la file a reussit sur le codec 5 a passer de 1/200 (5.02) a 1/350 (5.11). Je ne pense pas que la raison en soit que les matheux de chez Intel ne savent pas calculer, a mon avis c'est juste encore un de ces cas ou a besoin de faire des tests pour savoir si ca marche.
Kha
(qui va faire un post one liner pour se changer les idees)
C'est en fait assez penible a appliquer completement. Autant il est possible de s'arranger pour qu'une majorite des equipes ne voit de la solution adoptee que l'interface du coeur de cette appli. Autant il est quasiment impossible de "modulariser" le coeur, car c'est generalement un bloc monolithique.
En d'autres termes le dev du GUI ou du plugin Oracle peuvent se faire sans rien connaitre de la solution, mais pour le gros morceau il faut qu'il y est communication(sinon on joue a un jeu qui s'apelle l'interface du jour, ou tous les jours suite a une demande minime du groupe d'a cote on se retrouve a reecrire tous les headers et toutes les interfaces de sa partie).
De plus les projets les plus demandeurs de R&D ne sont pas forcement tous de gros projets, bien au contraire. Une micro appli pour plateforme embarquee, un codec, un repartiteur dynamique de flux necessitent souvent des annees/hommes de tests pour au final arriver avec un produit qui prend moins de 2Mo en memoire. Su run programme aussi physiquement petit, une repartition en sous equipes et sous-sous equipes n'aurait aucun sens
e ne vois pas en quoi le fait de reecrire un logiciel pose probléme. Le conception d'un logiciel n'est qu'un probléme de mathématique: c'est l'utilisation de un ou plusieurs algorithmes pour résoudre un probléme donné.
Pas du tout, l'ecriture d'un programe n'est pas un probleme mathematique. On peut demontrer qu'un algorythme est fini, que le probleme est calculable et soluble a coup sur. Mais ca n'empeche pas le nombre de facon de resoudre le dit probleme d'etre "grand". Pas plus que ca n'indique que le probleme est pratiquement soluble, les informations obtenues par approche mathematique sont le plus souvent purement theorique.
Par exemple un employe A bosse dans une entreprise X qui veut ecrire un programe. Les matheux planchent sur les modeles et en retiennent une dizaine qui sont "theoriquement realisables".
La dessus la boite X investit 20 ans/homme de R &D pour implementer et tester les solutions que les matheux ont decrit comme valables. Il en ressort au final qu'une seule solution est applicable en pratique (pour des raisons de charge, de temps de traitement, de coherence des donnees, de facilite de deploiement etc.).
L'entreprise X a pris un risque (rien ne guarantissait qu'une solution etait implementable), elle a claquee une fortune en recherche et en tests. Le prix de l'application refletera ces faits.
Maintenant si notre employe A quitte la boite X pour aller bosser chez Y qui veut creer un logiciel similaire. A a deux choix soit il dit qu'il connait la seule solution implementable, soit par respect envers son ancien employeur il se tait. Mais si il parle alors Y aura des avantages monstrueux sur X :
-Cout de recherche et de tests quasi null car la solution est deja connue
-Prise de risque minimale car l'entreprise Y sait que la solution est implementable.
Y sera donc en mesure de fournir une application de qualite identique a celle de X (en theorie) a un prix beaucoup plus faible.
Malgre mes penchants pour le libre, face a un cas comme celui que je viens de decrire je suis oblige d'admettre que si A donne la solution a Y alors il y a acte de concurrence deloyale.
Bien sur cela ne s'applique que sur de tres gros projet, ou des projets vraiment innovants, mais a la place de A je demanderais a l'entreprise Y de me sortir du projet, non par crainte des represailles judiciaire, mais par respect envers le travail de mon ancienne boite.
En fait c'est un peu plus complique que ca si ma memoire est bonne.
1) Independamment de ton employeur, c'est la personne physique ou morale qui a ecrit le cahier des charge est le cahier de devellopement qui heritent des droits. Donc si ton etreprise te demande d'ecrire un programme suivant certaines specifications, alors le code est a eux legalement parlant. Si il y a partage entre la maitrise d'oeuvre et la maitrise d'ouvrage, alors les deux entreprises impliquees peuvent se servir du code. Si tu devellopes sur ton temps libre un programe dont tu as toi meme ecrit le cahier des charges et le cahier de dev (c'est tres important de le faire en cas de conflit) alors la propriete te revient.
N.B ce type de restrictions n'est pas propre au logiciel, on retrouve des restrictions tout a fait similaires dans le monde du film (droits sur un scenario) et dans le monde de l'audio (droits sur un album)
2) Personne ne peut t'empecher de te servir une seconde fois de connaissances deja acquises. Par exemple si tu as appris les modeles de Gamma a l'ecole et que tu t'en est servi dans un logiciel de traitement d'infos boursieres (au hasard), en theorie personne ne peut t'empecher de reutiliser les memes modeles dans une autre application du meme type pour un autre employeur(heureusement). La chose a faire en cas de conflit est de prouver que tu connaissais cette solution (ou ce type de solutions) avant le travail que tu as effectue pour ton premier employeur. Pour faire preuve tu peux utiliser tes cours, des references a des livres que tu as lu, ou simplement le bon sens (utiliser un algorithme de compression dans un programe de back-up ).
3) La plupart des clauses de non concurrence sont contournables. Il suffit par exemple de demontrer que tu as un besoin fondamental de tes connaissances pour travailler et que l'entreprise a besoin fondamental de toi. Une personne qui a travaille 10 ans dans le domaine boursier a faire du dev sur des applications d'echanges boursiers peut sans grosse difficulte demontrer que si elle change de voie elle aura beaucoup plus de mal a retrouver un travail, de plus il y aurait un manque a gagner financier important. De meme pour passer outre les clauses de non concurrence une entreprise qui chercherait a embaucher un tel employe n'aurait qu'a dire qu'elle cherche urgament un developpeur qui a travaille 10 ans sur des applications d'echanges boursiers. Comme c'est un profil qui ne court pas les rues, elle peut invoquer la necessite et embaucher la personne malgre les clauses. Une autre facon de faire consiste a faire un contrat de mission en preembauche. Si l'entreprise X veut vous licensier et que l'entreprise Y veut vous embaucher, il suffit a l'entreprise Y de vous prendre en mission alors que votre employeur reste l'entreprise X pour que les clauses de non concurrence deviennent caduques (sinon la personne sitot embauchee ne pourrait plus travailler).
4) Une autre facon de contourner ponctuellement la clause de non concurrence consiste a tricher honteusement. Le truc est de faire appel a un homme de paille. Si tu te retrouves a travailler sur un projet extrement proche d'un autre projet que tu as eu chez un autre employeur, et que la seule solution est de reeutiliser les solutions qui avaient ete trouvee chez ton precedent employeur, voila la demarche a suivre : Il faut tout d'abord demander a etre sorti officiellement de l'equipe decisionelle de ce projet, et insister pour devenir simple developpeur/coordinateur(sur le papier au moins). Il faut ensuite faire ecrire a un tiers le cahier de dev qui contient toutes les solutions trouvees chez ton precedent employeur. A partir de la tu ne fais, officiellement, qu'implementer les solutions trouvees par d'autres personnes. La clause de non concurrence ne joue plus. Seul probleme si c'est trop gros ca se voit, et generalement ca ne pardonne pas devant les tribuneaux.
En conclusion je dirais que la meilleure solution consiste a ne pas signer de clauses de non concurrence. Une discussion calme avec le responsable lors du Nieme entretien devrait faire l'affaire. Il suffit de lui dire que l'on a rien contre l'idee de signer des clauses de non divulgation pour les decouvertes propres a l'entreprise et les solutions optimisee que l'on pourrait rencontrer lors du travail chez eux, mais que par contre une clause generaliste qui verrouille le code au fur et a mesure que vous l'ecrivez ne vous parait pas raisonable.
Il est vrai qu'en ce moment, avec la crise profonde de l'informatique, il est difficile de faire ce genre de demandes. Mais je pense que ca vaut quand meme le coup d'essayer.
Kha
Vois tu en fait c'est de la faute du pere noel, tu remarqueras que si tu compiles le 25 decembre cette singularite disparait. Maisen dehors de noel les ELFs ne font pas de cadeau.
Je sais pas il parait qu'il y a des pays ou une LS ne coute pas 3000 euros par mois et par metre, d'un coup ce genre de projet devient plus realisable
Kha
(pas taper)
Une question maintenant : ya un lien sur le message de linus qui annonce le 2.6 pour juin 2003. Qu'en est il aujourd'hui, juste par curiosité.
Le gros probleme des IRQs nouvelle generation semble etre presque resolu. Il y a encore un bon nombre de choses a changer (notemment les ponts ide-scsi qui ne fonctionnent plus) mais dans l'ensemble le bout du tunnel est assez proche. Donc le 2.6 en juin ca ne parait pas improbable du tout, meme si ca sera plutot mi-juin a mon avis.
Kha
J'ai un copain qui est dans le meme cas que toi. Le prob c'est qu'avec les vagues de crises successives il y a de la concurrence.
D'un cote on a des marketoides a poil ras qui ne savent rien faire si ce n'est se vendre (ils ont reussi a faire cracher 12M de francs a leur banque pour de la vente de patates douces sur internet), dont fort heureusement le nombre decline, et d'un autre cote on a des employees Thomson/CSF,Orange, vivendi avec 10 ans d'experiences dans les grso systemes et les SGBD mais qui sont pres a tout pour retrouver du boulot tout de suite (a 40ans un an au chommage ca pardonne pas) et qui donc se bradent.
La seule solution c'est d'etre tres agressifs(n.b au sens mise en valeur, pas au sens violence) lors des entretiens. 9 fois sur 10 il faudra faire un effort sur le salaire (comptez 20 000 a 30 000 frs/an de moins apr rapport a l'annee derniere).
A mon sens le truc serait de posseder un moyen de faire comprendre aux gens que
1) - Les CDs proteges ne sont pas des CDs et ont une qualite sonore tres en dessous de celle d'un CD (le moindre pepin s'entend)
2) - Un appareil capable de lire les CDs proteges est un appareil de mauvaise qualite (qui ne tient pas compte des informations de correction d'erreur).
3) - Le fait que ce ne soit pas des CD audios, mais des pieges destines a faire planter les systemes de copie peut dans certains cas entrainner une deterioration rapide de l'appareil, et ca m'ettonnerait beaucoup que ce soit pris en charge par le constructeur (surtout si c'est Phillips)
Perso je commence serieusement a me demander si je ne vais pas commence a etre de TRES mauvaise fois. Je pense qu'un scandale public de 3/4 d'heure dans une Fnac parisienne un samedi apres midi peut etre une excellente facon de faire connaitre le probleme.
En fait ca vient de l'epoque victorienne, comme il etait malpoli d'etre curieux (surtout entre gentlemen) il etait courant qu'une personne voulant savoir ce a quoi pensait une autre lui offre 2 shilings (a verifier) pour ses pensees. C'etait loin d'etre inocent comme offre, il etait considere que 2 shilings etait le prix a payer au passeur pour traverser le fleuve des morts, ceux qui ne les avaient pas etait condamnes a errer sur les berges eternellement (meme sous Victoria les londoniens avait su garder un certains nombre de traditions paienne). On posait donc courament 2 shilings sur les yeux d'une personne recemment morte pour qu'elle puisse s'affranchir du droit de passage.
Dans cette optique proposer 2 shilings pour les pensees revenait a dire que l'on etait ami (pret a le suivre jusqu'a la mort) avec la personne et que ce n'etait en rien de la curiosite mais de l'inquietude.
Il y a du avoir melange entre les differents courants europeens aux US , car on a vu en plus de gens qui annoncaient que leur idee pouvait etre stupide (precaution oratoire latine) et des gens qui offraient 2 shilings pour les idees des autres, un melange ou les gens proposaient d'eux meme 2 shilings pour leur propre idee.
Oui c'est pas mal du tout d'utiliser des define pour faire propre mais bon :
1) ca oblige a utiliser des API d'assez haut niveau (vu que X et gdi c'est quand meme tres different il faut rajouter une couche qui lie les deux) donc ca reporte le probleme sur "quelle api de haut niveau utiliser?" (WxWindows, Opengl, SDL,Gtk,QT ??) non parceque des gens qui codent en win32 et en xlib pure il y en a quand meme pas des masses.
2) Il s'agit juste de compiler derriere a la main (ou de faire un binaire de 8Go au choix). Et bon bien que j'aime beaucoup compiler mes propres binaires (j'utilise une Gentoo) je dois reconnaitre que l'idee de devoir recompiler des trucs comme OOo ca me casse prodigieusement les pieds.
3) Ca s'arrete generalement pas au define, les meccanismes d'evenements (et notamment les signaux) sont souvent tres different d'une API a l'autre donc des ifdef ils risquent d'y en avoir un paquet. Bonjour le boulot des developpeurs derriere.
Ben ce qui est surtout a hurler de rire c'est quand tu t'es paye il y a deux ans une platine lecteur CD a 5 000 francs avec des systemes anti saturations, correction d'erreur a la volee et extrapolation 48khz (le gros truc quoi) et que tout CD protege se fait jeter dessus. C'est ce qui est arrive a mon oncle il est fou de joie.
(N.B bien que sa platine de salon soit incapable de lire le cd, son PC n'a eu aucun mal a en extraire les pistes, il a refait tout le master a partir des .wav).
L'appel au boycott d'une marque est interdit, par contre l'appel au boycott d'un type de produit (ici les cds proteges) est parfaitement authorise. Sinon adieu adieu les manifs anti OGM, aurevoir les vegetariens fort en gueule etc.
Donc si tu te sens l'ame d'un contestataire de premiere ligne lache toi, personne ne pourras rien te dire.
[^] # Re: www.brevets-logiciels.com : UNE HONTE
Posté par Jerome Herman . En réponse au journal www.brevets-logiciels.com : UNE HONTE. Évalué à 2.
Kha
# Ca servira a rien mais ...
Posté par Jerome Herman . En réponse au journal www.brevets-logiciels.com : UNE HONTE. Évalué à 10.
Bonjour,
Suite a un passage sur votre site je me permet de vous faire part de mon point de vue personel sur les brevets logiciel et le logiciel libre.
Outre les erreurs PHP, un certains nombre d'autres choses m'ont choquees sur votre site :
A) les brevets
I-Critere de brevetabilité :
L'ensemble des criteres de brevetabilite est tres difficilement verifiable dans le cadre particulier des logiciels.
- Nouveaute : La nouveaute pure en informatique est tres rare, l'informatique est un moyen et non un but, de fait l'immense majorite des "nouveautes" de ce domaine ne sont en fait que des transposition vers l'informatique de solutions preexistantes. L'implementation au sein d'un logiciel d'une decouverte mathematique, physique ou statistique est elle une nouveaute ? Le fait de reussir a produire un programme capable de realiser une solution deja connue merite-t-il se label ? De meme dans un systeme extremement dependant des contraintes physique (en l'occurence la puissance des machines cibles), peut on considere comme nouveau l'implementation par une personne (morale ou physique) d'un systeme que tout le monde cherche a developper depuis des annees ? Le jour ou la technologie permettra de faire une "immersion totale" dans un reseau est ce que le premier implementeur aura produit quelquechose de nouveau ? Est-ce que le premier compilateur a avoir utilise un systeme pour optimiser la vitesse d'execution des programmes etait "nouveau", son inventeur aurait-il pu deposer un brevet sur l'optimisation a la compilation ?
- Inventive : Cette definition fait appel a "l'homme du metier", oui mais lequel ? Si j'ecris un programe pour de la creation de modeles graphiques pour architectes qui est l'homme du metier ? Le concepteur du modele dont je me sert pour ecrire le programe, le programeur que je suis, le graphiste qui utilise le produit ou l'architecte qui utilise le resultat ? Il y a fort a parier qu'en matiere d'evidence il y est de tres grosse differences de l'un a l'autre.
Comment evaluer cette notion d'evidence avant de breveter ? Normalement il y a un trio dans la notion d'invention : il y a l'inveteur, l'utilisateur et le beneficiaire. La notion "d'homme du metier" refere le plus souvent a l'utilisateur, en l'occurence : le graphiste. Je peux vous garantir que pour un graphiste lambda rien n'est evident dans un programe, mais la plupart seront, je l'espere, assez honnetes pour admettre qu'ils ne peuvent pas repondre. Reste l'inventeur (qui a tout interet a dire que son invention est inventive) et le beneficiaire (qui a tout interet a dire le contraire pour des raisons financieres) .
- suffisance de description : Une fois de plus le probleme de "l'homme du metier" se pose. De plus quelles sont les conditions necessaires a cette suffisance. Est-ce qu'un brevet de l'entreprise X disant qu'en utilisant une serie de logiciels de l'entreprise X on peut produire l'invention est valable. De plus un certain nombre de langages sont consideres comme des machines de Turing completes (capable de resoudre l'immense majorite des problemes). Suffit-il de dire "mon invention tourne sur une machine de Turing complete" pour que l'on puisse considerer qu'il y ait suffisance de description ? Dans le cas contraire il faut descndre d'un niveau dans la description et la on arrive sur ... le code source!
II-Portée de la protection
Certes tous les brevets sont publies, mais qui a les moyens financiers de faire une recherche d'antecedent sur l'ensemble des modules un peu innovant de son application pour verifier si il peut les utiliser librement. La publication des brevets ne rend pas beaucoup plus facile l'acces aux informations d'antecedence.
A part un nombre tres reduit de "tetes" meme un excellent programeur sera incapable de dire si son code est un cas particulier couvert par un brevet portant sur un sujet beaucoup plus general.J'ai appris tres recemment qu'il existait des liens tres etroits entre la theorie des noeuds et les algorithmes de compression sans perte. Ayant ecris plusieurs systemes de compression je me suis penche sur cette theorie pour voir si il y avait quelque chose a en retirer et je n'ai strictement rien compris. Peut on attendre de l'OEB qu'il soit capable de me dire que mon programme de compression de donnee est en fait un cas particulier d'un programme de recoupement de flux base sur la theorie des noeuds ?
III-Les procedures d'examen
Tout organisme est faillible, d'ailleurs l'OEB a tout mon respect pour avoir su se remettre en cause a un moment crucial, mais au vu des differentes que j'ai fait plus haut est-il seulement possible de mettre en place des procedures "justes".
IV-Europe vs USA
Me semblait-il que l'on pouvait aux USA deposer un concept meme si son implementation n'etait pas realisable de facon evidente , ce qui n'est pas le cas en Europe. S'agit-il d'une legende ?
B)Brevets et logiciels
Les logiciels ne sont pas brevetables en tant que tel, c'est la partie "si sa mise en oeuvre sur un ordinateur produit un effet technique supplémentaire, allant au delà des interactions physiques normales entre programme (logiciel) et ordinateur" de la phrase. Un logiciel ne peut etre brevete que si il participe en tant que module d'une realisation plus importante. En d'autres termes un logiciel dit "grand public" destine a s'installer sur une machine standard est tres difficilement brevetable. Un exemple serait un logiciel de domotique. Ce logiciel produirait "un effet technique supplémentaire" et serait donc brevetable. Mais un traitement de texte ou un lecteur video quel que soit leur complexite ne sont pas brevetable en l'etat. Par contre un traitement de texte capable de reconnaitre la qualite de papier utilise avant l'impression, ou un lecteur video capable d'adapter son rendu a la lumiere ambiente le serait. Ce type de brevet est par ailleurs totalement innofensif aux yeux du libre vu qu'il est quasiment impossible de les enfreindre sans le faire expres. De plus il faut savoir rester beau joueur : si une personne a eu l'idee en premier, c'est a elle que revient le merite.
C)Brevet et concurrence
Si il est vrai qu'un brevet peut servir de tremplin a une PME, le contraire est tout aussi vrai si ce n'est plus, tout du moins aux Etats-Unis. Lorqu'une PME se retrouve dans la ligne de mire d'une grande entreprise, les consequences sont souvent desastreuses. L'example qui me vient en tete est celui de Bleem. Bleem etait un emulateur de PlayStation, la console de jeux troisieme generation de Sony. C'etait ce qu'on apelle un emulateur haut niveau. Sony a assome l'auteur de ce logiciel de proces, perdant a chaque fois mais bloquant a la fois le temps et l'argent de la societe. En Europe cette demarche aurait ete impossible, le logiciel ne produisant pas d'effet technique il aurait ete "de facto" incapable d'enfreindre un brevet (comme quoi il y a des differences).
Il est vrai qu'un brevet peut servir de garantie aux yeux des investisseurs, mais est-ce que le prix a payer n'est pas trop fort ?
La lutte contre Microsoft n'a aucun rapport avec la lutte contre les brevets. Microsoft n'a jamais ou presque fait valoir ces brevets, ils ont par contre assez souvent enfreint les brevets, fait trainer le proces le plus possible avant de racheter la societe qui avait intente le proces(ce qui d'ailleurs remet un peu en question l'affirmation comme quoi le brevet permet aux PME de se defendre contre les entreprises plus grosse).
La lutte contre le brevet logiciel est une lutte qui vise simplement a s'assurer qu'une alternative est toujours possible. Qu'une personne ou une entreprise puisse produire une application sans debourser a l'avance une fortune ne frais de recherche d'antecedent (une autre entaille dans la certitude que les brevets favorisent les PME).
D) Cout de la protection
Les couts que vous evoquez (et dont sont d'ailleurs absents les couts de recherche d'antecedent lesquels sont presque aussi eleves que ceux de depot de brevet a l'heure actuelle) sont effectivement minimes pour une grosse entreprise. Pour une PME ils sont deja plus important, et pour un groupe d'ami qui a eu une idee geniale et qui veulent monter leur structure ils sont tout simplement prohibitifs. Quoi de plus naturel alors que de rendre les specifications du produit publiques et de se focaliser sur un marche de service pur. C'est une des idee forte derriere la philosophie du libre. Si on veut exploiter une idee sans se vendre a une grosse entreprise, le libre est une solution tout a fait raisonnable. Mais pour pouvoir faire cela, il faut que la recherche d'antecedent soit iniutile.
E)Section logiciel libre/Analyse ecconomique
- La logique du modele libre
Le logiciel libre propose d'offrir des logiciels de qualite (le prix n'ayant aucune importance) sur lequel le client a un controle total. On peut parfaitement vendre un logiciel libre, on peut meme le vendre cher et ce sans y associer aucun service. On est juste tenu de fournir le code source et d'authoriser sa distribution. Le libre assure que la personne qui l'utilise ne sera jamais coincee. Elle pourra toujours faire apple a des developpeurs pour faire les modification dont elle a besoin sur son produit, elle pourra toujours exporter ses donnees vers une autre plateforme (la aussi si besoin est en faisant appel a des devoleppeurs), elle pourra a son tour deployer ses applications chez ses clients pour harmoniser leurs echanges et ce sans surcout.
-Une ecconomie negligeant la valeur de la production de l'immatériel
Je passe rapidement sur une comparaison stupide entre la gratuite de l'immateriel et la gratuite du materiel : a la difference des oranges si je donne mon programme, je le possede encore.
L'ecconomie du libre ne neglige en aucun cas la valeur de l'immateriel, c'est meme au contraire une farouche partisanne de cette valeur. Les acteurs du libre esperent bien, pour la plupart, etre payes en amelioration. Une entreprise qui se tourne vers le libre en mettant une application maison sous license libre espere plus que tout que son programme va avoir du succes et qu'elle va pouvoir obtenir (en un temps infiniment plus court que celui auquel elle aurait pu pretendre seule) des corrections de bugs, des ameliorations ergonomiques, de nouvelles fonctionalites et des optimisations. Le fait que les echanges de valeurs ne sont font pas par cheques interposes ne veut absolument pas dire qu'ils sont absent.
(je suis ici oblige ,pour des raisons de logique, a passer directement au point Analyse juridique, je reviendrais sur la partie "les erreurs de ce modele" plus tard)
F)Analyse juridique
-Les contributeurs ne sont pas toujours titulaires des droits qu'ils abandonnent.
Outre le fait que les contributeurs n'abandonnent en rien leur droits(ils ne font que les partager, mais rien ne les empeches de produire leur application sous license fermee a cote), il faut bien faire la difference entre plusieurs choses: un employe qui utilise son temps de travail pour ecrire ou contribuer au logiciel libre sans l'accord de son patron vole celui-ci. Mais cela n'est ni plus ni moins condamnable qu'un employe qui joue au solitaire toute la journee. Cela existe je n'en doute pas mais de la a dire que c'est de la faute du libre il y a un gouffre. Il est par contre tres rare qu'un chercheur puisse ecrire du libre sans l'aval de sa hierarchie. Les projets de recherche sont souvent tres surveilles, proposee par des commites institutionels ou plus rarement par des entreprises, et couvrent plus souvent des preuves de faisabilite que des implementations adaptes. En d'autres termes la plupart des applications issues de la recherche sont a peu pres inutilisables en production. Les autres application sont souvent des commandes d'un client et sont bein entendu devellopees et licensiees suivant les desideratas de ce client.
Pas de reelle inquietude que la decouverte du siecle passe dans le monde du libre au nez a a la barbe de l'etat francais.
-Les licences de type GNU ne respectent pas le formalisme du droit français
Ce serait vrai si il y avait renonciation des droits, ce n'est pas le cas. Rien ne m'empeche si j'ecris un programme de le relacher a la fois sous license GNU et sous license proprietaire. De meme le code que j'apporte a un projet GNU preexistant peut tres bien etre utilise par moi dans un autre projet. La license GPL m'assurre juste que le code que je donne ne peut pas etre reutilise par un tiers dans une application non GNU.
-Les logiciels libres ne respectent pas le droit fiscal
J'imagine que vous limitez une fois d eplus la notion de prix a des especes sonnantes et trebuchantes, et que la valeur qu'une entreprise peut retirer d'un passage au libre (cf plus haut) ne compte pas.Deja cela revient a dire que le fait de ne pas vendre ses logiciels est anormal, en d'autres termes votre raisonement se mord un peu la queue : il faut vendre les logiciels parcequ'il ne faut pas ne pas les vendre.Pas tres godelien tout ca. De plus j'ignore completement quelle est le prix "normal" d'un logiciel. Quand est-il des freewares, des sharewares, des logiciels qui se financent par la publicite, des logiciels a but publicitaire, des produits fournit gratuitement avec l'achat d'un ensemble de logiciels, du code present dans les lessons d'initiations a des langages sur certains sites webs, des exemples etudies en cours par les eleves ? En d'autres termes tous ces produits que l'on peut obtenir sans debourser (et c'est volontaire si je ne dis pas gratuitement) sont-ils aussi illegaux ? De plus ou est le rapport avec la brevetabilite ? Le monde n'est pas en noir et blanc, meme si le libre est dans l'erreur sur certains points cela ne prouve en rien qu'il faille autoriser les brevets.
(je peux maintenant revenir sur ce que je considere comme une conclusion)
-Les erreurs de ce modele
*il s'agit d'un modèle anticoncurrentiel
Aux Etats Unis Sony a fait deposer un brevet sur la partie logicielle qui permet a ses consoles (Playstation 1 et 2) de s'initialiser et de lancer un programe. Le brevet est tourne de telle facon que toute tentative visant a essayer de produire un equivalent est immediatement illegale. On peut donc sous couvert de la loi ameriquaine interdire toute forme de concurrence logicielle(Amusant non? Encore une chose que notre legislation sur les brevets pourtant en tout point similaire ne permet pas). Je ne sais pas si le libre est anticoncurrentiel, j'aurais plutot eu tendance a trouver qu'il mettait tout le monde sur un pied d'egalite, et etait le seul cas possible de l'avenement de la concurrence pure et parfaite. Par contre en ce qui concerne les brevets je sais que ca va contre la concurrence, j'ai des exemples.
*il est contraire à l'esprit d'entreprise
J'aimerais bien connaitre le raisonnement qui vous permet d'affirmer cela. Le nombre d'entreprises qui produisent, utilisent, vendent, exploitent du libre est largement assez grand pour prouver le contraire. Si vous pensez que le libre s'impose par sa gratuite, vous avez tort. Le libre a pris son essor pendant une periode ou les prix des applications etaient deja en chute libre. Si il gagne des part de marches c'est exclusivement grace a sa qualite. Il stimule le marche en offrant une alternative qui evolue.De plus il serait stupide de dire qu'une PME qui est prete a payer quelques 30 000 francs+10 000francs/an pour proteger ses droits reculerait devant l'achat d'une serveur a 6 000 francs. Si vous pensez que le libre aneanti les volontes de creation d'entreprise logicielle, les createurs ayant trop peur de concurrencer un produit "gratuit" (sic), detrompez vous. Premierement la plupart des produits libre ont deja une contrepartie proprietaire (qui souvent se porte bien), deuxiemement c'est la qualite d'un produit qui permet de le vendre, non pas son prix. Un produit "bien fini" et stable rassurera certains responsables des achats et se vendra sans probleme.
*il privilégie les activités de distribution et de prestations annexes, au détriment de la création
Ben voyons, juste parce que le libre estime qu'il ne faut pas vendre la creation, ne veut pas dire que le libre la defavorise. Au contraire c'est un veritable bouillon de culture la dedans. On voit plus souvent les personalites du libre appeler a l'union et a la focalisation que demander la creation de nouveaux projets.
*il entraîne une déresponsabilisation des acteurs
Bon on passe rapidement sur le haut sens des responsabilites qu'ont certains acteurs du monde non libre, pour poser une question : l'ensemble du code etant visible, teste, souvent approuve par un comite, soumis en tests aux utilisateurs, valide, parfois audite intensivement ou est la deresponsabilisation ?
*il va à l'encontre d'une industrie dynamique de conception de logiciels en Europe
J'aime quand l'argumentation affirme de but en blanc la conclusion, comme ca discretement.
*il brade les résultats de la recherche financée par le contribuable
Cf plus haut, c'est hautement improbable. A part dans le cas de professeurs(qui ont devoir de retransmettre leur connaissances) c'est meme pratiquement impossible.
*il est contraire aux principes fiscaux.
Cf plus haut, si c'est le cas il est tres loin d'etre le seul.
Le libre ne conteste pas la propriete, il conteste l'exclusivite, il conteste le verouillage des techniques, il conteste la prise en otage de l'utilisateur par une societe editrice de logiciel, il conteste la brume qui etoure certaines applications etc. Mais pas la propriete. Pas du tout. Comme dit plus haut si j'ai envie de reutiliser le code que j'ai donne au libre dans des applications proprietaires ca ne pose aucun probleme, c'est le reste du monde qui ne peut pas. Preuve s'il en est que la notion de propriete n'a pas disparue.
Voila, tout ca pour mettre au clair un certain nombre de choses.
Salutations
Jerome Herman
[^] # Re: C'est vrai ça ?
Posté par Jerome Herman . En réponse à la dépêche Les nouvelles de MS : changement de discours sur Linux et «petit vent d'été». Évalué à 2.
http://www.marstoday.com/viewsr.html?pid=9192(...)
Kha
(quitte a etre hors sujet, autant faire ca bien)
[^] # Re: C'est vrai ça ?
Posté par Jerome Herman . En réponse à la dépêche Les nouvelles de MS : changement de discours sur Linux et «petit vent d'été». Évalué à 1.
Kha
[^] # Re: Droit d'auteur et travailleurs
Posté par Jerome Herman . En réponse à la dépêche Droit d'auteur et travailleurs. Évalué à 2.
Effectivement j'etais a cote de la plaque, mais il faut reconnaitre que la structure de tes phrases me laisse perplexe par exemple :
On a simplement pu démontrer son existence par des moyens détournés, sans exhiber une solution précise au problème.
Cette phrase sous entend que l'on sait qu'il y a une solution au probleme mais que l'on ne la connait pas. Alors qu'en fait on est absolument pas sur que cette solution existe, voir meme franchement sceptique ce que tu resumes tres bien dans ta phrase de conclusion.
Comme Boubou, tu confonds la prouvabilité d'une propriété (il existe une méthode en temps polynomial) avec l'exhibition d'une solution intéressante en pratique
Non du tout, j'ai suffisament de bouteille pour me mefier comme de la peste des trucs qui marchent vachement bien "sur le papier" cf mes autres postes plus haut. Je ne suis pas sur non plus que Boubou confonde. La discussion portait plus sur la necessite de faire des tests vis a vis d'un modele optimise.
les mathématiques appliquées et l'informatique sont deux disciplines séparées
Tres discutable, si on prend un domaine comme les reseaux de Petri colore ou l'implementation informatique decoule quasi directement du modele mathematique on se rend compte que bien que distinctes ces deux disciplines ne sont pas tres loin l'une de l'autre.
Kha
[^] # Re: Brevetabilité : Brevets logiciels et menaces sur l'économie
Posté par Jerome Herman . En réponse à la dépêche Brevetabilité : Brevets logiciels et menaces sur l'économie. Évalué à 4.
Deja fait, si je me souvient bien c'est meme le premier brevet depose.
Kha
[^] # Re: C'est vrai ça ?
Posté par Jerome Herman . En réponse à la dépêche Les nouvelles de MS : changement de discours sur Linux et «petit vent d'été». Évalué à 8.
La pile TCP/IP, les systemes de routages et les tunnels sont d'excellents points d'attaques pour prendre le controle des machines ou tout du moins utiliser des fonctionalites d'un reseau a l'insu des admins, donc je ne suis pas vraiment d'accord avec toi quand tu dis que cela ne devrait pas etre pris en compte. C'est l'eternelle question "who watches the watchmen ?" (qui surveille les gardiens, Alan Moore a lire absolument) .
C'est le "pratiquement" qui me gene....
Par pratiquement j'etend que la plupart des failles connues d'OpenBSD necessitent non seulement de la technique mais aussi un peu de chance pour pouvoir etre exploitee. La majorite des failles OpenBSD ne font que retransmettre les droits de l'executeur du demon, donc si on a bien verrouille ces droits on se retrouve avec un service en rideau point barre. Un utilsateur qui n'a pas de login (schell=/dev/null) qui est forcement chroote dans son coin (aucun prog "nuisible" a disposition) a du mal a faire des degats. Comme c'est souvent le cas par defaut a l'install ca limite en plus les erreurs des admins un peu brouillon.
Pour prendre un autre exemple, je vais parler de la Trusted Debian.
Trusted Debian a une voccation de serveur a part entiere, que n'a pas (a mon sens) OpenBSD. De fait TD est beaucoup plus versatile qu'OpenBSD donc beaucoup plus dure a securiser, ce qui augmente son merite. Neamoins personellement meme une TD je la mettrais derriere un OpenBSD (paranoia quand tu nous tient)
Tout ca pour dire que les chroot et autres "trucs pour proteger des programmes mal concus", bah on est jamais sur a 100% que c'est completement incontournable
C'est sur que l'on peut toujours tomber sur une personne plus maline que les autres qui va tomber sur une faille que personne n'avait vu jusque la. C'est d'ailleurs un des enormes avantages du libre (given enough eyeballs, all bugs are shallow , avec assez d'yeux tous les bugs sont evidents), mais malgre tout c'est clair qu'il ne faut pas en profiter pour bacler son propre travail. Cependant il est rassurant de savoir que la plateforme sur laquelle on bosse est solide et que les seuls bugs dont on a a se preocuper sont ceux que l'on pourrait ecrire ou creer par des erreurs de configuration. En d'autres termes je n'arrete pas de faire tres attention a ce que je fais, par contre je ne passe que tres peu de mon temps a controller ce que l'OS fait. Et ca c'est vraiment appreciable.
Kha
[^] # Re: Brevetabilité : Brevets logiciels et menaces sur l'économie
Posté par Jerome Herman . En réponse à la dépêche Brevetabilité : Brevets logiciels et menaces sur l'économie. Évalué à 2.
Ben il peuvent pas le code est propriete de SCO.
Kha
(pas taper)
[^] # Re: C'est vrai ça ?
Posté par Jerome Herman . En réponse à la dépêche Les nouvelles de MS : changement de discours sur Linux et «petit vent d'été». Évalué à 10.
Pas vraiment non, Dans OpemBSD dans l'install par defaut il y a tot ce qu'il faut pour faire un routeur/firewall/proxy NAT/tunnel. C'est le genre d'outils ideal a mettre aux bouts des DMZ quand on trouve que Cisco est trop cher.
De plus tous les demons OpenBSD sont chrootes par defaut. Donc ca limite vachement les problemes. Maintenant c'est clair que sur Apache, Samba ou DNS, ils se prennent les memes failles que les autres, mais vu que la base est quasi indestructible ces failles sont pratiquement inexploitables.
Il faut bien reconnaitre de plus qu'OpenBSD n'a pas vocation a etre installe en workstation ou meme en serveur complet. Linux et FreeBSD font beaucoup mieux le boulot a ce niveau la. Par contre en tandem c'est de la folie, un serveur Apache sur FreeBSD derriere un proxy OpenBSD c'est assez terrible.
Kha
[^] # Re: Droit d'auteur et travailleurs
Posté par Jerome Herman . En réponse à la dépêche Droit d'auteur et travailleurs. Évalué à 1.
Ca ne depend pas, il est prouve (mathematiquement) que si un probleme NP complet a une solution polynomiale, alors tous les problemes NP complet ont une solution polynomiale (pour rappel NP ne veu pas dire non polynomial, mais non solvable polynomialement, ie on enpeut pas trouver de solutions par une approche polynomiale, mais la solution peut elle etre polynomiale).
De plus en passant par les algo de reduction dont parle Boubou on peut "extraire" une solution polynomiale a n'importe quel probleme NP complet a partir d'une solution d'un probleme NP complet donne.
En d'autres termes si on trouve un jour une solution polynomiale a un probleme NP complet, tous les problemes NP complet seront resolu dans la foulee avec une solution polynomiale pour chacun.
Kha
[^] # Re: Droit d'auteur et travailleurs
Posté par Jerome Herman . En réponse à la dépêche Droit d'auteur et travailleurs. Évalué à 5.
Tres simplement : traitement d'un flux de donnees, ou de facon generale tout domaine ou on a pas la maitrise des flux entrants. On peut demontrer que le traitement d'un jeu de donnees prendra un certain temps machine a condition de connaitre suffisament bien le contenu de ce jeu.
Ce qui est beaucoup plus dur c'est d'etre capable de traiter des donnees exterieures dont on se doute qu'elle risquent d'etre incompletes a un moment ou a un autre tout en gardant une coherence de la base interne. La les maths ne peuvent pas vraiment assurer un resultat (meme si l'utilisation d'outils stochastiques permet de debrouisailler pas mal).
Trois examples pour se faire une idee :
1)Traitement de flux boursiers : On recoit des quotes boursieres par satellite en temps reel. Il faut ecrire un programme capable de transformer ces informations ephemeres en un historique complet. En cas de "flambee" boursiere les informations que l'on recoit passent en mode "burst" a savoir une quote qui remonte a jusqu'a il y a 10 minutes puis la liste des variations au coup par coup jusqu'a maintenant. Bien sur si il y a perte d'une information sur les variations d'une action, les variations suivantes sont perdues aussi. Question : Est ce que je peux etre sur que ma base sera "propre" demain en sachant que je peux m'aider d'un fournisseur d'historique externe pour verifier le contenu de ma base ?
Reponse : non, rien ne dit que j'aurais fini le boulot a temps. En utilisant les stochastiques je peux etre raisonablement sur. La seule "bonne" facon de verifier c'est de tester en rejouant par exemple une des journees boursiere les plus chargees.
2)Maintenance serveur : On a un serveur qui doit effectuer un certains nombre de tache la nuit. Ces taches sont pour certainnes paralelisables pour d'autres mutuellement exclusives. Ce sont les taches suivantes
a) - Consolidation base de donnees
b) - Verification et eventuellement recreation des index base
c) - Backup des disques
d) - Mise a jour automatique des versions des applis si besoin
e) - Update des scripts de traitement si besoin
f) - mise a jour des droits utilsateurs si besoin
g) - verification de la synchro applis avec un autre serveur en load balancing, et mise a jour si besoin.
Je sais (parceque j'ai une enorme base et de vieux serveurs) que je ne pourrais pas faire toutes les operations dans la nuit. Il faut pourtant que les serveurs soient "libres" le lendemain.
De plus avant de consolider la base de donnees(a) il faut faire un backup (c)
De meme (b) necessite (a)
(c) n'a pas de prerequis mais prend du temps
(d) necessite (c) et implique (g) et enventuellement (e)
(e) peut necessiter (f) et/ou (d)
(f) implique (a) (ne pas garder en base des utilisateurs qui n'existent plus)
(g) peut necessiter (f)
En sachant que je n'ai pas le droit de faire deux backups du serveur le meme soir (ou alors exceptionellement avec une personne sur site pour changer les bandes) est ce que je peux etre sur que chacune des operations sera effectuee au moins deux fois par semaine ?
Pour les memes raisons que plus haut : non. Une fois de plus le test est la seule methode valide.
3)compression de flux videos. En theorie en compression video on peut atteindre des taux de 1400/1 en pratique on est proche de 500/1. Intel avec son codec Indeo, juste en essayant des equations d'ondes a la file a reussit sur le codec 5 a passer de 1/200 (5.02) a 1/350 (5.11). Je ne pense pas que la raison en soit que les matheux de chez Intel ne savent pas calculer, a mon avis c'est juste encore un de ces cas ou a besoin de faire des tests pour savoir si ca marche.
Kha
(qui va faire un post one liner pour se changer les idees)
[^] # Re: Droit d'auteur et travailleurs
Posté par Jerome Herman . En réponse à la dépêche Droit d'auteur et travailleurs. Évalué à 2.
En d'autres termes le dev du GUI ou du plugin Oracle peuvent se faire sans rien connaitre de la solution, mais pour le gros morceau il faut qu'il y est communication(sinon on joue a un jeu qui s'apelle l'interface du jour, ou tous les jours suite a une demande minime du groupe d'a cote on se retrouve a reecrire tous les headers et toutes les interfaces de sa partie).
De plus les projets les plus demandeurs de R&D ne sont pas forcement tous de gros projets, bien au contraire. Une micro appli pour plateforme embarquee, un codec, un repartiteur dynamique de flux necessitent souvent des annees/hommes de tests pour au final arriver avec un produit qui prend moins de 2Mo en memoire. Su run programme aussi physiquement petit, une repartition en sous equipes et sous-sous equipes n'aurait aucun sens
Kha
[^] # Re: Droit d'auteur et travailleurs
Posté par Jerome Herman . En réponse à la dépêche Droit d'auteur et travailleurs. Évalué à 2.
Pas du tout, l'ecriture d'un programe n'est pas un probleme mathematique. On peut demontrer qu'un algorythme est fini, que le probleme est calculable et soluble a coup sur. Mais ca n'empeche pas le nombre de facon de resoudre le dit probleme d'etre "grand". Pas plus que ca n'indique que le probleme est pratiquement soluble, les informations obtenues par approche mathematique sont le plus souvent purement theorique.
Par exemple un employe A bosse dans une entreprise X qui veut ecrire un programe. Les matheux planchent sur les modeles et en retiennent une dizaine qui sont "theoriquement realisables".
La dessus la boite X investit 20 ans/homme de R &D pour implementer et tester les solutions que les matheux ont decrit comme valables. Il en ressort au final qu'une seule solution est applicable en pratique (pour des raisons de charge, de temps de traitement, de coherence des donnees, de facilite de deploiement etc.).
L'entreprise X a pris un risque (rien ne guarantissait qu'une solution etait implementable), elle a claquee une fortune en recherche et en tests. Le prix de l'application refletera ces faits.
Maintenant si notre employe A quitte la boite X pour aller bosser chez Y qui veut creer un logiciel similaire. A a deux choix soit il dit qu'il connait la seule solution implementable, soit par respect envers son ancien employeur il se tait. Mais si il parle alors Y aura des avantages monstrueux sur X :
-Cout de recherche et de tests quasi null car la solution est deja connue
-Prise de risque minimale car l'entreprise Y sait que la solution est implementable.
Y sera donc en mesure de fournir une application de qualite identique a celle de X (en theorie) a un prix beaucoup plus faible.
Malgre mes penchants pour le libre, face a un cas comme celui que je viens de decrire je suis oblige d'admettre que si A donne la solution a Y alors il y a acte de concurrence deloyale.
Bien sur cela ne s'applique que sur de tres gros projet, ou des projets vraiment innovants, mais a la place de A je demanderais a l'entreprise Y de me sortir du projet, non par crainte des represailles judiciaire, mais par respect envers le travail de mon ancienne boite.
Kha
# Re: Droit d'auteur et travailleurs
Posté par Jerome Herman . En réponse à la dépêche Droit d'auteur et travailleurs. Évalué à 10.
# Re: .a et .so
Posté par Jerome Herman . En réponse au journal .a et .so. Évalué à 6.
Kha
(pas taper)
# Re: Gentoo Linux fait de la pub pour l'Armée Américaine
Posté par Jerome Herman . En réponse au journal Gentoo Linux fait de la pub pour l'Armée Américaine. Évalué à 1.
Kha
(pas taper)
[^] # Re: VDSL disponible par 81° de latitude nord
Posté par Jerome Herman . En réponse à la dépêche VDSL disponible par 81° de latitude nord. Évalué à 4.
[^] # Re: Encore une analyse Linux VS Unix
Posté par Jerome Herman . En réponse à la dépêche Encore une analyse Linux VS Unix. Évalué à 3.
[^] # Re: Quel rapport avec le libre ?
Posté par Jerome Herman . En réponse à la dépêche Microsoft se lance dans le discount. Évalué à 1.
Kha
# Re: Jeune diplomé cherche CDD ...
Posté par Jerome Herman . En réponse au journal Jeune diplomé cherche CDD .... Évalué à 2.
D'un cote on a des marketoides a poil ras qui ne savent rien faire si ce n'est se vendre (ils ont reussi a faire cracher 12M de francs a leur banque pour de la vente de patates douces sur internet), dont fort heureusement le nombre decline, et d'un autre cote on a des employees Thomson/CSF,Orange, vivendi avec 10 ans d'experiences dans les grso systemes et les SGBD mais qui sont pres a tout pour retrouver du boulot tout de suite (a 40ans un an au chommage ca pardonne pas) et qui donc se bradent.
La seule solution c'est d'etre tres agressifs(n.b au sens mise en valeur, pas au sens violence) lors des entretiens. 9 fois sur 10 il faudra faire un effort sur le salaire (comptez 20 000 a 30 000 frs/an de moins apr rapport a l'annee derniere).
Kha
[^] # Re: CD audio - protection contre la copie : la première fois ça fait mal
Posté par Jerome Herman . En réponse au journal CD audio - protection contre la copie : la première fois ça fait mal. Évalué à 3.
1) - Les CDs proteges ne sont pas des CDs et ont une qualite sonore tres en dessous de celle d'un CD (le moindre pepin s'entend)
2) - Un appareil capable de lire les CDs proteges est un appareil de mauvaise qualite (qui ne tient pas compte des informations de correction d'erreur).
3) - Le fait que ce ne soit pas des CD audios, mais des pieges destines a faire planter les systemes de copie peut dans certains cas entrainner une deterioration rapide de l'appareil, et ca m'ettonnerait beaucoup que ce soit pris en charge par le constructeur (surtout si c'est Phillips)
Perso je commence serieusement a me demander si je ne vais pas commence a etre de TRES mauvaise fois. Je pense qu'un scandale public de 3/4 d'heure dans une Fnac parisienne un samedi apres midi peut etre une excellente facon de faire connaitre le probleme.
Kha
[^] # Re: mes 0.02 cts d'euro
Posté par Jerome Herman . En réponse à la dépêche Les modéros LinuxFR. Évalué à 3.
Dans cette optique proposer 2 shilings pour les pensees revenait a dire que l'on etait ami (pret a le suivre jusqu'a la mort) avec la personne et que ce n'etait en rien de la curiosite mais de l'inquietude.
Il y a du avoir melange entre les differents courants europeens aux US , car on a vu en plus de gens qui annoncaient que leur idee pouvait etre stupide (precaution oratoire latine) et des gens qui offraient 2 shilings pour les idees des autres, un melange ou les gens proposaient d'eux meme 2 shilings pour leur propre idee.
kha
[^] # Re: mozilla-bonobo : intégrer les composants Gnome dans Mozilla
Posté par Jerome Herman . En réponse à la dépêche mozilla-bonobo : intégrer les composants Gnome dans Mozilla. Évalué à 1.
1) ca oblige a utiliser des API d'assez haut niveau (vu que X et gdi c'est quand meme tres different il faut rajouter une couche qui lie les deux) donc ca reporte le probleme sur "quelle api de haut niveau utiliser?" (WxWindows, Opengl, SDL,Gtk,QT ??) non parceque des gens qui codent en win32 et en xlib pure il y en a quand meme pas des masses.
2) Il s'agit juste de compiler derriere a la main (ou de faire un binaire de 8Go au choix). Et bon bien que j'aime beaucoup compiler mes propres binaires (j'utilise une Gentoo) je dois reconnaitre que l'idee de devoir recompiler des trucs comme OOo ca me casse prodigieusement les pieds.
3) Ca s'arrete generalement pas au define, les meccanismes d'evenements (et notamment les signaux) sont souvent tres different d'une API a l'autre donc des ifdef ils risquent d'y en avoir un paquet. Bonjour le boulot des developpeurs derriere.
Kha
[^] # Re: Moué...
Posté par Jerome Herman . En réponse au journal CD audio - protection contre la copie : la première fois ça fait mal. Évalué à 4.
Ben ce qui est surtout a hurler de rire c'est quand tu t'es paye il y a deux ans une platine lecteur CD a 5 000 francs avec des systemes anti saturations, correction d'erreur a la volee et extrapolation 48khz (le gros truc quoi) et que tout CD protege se fait jeter dessus. C'est ce qui est arrive a mon oncle il est fou de joie.
(N.B bien que sa platine de salon soit incapable de lire le cd, son PC n'a eu aucun mal a en extraire les pistes, il a refait tout le master a partir des .wav).
Kha
[^] # Re: Moué...
Posté par Jerome Herman . En réponse au journal CD audio - protection contre la copie : la première fois ça fait mal. Évalué à 2.
L'appel au boycott d'une marque est interdit, par contre l'appel au boycott d'un type de produit (ici les cds proteges) est parfaitement authorise. Sinon adieu adieu les manifs anti OGM, aurevoir les vegetariens fort en gueule etc.
Donc si tu te sens l'ame d'un contestataire de premiere ligne lache toi, personne ne pourras rien te dire.
Kha