Dans sa conclusion, elle montre que les marchés publics, de par leur encadrement très strict peuvent utiliser sans problème les logiciels libres du moment que les contrats sont passés en bonne forme. Les risques juridiques brandis par SCO ou Microsoft ne sont donc que des affabulations soigneusement entretenues par ceux que les logiciels libres dérangent.
En comparaison, l'insécurité juridique liée aux brevets logiciels ne relève pas du fantasme, Microsoft vient d'être confronté à cette dure réalité car il a été condamné à verser 1,5 milliard de dollars à Alcatel-Lucent pour violation de brevets concernant le format de compression mp3. Les brevets logiciels créent donc de l'insécurité juridique, pas les logiciels libres. La conférence de Marie José Palasz commence à la minute 55 de la partie 2 de la conférence Adèle.
Elle est précédée des conférences de Thierry Leblond qui expose la stratégie de migration du ministère de la défense puis de Guy Duplaquet qui explique qu'il suit la même démarche pour le compte du ministère de la justice.
# Insécurité juridique liée aux brevets logiciels
Posté par IsNotGood . Évalué à 2.
???
Je ne vois pas ce que vient foutre l'insécurité juridique dans cet exemple.
J'ai raté un épisode ?
Que veut dire "insécurité juridique" ?
[^] # Insécurité juridique liée aux brevets logiciels
Posté par robdeniro . Évalué à 5.
Insécurité juridique signifie : Risque important de contentieux , de procés , etc ....
Quand on utilise des logiciels libres (en Europe) -> Aucun risque de procés (ou trop peu pour qu'on en parle)
Quand on a à supporter les brevets logiciels - > N'importe quel code ou éditeur peut être attaqué (libre ou propriétaire)
[^] # Re: Insécurité juridique liée aux brevets logiciels
Posté par Nicolas Legrand (site web personnel) . Évalué à 2.
Le coup du brevet, c'est justement pour faire « Haha ! Regardez j'ai un bout de papier qui dit que c'est à moi, que c'est moi qu'ai inventé ! » Alors oui, dans les faits en cas de litige une fois sur deux le brevet est cassé, et qui plus est le brevet est mal adapté aux logiciels (selon moi). Mais faut s'arrêter là... Sinon on finira par entendre que les brevets donnent des boutons et diminuent la fertilitée des moutons...
Et franchement je trouve normal qu'en cas de litige sur du code ou n'importe quoi on puisse faire des procès. Sinon comment défendre les logiciels sous GPL ? Ça fait un peu genre « Allez-y ces pouilleux ont pas de quoi défendre leurs technos ou leurs licences ! Faites ce que vous voulez avec ! »
Enfin je grossis le trait bien sûr :-)
[^] # Re: Insécurité juridique liée aux brevets logiciels
Posté par Vador Dark (site web personnel) . Évalué à 10.
Avec les brevets sur les idées, on ne parle pas de quelqu'un qui a repompé un bout de code. On parle de quelqu'un qui a repompé une idée.
Exemple: tu as une superbe idée de tournure de phrase qui fait super bien, et que tu exploites sur cette phrase. Le droit d'auteur, ce sera le droit que tu aura sur cette phrase. Bon, heureusement qu'on ne peut interdire l'utilisation d'une phrase, mais c'est pour l'exemple. Le brevet te permettra de dire "l'idée de la tournure, c'est moi qui l'est trouvé, c'est à moi".
Les problèmes sont que:
->Lorsqu'on a une idée, aussi génial soit-elle, on réutilise des idées déjà existante. Pour ta tournure de phrase, tu réutilises le langage par exemple. Et c'est même pire que ça, car tu ne sais pas toujours ce que tu réutilises(tu peux très bien réutiliser la logique acquise par les mathématiques, même inconsciemment, ton idée peut aussi faire appelle à une "sous-idée" qu'un autre à eu avant toi, mais que tu as retrouvé). Ainsi, on fait comme des territoires sur la connaissance : ce bout là est à moi, celui-là aussi. Et donc il est impossible de créer de nouvelles idées sans réutiliser des idées appartenant à d'autres. Le problème est que tout le monde réutilisent des idées appartenant à d'autres, par conséquents tout le monde est attaquable. Il y a celui qui a lui aussi de nombreuses idées, et qui va pouvoir créer sans risquer d'être attaquer car tout le monde sait qu'il pourra attaquer en retour. On le voit : chaque fois qu'une boite A se fait attaquer par une boite B, elle annonce qu'elle va attaquer la boite B en retour pour les brevets que cette dernière viole. Microsoft l'a déjà fait avec Alcatel, Apple l'a également fait lorsque ça lui est arrivé. Il n'y a que la petite PME qui n'a pas les moyens de s'acheter de la connaissance qui ne pourra répliquer, et qui pourra sans crainte être attaquée.
->Ensuite, quand on créé des idées a partir des idées des autres, la moindre des choses, c'est quand même de laisser les autres recréer a partir de ses propres idées. Je ne crois pas que Microsoft est réinventés les mathématiques par exemple. Et les entreprises pharmaceutiques feraient-elles ce qu'elles font aujourd'hui si il n'y avait pas eu tout ce qui avait été découvert jusqu'à présent, et pas seulement par elle?
Einstein disait "le génie, c'est l'art de cacher ses sources". Cela montre qu'il avait bien compris, qu'aussi énorme soit ses découvertes, ça n'est finalement qu'une fine couche rajouté sur la connaissance existante. Il n'a pas réinventé l'addition pour cela. Et d'autres peuvent réutiliser ces créations pour encore faire progresser le monde. C'est comme ça que le monde avance.
Tout ça pour dire ce qu'on savait déjà, mais qu'il est important de comprendre:
->Les brevets sur les idées n'aident pas l'innovations. Ils servent uniquement à instaurer des monopoles.
->Le droit d'auteur n'EST PAS comparable aux brevets sur les idées. Le droit d'auteur concerne une réalisation, là où un brevet sur les idées concerne les idées qui la compose.
[^] # Re: Insécurité juridique liée aux brevets logiciels
Posté par Pol' uX (site web personnel) . Évalué à 5.
Vu qu'un brevet est forcément sur une idée, tu est donc contre les brevets (moi aussi). On brevette une méthode, et on dépose un modèle : les objets ne sont pas soumis aux brevets.
Peu importe, si neandertal avait breveté la hâche, on aurait l'air malin aujourd'hui ! Quoi que ... cro-magnon lui aurait peu être cassé la gueule !
La confusion sur le domaine de l'immatériel règne dans l'esprit de chacun, et l'expression "propriété intellectuelle" y est pour beaucoup (c'est d'ailleurs sûrement volontaire !). Pour clarifier ce point, je recommande la lecture de cet article, par RMS : http://www.gnu.org/philosophy/not-ipr.fr.html
Notons tout de même que j'ignore à quel point on peut transposer ses propos dans notre société française. Ces sujets sont à manipuler avec des pincettes.
Adhérer à l'April, ça vous tente ?
[^] # Re: Insécurité juridique liée aux brevets logiciels
Posté par Yth (Mastodon) . Évalué à 8.
Une méthode, ou un processus, c'est une série d'idées validées ou invalidées par des expérimentations, menant à un moyen physique d'obtenir un résultat donné avec un matériel donné.
Par exemple, pour avoir de l'eau salée, tu prends de l'eau et tu mets du sel dedans, c'est une méthode, et pour en arriver là tu as pu expérimenter qu'en mettant du sucre, ben t'avais de l'eau sucrée, et que donc ce n'était pas ce que tu voulais, et tu as validé le fait qu'en mettant du sel dans ton eau tu obtenais de l'eau salée.
Ici c'est trivial et donc non brevetable, mais si ça l'était, ni l'« idée » de mettre des produits, en particulier le sel, dans l'eau, ni celui d'avoir de l'eau salée, ne sont brevetable, seul le processus original de mettre du sel dans l'eau pour obtenir de l'eau salée est breveté.
Un autre peut très bien obtenir lui aussi de l'eau salée, par exemple simplement en allant la pomper dans la mer, et ton brevet sur l'eau salée ne l'empêchera pas lui d'en avoir un aussi sur l'eau salée, puisque les processus de fabrication sont différents, et que ce sont ces derniers qui sont brevetables.
Le brevet logiciel c'est sans même avoir de processus pour obtenir de l'eau salée, de dire « eh mais on pourrait avoir de l'eau salée ! C'est mon idée, je la brevette », ce qui est fondamentalement débile...
Un peu comme de breveter le double-clic, ou les liens hypertexte...
Tu vois, avec notre système de brevets, l'homme de néandertal ne pouvait pas breveter la hache, mais juste un moyen d'en fabriquer une. Et cro-magnon pouvais toujours en faire une d'une autre manière (ce qu'il a probablement fait, parce que des manières de fabriquer une hache, il a dû y en avoir des centaines au moins dans l'histoire humaine).
Yth.
[^] # Re: Insécurité juridique liée aux brevets logiciels
Posté par Pol' uX (site web personnel) . Évalué à 5.
Ça montre au moins qu'il n'y a pas que dans le cas du logiciel que les brevets posent problème, que les offices de brevets méritent une bonne restructuration en profondeur, et après ça, je pense que je resterai tout de même opposé au brevets.
Adhérer à l'April, ça vous tente ?
[^] # Re: Insécurité juridique liée aux brevets logiciels
Posté par Vador Dark (site web personnel) . Évalué à 1.
[^] # Re: Insécurité juridique liée aux brevets logiciels
Posté par IsNotGood . Évalué à 4.
La méthode en logiciel c'est le code source. Le code source est déjà protégé par le droit d'auteur. D'ailleurs le droit d'auteur protège plus longtemps que les brevets.
Faire les brevets logiciels sur les méthodes n'a pas de sens. C'est déjà protégé par le droit d'auteur.
> Ça montre au moins qu'il n'y a pas que dans le cas du logiciel que les brevets posent problème
Il ne pose pas de problème dans l'industrie (où on ne brevette que des moyens pour obtenir une fonctionnalité et jamais la fonctionnalité).
Il y a deux domaines ou les brevets tels qu'ils sont appliqués posent problème :
- Le logiciel (car on brevete une idée)
- La chimie/medecine quand on brevete une molécule. Une molécule est une invention ou une découverte (comme on découvre une étoile). Ainsi des molécules qu'on trouve dans la nature ont été breveté (ce qui est une abhération complète). On a ici un cas rare où un brevet a été annulé en justice (la boite avait obtenu un brevet pour une molécule qu'on trouve dans la nature). Notons qu'ici il y a une insécurité juridique, puisque le brevet a été annulé, mais on ne va pas s'en plaindre.
[^] # Re: Insécurité juridique liée aux brevets logiciels
Posté par Jimmy . Évalué à 4.
On liste généralement 3 conditions :
- nouveauté
- inventivité
- application industrielle
(plus de détails ici : http://fr.wikipedia.org/wiki/Brevet#Droit )
Effectivement, on ne peut (si tout se passe normalement) breveter que des procédés, pas les idées sous-jacentes. En effet, une idée est une pure oeuvre de l'esprit et n'a pas d'application industrielle directe, seule l'implémentation de l'idée en a. Et il est heureux qu'une autre implémentation de la même idée, qui serait nouvelle, inventive et applicable industriellement soit également récompensée par un avantage concurrentiel provisoire* : ca s'appelle encourager le progrès, et c'est à ca que servent les brevets.
Si on autorise les brevets logiciels, on se retrouve avec une démarche bancale dans tous les cas. Supposons un logiciel proposant une fonctionnalité inédite, astucieuse (même pour un spécialiste) et répondant à une large demande :
- Breveter l'implémentation, ca implique de publier le code source dans le texte du brevet, puisque le logiciel n'est "que" l'expression d'idées dans un langage (informatique). Du coup, il est facile de refaire une implémentation différente, par exemple dans un autre langage, et de contourner ainsi le brevet. On se retrouve tenté d'"obfusquer" le code, ce qui ruine la démarche ...
- Breveter l'implémentation sans la divulguer, ca revient à breveter une boîte noire. C'est contraire à l'idée de capitalisation de la connaissance du système de brevet, qui lutte justement contre le secret, et ca ne permet pas de valider la condition d'inventivité (et parfois celle d'applicabilité). Comment faire valoir un droit sur quelquechose de confidentiel ? Toute ressemblance avec le mécanisme de droit d'auteur et avec l'actualité récente ( http://linuxfr.org/2007/02/28/22134.html ) n'est pas fortuite.
- Breveter l'idée, cela va encore plus loin : même plus besoin de faire une implémentation et de la garder secrète ! Il suffit d'imaginer quelquechose, même si c'est est inapplicable dans l'état de la technique, même si il est trivial, de le décrire en termes suffisamment vagues, et d'attendre. Avec un peu d'habileté rhétorique, ca n'a même pas besoin d'être nouveau. Le premier que se risque à implémenter quelquechose de ressemblant devient une proie juridique facile. C'est un comportement de parasite. Mais le plus grave, c'est que ca verrouille une branche du progrès, un domaine où aucune amélioration n'est possible car la moindre implémentation tombe sous le coup d'un monopole conceptuel.
Allez, un exemple loufoque pour la forme : J'ai rêvé ce matin qu'il serait hyper kewl de faire un logiciel pour prédire l'avenir. C'est nouveau, personne n'a écrit de tel logiciel avant. C'est inventif (enfin, ca se serait si j'avais une idée de comment faire), car ce n'est absolument pas trivial pour l'homme du métier. Et ca aurait sûrement un succès fou si c'était réalisable. Je dépose donc un brevet sur l'idée d'un médium numérique, en brodant 10 pages sur l'idée qui tient dans cet unique paragraphe. Et je vais aussitôt coller des procès à tous les astrologues, devins, marabouts, analystes financiers et météorologues qui ont l'outrecuidance d'utiliser un ordinateur pour exercer leur art divinatoire, au mépris de ma propriété intellectuelle (toute neuve). Et si dans 10 ans un génie trouve un moyen de réellement faire un logiciel pour voir le futur, je pourrai l'empêcher d'exploiter commercialement son implémentation concrète de mon idée abstraite.
Tout ca pour dire qu'un logiciel, c'est couvert par le droit d'auteur, point barre. Tout le reste ne tient pas debout.
* l'étalonnage du terme "provisoire" est également un sujet épineux ...
[^] # Re: Insécurité juridique liée aux brevets logiciels
Posté par Thomas Douillard . Évalué à 2.
Une méthode de résolution de problème, un algorithme, un peu complexe, ça correspond à ta définition. Genre une méthode pour résoudre efficacement des systèmes d'équations non linéaires un peu complexes, ou à optimiser, ou avec des contraintes quantifiées, c'est une série d'idées validées ou invalidées par des expérimentations, le tout n'étant pas trivial à trouver ni forcément à implémenter.
Et je ne pense pas qu'on puisse breveter le 'eh mais on pourrait résoudre des équations !'
[^] # Re: Insécurité juridique liée aux brevets logiciels
Posté par Vador Dark (site web personnel) . Évalué à 3.
[^] # Re: Insécurité juridique liée aux brevets logiciels
Posté par Dr BG (site web personnel) . Évalué à 3.
[^] # Re: Insécurité juridique liée aux brevets logiciels
Posté par Christophe Duparquet (site web personnel) . Évalué à 3.
Breveter une méthode, ce qui me semble bien relever de l'idée, c'est se l'approprier et donc déclarer que personne d'autre n'a plus le droit d'avoir la même idée et de la mettre en oeuvre. Ça me dérange.
« J'ai pas Word, j'ai pas Windows, et j'ai pas la télé ! »
[^] # Re: Insécurité juridique liée aux brevets logiciels
Posté par Nicolas Legrand (site web personnel) . Évalué à 3.
Ce que je voulais dire, c'est que toute forme de propriété intellectuelle (c'est-à-dire pas que le droit d'auteur) est susceptible d'être utilisée pour attaquer et défendre un projet.
En fait ce qui est intéressant c'est que le brevet a été fait pour alléger ou simplifier les procédures judiciaires et que aujourd'hui ça les alourdit et d'autant plus que l'on brevette n'importe quoi même les idées. Donc oui, on a sans doute moins de procès avec moins de brevets, ce qui n'empêche pas la possibilité de procès entre deux programmes non brevetés par exemple...
Dans le commentaire auquel je répondais on avais presque l'impression qu'être contre les brevets et d'utiliser les logiciels libres protégeaient des procès. Ce que je trouvais curieux et ceux à quoi je répondais...
C'est _tout_ ce que je voulais dire, ça ne méritait pas deux tonnes de commentaire où tu ne m'a rien appris et qui n'a rien à voir avec ce que je disais... Je suis assez fasciné devant le plussage excessif (que je ne te reproche pas), j'ai dû soit très mal m'exprimer, soit le discours classique entendue mille fois et le crachat systématique ou « c'est mal tu vois » proche du mot « brevet » donne envie à notre communauté d'applaudir hystériquement et de huer ceux qui ne font pas de même...
[^] # Re: Insécurité juridique liée aux brevets logiciels
Posté par Earered . Évalué à 7.
Propriété intellectuelle[1] != Intelectual Property[2]
En France (aucune idées pour le Canada, la Belgique et les autres pays francophone), la prorpiété intellectuelle ne couvre que le droit d'auteur et les droits voisins. Elle ne couvre que les spécificité d'expression d'une oeuvre :
-les recettes et règles de jeux ne sont pas protégés (concept, idées, formules)
-le texte d'un livres de recettes, d'un livres de jeu de rôles, ou une interprétation musicales sont protégés par le droit d'auteurs
Les brevets, design, et marques sont couverts par la propriété industrielle[3]
Maintenant, pour le risque juridique.
Aux dernières nouvelles, dans nos sociétés, un délit intentionnel est plus rare qu'un délit involontaire.
Propriété intellectuelle -> copie involontaire improbable, risque de délit intentionnel (plagiat délibéré)
Brevet -> implémentation concurente similaire involontaire probable (gutenberg, chine, impression, toussa) risque de délit involontaire.
D'ou risque du domaine de la propriété intellectuelle < risque du domaine des brevets.
[1] http://www.legifrance.gouv.fr/WAspad/UnCode?code=CPROINTL.rc(...)
[2] http://www.wipo.int/portal/index.html
[3] http://www.inpi.fr/
N.B.
Business Intelligence != Intelligence économique
Intellectual property != Propriété intellectuel
Business intelligence ~= Renseignement économique
Intellectual property ~= Propriété immatérielle (par opposition à physical property).
T'es pas le premier, ni le dernier (ni le seul, je suis là aussi ^_^) a te faire avoir par les mélanges d'angliscisme et faux amis anglais (et ceux sur intelligence sont particulièrement vicieux, surtout que même nos amis anglais oublie aussi parfois eux même le sens de leur mots, cf business intelligence...).
[^] # Re: Insécurité juridique liée aux brevets logiciels
Posté par Nicolas Legrand (site web personnel) . Évalué à 1.
[^] # Re: Insécurité juridique liée aux brevets logiciels
Posté par Picachou . Évalué à 3.
Heu... pour moi un brevet ça porte sur un procédé industriel, et c'est de la propriété industrielle (en tout cas en France).
D'ailleurs certains proposent qu'on limite le champ de la brevetabilité à des "procédés qui mettent en oeuvre les forces de la nature" ; ça me semblerait cohérent.
AMHA, pour te répondre sur le rapport entre les brevets et les procès, le problème est qu'on multiplie les brevets triviaux et non pertinents (dans tous les domaines) tout simplement parce qu'on mesure l'activité d'innovation de nos laboratoires au nombre de brevets qu'ils déposent selon le principe "plus de brevets = plus d'innovation", ce qui est d'autant plus débile que lesdits brevets ne sont jamais mis en oeuvre.
On est donc loin de l'objectif initial du brevet qui est de favoriser l'innovation en offrant une protection juridique et une exclusivité au déposant, afin qu'il exploite le procédé industriel et puisse le rentabiliser avantageusement pendant la durée du brevet.
L'abus de brevets aboutit donc forcément à des conflits de propriété industrielle, où sont avantagés les plus gros qui ont les moyens de déposer des brevets inutiles et inutilisés, et de les revendiquer lorsque l'occasion se présente - alors que les petits n'ont même pas toujours les moyens de déposer un simple brevets national.
[^] # Re: Insécurité juridique liée aux brevets logiciels
Posté par Christophe Duparquet (site web personnel) . Évalué à 3.
J'aurais plutôt dit «les moyens de payer pour garder le droit d'exploiter ses propres connaissances». Ce qui est un comble !
« J'ai pas Word, j'ai pas Windows, et j'ai pas la télé ! »
[^] # Re: Insécurité juridique liée aux brevets logiciels
Posté par IsNotGood . Évalué à -1.
L'homicide présente alors une insécurité juridique ?
[^] # Re: Insécurité juridique liée aux brevets logiciels
Posté par robdeniro . Évalué à 3.
[^] # Re: Insécurité juridique liée aux brevets logiciels
Posté par Yth (Mastodon) . Évalué à 3.
C'est salement peu tranquille, juridiquement, de tuer des gens, entre autres soucis divers...
Yth.
[^] # Re: Insécurité juridique liée aux brevets logiciels
Posté par IsNotGood . Évalué à -1.
C'est bien qu'il ait une "insécurité juridique" pour les homicides ou c'est mal ?
D'ailleurs, il y a-t'il une "insécurité juridique" pour les homicides ?
Si oui, c'est bien ou c'est mal de la retrouver dans les brevets logiciels ?
Si non, alors pourquoi il y a une "insécurité juridique" avec les brevets logiciels ?
Qu'es-ce qu'il y a de spécifique, juridiquement parlant, dans les lois liées aux brevets logiciels qui crée une "insécurité juridique" ?
Je suis contre les brevets logiciels, ça ne fait pas l'ombre d'un doute. Mais ce n'est pas parce que je suis contre les brevets logiciels que je vais dire, pour ne pas dire inventer, que les brevets logiciels créent une insécurité juridique. Les brevets logiciels mettent les PME (et pas seulement elles) dans l'insécurité, j'en suis convaincu. Mais pas dans l'insécurité juridique. Les textes de lois sont claires, si tu violes un brevet, c'est panpancucu.
D'ailleurs, ne serait-il pas mieux pour le logiciel libre qu'il y ait une insécurité juridique ?
Je pense que oui. Donc pourquoi s'en plaindre ?
Le problème des brevets logiciels est d'autant plus grave qu'il n'y a pas d'insécurité juridique (comme pour les homicides).
A-t-on vu une fois un tribunal ne pas mettre de peine à une boite qui viole des brevets ? Je ne crois pas.
[^] # Re: Insécurité juridique liée aux brevets logiciels
Posté par Nelis (site web personnel) . Évalué à 3.
Par exemple le lien hypertexte ... Ce qui fait qu'en informatique, on se retrouve avec une tonne de brevets super vague, représentant juste une idée mais pas une méthode précise, qui fait qu'en écrivant n'importe quel bout de code, tu es presque sur de violer 10 brevets.
Alors maintenant, effectivement la société ayant un brevet foireux peut perdre son procès, mais qui a les reins assez solide pour supporter un tel procès, même si au final on peut le gagner ?
Même MS qui avait pourtant payé une licence pour utiliser les MP3 s'est retrouvé attaqué pour violation d'un autre brevet. D'où le terme insécurité juridique.
[^] # Re: Insécurité juridique liée aux brevets logiciels
Posté par IsNotGood . Évalué à 2.
Le problème c'est les brevets logiciels. C'est le principe de breveter une idée qui est mauvais. Ce principe était mauvais/néfaste, qu'il y ait ou non une "insécurité juridique" ne change pas grand chose.
Tu préfères les brevets logiciels (le principe de breveter une idée) sans insécurité juridique ?
Moi, je ne suis pas convaincu.
> Même MS qui avait pourtant payé une licence pour utiliser les MP3 s'est retrouvé attaqué pour violation d'un autre brevet.
Ça c'est ce que dit MS. Les juristes ne sont pas des abrutis. Et si MS c'est pris une amende dans la gueule, c'est bien que MS n'avait pas acquité les droits mp3.
Si ce n'est pas le cas, je conseille à Alcatel-Lucent de faire un nouveau procès pour décrocher encore le jackpot. D'ailleurs ils pourraient plannifier d'en faire un par mois (ça permet à MS de mettre de l'argent de côté).
[^] # Re: Insécurité juridique liée aux brevets logiciels
Posté par Nelis (site web personnel) . Évalué à 3.
Les brevets logiciels créent de facto une insécurité juridique (ie personne n'est à l'abris d'un procès) car ils brevètent des idées.
Les brevets logiciels sont donc à éviter.
[^] # Re: Insécurité juridique liée aux brevets logiciels
Posté par IsNotGood . Évalué à 2.
Formulé comme ça pourquoi pas. Tout développeur peut coder une idée sans se rendre compte qu'elle fait l'objet d'un brevet. Les petites boites n'ont pas les moyens de vérifier ça.
Mais ta formulation ne colle pas au cas MS/Alcatel. MS sait que mp3 est breveté.
[^] # Re: Insécurité juridique liée aux brevets logiciels
Posté par maximegb . Évalué à 4.
Les brevets logiciels créent donc de l'insécurité juridique...
Ca ok on le savait déjà, on ne peut pas savoir quand on écrit un logiciel, libre ou non, si on enfreint un brevet logiciel.
... pas les logiciels libres.
Ni plus ni moins que les logiciels propriétaires. Puisque ce sont les brevets logiciels qui créent l'insécurité, pas les logiciels.
Je peux déposer un brevet logiciel, puis diffuser du code sous une license libre qui applique ce brevet. Mon brevet sera source d'insécurité juridique, quoique dise la license libre que j'aurai choisi.
[^] # Re: Insécurité juridique liée aux brevets logiciels
Posté par wistiti68 . Évalué à 7.
Si j'ai bein compris l'article (j'ai pas encore regadrer la vidéo), au début la question était si les logiciels libre était source d'insécurité, thèse entretenu par MS et SCO. Marie José Palasz a agumenté et démoli ce préjugé.
puis elle a réorienté le débat sur les brevet logiciels, en démontrant que eux sont effectivement source d'insécurité (quelque soit la licence du logiciel)
A la fin elle conclu sur les deux axes de son discour: d'un coté les BL sont sources d'insécurité juridique, de l'autre les LL ne le sont pas.
[^] # Re: Insécurité juridique liée aux brevets logiciels
Posté par wistiti68 . Évalué à 4.
De plus ça entraine une insécurité des clients. Là c'est MS donc ça va, mais si ça aurait été une petite PME, elle aurait mit les clefs sous la porte et les client se serait retrouvé sans support technique.
Au fait, avec 1,5 milliard d'euros, Alcatel-Lucent compte toujours licencier du personnel? Ca permet de financer pas mal d'emploi pendant un paquet d'année tout cet argent.
Ouai ouai j'oubliais, faut d'abord rémunéré les actionnaire. C'est vrai que ça coûte chère ça aussi....
[^] # Re: Insécurité juridique liée aux brevets logiciels
Posté par Nicolas Schoonbroodt . Évalué à 3.
[^] # Re: Insécurité juridique liée aux brevets logiciels
Posté par IsNotGood . Évalué à 2.
Désolé, mais ça n'a aucun sens. Toute lois crée alors de l'insécurité juridique car avec toute lois tu risque de te faire attaqué en justice à tout moment.
L'insécurité juridique peut-être par exemple lorsque la justice n'a pas statué sur un cas. Par exemple avec la GPL il y avait une insécurité juridique car on ne savait pas comme la GPL pouvait être interprété par la justice (le débat est maintenant fermé je crois). Ça c'est de l'insécurité juridique. Du moins c'est comme ça que je le comprend. Par contre ne pas aquiter les droits d'utilisation d'un brevet ne présente pas d'insécurité jurique. Dans ce cas tu sais que "tu vas t'en prendre plein la gueule et le plaignant plein les fouilles".
[^] # Re: Insécurité juridique liée aux brevets logiciels
Posté par Picachou . Évalué à 3.
Typiquement, la loi DADVSI (exemple devenu si banal...) est génératrice d'insécurité juridique - entre autres - pour les logiciels P2P puisqu'il est précisé à l'article 21 (article L.335-2-1 du code de la propriété intellectuelle - voir sur Légifrance)
Or on ne sait pas ce qu'est un "logiciel manifestement destiné...", on sait juste que potentiellement ça vise les logiciels P2P puisque c'est l'intention affichée de ceux qui ont défendu cet article.
Il y a donc une insécurité juridique autour des logiciels P2P. Seule une jurisprudence pourra nous en dire plus sur la portée de cet article.
[^] # Re: Insécurité juridique liée aux brevets logiciels
Posté par Pierre Jarillon (site web personnel) . Évalué à 8.
Dans cette affaire, les seuls gagnants sont les juristes. Je disais un jour à l'un d'eux que leur fond de commerce se résumait à : Payez-moi, je vous protègerai. Mais de qui ? De vous et de vos semblables. C'est exactement ce que faisait Al Capone et on appelle ça du racket et c'est une pratique mafieuse.
On voit donc que payer n'a pas suffit dans cette affaire. Il y a bien insécurité juridique car les deux entreprises se sont lancées dans des procédures qui risquent de durer très longtemps et de leur coûter très cher. Les gagnants seront leurs avocats, eux, il gagnent à tous les coups.
[^] # Re: Insécurité juridique liée aux brevets logiciels
Posté par wistiti68 . Évalué à -1.
Ça n'a rien à voire. Ici ça s'appel de la protection intellectuelle et c'est une pratique capitaliste.
Qu'est ce qu'il t'avasi répondu ton juriste?
[^] # Re: Insécurité juridique liée aux brevets logiciels
Posté par maximegb . Évalué à 1.
Une pratique du capitalisme ou une dérive de certains capitalistes qui ont fait voter les lois permettant ce type de dérive ?
les seuls gagnants sont les juristes
Et les intermédiaires financiers qui savent gérer ces incertitudes pour en tirer profit, quelque soit le gagnant du moment.
[^] # Re: Insécurité juridique liée aux brevets logiciels
Posté par Nelis (site web personnel) . Évalué à 4.
Donc ici, cet argument est démonté. D'autant plus que Microsoft lui même souffre de cette insécurité juridique (créer par les brevets logociels).
[^] # Re: Insécurité juridique liée aux brevets logiciels
Posté par palm123 (site web personnel) . Évalué à 1.
J'avais lu qu'Ibm gagnait plus de sous avec ses brevets + procès qu'en faisant son métier de services/vendeur en informatique.
A confirmer.
J'aurais du breveter "access violation" dans les programmes DOS
:-)
ウィズコロナ
[^] # Re: Insécurité juridique liée aux brevets logiciels
Posté par IsNotGood . Évalué à 2.
> Pour rappel, des boites comme SCO ou MS mettent en garde les organismes publics voulant passer à Linux contre une prétendue insécurité juridique des logiciels libres (Attention, ils violent des brevets et bla bla bla).
Oublions le "insécurité juridique" qui est utilisé à toutes les sauces.
http://showusthecode.com/
Une lois néfaste dans son principe (comme c'est le cas pour les brevets logiciels je pense) est une lois néfaste. Si elle a des points qui crée une "insécurité juridique" alors elle doit être corrigée (c'est le boulot des juristes/législateurs). Et si elle est corrigée, ça reste toujours une lois néfaste car son principe est néfaste (ici reconnaitre qu'une idée est brevetable).
Donc à quoi ça sert de souligner ou s'en prendre à une supposée "insécurité juridique" des brevets logiciels ? Si cette "insécurité juridique" est virée, les brevets logiciels restent toujours néfastes.
Je me trompe ?
[^] # Re: Insécurité juridique liée aux brevets logiciels
Posté par robdeniro . Évalué à 3.
Oui , avec ou sans justice , les brevets sont néfastes mais si il n'y a pas de justice ,
tout le monde peut enfreindre les brevets sans aucun riques .
Brevets et justice vont de paire .. Les (grosses) boites déposent des brevets car elles pensent qu'elles pourront les défendre devant un tribunal . C'est pour ça que les petites boites déposent peu de brevets en général . Déposer un brevet coute cher mais un procés pour défendre ce brevet coute encore plus cher .
D'ailleurs , le plus souvent , ce n'est pas le brevet lui même qui fait basculer le procès mais la manière dont il est défendu .
C'est pour ça que certains brevets (techniques) sont achetés par des boites de juristes et d' avocats car ils pensent faire plus de blé sur leur propre prestation de plaidoierie en face des avocats des vrais industriels que sur l'exploitation même de ces brevets .
Les brevets deviennent même une monaie d'échange entre les grosses boites plutôt que des devises qui sont contrôlées et taxées. Et ces portefeuils de brevets ne sont pas à la portée des PME .
# Les brevets logiciels c'est bon mangez-en
Posté par fredix . Évalué à 5.
[^] # Re: Les brevets logiciels c'est bon mangez-en
Posté par Pierre Jarillon (site web personnel) . Évalué à 3.
[^] # Re: Les brevets logiciels c'est bon mangez-en
Posté par BAud (site web personnel) . Évalué à 2.
# Ça me laisse perplexe...
Posté par Frédéric Lopez . Évalué à -1.
Ça me paraît quand même un peu contradictoire...
Sans compter qu'il est également dit qu'on ne peut pas lancer un marché public concernant l'acquisition d'un logiciel libre, puisque les contrats sont conclus uniquement à titre onéreux. Comment pourrait-on alors exiger un logiciel libre ?
En passant par un marché de service plutôt qu'un marché de fourniture ?
Mais dans ce cas, ça écarte de fait les logiciels propriétaires puisque leur coût est généralement beaucoup plus élevé que celui des prestations associées, et que dès lors on ne peut pas les faire passer par des marchés de service. Ça me semble être en totale contradiction avec le principe d'équité du code des marchés publics.
¹ http://www.marche-public.fr/CMP-2006/Specifications-techniqu(...)
[^] # Re: Ça me laisse perplexe...
Posté par Sylvain Sauvage . Évalué à 4.
– s'il est déjà développé, tu paies pour une licence, pour des droits ;
– s'il n'est pas développé, tu paies le développement d'abord puis tu te retrouves au cas précédent, et le développement est un service.
[^] # Re: Ça me laisse perplexe...
Posté par Frédéric Lopez . Évalué à 2.
http://www.marche-public.fr/Marches-publics/Definitions/Entr(...)
[^] # Re: Ça me laisse perplexe...
Posté par Sylvain Sauvage . Évalué à 3.
Je dis qu'un logiciel, qu'il soit ou non déjà développé, est un service.
Ton propos était qu'il s'agissait d'un marché de fournitures.
Or ta citation me dit ce qu'est un marché public de services : ce n'est pas un marché de travaux ni un marché de fournitures, et le lien que tu donnes ne donne pas plus précision : p.ex. quels sont les services visés à cette annexe II ?
En quoi l'achat de licences de logiciels serait-il un achat de fournitures ?
Je ne dis pas que tu as tort. D'ailleurs, ce ne serait pas la première fois que l'on verrait des règles contradictoires entre elles. Je dis juste que tes arguments sont hors propos.
[^] # Re: Ça me laisse perplexe...
Posté par Frédéric Lopez . Évalué à 1.
http://www.marche-public.fr/Marches-publics/Definitions/Entr(...)
http://www.marche-public.fr/Marches-publics/Definitions/Entr(...)
Les termes utilisés dans les CCAGs (cahiers des clauses administratives générales) sont différents de ceux du Code des Marchés Publics 2006, mais la distinction entre développement spécifique et achat de logiciel existe bel et bien. Il faut dire que les CCAG datent des années soixante-dix, ils sont d'ailleurs actuellement en cours de refonte.
Il est possible de consulter les sites des acheteurs publics (collectivités locales et territoriales, administrations) et les plates-formes de marchés publics sur le Web pour constater que cette distinction est bien respectée.
[^] # Re: Ça me laisse perplexe...
Posté par Sylvain Sauvage . Évalué à 3.
C'est justement là que pour moi ce n'est pas évident : le logiciel n'est pas un produit dans le sens de « produit fini », « bien meuble », c'est un service. En compta, vendre une licence est classé dans la vente/prestation de services, pas dans la vente de produits (finis).
Et en fait, la qualification de fournitures s'applique ici aux logiciels « de l'étagère », dont le côté services disparaît devant l'aspect produit de masse. Mais où se place le curseur ? Quand est-ce que la configuration, l'installation d'un logiciel devient « sur mesure » (pour reprendre le terme utilisé pour les formations qui, finalement, sont dans le même cas) ?
[^] # Re: Ça me laisse perplexe...
Posté par Pierre Jarillon (site web personnel) . Évalué à 4.
Avec les logiciels du commerce, on paie pour un droit d'usage (la licence) et non pour un achat. Il n'y a pas de transfert de propriété, ce n'est donc pas un achat.
Si ce n'est pas un achat, c'est donc un service car je ne vois pas d'autre alternative.
Dans le cas des logiciels libres, il n'y a pas d'ambiguité.
[^] # Re: Ça me laisse perplexe...
Posté par jarodender . Évalué à 0.
C'est au contraire très équitable puisque le but c'est bien de prendre le moins cher, peu importe la manière.
D'autre part il n'est pas si certain que la maintenance d'un logiciel libre soit moins chère que celle d'un logiciel propriétaire, je pense même que c'est le contraire, car une boite proprio a déjà une forte expérience de maintenance dans son produit contrairement au libre.
D'ailleurs c'est l'un des points faibles du libre :c'est de ne pas avoir assez de propositions complètes de service, je ne dis pas que ça n'existe pas, mais que cela est souvent onéreux. Je pense que plus les logiciels libres entreront dans le monde de l'entreprise et des services publics, meilleur et moins cher sera le support. De plus le développement et la qualité des logiciels seront alors très vite en adéquation avec les demandes du marché, ce qui n'est pas encore le cas pour beaucoup de produits libres.
[^] # Re: Ça me laisse perplexe...
Posté par Frédéric Lopez . Évalué à 2.
Le but des marchés publics n'est absolument pas de prendre le moins cher, c'est de prendre le mieux disant dans le respect de l'équité pour les fournisseurs.
Si le but était de prendre le moins cher, il faudrait complètement réformer le Code des Marchés Publics, parce que dans la pratique ça coûte plus cher de passer par lui.
Les entreprises ne sont pas idiotes, elles connaissent les seuils à ne pas dépasser pour les marchés et elles connaissent aussi les pratiques de leurs concurrents. Il y a même assez souvent suspicion d'entente entre fournisseurs sur les offres sans que personne ne puisse rien y faire.
Ce point de vue d'un ancien ministre délégué au budget résume assez bien la situation à mon avis :
http://www.alain-lambert-blog.org/index.php?2006/08/06/612-n(...)
La part dédiée à la maintenance dans les logiciels propriétaires tourne généralement autour des 15% à + ou - 5%. Ce que je voulais dire dans mon message précédent, c'est que ce montant est largement inférieur au coût d'acquisition du logiciel et que de fait, un logiciel propriétaire ne peut pas être acheté via un marché de service si ce n'est pas un développement spécifique.
Et dans le cadre d'un marché de service, la disparité de coût entre un développement spécifique et l'utilisation d'un logiciel libre rompt complètement le principe d'équité du CMP.
Mon but n'est pas de dire qu'il ne faudrait pas favoriser les LL dans le cadre des marchés publics, je me réjouirais que ce soit possible, mais seulement qu'en l'état, ça me semble incompatible avec les principes définis dans le Code des Marchés Publics.
[^] # Re: Ça me laisse perplexe...
Posté par maat (site web personnel) . Évalué à 5.
Ben... faut juste savoir lire et faire l'effort de comprendre le texte de la GPL... ou à défaut, pour se faire une bonne idée du truc, de lire la licence CECILL (http://www.cecill.info/licences/Licence_CeCILL_V1-fr.html ) conçue pour être une licence valide en droit français et compatible avec la GPL.
Extrait de la licence CECILL :
Les logiciels libres n'imposent pas la gratuité... ça ne sera que la cent dix millionième fois que quelqu'un reproduit cet amalgame vaseux consistant à assimiler libre et gratuit alors que ça n'a rien à voir.
Quand à ça :
Le fait qu'un logiciel soit libre ne présume en rien de son mode de fabrication, de sa marque, ou de son origine... en revanche c'est une caractéristique technique (accès libre au code) et juridique (droit modification et de rediffusion) qui peut entrer de plein droit dans une spécification de besoin ou un cahier des charges (ianal ceci dit).
[^] # Re: Ça me laisse perplexe...
Posté par Frédéric Lopez . Évalué à 1.
Je ne t'ai pas attendu pour lire et comprendre la GPL, j'utilise Linux professionnelement et personnellement depuis 10 ans, alors tu peux t'abstenir de ce genre de remarques désagréables. Merci.
Comme l'explique si justement l'article associé à cette dépêche, il n'y a pas de problème de validité de la GPL en France puisque c'est le contrat entre les parties qui s'applique et qui doit être conforme au droit Français, en l'absence de mentions particulières dans la licence. Cet article vient de confirmer, s'il était besoin, que ce n'était pas la peine de créer une énième licence libre...
[^] # Re: Ça me laisse perplexe...
Posté par Frédéric Lopez . Évalué à 1.
Effectivement, je n'avais pas imaginé qu'un fournisseur ose proposer un logiciel libre avec un coût d'acquisition non nul dans le cadre d'un marché de fourniture. Pourquoi pas...
Enfin dans ce cas, n'importe quel autre fournisseur pourrait fournir le même logiciel un petit peu moins cher et emporter le marché.
Et conformément au Code des Marchés Publics, si ce logiciel est proposé à moins de 4000 ¤, l'acheteur n'est même pas obligé de passer par un marché public. Quel serait alors l'intérêt de proposer un logiciel libre dans le cadre d'un marché public ?
Le fait qu'un logiciel soit libre n'est pas une caractéristique technique du produit, c'est une caractéristique de la licence, donc juridique comme tu le dis.
Et pour la partie technique, on peut effectivement demander que le fournisseur donne accès aux sources pour permettre la maintenance en interne. Mais je ne vois pas ce qui pourrait justifier d'exiger un code source redistribuable (donc sous licence libre) dans le cadre des besoins techniques d'une collectivité.
Dans l'article présenté dans la dépêche, rien de ce qui est cité ne me semble aller dans ce sens (choix technologiques antérieurs, respect de normes et standards, maîtrise, indépendance, pérennité). Une licence non libre de type Shared Source pourrait aussi bien convenir dans ce cadre...
[^] # Re: Ça me laisse perplexe...
Posté par Picachou . Évalué à 1.
Toutefois, le champ des critères d'appréciation est assez large puisqu'il faut prendre en compte à la fois la compétence (mais c'est assez flou, je te l'accorde bien volontiers), l'assise financière, et la conformité au cahier des charges.
Enfin bref si tu as deux SSII de référence qui te proposent la même chose, il faut prendre la moins chère des deux.
Ben oui, sauf qu'en général on ne vend pas juste un logiciel, on vend aussi l'intégration, la formation et plus globalement tout ce qui va autour du logiciel. C'est pour ça qu'il existe des marchés publics logiciel libre.
Sinon, effectivement, s'il n'y a pas de prestation je ne vois pas l'intérêt d'un marché public pour acquérir un logiciel standard, quelle que soit sa licence...
[^] # Re: Ça me laisse perplexe...
Posté par Hrundi V. Bakshi . Évalué à 4.
Et donc parfaitement compatible avec des spécifications de cahier des charges
[^] # Re: Ça me laisse perplexe...
Posté par Frédéric Lopez . Évalué à 1.
C'est typiquement ce qui est indiqué par « faire mention d'un mode ou procédé de fabrication particulier ou d'une provenance ou origine déterminée ».
Ça n'a donc normalement rien à faire dans des spécifications techniques.
[^] # Re: Ça me laisse perplexe...
Posté par Guillaume Rossignol . Évalué à 2.
Fondamentalement, lorsqu'un client veut du logiciel libre, il ne s'interresse pas à la facon dont le logiciel à été ecrit ni d'où il vient mais de ce qu'il peut faire avec... par exemple modifier son fonctionnement "à la source" tout comme il pourrait demander à ce que les chiffres negatif apparraissent en rouge (superbe specificité technique non ? ^ ^ )
[^] # Re: Ça me laisse perplexe...
Posté par Frédéric Lopez . Évalué à 2.
Si, mais seulement dans le cadre des besoins du pouvoir adjudicateur (une commune par exemple). Et je ne vois pas en quoi le fait de pouvoir redistribuer le code est nécessaire à ses besoins.
C'est clair, mais ce que je veux montrer, c'est qu'exiger un logiciel libre dans le cadre d'un marché public n'est pas un critère technique. Autant rien n'empêche d'utiliser des logiciels libres sans passer par un marché public - ce qui se pratique déjà couramment - autant exiger un logiciel libre dans un marché public me semble être un choix politique et non technique, ce qui est contraire au Code des Marchés Publics.
Pour illustrer l'aspect contraignant du Code des Marchés Publics, il est par exemple interdit de citer des marques et des fréquences de microprocesseur dans les spécifications techniques de matériel informatique.
La Communauté Européenne a notamment engagé une procédure d'infraction contre l'Espagne sur ce point en 2006, en disant que c'était discriminatoire et incompatible avec les directives européennes.
[^] # Re: Ça me laisse perplexe...
Posté par Guillaume Rossignol . Évalué à 3.
J'en ai bavé pour trouver un exemple un peu coherent, mais prenons une commune avec plusieurs bibliotheque. La commune commande un logiciel de gestion des livres dans les bibliotheque avec un client assez poussé pour les abonnée permettant de garder des notes sur les bouquins qu'on aurait emprunté (etc.). Si la commune veut pouvoir fournir le logiciel à n'importe qui, la liberté de redistribution semble importante. Si elle veux pouvoir faire des modification sur le logiciel sans avoir à tout refaire (tiens, si on rajoutait les nouvelles acquisition dans la partie droitedu logiciel), le droit de modifier le logiciel et avoir le code source semble necessaire.
En plus, sa permet de ne pas etre coincés avec la societé qui a fourni le produit si le produit à un moment ne repond plus exactement au besoin et que le fournisseur original ne veut pas ou ne peux pas (faillite ?) retoucher le logiciel.
[^] # Re: Ça me laisse perplexe...
Posté par maat (site web personnel) . Évalué à 3.
(ps : désolé pour le ton aigre de mon précédent post mais faut éviter de trop fuder aussi c'est agaçant)
tsk. pas bien de déformer mes propos j'ai dit que le fait de demander un logiciel libre relevait à la fois de contraintes techniques *et* juridiques.
Au passage pour le besoin il suffit que l'organisme adjudicateur ait un role de soutien vis à vis d'autres entités publiques pour que le besoin de pouvoir rediffuser une version modifiée prenne tout son sens (il y a aussi les cas de rétrocession dans un souci de réduction des couts ou de protection des modifictions contre l'appropriation expliqués dans le guide pdf que j'ai mis en lien plus bas)
Des caractéristiques techniques... des spécifications techniques pfff premièrement c'est pas la même chose et l'acceptation de la notion de spécifications techniques est terriblement large (définie par décrêt http://www.marche-public.fr/Marches-publics/Textes/Arretes/A(...) )
C'est déjà pas bien net à la base... clairement sujet à interprétation et, histoire d'élargir encore un peu le truc, le décrêt s'offre le luxe de rajouter une couche de flou à l'article 2 histoire de pouvoir jouer avec les cas "non prévus". Autrement dit le caractère technique ou non d'une specification technique est laissé à l'appréciation de l'organisme adjudicateur à condtion que ces spécifications ne tombent pas dans le travers du favoritisme plus ou moins déguisé. Le guide des partiques à éviter sert d'illustration... l'idée fondamentale étant d'éviter les bidouillages de clauses techniques pour "favoriser les copains" hors dans le cas des logiciels libres de telles exigences n'entrent pas dans la catégorie des manoeuvres de favoritisme mais permettent de servir l'intérêt supérieur de l'organisme adjudicateur et à travers lui l'intérêt supérieur du service public.
Deuxièmement les spécifications techniques recouvrent aussi la notion d'exigence fonctionnelle (Article 6 du code des marchés publics de 2006 toussa http://www.marche-public.fr/CMP-2006/Specifications-techniqu(...) )
hors en termes d'exigences fonctionnelles, en particulier pour les organismes de soutien, la possibilité d'accéder aux sources, des les customiser et de les distribuer relève clairement du besoin fonctionnel. La dimension juridique n'est donc clairement pas la seule à entrer en ligne de compte.
Troisièmement une spécification de licence ne présume (je me répète mais visiblement c'est nécessaire) ni de l'origine (n'importe qui peut répondre) ni d'un mode ou d'un procédé de production particulier... et ça ne télescope pas le principe de concurence : si un vendeur refuse de releaser sous GPL un de ses softs pour répondre à un marché public exigeant la GPL ça n'est pas qu'il *peut* pas... c'est qu'il *choisit* de ne pas le faire.
Quatrièmement la notion de licence applicable relève des clauses particulières et à ce titre peut figurer sans souci dans les exigences d'un marché public (confer les guide ci dessous)
Cinquièmment les sites gouvernementaux définissant les bonnes pratiques et les guides à l'usage des organismes adjudicateurs publient des guides de choix concernant les logiciels libres dissipant définitivement tout doute quand aux aspects juridiques des marchés publics :
Guide de choix et d’usage des licences de logiciels libres pour les administrations
http://synergies.modernisation.gouv.fr/article.php3?id_artic(...)
http://synergies.modernisation.gouv.fr/IMG/pdf/Guide_LLL-2.p(...)
Logiciel libre et marchés publics : les obstacles juridiques faciles à dépasser
http://synergies.modernisation.gouv.fr/article.php3?id_artic(...)
Pour une approche juridique plus large il y a aussi l'article de l'encyclopédie juridique des bien informatiques (un peu rude à digérer mais très intéressant)
http://encyclo.erid.net/document.php?id=491#ftn78
[^] # Re: Ça me laisse perplexe...
Posté par Frédéric Lopez . Évalué à 0.
En quoi ça justifie de pouvoir redistribuer les sources ? Si le pouvoir adjudicateur a un rôle de soutien, il n'a pas besoin de distribuer autre chose que le produit fini, dans ce cas les binaires. Même si lui-même a accès aux sources.
Exiger un logiciel libre vise clairement à « favoriser les copains », c'est un choix politique. Ça exclue de fait les « pas copains », les logiciels propriétaires.
Je suis évidemment d'accord avec le fait que l'exigence d'une licence libre favorise « l'intérêt supérieur du service public », mais ça me paraît être en contradiction avec le Code des Marchés Publics.
Exiger la disponibilité des sources et la possibilité de les modifier pour ses besoins internes peut effectivement ressortir d'un besoin fonctionnel (maîtrise, indépendance, pérennité), mais les redistribuer, ça se justifie comment ?
Si, ça télescope le principe de concurrence en excluant les logiciels propriétaires. Quand je vois que l'Europe interdit de spécifier des marques ou fréquences de microprocesseurs, je me demande ce que ça donnerait pour des logiciels libres.
S'il s'appuie sur des briques non libres, il ne peut pas. C'est le cas de nvidia pour ses pilotes par exemple (enfin c'est ce qu'ils disent en tout cas). Sans compter que je ne vois pas sur quel modèle économique une entreprise qui faisait des logiciels propriétaires pourrait survivre en fournissant ses logiciels sous licence libre.
Ce guide (que j'avais déjà lu) ne dit rien à propos de la licence qui relèverait des clauses particulières et qui pourrait figurer sans souci dans les exigences d'un marché public.
Bon, on va pas passer 107 ans a épiloguer sur le sujet, je pense qu'en l'état le Code des Marchés Publics ne permet pas d'exiger des logiciels libres, tu penses le contraire. On n'est clairement pas d'accord et je ne vois pas comment nos points de vue pourraient se concilier.
Je serais quand même curieux de voir ce que donnerait un appel d'offre d'un montant significatif pour l'acquisition d'un logiciel libre dans un créneau ou de gros acteurs propriétaires sont présents.
Les entreprises n'hésitent pas à utiliser tous les textes disponibles² pour chercher à casser des attributions de marchés publics, donc je ne serais pas étonné qu'un procès soit intenté par l'acteur majoritaire sur le marché.
En attendant, comme le dit Alain Lambert¹ (ancien ministre du Budget, sénateur, conseiller général), « le délit de favoritisme tétanise tellement les agents et les élus qu'ils préfèrent mal acheter que s'exposer au pénal ».
¹ http://www.alain-lambert-blog.org/index.php?2006/08/06/612-n(...)
² http://www.achatpublic.com/news/Extraits/InfoduJour/AchatPub(...)
[^] # Re: Ça me laisse perplexe...
Posté par Guillaume Rossignol . Évalué à 3.
L'entreprise choisit de fournir (ou pas) des licences permettantde considerer le logiciel comme libre. Toutes les boites peuvent appliquer une licence libre à un de leur produit, nike ne pourra jamais mettre un logo adidas sur leurs chaussures ^ ^.
Imaginons, un departement souhaite fournir un logiciel de... bref, un logiciel à ses communes. Pour des raisons de customisation, controle de ce qui se passe, les communes peuvent preferer avoir les sources. Donc il faut que le departement fasse un appel d'offre pour un logiciel dont on peut redistribuer les sources.
Mettons, on decide de commander des vetements aux couleurs de la ville... d'un coup, sa exclue de l'appel d'offre les boites qui ne font pas des couleurs sur mesure... c'est un peu comme sa que je le voit, une boite decide de ne faire que du logiciel proprietaire, ben elle assume.
En fait demander un LL (et plus particulierement si on reclame de pouvoir redistribuer sous la licence qu'on veux) permet d'acheter et d'être "maitre" d'un logiciel , alors qu'un logiciel proprietaire ne donne que le droit d'utilisation. En gros, ce serait : vous nous filez un logiciel, puis apres, on fait ce qu'on veux avec, vous nous oubliez, ce qui à premiere vue, semble être une revendication honnete de la part d'un client.
Par contre, autant je pense que reclamer les liberté des LL dans un appel d'ofrre ne serait pas problematique, autant reclamer une licence particuliere meriterait une analyse plus profonde du schmilbick :)
[^] # Re: Ça me laisse perplexe...
Posté par Frédéric Lopez . Évalué à 1.
Dans ce cas, il suffit de demander que le code source soit accessible et modifiable par le pouvoir adjudicateur et les autres entités pour lesquelles il agit. Il n'est pas nécessaire qu'il soit redistribuable à quiconque.
Ça, c'est du fonctionnel, c'est comme d'exiger un graphisme conforme à la charte graphique d'une ville pour un portail par exemple.
Il n'y a pas besoin d'une licence libre pour être maître du logiciel, il suffit d'avoir accès aux sources et d'avoir le droit de les modifier.
[^] # Re: Ça me laisse perplexe...
Posté par Guillaume Rossignol . Évalué à 2.
A mon sens, demander un logiciel libre c'est dire aux entreprises : "Vous allez nous devellopper un logiciel que nous pourrons utiliser comme si nous l'avions developpé en interne".
Pour faire une analogie "foireuse" c'est :"plutot que d'engager une equipe d'informaticien pour qu'ils fassent le boulot pour nous, nous allons commander un logiciel que nous pourrons utiliser comme si c'est nous qui l'avions ecrit" plutot que :"nous allons acquerir un logiciel, mais il faudra quand même faire attention à ce qu'on fera avec". C'est pourquoi je verrai plutot dans les marchés publics des demandes de licence style "BSD" plutot que GPL.
Apres, si les organisme publics n'ont pas le droit de revendre ou de distribuer comme sa des logiciels, je remballe toute mon argumentation illico ^ ^
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.