Pastèque est un logiciel de point de vente (point of sales). Avec le matériel adéquat (imprimante thermique, lecteur de carte bleue…), il permet de gérer tout point de vente : restaurant, épicerie, bar, librairie…
Le 28 août est, selon le calendrier républicain, le primidi 11 fructidor (222 cette année) et, surtout, le jour de la pastèque. On a décrété que ça serait l’anniversaire du projet : c’était les 2 ans. Il y a deux ans, on travaillait à l’arrache le P.O.S. d’OpenBravo pour les besoins d’un restaurant (2 sous de table) et d’un bar (le Café citoyen) militants, exigeant du logiciel libre.
Aujourd’hui, Pastèque est devenu un projet logiciel à part entière. L’anniversaire est l’occasion de faire un point d’étape.
Changements techniques
OpenBravoPOS, logiciel à l’origine de Pastèque, commence à vraiment être loin derrière. C’est dommage, le code en catalan avait un exotisme certain pour les Nordistes et Belges qui ont travaillé dessus.
Nous nous orientons vers un modèle client‐serveur, simplifiant la gestion simultanée de plusieurs points de vente.
Pastèque n’est donc plus tant un logiciel qu’une suite :
- Pastèque Server, interface de programmation (API) pour les clients, interface d’administration ;
- Pastèque Desktop, le client historique, mais dont l’interface est en train d’être révolutionnée par Clic’Ordi ;
- Pastèque Android, le client Android qui progresse énormément avec l’intégration d’imprimantes thermiques, du système de paiement Payleven, des lecteurs de code‐barres, etc.
Une version HTML 5 est envisagée, mais il paraît pour le moment trop ambitieux de maintenir quatre logiciels de front.
On a mené quelques rationalisations, notamment sur la numérotation des versions. La version stable est la 5.
Changements autour du logiciel
Une communauté commence à apparaître autour de Pastèque, avec des scripts avancés proposés sur le forum ou les premières contributions majeures en code de Clic’Ordi.
Le site Web a été refondu pour quelque chose de plus « professionnel ». Un site communautaire dédié a été mis en place.
Un site sert à l’accès aux comptes en ligne et le Redmine est toujours en IPv6 uniquement. :-)
Changements dans le modèle économique
Le modèle client‐serveur posait un problème économique à pas mal d’utilisateurs. En effet, il n’existait plus de solutions gratuites. Les comptes sur les serveurs de Scil étaient payant, tout comme l’accès à Pastèque Server pour l’auto‐hébergement (licence GPLv3, payante).
Scil a donc opté pour la gratuité pour les petits commerçants (3 points de vente). Les commerces plus gros trouveront les tarifs très raisonnables : 15 € par points de vente au‐delà du troisième.
Et l’avenir ?
Le logiciel progresse bien, tant techniquement que commercialement. On ne se bile pas trop sur la technique.
À présent qu’elle émerge, l’organisation de la communauté et ses droits sont un point à envisager (pour l’instant tout appartient à la coopérative Scil). La question du caractère payant de l’accès à Pastèque Server sera également à étudier.
Aller plus loin
- Article sur les deux ans de Pastèque (850 clics)
- Scil, coopérative éditrice du logiciel (650 clics)
- Clic’ordi, contributeur au logiciel (353 clics)
- Téléchargement (1055 clics)
- Site de dev (IPv6) (716 clics)
# et paf
Posté par BAud (site web personnel) . Évalué à 3.
pastèque !
bonne continuation et courage pour la suite :-)
toujours en IPv6 ?
[^] # Re: et paf
Posté par Elephant (site web personnel) . Évalué à 2.
Yeap yeap. Et il semble que ça ne bloque pas les contributions :-)
[^] # Re: et paf
Posté par openbar . Évalué à -1.
Est-ce pour cela que je n'arrive pas à trouver trace du code source? Si j'ai bien lu, le serveur n'est même pas libre, c'est bien cela?
[^] # Re: et paf
Posté par Elephant (site web personnel) . Évalué à 8.
Si c’est libre. C’est de la GPLv3+. Je crois que tu bloques parce qu’on demande un paiement contre une version, mais ce n’est pas incompatible avec la GPL. Qui plus est, le prix reste accessible, pour un petit commerçant qui aurait une poignée de POS, c’est 1500€, soit le prix de deux licences d’un POS proprio phare (je vous laisse regarder sur metro.fr)
Comme évoqué, c’est un truc avec lequel on n’est pas à l’aise mais, « La réalité du terrain était parfois quelque peu différente. Même si la réussite des produits open source en provenance d’éditeur est réelle, si le nombre d’implémentations ne cesse de croitre, il n’a pas été pas toujours si simple pour l’éditeur, père fondateur du produit, de capter les « royalties » escomptés. » (src: cf http://www.journaldunet.com/solutions/expert/58291/open-source-2-0-ou-l-ere-de-la-maturite.shtml)
Pour le code source, tu as du mal chercher :
— http://redmine.scil.coop/projects/pt-desktop/repository
— http://redmine.scil.coop/projects/pt-android/repository
L’accès Git est documenté ici : http://redmine.scil.coop/projects/pt-desktop/wiki/Getting_the_source_code
Fais gawf à pas finir comme le grincheux dans Palace/Pub de la MAAF :-)
[^] # Re: et paf
Posté par openbar . Évalué à 2.
Donc c'est bien ça, la grande majorité des internautes, qui n'a pas de connectivité ipv6 ne peut pas acceder au code source des clients. Est-ce dans une démarche militante pour forcer la transition à ipv6, ou alors c'est une volonté de limiter l'accés au code source? Peut-être est-ce un mélange des deux?
Quand au serveur, si on paie 1500€, a-t-on accés aux versions amenées a sortir dans le futur, ou vous envoyez juste une archive avec le code source actuel, et pour les versions suivantes il faut payer a nouveau 1500€ pour par exemple une mise a jour de securité? Et pour la version majeure suivante, qu'en est-il?
[^] # Re: et paf
Posté par Elephant (site web personnel) . Évalué à 2.
Il y a mille façons d’accéder à un site IPv6 only depuis une IPv4, hein, et il s’agit uniquement de l’accès au dépôt de dev. Le code source des versions distribuées est disponible à côté des versions distribuées sur downloads.scil.coop
Quand au modèle économique autour de serveur, bah tu lances des pistes de réflexion. Comme je l’ai dit, on est en réflexion là-dessus en effet. Pastèque étant notre quotidien, si on n’a pas tranché, c’est qu’on n’a rien vu d’évident. Ça te dirait pas te me demander comment je vois les choses ? Les solutions que tu évoques, je les connais déjà très bien mais elles font cas de la gratuité qui n’est pas un point important, surtout quand le tarif est très raisonnable ; pour le prix de 2 POS proprios, tu peux avoir une infinité de POS libres ? It’s a deal !
[^] # Re: et paf
Posté par openbar . Évalué à 6.
Quand je te pose ces questions, il est implicite que ta réponse est ta vision des choses. Mais si tu veux, je te le demande explicitement:
Comment vois-tu les choses?
Il est vrai que le tarif est raisonnable pour une entreprise avec un CA de 500 000€, mais pour un particulier comme moi qui voudrait jeter un coup d'oeil sur les sources, c'est totalement prohibitif.
[^] # Re: et paf
Posté par JGO . Évalué à 5.
Bonjour, dans le détail votre business plan c'est : vendre des caisses qui en l'occurrence sont livrées avec Pastèque, ou bien vendre des services autour d'un logiciel adaptable aux caisses que les clients possèdent ?
En pratique, un petit commerçant peut-il débuter avec pastèque de façon gratuite ou doit-il obligatoirement télécharger contre paiement ? (Je ne critique pas, je demande.)
Si le commerçant a une seule caisse, peut-il se passer du serveur et juste installer le client sur un ordinateur portable connecté à une imprimante ? Si c'est le cas, quels sont les avantages d'utiliser le serveur, est-ce pour avoir une mise à jour centralisée des prix / gestion des stocks / comptabilité simplifiée ?
[^] # Re: et paf
Posté par Elephant (site web personnel) . Évalué à 4.
Le logiciel libre implique de donner le code source à ceux à qui on a distribué une version du logiciel. Le logiciel se trouve être payant, tu ne l’as pas, tu n’as pas accès aux sources.
La grosse question pour nous, en tant que coopérative et donc entreprise avec des salariés, est de trouver un modèle économique viable.
Peut-être que l’édition d’un logiciel par une coopérative avec des salariés (j’insiste : on doit être salarié, on ne peut pas être une startup où on renonce temporairement à toucher des salaires) est une impasse, va savoir.
Quand au troll sur la gratuité ou l’accès aux particuliers, je n’entrerai pas dedans. Nous sommes moins cher que le proprio et nous sommes libres. Pour paraphraser ce qu’on disait à l’époque, « Pastèque ? Y’a plus cher mais c’est pas libre »
[^] # Re: et paf
Posté par Elephant (site web personnel) . Évalué à 4.
Le modèle éco repose sur 3 trucs : vente de matériel pré-configuré, petits services (support, installation à distance, développement de rapports custom) et la vente de dev.
Du coup, le serveur rentre pas dans ces cases. Pour autant on a un peu peur de le rendre dispo. On l’a développé totalement de 0. S’il n’y avait pas de retour, ça nous affecterait humainement. Du coup pour le moment, on « force » la contribution par ce coût de licence (qui reste un GPLv3+, j’ai l’impression que je ne le dirais jamais assez :-))
Pour le dev, l’air de rien, on en vend pas mal et qui remonte en upstream. Pour les toulousains, vous pouvez passer commande chez les gars de midi-délices qui ont fait vraiment beaucoup pour Pastèque Android.
Pour la petite anecdote rigolote, la Basilique du Rosaire de Lourdes (oui, oui, Lourdes) a permis le multi-devise dans le logiciel.
On a la possibilité d’utiliser gratuitement le logiciel tant qu’on a moins de 3 POS. On est encore mauvais sur les modules complémentaires à activer, mais ça va se débloquer.
Il ne peut plus avec les nouvelles versions. Il faudrait avoir Pastèque server en local.
Mais ça peut être une première piste de solution pour le modèle de distribution de Pastèque Server : vente de matos standalone avec le serveur pré-installé.
[^] # Re: et paf
Posté par JGO . Évalué à 2.
Merci pour la réponse. Cela dit je n'ai toujours pas compris à quoi sert le serveur (surtout que les anciennes versions fonctionnent sans).
[^] # Re: et paf
Posté par Elephant (site web personnel) . Évalué à 1.
Pour les anciennes versions, uniquement à coordonner plus facilement plusieurs POS.
Pour les nouvelles versions, elles ne marchent tout simplement pas sans :-)
[^] # Re: et paf
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Je rebondis sur cette phrase de toi :
Et reprends à mon compte une question posée par JGO :
Si j’ai bien compris, votre produit de base est une caisse connectée à votre serveur à vous, mais il est techniquement possible d’avoir un serveur chez soi. Cependant, dans le cas d’un point de vente situé dans un lieu sinistré en terme de connexion internet, avoir un serveur chez soi est la seule solution viable.
Je te recite :
J’en déduis que ce cas là, s’il est possible, n’est pas vraiment expérimenté.
Il y a des cas comme celui que je cite (accès au serveur non fiable) où l’intérêt pour Pastèque porte moins vers la vente d’accès à votre serveur qu’à l’achat de service d’installation et maintenance d’une caisse et d’un serveur dans le point de vente. Dans ce cas, plutôt qu’un matos standalone avec serveur, il pourrait être plus intéressant d’installer le serveur sur le parc déjà existant et bien développé (peut-être dans une machine virtuelle dédiée).
Cette possibilité est-elle réalisable ?
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: et paf
Posté par Elephant (site web personnel) . Évalué à 1.
Oui et non.
Les besoins de connexion ne sont vraiment pas énorme. À moins d’être sur un 56K, ça roule. C’est que du texte chiffré (sauf si dans ta config tu charges des images pour les produits, mais c’est facultatif)
On verra peut-être apparaître le problème si nous avons des utilisateurs dans des pays moins développés à l’avenir.
Ah mais oui. Depuis le début oui. On vend Pastèque serveur et c’est à peine le prix de deux licences de POS qu’on trouve chez metro (voir ici)
On a même déjà des gens qui l’ont fait, il traîne des serveurs Pastèque ça et là !
Globalement, il ne faut pas perdre de vue que notre soucis est de « rentrer dans nos frais », rien de plus.
Si un jour assez de gens utilisent le logiciel, ça peut être un crowd funding pour le rendre gratuit par exemple.
[^] # Re: et paf
Posté par JGO . Évalué à 3.
Si le logiciel Pastèque ne se lance pas sans un composant proprio qui est nécessairement distribué avec Pastèque (dans les versions récentes), ça s'appelle un bundle, non ? Dans ce cas c'est risqué, car si je comprends bien, la licence devrait vous obliger à distribuer l'ensemble du bundle selon la GPL.
[^] # Re: et paf
Posté par Elephant (site web personnel) . Évalué à 3.
Le composant n’est pas proprio. Il est disponible en licence GPLv3+.
Dans la volonté d’un système entièrement auto-hébergé, nous introduisons une dépendance payante en effet.
Pour citer l’autre, « il n’y a pas de repas gratuit »
[^] # Re: et paf
Posté par MaelR . Évalué à 0. Dernière modification le 04 septembre 2014 à 13:53.
Je confirme : la GPL 3 permet de faire payer l'accès au code source.
Après, le bénéficiaire a le droit de publier ce code librement et de le redistribuer.
Mais il faut savoir apprécier l'environnement du projet. Rien n'est gratuit et à un moment il faut bien rémunérer l'effort fourni d'une manière ou d'une autre.
Et c'est la garantie que le projet vie évolue, va de l'avant.
[^] # Re: et paf
Posté par BAud (site web personnel) . Évalué à 1.
pas exactement…
Tu peux faire payer le binaire (si c'est compilé) et tu te dois de proposer le code source pour un montant couvrant les frais d'acheminement au plus. En tant que tel, tu ne fais pas payer le code source, mais rien n'oblige de donner le binaire gratuitement.
le §6 de http://www.gnu.org/licenses/gpl.html#section6 correspondant à ce que j'indique :
[^] # Re: et paf
Posté par ChickenKiller . Évalué à 3.
T'aurais quand même pu attendre 1h15 de plus …
# Version HTML5
Posté par lenod . Évalué à 2.
Si vous développez une version HTML5, il n'y a qu'un pas pour en faire une application firefox OS et un demi pas de plus pour ce ça donne une application android de fait. Ça fait donc potentiellement moins de logiciels à maintenir.
[^] # Re: Version HTML5
Posté par Elephant (site web personnel) . Évalué à 4.
Oui. Mais non :-)
Le POS est un domaine un peu particulier notamment quand il est question d’intensivité des ventes. C’est ce qui fait que les POS d’Odoo ou d’OpenBravoPOS, aussi intéressants soient-ils, sont des jouets dans pas mal de cas pour l’instant. Par exemple, c’est la brasserie qui sert à midi et doit encaisser tout le monde entre 13H30 et 13H45. L’air de rien, ces cas d’intensification ponctuelle des ventes sont fréquents pour beaucoup de commerces.
Du coup, HTML5 ne me paraissait pas très mature pour faire quelque chose d’efficace. On a des problématiques de drivers (imprimantes thermiques, lecteurs carte bancaire) et de réactivé qui ne sont/n’étaient toujours pas très bien résolus. Je clame pas avoir raison, juste que c’était mon impression et que ça a guidé les choix de dev :-)
Ceci dit, oui il faut s’y mettre. Il existe une demande pour une interface HTML: Et la techno va très probablement continuer à s’améliorer et répondre à ces points rapidement.
[^] # Re: Version HTML5
Posté par lenod . Évalué à 1.
Ce n'est pas le serveur quoi gère les drivers et tous ces trucs problématiques ?
[^] # Re: Version HTML5
Posté par Elephant (site web personnel) . Évalué à 1.
Non. Par contre, j’ai lu des trucs sur HTML5 et le gestion du matériel. C’est à creuser
Un soucis, c’est l’impression directe sans passer par la case du pop-up d’impression système. Celui-là, si vous avez la réponse, ça débloque beaucoup de choses
[^] # Re: Version HTML5
Posté par petitwilly . Évalué à 1.
Lundi Matin Business avais a une époque une extension pour Firefox qui faisait cela. mai il fallait payer.
je l'ai eu entre les mains, c'est en gros un code xul qui récupère lURL du pdf et la redirige vers l'imprimante.
je ne sais pas si les gens qui on forké LMB ont développés le même genre d’extension.
http://www.sootherp.fr/
[^] # Re: Version HTML5
Posté par groumly . Évalué à 2.
Qui serait suffisament fou/idiot pour distribuer du html5 dans un bundle natif?
Distribuer du html5 dans une appli (soit disant) native combine les inconvenients des 2 mondes (mauvaises perfs, pas d'acces au hard et casse tete de deploiment) sans profiter des avantages (fkexibilite de deploiment, performance, acces au hard).
Ya pas de mal a faire du web (non, vraiment, aucun), mais distribuer du web comme une appli native me parait vraiment marcher sur la tete, juste pour suivre le buzzword "app".
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
# GPL payant
Posté par espitall . Évalué à 1.
Imaginons qu'une personne paye, il a donc droit au code source sous GPL.
La GPL n'autorise-t-elle pas ce client à redistribuer de manière gratuite le code ? Si oui, ce modèle économique ne serait-il pas bancal ?
[^] # Re: GPL payant
Posté par Elephant (site web personnel) . Évalué à 3.
Si, tout à fait.
Et plusieurs personnes ont le logiciel et le code. Elles sont libres de le redistribuer mais pas contraintes à le faire
[^] # Re: GPL payant
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Il peut redistribuer de manière gratuite, à moins cher ou à plus cher (et devient alors distributeur (convey) selon la GPLv3). C'est un modèle utilisé par divers acteurs, et ce modèle est évoqué dans le très ancien article de la FSF, ou dans les positions April en 2008 sur la GPLv2 par exemple.
[^] # Re: GPL payant
Posté par Zenitram (site web personnel) . Évalué à 2.
Oui…
Tu peux compter sur le fait que la majorité des gens ne connaitront pas le site web perdu qui distribue les sources, si tant il en est que ce site existe (faut une personne qui ai envie de le faire).
Donc non, c'est pas bancal, c'est justement un autre modèle que de tout faire gratuit.
De la même manière, il y en a qui diffusent le binaire payant alors qu'il te suffit de compiler et le mettre à disposition.
Ou thePiratebay n'a pas tué les ventes de proprio. Et j'en passe comme exemples.
Bref, une question de principes pour les uns, de non connaissance du truc gratuit mais perdu dans un coin du web pour d'autres, ça marche déjà pour plein de monde.
# Fonctionnalité nécessaire
Posté par Le Pnume . Évalué à 7.
Bonjour,
Une question essentiel pour tout commerçant qui se respecte. Est il facile avec Pasteque de faire disparaitre les payements en liquide des relevés de la caisse ?
[^] # Re: Fonctionnalité nécessaire
Posté par Elephant (site web personnel) . Évalué à 1.
Mais voyons, c’est strictement interdit !
Les caisses proprios, y compris les caisses « mécaniques » gardent en mémoire les tickets annulés. Ce n’est pas encore le cas de Pastèque, mais c’est un fonctionnement que je souhaite développer.
En Belgique pour la restauration, et ça va arriver en France, les caisses doivent être certifiées et contenir une boîte noire ou envoyer en direct leurs données aux impôts (j’ai survolé le sujet, ñ’hésitez pas à préciser mon propos)
Donc bon, celui qui veut passer une vente au black, il ne la met pas dans sa caisse point
[^] # Re: Fonctionnalité nécessaire
Posté par dj_ (site web personnel) . Évalué à 4.
Certaines caisses ont des modules pour mettre au black un partie des paiements ici sur cuers info ou sur rue89
[^] # Re: Fonctionnalité nécessaire
Posté par Le Pnume . Évalué à 2.
D’ailleurs dans l'article de de Cuers.info, il y a une citation d'un distributeur de OpenBravo qui indique
[^] # Re: Fonctionnalité nécessaire
Posté par Elephant (site web personnel) . Évalué à 2.
Je confirme que la question est quasi-systématique. On a même des gens qui assument de la poser par écrit dans des mails non-chiffrés !
Pire, certains pensent qu’au prétexte qu’elles ont l’air plus rustiques, les caisse « mécaniques » (vous savez, sans écran tactile, avec plein de touches) facilitent le black. Les pauvres, s’ils savaient ce que fait le soft qui est embarqué dans ces machines …
Le plus fun, c’est que celles vraiment bas de gamme finissent par dégueuler le contenu de leur mémoire interne quand elle sature. La caisse imprime un gigantesque ticket contenant TOUT. Faut le voir pour le croire tant c’est énorme ce que ça imprime (et en plus ça coûte cher en papier thermique cette connerie)
[^] # Re: Fonctionnalité nécessaire
Posté par BAud (site web personnel) . Évalué à 1.
Quitte à ne pas gérer le black, ce serait tellement mieux d'avoir une « caisse noire » :-)
Il est parfois légitime que les paiements soient effectués en liquide (un avoir par exemple… pourquoi payer 2 fois ?).
Bon, ayant eu des parents commerçants, effectivement le liquide me payait mes bonbecs quand j'étais petit (genre 2 à 3 francs par mois) voire mes BD et bouquins (10 Francs les 5 bibliothèques verte !). Le liquide vu comme la caisse noire, cela a pratiquement disparu avec la carte bleue, si c'est 10% du CA c'est bien le max àmha… (en tout cas dans un magasin, dans un restau, je ne sais pas).
[^] # Re: Fonctionnalité nécessaire
Posté par sebas . Évalué à 0. Dernière modification le 31 août 2014 à 13:00.
… ce qui, soit dit en passant, génère une sorte de nouvel impôt privé puisqu'un pourcentage de 90% des achats chez les commerçants (selon tes estimations) vont dans les caisses de Visa/MC/Amex/…, alors que ces entités ne sont pour rien dans la production de ces marchandises ou services.
Au Brésil, une grosse majorité (dont la totalité de la classe moyenne et supérieure) paye ses achats avec des cartes de crédit ou de débit. Les banques reçoivent 5% au passage ! Je ne connais pas les chiffres en France, mais ça fait quand même peur.
Apple n'a rien inventé avec le racket sur les revenus des applications dans les app-stores, finalement ;-)
[^] # Re: Fonctionnalité nécessaire
Posté par claudex . Évalué à 7.
En même temps, c'est aussi un service pour le commerçant. Je pense que beaucoup seraient bien moins intéressé de trimballer tout leur chiffre d'affaire en cash. Certains endroits demandent même à leurs clients de payer via des cartes de débits pour éviter d'avoir ce problème.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Fonctionnalité nécessaire
Posté par groumly . Évalué à 3.
Sans compter l'impact sur les ventes, s'il faut tout payer en cash, ca va vite devenir genant, et les gens vont moins acheter.
Le premier qui mentionne bitcoin et/ou les cheques, je le mord.
Frais de transaction dans le premier cas, vu que les commercants ne vont pas tout implementer eux meme, et donc passer par un tiers qui va se servir au passage (je mentionne meme pas la volatilite du cours), methode incroyablement lente et risquee a grande echelle dans le deuxieme.
Comme tu dit, c'est un service: qq1 t'aide a vendre plus et plus rapidement, il prend un commission.
Comme les appstores en fait :)
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Fonctionnalité nécessaire
Posté par claudex . Évalué à 3.
Je l'avais volontairement écarté partant du principe que ça ne marche qu'à partir d'une masse critique. Il faut d'autre un autre argument pour arriver à cette masse critique. (Surtout qu'au début des cartes, beaucoup de monde devait trouver ça plus gênant qu'autre chose)
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Fonctionnalité nécessaire
Posté par gUI (Mastodon) . Évalué à 2. Dernière modification le 01 septembre 2014 à 10:50.
Il me semble que en France il est interdit de refuser le paiement liquide (en dessous d'un certain montant, où là c'est interdit). C'est pour ne pas faire de monnaie concurrente.
J'avais lu que les magasin qui affichent par exemple "nous refusons les billets de 100€" n'ont pas le droit de le faire. Par contre ils ont parfaitement le droit de ne pas rendre la monnaie (c'est au client de faire l'appoint : rendre la monnaie est un geste commercial).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Fonctionnalité nécessaire
Posté par claudex . Évalué à 3.
Mais où est-ce j'ai écris que les commerçants refusent le liquide ? Quand on te demande l'heure, tu te sens obligé d'acheter une montre pour pouvoir répondre ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Fonctionnalité nécessaire
Posté par gUI (Mastodon) . Évalué à 3. Dernière modification le 03 septembre 2014 à 18:14.
Il me semblait que "demandent à leur client" avait un sens plus fort. Si ils le demandent poliment avec "ça m'arrangerait bien", alors c'est bon :)
Par contre j'ai pas compris le coup de la montre :( (il dit qu'il voit pas le rapport)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Fonctionnalité nécessaire
Posté par sebas . Évalué à 1.
Vu que c'est du libre, le commerçant pourrait très bien inclure un module qui fasse ça dans le source (qu'il aurait trouvé, par exemple, dans un forum), le recompiler et exécuter la version modifiée sans que la responsabilité de l'éditeur soit engagée, non ?
[^] # Re: Fonctionnalité nécessaire
Posté par Elephant (site web personnel) . Évalué à 1.
Oh oui. D’ailleurs, si nous devions attaquer le marché belge de la restauration où les logiciels doivent être certifiés, seule une certaine build de notre logiciel, contrôlée au MD5, serait valable.
Cette notion certification entrave la liberté de bidouille, c’est une plaie.
[^] # Re: Fonctionnalité nécessaire
Posté par niavlys . Évalué à 1.
bon, la fraude a encore de beaux jours devant elle…
[^] # Re: Fonctionnalité nécessaire
Posté par Elephant (site web personnel) . Évalué à 2.
En même temps, celui qui en est à compiler un binaire en se faisant chier à contrôler le MD5, c’est qu’il est dans une sacrée magouille et c’est pas le MD5 de son apk ou de son jar qui sera la cause de sa perte :-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.