Sommaire
Dans mon entreprise, on utilise des logiciels libres. Il arrive qu'on aie besoin de modifier ces logiciels tiers, pour gérer un cas spécifique ou pour une meilleure intégration dans l'application.
Et parfois, en se lançant dans ce genre de travaux, on tombe sur une surprise :
Il existe des logiciels libres dont il est presque impossible d'utiliser les libertés sans une quantité déraisonnable de travail.
Je ne parle pas d'openwashing ici, cette technique qui consiste à faire croire qu'un logiciel est libre mais ne l'est pas et dont on a récemment parlé ici. Non, je parle de programmes véritablement libres (sous licence Apache ou MIT généralement, notre code n'étant pas libre ça ne peut être des licences contaminantes comme la GPL) mais dont les subtilités font que… visiblement quelqu’un ne veut pas que les libertés soient trop utilisées. On notera déjà que c'est souvent des logiciels dont il existe une version avancée commerciale.
Les libertés d'exécution et de redistribution sont généralement faciles à appliquer ; le problème survient souvent quand on veut étudier le programme et l'améliorer. Voici quelques exemples de techniques utilisées ; certaines peuvent être expliquées par un simple manque de volonté d'adhérer à l'esprit du logiciel libre ou par une mauvaise organisation interne ; d'autres s'approchent du sabotage. Dans tous les cas, la licence est respectée à la lettre.
Toutes les techniques ci-dessous ont été croisées dans des cas réels (heureusement pas toutes sur le même projet) :
Aucune documentation technique
Il n'existe aucune documentation technique d'aucune sorte. Selon la taille du logiciel, ça peut être plus ou moins gênant (je vous laisse imaginer quand le workspace du projet fait plusieurs centaines de Mo).
Parfois, rien qu'obtenir une version exécutable du logiciel à partir des sources est un calvaire.
Une version avancée consiste à utiliser des frameworks, compilateurs ou réglages exotiques, sans que ce soit documenté publiquement.
Les dépendances cachées
Les dépendances du projet vont par défaut se télécharger depuis un serveur qui appartient à la même organisation que le projet, et pas depuis les dépôts standards. Et surprise, ce serveur ne contient (en public) que les dernières versions des dépendances.
Au pire, ces dépendances sont elles-mêmes libres, on peut toujours aller les chercher et les compiler à la main, mais la quantité de travail pour obtenir une version fonctionnelle explose dès qu'on veut autre chose que la toute dernière version. Et je ne parle pas de la galère quand on veut mettre à jour un fork depuis l'origine.
Le faux dépôt de sources
Celle-ci est subtile : le dépôt des sources public n'est d'évidence pas un dépôt de travail, puisqu'il ne contient qu'un seul commit par version, sans le moindre commentaire. Ça n'est pas gênant tant qu'on essaie pas de maintenir un fork.
La version avancée, qui consiste à ne fournir les sources que sous la forme d'un dossier compressé sans le moindre historique, semble avoir à peu près disparue, du moins dans mon domaine.
Le tapis et le labyrinthe mouvant
Deux variantes d'une même technique :
- Les sources peuvent être planquées à un endroit inaccessible, voire carrément absentes du site éditorial – rien, pas même un lien, pas même une mention claire de la licence : si tu ne sais pas déjà que le logiciel est libre… tu le découvres en lisant la licence après avoir donné toutes tes informations pour la fameuse « version de démonstration 30 jours ».
- Le site change tout le temps, et la manière d'accéder aux sources n'est jamais la même d'un mois sur l'autre.
À noter que quelques entreprises ne fournissent les sources qu'aux clients de l'entreprise, ce qui est généralement autorisé.
Une variante intéressante du point 2, c'est quand le logiciel change régulièrement de grands pans de son architecture.
Le code qui fait des suppositions sur l'environnement de développement
Généralement à base de chemins en dur dans le code ou de réglages spécifiques à un IDE. C'est rare, mais on en croise…
La ressource libre-mais-déposée
Ici ça s'applique plus aux ressources qu'au code, principalement aux logos : votre ressource est libre, mais est une marque déposée. Il y a plein de cas où on ne peut pas l'utiliser. Par exemple, le logo GNU n'illustre pas la version d'origine de cet article, parce que, je cite (le gras est d'origine) :
Ce dessin est utilisable conformément à la GNU FDL v1.3, à la licence Art libre ou à la Creative Commons CC-BY-SA 2.0 (résumé en français ici). Toutefois, c'est aussi un logo déposé du projet GNU. Si vous voulez vous servir de cette tête de GNU pour mettre en lien un site web de la Free Software Foundation ou du projet GNU, n'hésitez pas ; de même, vous n'avez pas besoin de permission supplémentaire pour l'utiliser dans des contextes qui parlent de GNU de manière positive et exacte. Pour tout autre usage, veuillez au préalable demander la permission à licensing@fsf.org.
Source: La page du logo GNU sur le site de la FSF
Et donc ce logo est disponible sous 3 licences libres différentes, mais a des restrictions très fortes sur l'usage qui peut en être fait. C'est en fait valable avec à peu près tous les logos et toutes les marques – et les règles d'utilisations de logos et marques d'entreprises peuvent être bien plus restrictives.
La conclusion de tout ceci ?
Qu'un logiciel soit libre n'impose pas que son développeur doive vous faciliter l'application des libertés.
C'est quelque chose qu'on croit trop souvent, de même qu'on mélange souvent « libre » et « gratuit ».
Ce texte, placé sous licence CC BY 4.0, est une légère adaptation pour LinuxFR.org de l'original disponible sur Zeste de Savoir.
# Système politique
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 10.
Jolie illustration du fait qu'il n'y ait pas de loi (au sens système politique) parfaite. L'important c'est le cœur — mentalité — des gens.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
# Makefile et cie
Posté par eingousef . Évalué à 5.
Concernant le premier point, j'ai une question. J'ai déjà rencontré des cas le logiciel où tout le code était présent, mais pas le Makefile, le CMakeLists ou autre fichier servant de point de départ à la compilation qui aboutit au binaire fourni sur le site du projet. Est-ce que ce sont des logiciels libres ou pas ? Est-ce que le Makefile est considéré comme faisant partie du code ou est-ce que c'est juste de la doc dont l'absence n'est pas une violation des 4 libertés ?
*splash!*
[^] # Re: Makefile et cie
Posté par Nairwolf . Évalué à 1.
Je me suis posé la même question. Pour moi, il n'y a pas de violation. Rien ne m'interdit de diffuser du logiciel sous licence libre qui ne serait pas compilable.
[^] # Re: Makefile et cie
Posté par gouttegd . Évalué à 10.
Ce n’est sans doute pas le cas de toutes les licences libres, mais la GPL au moins est claire sur ce point. Extrait de la GPL 2 :
Extrait de la GPL 3 :
[^] # Re: Makefile et cie
Posté par Chuck #1 . Évalué à 2.
L'article parle de licences plus permissives autorisant la réutilisation dans des logiciels privateurs. Les auteurs de la GPL ont effectivement pensé aux détails pour que les libertés d'un logiciel libre soient effectives.
Cette signature est publiée sous licence WTFPL
# Pas forcément commercial
Posté par claudex . Évalué à 10.
Remarque que j'ai déjà vu ces points dans des logiciels libres sans version commerciale (et dans des logiciels développés et utilisés uniquement en interne (donc pas de raison d'obfusquer)).
« 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: Pas forcément commercial
Posté par Liorel . Évalué à 3.
Même en interne, il y a une raison d'obfusquer. Ça peut être d'avoir un point de négociation en cas de licenciement ("vous me virez, mais le logiciel XXX vous lâchera dès qu'il faudra le mettre à jour").
C'est très égoïste, mais si la boîte a un gros turnover…
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: Pas forcément commercial
Posté par Marotte ⛧ . Évalué à -2. Dernière modification le 13 juin 2018 à 21:28.
C’est pas seulement de l’égoïsme, c’est de la malhonnêteté pure est simple.
Et puis c’est quoi le point de négociation en cas de licenciement ? Éviter ce licenciement ? Et bien si « ça marche », bonjour la relation de travail à venir pour la suite… On va demander à celui ou celle qui s’est rendu⋅e indispensable, discrètement dans le dos de tous, de réduire voire supprimer, l’adhérence entre son poste et sa personne ? Ou bien on va se résigner à être dépendant de cet⋅te employé⋅e pour une durée indéterminée ?
Je dirais que dans ce cas, "on" devrait peut-être virer ce mauvais élément, ce traître, ce saboteur… cette salope !… malgré le risque de voir partir une ou deux compétences clés…
[^] # Re: Pas forcément commercial
Posté par Sébastien Le Ray . Évalué à 10.
AHAH magique l'écriture inclusive qui pourrit la lecture pour finir par « cette salope »…
[^] # Re: Pas forcément commercial
Posté par Tit . Évalué à 10. Dernière modification le 14 juin 2018 à 09:45.
je pense que dans son dernier paragraphe marotte tente une nouvelle version de l’écriture inclusive : on met aléatoirement les mots au masculin ou au féminin, il aurait pu aussi écrire : cette saboteuse, cette traitresse, ce salaud, par exemple.
bravo marotte, bonne innovation, c'est bien plus lisible que le paragraphe précédent
[^] # Re: Pas forcément commercial
Posté par j_m . Évalué à 1.
L'intention est bien, mais j'ai un doute sur salope. Il a peut-etre voulu dire salaude, le feminin de salaud?
[^] # Re: Pas forcément commercial
Posté par Marotte ⛧ . Évalué à -4.
Salope sonne mieux que salaud mais visiblement ça passe moins bien _o_ C’était pourtant un effort pour une écriture inclusive comme le début du commentaire :)
[^] # Re: Pas forcément commercial
Posté par Marotte ⛧ . Évalué à -3.
Je vois pas comment faire autrement pour une écriture vraiment inclusive (qui se doit aussi d’être inclusive avec les mots, pas de raison d’en écarter certains), parce qu’on ne peut pas tout le temps utiliser le point du milieu.
[^] # Re: Pas forcément commercial
Posté par Marco . Évalué à 10.
Sauf que ça exclut des gens : dyslexie, ceux qui ont des difficultés de lecture, étrangers qui apprennent le français, ceux qui ont besoin d'un lecteur d'écran pour lire.
Le point au milieu perturbe ma lecture alors que je n'ai aucun problème de lecture : normal quand je lis je déplace mes yeux sur le texte de manière constante, et ce . ralentit ma lecture. Alors imagine la personne qui a un handicap qui peut l'handicaper dans sa lecture.
Dans les pays anglo-saxon ils n'ont pas le pb de l'écriture inclusive, pourtant il y a des inégalités salariales aussi.
[^] # Re: Pas forcément commercial
Posté par Marotte ⛧ . Évalué à -10. Dernière modification le 15 juin 2018 à 10:27.
Les peuples anglo-saxons et les peuples nordiques sont notoirement moins machistes que les peuples latins.
Je soutiens l’adoption de l’écriture inclusive pour sa portée symbolique, c’est un signe d’ouverture vers le sexe oppressé, qui permet de rappeler que les femmes sont là et que les deux sexes comptent autant l’un que l’autre. Ce n’est pas ça qui réglera le problème des inégalités salariales même si ça ne peut qu’aller dans ce sens.
Au fond de moi, je me permets de continuer à penser que les femmes dans leur ensemble n’ont pas besoin de l’écriture inclusive (ou de la galanterie) pour être reconnues à leur juste valeur. Il semblerait que certaines pensent le contraire, si ça ne coûte qu’une très légère irritation oculaire à certain⋅e⋅s… je peux essayer pour leur faire plaisir.
Tu t’y habitueras ne t’inquiète pas. Moi aussi, s’il y en a trop, ça m’incite à abandonner la lecture. C’est bien pour ça que je milite pour l’utilisation de la version féminine d’un mot quand on a le choix, pour équilibrer avec le masculin, qui est sinon toujours choisi comme neutre.
Vraiment, « Mesdames et messieurs les député⋅es », si ça perturbe ta lecture et bien je dirais qu’il en faut pas beaucoup… En chasse fixe je comprends que ça puisse piquer un peu (en restant acceptable), en chasse variable, avec ce signe qui prend peu de largeur, c’est très lisible.
[^] # Re: Pas forcément commercial
Posté par Marco . Évalué à 9.
T'es sur de ça ? Quand je vois un Trump au pouvoir aux États-Unis je me méfie de ce genre d'assertion.
J'ai vérifié sur le site eurostat les écarts de salaire entre homme-femme :
On constate que la Suède, le Danemark et la Finlande font à peine mieux que la France en matière d'égalité salariale (13.3/15/17.4/15.2 respectivement)
Le Royaume-Uni et l'Allemagne ont un écart de plus de 20%
L'Italie, peuple réputé machistes ont un écart de 5%
Oui l'écart salariale ne veut pas tout dire sur la réalité de l'égalité des sexes. Mais on constate que les pays en avance sur ce genre de question n'ont pas une meilleure égalité salariale qui me semble être un bon indicateur (même si non corrigé : car ça veut dire que les femmes ont des difficultés à accéder à certains postes).
Dans ma tête ça donne Mesdames et messieurs les députéeeeuh quand je lis et c'est perturbant. J'arrive à comprendre le sens de la phrase mais c'est plus long. Et comme je l'ai dit c'est très exclusif aux personnes qui peuvent avoir des difficultés de lecture.
[^] # Re: Pas forcément commercial
Posté par Yves (site web personnel) . Évalué à 3.
Je suis d’accord avec toi sur le principe, mais… non, désolé, sur mon affichage actuel (Firefox Windows), le point est entouré de suffisamment de blanc pour que ça perturbe. Il pourrait être largement plus étroit (je dirais 5×), et ça irait beaucoup mieux !
Comme toi, je ne pense pas que l’écriture inclusive soit une pratique très déterminante pour l’égalité mais je comprends que ça vaille le coup d’essayer. Contrairement à toi, je ne m’y adonne pas…
À propos, saviez-vous que cette priorité donnée au masculin est une inégalité récente, et qu’autrefois, on utilisait indifféremment masculin et féminin quand le contexte ne requérait pas spécialement l’un ou l’autre ?
[^] # Re: Pas forcément commercial
Posté par sirthie . Évalué à 2.
En fait, le point médian est utilisé pour représenter les espaces dans les logiciels de traitement de texte et de PAO en mode Affichage des caractères non imprimables (espaces, tabulations, sauts de ligne et de paragraphe, etc.).
Un point médian avec ses marges latérales a donc exactement la largeur d'un espace, ce qui, je trouve aussi, est beaucoup trop large pour de l'écriture inclusive (et bon amusement quand vous travaillez en mode Affichage des caractères non imprimables).
[^] # Re: Pas forcément commercial
Posté par kna . Évalué à 10.
Ben si c'est si important pour toi, tu prends la peine de tout écrire, par exemple : les lecteurs et les lectrices sont perturbés par le point-médian. C'est français, c'est lisible, et personne ne s'en plaint.
[^] # Re: Pas forcément commercial
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 9.
Je suis tellement d'accord avec ça… je ne comprends pas pourquoi des gens persistent à utiliser le point médian ou des montages abscons type « celleux » (ou « ceulles », y'a pas de règle) dans des contextes où il n'y a pas de limitation de caractères.
Après je conçois que ce genre de montage peut être pratique quand on a une limite de taille forte. Mais dans le cas général on peut tout à fait faire de l'écriture inclusive dans son acceptation la plus extrême tout en respectant la personne qui lira le texte. Et ce n'est pas significativement plus long à rédiger.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Pas forcément commercial
Posté par Marotte ⛧ . Évalué à -7.
les lecteurs et les lectrices ne sont pas perturbé⋅es1 par le point-médian !
Il est nécessaire d’insister sur le fait que ça ne pose pas plus de problème aux hemmes2 ;)
Ici je serais très favorable à accepter comme correct les deux accords, au masculin (parce que forme "classique") ou au féminin (parce que règle de proximité, mais même sans ça).
On en a déjà parlé ici, ça ouvre la possibilité d’être équivoque, ou plutôt, on ne peut plus, simplement avec l’accord, préciser de quelle partie du sujet on parle. « Les lecteurs et les lectrices perturbées » signifie, selon la règle en vigueur, que seules les lecteur⋅ices1 muni⋅es1 (à priori…) d’un vagin sont perturbées : information implicitée par la grammaire, non explicité par la syntaxe → c’est une source de complexité de la langue (facile de passer à côté en lisant ça), donc de son inefficacité (à « régner » en tant que langue). La règle actuelle permet de transmettre une information plus subtile mais cela implique un plus fort risque de mauvaise transmission.
[1] J’ai employé la forme courte, avec un seul point : muni⋅e⋅s → muni⋅es, qui est plus concise, moins pédante et donc plus agréable, qui, comme tout changement d’habitude moins contraignant, a plus de chance d’être adopté⋅e rapidement.
[2] aux hommes qu’aux femmes → aux hemmes (ou aux fommes…) : pour celui-ci je ne suis pas sûr que les yeux des lecteurs, ou même leur âme, soient prêt⋅es
[^] # Re: Pas forcément commercial
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 10.
Ça fait des années qu'on me dit qu'avec l'habitude je ne verrai plus le point médian (ou avant qu'il ne soit utilisé, les constructions comme « perturbé-es », « perturbé(e)s » ou « perturbéEs »).
Le fait est que j'ai beau essayer, je bute systématiquement dessus, après des années à voir ce genre de trucs, et des pelletées de textes qui l'utilisent.
Ce serait bien que les zélotes de ce genre d'écriture acceptent d'entendre que si, on peut être de bonne foi et faire des efforts, mais ne pas réussir à se faire à ce genre de chose. Merde, c'est ma vie, je sais mieux que toi si je suis gêné dans ma lecture ou non !
J'ajoute que ce genre d'affirmation péremptoire passe encore moins bien quand les personnes qui disent qu'on peut s'y faire se braquent complètement à la vue de l'orthographe de 1990 et refusent d'admettre que l'on puisse écrire « ognon » ou « nénufar ».
Enfin, en réfléchissant un minimum on peut dégager une grande partie des constructions qui appellent un raccourcissement en point médian en se contentant de les remplacer par des tournures de phrase neutres. Cf ce message et le précédent pour exemples.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Pas forcément commercial
Posté par Faya . Évalué à -10.
Tu as un soucis d'adaptation. C'est l'un des gros avantages de l'être humain, on sait s'adapter. Si t'y arrives pas, ça n'est pas normal. Ça voudrait dire qu'un simple changement de police, passer du Sans au Serif par ex. t'empêcherait aussi de lire un texte…
J'ai l'impression que c'est comme les électro-sensibles qui sont malades à proximité d'une antenne GSM jusqu'à ce qu'on leur explique qu'elle n'est pas branchée et n'émet rien. Un genre d'effet nocébo. Si y'avait moyen de faire des études en double aveugle pour mesurer la gêne de cette écriture, on aurait des surprises… Ou on pourrait commencer par mesurer la gêne par sexe, on se rendrait ptêt compte qu'en fait ça dérange essentiellement les hommes qui ne veulent surtout pas qu'on touche à leur précieux masculin qui l'emporte.
Ce qui ne signifie pas que le symptôme (la gêne) n'existe pas mais la raison est ailleurs…
[^] # Re: Pas forcément commercial
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 10.
Je chercherais plutôt du côté de la méthode d'apprentissage de la lecture utilisée.
J'espère aussi que tu te rends compte à quel point ce que tu dis là est prétentieux, hautain et méprisant.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Pas forcément commercial
Posté par Faya . Évalué à -9.
Je me rends compte que ça doit être très désagréable à entendre pour qqun qui a effectivement du mal à lire. Mais ça ne change rien à l'affaire…
J'ai participé à des réunions d'électro-sensibles qui étaient outrés qu'on leur dise que leur problème ne venait pas des ondes. Y'a même une dame qui s'est mise à pleurer en disant qu'elle n'était "pas folle"… Parce que le symptôme est réel ! Mais j'ai un doute sur la raison invoquée.
[^] # Re: Pas forcément commercial
Posté par claudex . Évalué à 10.
Sauf qu'il y a des études scientifiques sur la lecture de texte et qu'ajouter un espace (via le point) au milieu d'un mot, ça perturbe la lecture. Ce n'est pas juste un sentiment.
« 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: Pas forcément commercial
Posté par Marco . Évalué à 10. Dernière modification le 15 juin 2018 à 19:49.
L'écriture inclusive est imprononçable à voix haute ce qui peut rendre très difficile la lecture.
Quelqu'un ayant des difficultés de lecture pour x ou y raisons peut avoir de réelle difficulté à lire avec l'écriture inclusive (y a environ 5% de dyslexique par exemple, y a des déficients visuels, des gens dont la langue maternelle n'est pas le français, quelqu'un qui a oublié ses lunettes)
Que ça embête aussi les femmes ayant des difficultés de lecture ? Que ça casse le rythme lorsqu'on lit à voix haute ou dans sa tête ?
Sérieux vous êtes capables capable d'écrire "lecteur⋅ices" mais pas capables d'écrire "les lecteurs et les lectrices" c'est quand même plus fluide à lire non ?
[^] # Re: Pas forcément commercial
Posté par Faya . Évalué à -4.
Je ne faisais bien sûr pas référence aux personnes qui ont déjà des difficultés pour lire un texte normal. Bien sûr pour ceux là ça va aggraver les choses.
Je suis capable de rien du tout, je trouve ce point-médian hideux et ne l'utiliserai pas. Je suis d'accord avec toi, la 2e version est bien mieux. Mais dire que ça rend un texte illisible, c'est du foutage de gueule.
[^] # Re: Pas forcément commercial
Posté par Marotte ⛧ . Évalué à -2.
Ahh… mais de bonne foi tu as toutes les chances d’avoir tort face à moi ! ;)
T’as le droit de pas supporter/apprécier ce point médian. C’est juste un manque d’adaptation mineur, ce n’est pas grave, surtout si tu ne transmets pas tes gènes défaillants. ===> []
[^] # Re: Pas forcément commercial
Posté par Marotte ⛧ . Évalué à 4.
Je déteste « ognon » (pour moi ça fait un g dur, même s’il n’y a aucune raison) mais il fallait bien avouer que le français méritait, et mérite encore et toujours, un bon dépoussiérage. L’autorisation de « événement » par exemple.
Nénufar me va très bien, aucune raison de conserver ce "phar" final. C’est comme « clef » et « clé ». « clé » avait remplacé (comme une alternative) « clef » bien avant la réforme de 1990. C’est bien que notre langue évolue.
[^] # Re: Pas forcément commercial
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 2.
Je ne vois pas où tu veux en venir, « événement » était l'orthographe normale avant 1990, « événement » est l'orthographe alternative autorisée depuis 1990, qui correspond à la prononciation, et qui était très largement utilisée avant 1990 (ici la réforme n'a fait qu'officialiser ce qui était une faute courante).
La connaissance libre : https://zestedesavoir.com
[^] # Re: Pas forcément commercial
Posté par Sébastien Le Ray . Évalué à 5.
C'est dommage que vous ayez tous les deux fait des typos :)
[^] # Re: Pas forcément commercial
Posté par Marotte ⛧ . Évalué à 2.
Pas une typo de ma part, je croyais que c’était l’inverse…
[^] # Re: Pas forcément commercial
Posté par Marotte ⛧ . Évalué à -5.
Cette forme est pourtant courante depuis longtemps pour les pluriels. Elle ne facilite pas la lecture, personne dira le contraire, mais je pense qu’il y a largement plus de gens qui réussissent à s’en accommoder, que de gens qui « buttent » vraiment là-dessus. Tu n’as pas de chance à ce niveau là (avis perso). Il faut bien avoir des points faibles dans la vie !
Pour ce qui est du manque d‘adaptation de ceux qui ne supportent pas l’écriture inclusive avec un point médian… mon commentaire était sciemment polémique. C’est normal que ça puisse gêner, même les plus doués, même ceux qui ont la plus grande faculté d’adaptation. Ceci pour la simple raison qu’il s’agit d’un changement. Ne pas avoir à s’adapter, ça reste le meilleur moyen de réussir à le faire…
On verra bien. Pour l’instant je ne dirais pas que l’écriture inclusive « a gagné », elle n’est encore utilisée que par certains groupes sociaux, et son utilisation est très clairement considérée comme un acte, du moins une prise de position, politique. C’est pour symboliquement marquer la volonté d’avoir un traitement égal du masculin et du féminin (masculin et féminin au sens large). Pour dénoncer le déséquilibre entre les deux sexes, pour exiger une relation égalitaire à la place.
Si ce point médian permet, de par le rejet qu’il suscite, d’obliger les gens à réfléchir au caractère inclusif/sexiste de leurs phrases lorsqu’ils écrivent, et donc, in fine, d’écrire autrement, il aura fait son travail.
[^] # Re: Pas forcément commercial
Posté par Guillawme (site web personnel, Mastodon) . Évalué à 8.
En fait tu n’en sais rien. Il y a peut-être bien plus de gens que ça insupporte et qui arrêtent tout simplement de te lire plutôt que de perdre du temps à essayer de te convaincre que c’est n'importe quoi d’écrire comme ça.
[^] # Re: Pas forcément commercial
Posté par CHP . Évalué à 8.
Et si, justement, en rappelant constamment qu'on est pour un traitement égal, on ne faisait que rappeler constamment aux femmes leur statut de victimes ?
Tu imagines si la RATP se mettait à écrire dans tous les bus "les noirs ont le droit de s'assoir où ils veulent dans le bus, à l'avant comme à l'arrière" ?
Le simple fait qu'on l’écrive, qu'on le répète, montre que ce n'est pas évident pour tous, et quelque part légitimise le point de vue de ceux pour qui ça n'est pas évident.
[^] # Re: Pas forcément commercial
Posté par Marotte ⛧ . Évalué à 3.
C’est possible.
Le racisme envers les noirs, en France, il a quasiment disparu si on le compare au machisme. Autrement dit, le machisme est un problème soulevé bien plus récemment que la haine/peur des noirs. Le fémin⋅az⋅isme1 est encore dans la phase : il faut (faire) parler du problème, même au risque d’être outrancier, les gens n’ont pas encore assez conscience de ça, voire mettent encore la tête dans le sable.
[1] Le point du milieu permet de raccourcir la phrase, et pas forcément pour l’aspect du genre, il faut lire : « Le féminisme comme le féminazisme » (ie: les modérées comme les extrémistes)
[^] # Re: Pas forcément commercial
Posté par CHP . Évalué à 8.
Ce que je voulais dire avec l'exemple des bus et des noirs, c'est que, si la RATP le faisait, tout le monde serait choqué. Cela montre que le fait de rappeler quelque chose qui devrait être évident revient à accepter qu'on mette en doute cette évidence. Pour moi, l'écriture inclusive relève un peu de ce problème (en plus d'être moche et d'être de l'enculage de mouche) : le fait de vouloir rappeler à chaque phrase (et parfois plusieurs fois dans la même phrase !) que les femmes et les hommes ont la même valeur, cela revient à accepter qu'on mette en doute cette évidence. Et en plus, c'est moche et les mouches ont droit à leur tranquilité :)
[^] # Re: Pas forcément commercial
Posté par Michaël (site web personnel) . Évalué à 9.
Souligner la présence des femmes dans les assemblées où elles n'ont aucune raison de ne pas être me semble justement exprimer une intention inverse à celle initiale.
Et donc du coup, l'approche retenue consiste à attaquer le problème par un chantier qui demande un effort démesuré pour un résultat quasi nul? C'est brillant. Tu as déjà vu beaucoup de discussions sur l'écriture avec point milieu qui s'ouvraient sur une discussion sur les problèmes liés au sexisme? À la rigueur si quand on a acquis l'attention de son auditoire an utilisant le point milieu comme chiffon rouge on ouvrait la discussion sur le sujet véritable, c'est-à-dire le machisme, on verrait une utilité à l'artifice, mais rester sur le point milieu pour essayer de convaincre autrui qu'on ne lit pas moins bien les textes rédigés ainsi est une perte de temps.
En France il y a beaucoup de pauvres. Pour attirer l'attention sur ce sujet de société, je propose de remplacer le
epar un€– €t quand on s'y habitu€, c€ n'€t pas plus difficil€ à lir€!.[^] # Re: Pas forcément commercial
Posté par Marotte ⛧ . Évalué à 4.
Rich€ id€€ !
[^] # Re: Pas forcément commercial
Posté par Michaël (site web personnel) . Évalué à 6. Dernière modification le 09 juillet 2018 à 01:45.
Comme quoi plus on réfléchit à cette écriture avec point milieux plus on se rend compte qu'aux yeux des tenants de cette forme, être remarqué est bien plus important que de faire une place pareillement belle aux hommes et aux femmes dans leurs phrases. Un projet politique qui se résume en une image:
[^] # Re: Pas forcément commercial
Posté par Marco . Évalué à 9.
Euh tu sais le monde est petit, mais genre vraiment petit. Un coup de fil à ton ancien employeur c'est vite fait. Surtout si t’envisage de chercher un emploi dans la même ville.
Pis faut arrêter de se croire indispensable, comme on dit dans ma boîte : "les cimetières sont remplis de gens indispensable".
Et dans le pire des cas, on recommence à 0 plus viable économiquement
[^] # Re: Pas forcément commercial
Posté par Morovaille . Évalué à 1.
Visiblement, ce n'est pas si simple : https://workplace.stackexchange.com/questions/113345/how-to-stop-an-employee-from-holding-the-company-hostage
Ce commentaire est libre de droit, vous pouvez le réutiliser comme bon vous semble.
[^] # Re: Pas forcément commercial
Posté par Obsidian . Évalué à 10.
Comme dit plus haut, c'est malhonnête en soi et personne ne fonctionne au chantage. En plus, dans notre métier en particulier (pourvu que ça dure) les développeurs sont quasiment en situation de plein emploi. Donc, soit le dev est incompétent (il y en a beaucoup plus que l'on croit) au moins sur une techno donnée, soit la compagnie fait déjà des pieds et des mains pour tenter de retenir ses éléments.
Avec ça, il y a un phénomène dont toutes les petites et moyennes structures ont fait l'expérience si elles ont un jour mené un projet de développement : même avec la meilleure volonté du monde, le logiciel devient de toutes façons et de lui-même, soit obsolète soit impossible à maintenir. Même si le dev est un « full stack » et connaît toutes les technologies sur le bout des doigts, il faut toujours au moins 500 jours/homme pour produire quelque chose qui soit réellement abouti sur tous les plans. Même faire de l'intégration, ou être mainteneur de packages pour une distribution, est une activité extrêmement chronophage. Et l'ennui des petites structures, c'est que pour verser un salaire au développeur, il faut vendre vite et si possible beaucoup.
Donc, le dev n'a pas le temps de produire quelque chose d'exhaustif dès le départ. Ce n'est pas du mercantilisme, c'est juste que s'il n'y a pas rapidement une première vente, il n'y aura pas de fond pour poursuivre le développement.
Du coup, les logiciels qui deviennent vraiment pérennes dans le temps sont ceux dont l'équipe a pu atteindre une masse critique, justement parce qu'elle ne dépend pas d'un seul développeur. Donc soit les logiciels de grosses entreprises, avec des équipes et des processus métier bien rodés, soit des projets de logiciel libre qui, par nature, ne sont pas liés au départ à une contrainte de temps et que les personnes intéressées peuvent rejoindre au fur et à mesure de leur avancement.
Et enfin, lorsque l'on arrive à surmonter tout cela, dans le contexte actuel, c'est généralement le développeur qui part de lui-même. Du coup, toutes les sociétés sont déjà habituées à prévoir un plan de repli ou à mettre carrément un projet en sommeil le temps de former une autre équipe.
La meilleure façon, au contraire, de pérenniser son emploi est d'être rentable. Il ne s'agit pas de devenir volontairement une vache à lait bien sûr, mais le meilleur argument pour se rendre « indispensable » est d'être capable d'exhiber ce que ton travail rapporte à la compagnie par rapport à ce que tu lui coûtes. Fort de cela, et si ça marche bien, tu peux essayer de négocier une augmentation pour récupérer ta part du gâteau tout en restant « profitable ».
Et s'il s'avère que justement, « ce n'est pas la politique de la compagnie » ou que tu travailles dans une de ces SSII où le principe est de te payer le minimum en te promettant monts et merveilles jusqu'à ce que tu décides toi-même de mettre un terme à la mascarade, alors au contraire, il faut essayer de perdre le moins de temps possible et essayer rapidement une nouvelle structure. Et pour cela, tu auras besoin à la fois de faire une transmission de compétences pour être libéré rapidement et d'un portfolio pour intégrer facilement un autre poste. Et ça, ce sont deux très bonnes raisons d'écrire le code le plus propre et le plus accessible possible.
Pour finir, sache que la personne qui devra un jour faire face à ton code réellement « obfusqué » sera probablement… toi-même. Entre 20 et 35 ans, on retient en général tout de tête. Après, ça devient difficile. Mais malgré cela, imagine qu'on te place huit mois sur une mission secondaire, puis que tu prennes trois semaines de vacances avant de reprendre ton développement initial. Tu verras alors à quel point il est difficile de se ré-immerger dans son propre travail…
[^] # Re: Pas forcément commercial
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à -2.
« ce n'est pas la politique de la compagnie »
On dit pas compagnie en Français. On dit entreprise. Merci.
[^] # Re: Pas forcément commercial
Posté par Dr BG . Évalué à 10.
Même pour la 7ième ?
[^] # Re: Pas forcément commercial
Posté par liZe . Évalué à 8.
C'est ton avis mais ce n'est pas celui de l'un des dictionnaires de référence.
(Par ailleurs, en français, on ne met pas de majuscule à « français » dans ce cas de figure.)
[^] # Re: Pas forcément commercial
Posté par Jiel (site web personnel) . Évalué à 4.
Ce n'est pas non plus l'avis de https://fr.wiktionary.org/wiki/compagnie
Le mot "compagnie" est attesté en français depuis longtemps, voir par exemple Compagnie de chemins de fer départementaux ou Compagnie des Indes.
Le mot anglais dérive de l'usage français a priori.
[^] # Re: Pas forcément commercial
Posté par Guillaume Smet (site web personnel) . Évalué à -2.
Oui, enfin, les deux exemples que tu donnes datent un peu…
De nos jours, il est beaucoup plus courant d'utiliser "société" ou "entreprise". "Compagnie" est plutôt désuet.
[^] # Re: Pas forcément commercial
Posté par Faya . Évalué à 10.
Compagnie n'est pas du tout désuet au Québec (ni "soulier" ou d'autres mots considérés comme "anciens" de votre côté de l'Atlantique).
On est pas sur Linuxfr_FR ;-)
[^] # Re: Pas forcément commercial
Posté par groumly . Évalué à 7.
Chez moi, tu te fais virer pour ça. Et comme un malpropre, sans préavis, escorté par la sécu et tout.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Pas forcément commercial
Posté par Psychofox (Mastodon) . Évalué à 3.
Dans les plupart des boites tout le monde se fait virer comme ça. C'est pas parce que tu passes pour un malpropre mais si tu te fais virer c'est que la relation de confiance n'existe plus donc l'entreprise doit se protéger de toute possible tentative de vengeance.
[^] # Re: Pas forcément commercial
Posté par groumly . Évalué à 6.
Pas par chez moi. La plupart des ingénieurs qui se font virer se font en fait "managed out".
En gros, on met la personne sur un "performance improvement plan", et elle a 30 a 60 jours pour améliorer une liste de choses, et on suit ca toutes les semaines.
Sauf qu'on sait très bien que la personne ne va pas s'améliorer (sinon on serait pas sur un pip, parce qu'avant le pip, ca a été discute en long en large et en travers avec ladite personne).
C'est une façon polie de dire a la personne "on te donne 60 jours de notice (ce qui est enaurme ici), commence a chercher un boulot ailleurs, on aura pas a te virer, et t'auras pas a expliquer pourquoi t'as pas de references a donner de ton ancien boulot".
La plupart comprennent le message assez vite, mais j'ai deja vu des longuets a la reaction qui sont passe a 2 doigts de se retrouver le bec dans l'eau.
Le mec viré comme un malpropre, c'est le mec qui a fait une faute grave qu'on vire sur le champs, sans en discuter avec lui.
En gros, HR l'attends a son bureau le matin, meeting surprise "pas la peine de poser tes affaires, on va pas rester longtemps. enfin, toi surtout". J'ai vu ca une fois en 5 ans. Des mecs "managed out", par contre…
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Pas forcément commercial
Posté par Sacha Trémoureux (site web personnel) . Évalué à 10.
Ça a l'air génial où tu bosses dis donc.
[^] # Re: Pas forcément commercial
Posté par eingousef . Évalué à 10.
Bah ouais. Les employés ont des pip avant de partir.
*splash!*
[^] # Re: Pas forcément commercial
Posté par passant·e . Évalué à 3.
Oui c'est le RH qui s'en charge lui-même
Je trolle dès quand ça parle business, sécurité et sciences sociales
[^] # Re: Pas forcément commercial
Posté par Psychofox (Mastodon) . Évalué à 2.
Ce sont des bisounours chez toi. Partout où je suis allé celui qui est viré s'en est rendu compte quand son badge ne fonctionnait plus le matin et qu'il doit appeler la réception pour qu'on lui ouvre et qu'on lui explique que non il doit rentrer chez lui et qu'on le contactera pour récupérer ses affaires.
Bien sur sauf faute grave ou gros clash la veille en général il y'avait eu des séances au préalable avec cette personne et le management pour lui dire que des trucs allait pas et qu'il devait se ressaisir.
[^] # Re: Pas forcément commercial
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 10.
Tu es dans quel pays ? Parce que ce genre de fonctionnement m'a l'air assez peu légal en France.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Pas forcément commercial
Posté par thamieu . Évalué à 2.
En matière de licenciement plus grand-chose n'est illégal en France depuis très récemment : les ordonnances Macron.
Lorsqu'un employeur vire un salarié aujourd'hui, il peut le faire sans « cause réelle et sérieuse ». Si le salarié décide d'aller s'épuiser au tribunal, il sait à la fois qu'il ne pourra pas escompter réparation au-delà d'une certaine grille. Par exemple, 5 mois de salaire pour 5 ans d'ancienneté. Il sait aussi qu'il risque de se faire blacklister chez les autres employeurs du même secteur.
Voilà le texte de l'ordonnance.
Concrètement ça veut dire que le CDI n'existe plus en France.
Pour rappel, cette ordonnance ne fait que reprendre certaines de disposition de la loi El Khomri, loi soutenue notamment par la CFDT car elle pouvait « répondre à une ambition de progrès ». On appréciera toute la dimension constructive de ce soi-disant syndicat de salariés.
[^] # Re: Pas forcément commercial
Posté par -Nicolas- . Évalué à 5.
Attention pour les prud'hommes c'est à double tranchant pour l'employeur. Ça lui fait une mauvaise pub. Surtout dans un secteur où on a encore un rapport de force favorable.
Je bosse en SSII, client pervers narcissique, harcèlement moral, là-dessus je me tape une procédure de licenciement, inaboutie parce que professionnellement je suis bon et qu'il n'avait absolument rien (le client par contre une tanche de première). Là j'attends le paiement de mon déménagement et je vais pas te le louper l'employeur. J'ai très largement moyen aux prud'hommes d'obtenir un licenciement nul (donc 6 mois de salaire mini+préavis&co), puis faire une bonne pub au client et à la SSII. Sans compter mon client actuel qui aura droit a une petite explication étant donné que je vais partir du jour au lendemain (faut pas croire le système des SSSI leur est imposé par leur hiérarchie mais ça les gonfle aussi). Bouche à oreille. Dans un petit milieu ça se sait vite. Si y'a moyen d'envoyer au pénal aussi le client… La preuve pour le harcèlement y est plus difficile (surtout qu'il était suffisamment malin pour ne laisser ni traces écrites ni témoins) mais je dois pouvoir le faire tomber avec autre chose.
3615 MAVIE
[^] # Re: Pas forcément commercial
Posté par -Nicolas- . Évalué à 3.
J'ajoute : si l'employeur se trompe, il risque plus gros. Il a intérêt à recueillir un minimum les explications du salarié.
[^] # Re: Pas forcément commercial
Posté par -Nicolas- . Évalué à 1.
Même en cas de faute il doit y'avoir une procédure. Ce que tu décris c'est plutôt une mise à pieds, suivie d'un licenciement.
[^] # Re: Pas forcément commercial
Posté par groumly . Évalué à 3.
Pas en californie non (ou l’immense majorité des autres etats). At will employment qu’ils appellent ça. Les deux parties peuvent rompre le contrat instantanément, sans justification.
Ya des protections pour certains cas, quand même (femme enceinte, discrimination raciale/sexiste, jeunisme, ce genre de trucs), mais sorti de ça, c’est un pays libre. Le mec qui fait une faute grave volontairement, il se fait effectivement virer sur le champs.
En pratique, les employés donnent 2 semaines de préavis (1 à 3 mois pour des postes plus haut niveau), et certains employeurs appliquent la technique décrite au dessus.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Pas forcément commercial
Posté par claudex . Évalué à 5.
(je répond à ce commentaire, mais c'est plus une réponse à toutes les réponses)
C'est un cas qui existe. je suis d'accord. Ce que les gens qui te répondent n'ont pas l'air de comprendre. C'est que quand ça marche pour l'employé, c'est fait de manière subtile. Il ne crie pas debout à poil sur les tables "je suis invincible". Il montre plutôt qu'il est celui qui sait résoudre la plupart des problèmes lié au logiciel.
Il faut aussi noter que ça ne marche évidemment que dans des structures où la direction n'est pas capable d'évaluer la compétence des employés. Soit parce qu'il y a une équipe de dev très réduite parce que ce n'est pas le métier de l'entreprise. Soit parce que la direction est tout simplement mauvaise pour le métier de l'entreprise (et il ne faut pas croire qu'une boîte comme ça coule très vite).
« 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: Pas forcément commercial
Posté par -Nicolas- . Évalué à 3.
Dans certaines entreprises ce sont les employés compétents et efficaces qui sont remerciés… (jalousie des collègues, peur du n+1 pour sa place, n+2 pas capable d'évaluer, ajoute à ça un management basé sur l'évaluation de tout et n'importe quoi sauf le métier du salarié).
[^] # Re: Pas forcément commercial
Posté par Lutin . Évalué à 4.
Légende urbaine:
- soit tu es tout seul sur ton projet et la boîte ne comprend pas à quel point tu es irremplaçable
- soit ton collègue revert ton commit obfuscateur et va demander à l'adminsys de t'enlever les droits pour pousser ton code sur le repo le temps que les rhs décident quoi faire de toi.
# Dans un tel cas, pourquoi faire du logiciel libre ?
Posté par Nairwolf . Évalué à 3.
Merci pour ce journal. Quand j'ai découvert le logiciel libre, c'était une question que je me posais. Est-ce qu'il existe des projets qui contournent les règles du logiciel libre ? Il y a pas mal de techniques que je n'imaginais pas. Personnellement, je me demandais s'il était possible de rendre libre le code source, mais de ne pas donner d'information pour la compilation, par exemple, ne pas fournir de Makefile compilant un projet C. Cela reste-il "libre" ? A priori oui.
Et oui, le logiciel libre n'est pas toujours synonyme de collaboration. Il ne donne pas non plus d'indicateur sur la "facilité" d'accès aux sources, ou à sa compréhension.
Je me demande aussi si je fournis un code source offusqué (en remplaçant les variables par des caractères aléatoires, par exemple), est-ce que cela reste du code libre ?
L'autre question que je me pose et que j'aimerai bien que l'auteur du journal réponde, c'est pourquoi, selon lui, les développeurs de ces logiciels libres, mais dont rien n'est fait pour les rendre accessible, font-ils cela ? Quel est leur but ? Quitte à rendre les libertés du logiciel libre quasiment inapplicable en pratique, pourquoi mettre le logiciel sous une licence libre ?
[^] # Re: Dans un tel cas, pourquoi faire du logiciel libre ?
Posté par eingousef . Évalué à 5.
Un code obfusqué c'est non-libre d'après la FSF.
*splash!*
[^] # Re: Dans un tel cas, pourquoi faire du logiciel libre ?
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 10.
Pourquoi ? Je dirais plusieurs possibilités :
La connaissance libre : https://zestedesavoir.com
[^] # Re: Dans un tel cas, pourquoi faire du logiciel libre ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 9.
D'autres cas:
* Le projet utilise du code GPL et est donc obligé de fournir toutes ses sources à ses clients, mais sans avoir envie que les gens se les approprient,
* Un développeur a bien envie de publier le code, mais sans avoir forcément le temps de le faire correctement,
* Un développeur a senti le vent tourner, et décide de publier les sources de son projet avant qu'il soit annulé et que tout parte à la poubelle (ça s'est produit par exemple pour Tracker, l'explorateur de fichiers de BeOS)
Parfois plus simplement, des gens ont entendu parler du logiciel libre et se disent "trop bien, on a juste à publier nos sources sur un serveur FTP et plein de gens vont venir travailler gratuitement pour nous" ou un truc de ce genre. Parfis au départ il y a quelqu'un qui a essayé de vendre le logiciel libre à son boss, mais le message n'est pas complètement passé…
De façon générale ça peut être plein de sortes de malentendus de ce genre qui aboutissent à un compromis bizarre. Sans forcément de mauvaises intentions pour autant.
[^] # Re: Dans un tel cas, pourquoi faire du logiciel libre ?
Posté par windu.2b . Évalué à 4.
Moi, j'y vois plusieurs raisons (compatibles entre elles) :
* le code était proprio et a été libéré, tel quel. Mais tout ce qui dépendait de choix internes (IDE et donc son fichier workspace, libs, …) ainsi que tout ce qui gravite autour (documentation) n'a pas été libéré/adapté en conséquence, parce que ça prendrait du temps.
* Le code a été libéré, pour faire plaisir ou parce que c'est dans l'air du temps. Donc, là encore, on fait le minimum syndical.
[^] # Re: Dans un tel cas, pourquoi faire du logiciel libre ?
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 2.
Exact, y'a ça aussi.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Dans un tel cas, pourquoi faire du logiciel libre ?
Posté par beckbeckbondieu . Évalué à 3.
Ça peut aussi permettre de répondre à un appel d'offre qui exige une licence libre, je suppose
# Autre plus subtil: trop complexe à modifier pour le public du projet
Posté par Jean Gabes (site web personnel) . Évalué à 5.
salut,
dans le genre j'ai eu à gérer un autre cas: une société qui souhaite participer au projet en mettant des devs à dispo, mais qui te dis en off très clairement que par contre elle compte faire en sorte que seuls des dev professionnel (aka les siens) ne pourront modifier le code (alors que le projet a toujours voulu qu'un utilisateur "standard" soit capable sans avoir fait une thèse en génie logiciel).
Là l'effet est imparable: byebye les patchs communautaires, et tu es obligé de passer par elle pour demander une évolution.
Mais c'est plus "professionnel" donc c'est mieux hein ^
[^] # Re: Autre plus subtil: trop complexe à modifier pour le public du projet
Posté par Olivier . Évalué à 4.
À l’époque d’OpenOffice.org, tout contributeur externe à Sun (puis Oracle) devait signer un «Contributor Agreement» qui accordait un droit de propriété du code à Sun (puis Oracle). Ça a toujours été controversé dans la communauté autour d’OOo.
[^] # HS CLA
Posté par Zenitram (site web personnel) . Évalué à 4. Dernière modification le 13 juin 2018 à 13:58.
le sujet de CLA n'a absolument rien à voir avec le sujet débattu (aucun "effet est imparable"), c'est complètement orthogonal.
Et depuis, on s'est rendu compte que les CLA étaient assez utiles (coucou VLC qui en a chié pour relicensier en LGPL).
Un journal sur le sujet : Utilité des CLA quand on fait du libre et que du libre
[^] # Re: HS CLA
Posté par Olivier . Évalué à 5.
Je ne répondais pas au journal mais au commentaire précédent.
Que cela puisse avoir une utilité pour la boîte qui l’exige, oui, bien sûr.
Mais que cela soit propice au logiciel ou au développement d’une communauté, c’est une autre affaire.
OpenOffice.org exigeait la signature d’un CA, ainsi que l’écriture de spécifications pour les nouvelles fonctionnalités. C’était assez procédurier.
Le build était réputé compliqué sur Linux et super chiant sur Windows.
Ajoutons à cela que le code d’OOo était typique du plat de spaghettis difficile à démêler (et que pas grand-chose n’était fait pour y remédier).
Rien n’était fait pour faciliter les contributions extérieures au code, et Sun y semblait même réticent. Remonter des patchs upstream, c’était lent et compliqué, semble-t-il. Ce n’est pas pour rien qu’il y avait un fork nommé Go-OO.
Sun/Oracle ne sont jamais allés aussi loin que ce que décrit le journal, mais on était dans une situation intermédiaire où il y avait une volonté forte de garder la mainmise sur le produit en limitant les contributions au code (mais pas sur le reste).
Donc, pour citer le journal, rien de simple pour ceux qui avaient «besoin de modifier ces logiciels tiers, pour gérer un cas spécifique». Et c’était voulu.
À la naissance de LibreOffice, les premières choses faites ont été :
— supprimer le Contributor Agreement (à la place on spécifie juste la licence du patchs et la plupart des dévs déclarent que tous leurs patchs présents et à venir sous la licence de LO),
— oublier l’exigence d’écrire des spécs,
— simplifier les procédures de build,
— simplifier le code (procédure qui a pris des années, des millions de lignes de code supprimées).
Apache aussi a fait de même pour OpenOffice (dans une moindre mesure, faute d’un nombre suffisant de contributeurs).
Le code d’OOo a fait l’objet d’une guerre larvée entre Sun/Oracle, Novell, IBM, avec des intentions affichées pas toujours très claires, guerre qui s’est poursuivie dans une certaine mesure entre TDF et Apache. (C’est IBM qui a poussé Oracle à publier OOo sous licence Apache, après son abandon par Oracle, suite au fork LibreOffice. IBM, pour rappel, produisait un fork d’OOo nommé Lotus Symphony, mais a toujours été réticent à reverser les patchs upstream à Sun, pour les raisons qu’on devine. On peut présumer que la licence Apache convenait mieux à IBM pour produire un fork payant sans avoir nécessairement à reverser les sources.)
[^] # Re: HS CLA
Posté par Zenitram (site web personnel) . Évalué à -4. Dernière modification le 14 juin 2018 à 08:26.
D'après toi, d'où venait les mots "effet est imparable"? Du journal?
Ca commence bien…
Je persiste donc, surtout à la vue de ce genre de phrase qui montre l'attention prise à ma réponse.
Opposer, toujours opposer, sans imaginer qu'un logiciel peut être étroitement lié à la boite qui le soutient…
A partir de cette opposition, difficile de discuter.
Je fais un édit sur ma première réponse : CA, ça veut dire CAA ("je te file tous les droits et je les perd"), ou CLA ("je te file e droit de faire comme moi sans rien perdre")? A ma connaissance, c'était CAA, et le CAA pose des problèmes et n'est plus vraiment utilisé.
Mais ça reste toujours orthogonal au libre.
4 choses donc. Et tu n'as aucune idée si la suppression du CLA a aidé ou pas.
Un peu comme les gens disant que Linux a marché sur BSD grâce au copyleft pour faire dire que le copyleft marche mieux que le copyfree (en fait, on soupçonne que c'est plus à cause de procès intentés sur BSD au début et à la gestion du meneur).
Sinon, les projets GNU demandent carrément de transmettre les droits, jQuery a un CLA, Mozilla aussi (un peu joueurs, passent par "set of licenses acceptable to the Mozilla Foundation"), OpenStack… et ne s'en portent pas plus mal. Ha, Wikipedia aussi, ils sont même passé de GFDL à CC-BY-SA (ouf), c'est pourri Wikipedia à demander à ce que tu ne puisses pas bloquer un changement de licence sans qu'on doive virer tes contributions?
Bref, tu ne sais pas.
Mais tu n'as toujours pas dit en quoi c'est lié au libre, au journal, ou au commentaire auquel tu répondais. La gestion légale (aussi connue par "évitons les merdes plus tard", parce que du monde en a connu des merdes quand il y a eu un petit problème à régler pour le projet mais que les gens ont dit "ha ben non moi je ne veux pas") n'est pas pour "faire chier" c'est à dire bloquer les autres comme ce dont on parle, et n'influe pas sur l'utilisabilité ou l'extensibilité du code (mais par contre ça peut permettre de filtrer les chieurs :) ).
Les CLA sont un tout autre débat sur savoir comment on veut piloter un projet dans le futur, au mêe titre qu'un débat Copyleft contre Copyfree tout aussi orthogonal, pas sur comment gérer (utiliser, contribuer) sur l'existant.
[^] # Re: HS CLA
Posté par Olivier . Évalué à 4. Dernière modification le 14 juin 2018 à 11:24.
Mon commentaire ne soutenait ni n’infirmait le commentaire auquel il répondait, ce n’est qu’une remarque (trop) anodine qui aurait mérité plus de développement, ce que j’ai fait après coup.
Les comportements décrits par le journal, le commentaire auquel je réponds, et mon second commentaire mentionnent des méthodes pour tenter de garder la mainmise sur du code, ce que j’ai fait aussi, sans porter de jugement, tu noteras. Je m’en moquais à l’époque et c’est toujours le cas. Je ne crois pas beaucoup à « l’esprit du logiciel libre », car chacun y met un peu ce qu’il veut. L’esprit, c’est surtout la licence, et elles sont trop divergentes pour avoir le même « esprit ». Et les pratiques sont encore plus divergentes.
Les nouveaux contributeurs à la naissance de LibreOffice sont venus rapidement dès l’annonce du fork qui a été accueilli avec une joie et une impatience qui m’ont étonné. Donc, avant les autres avantages que j’ai listés.
Dans le fond, je ne fais que redire ce que tu peux lire ici : https://books.google.fr/books?id=jchHDwAAQBAJ&pg=PT70&lpg=PT70&dq=openoffice.org+contributor+licence+agreement&source=bl&ots=amrkTcxKJJ&sig=ya3OQvrlPLf1YUgoc89Ymgt8Y20&hl=fr&sa=X&ved=0ahUKEwioztnI2NLbAhUE6xQKHb4NDPgQ6AEIezAJ#v=onepage&q=openoffice.org%20contributor%20licence%20agreement&f=false
Pour le rapport au journal, relis la première partie. Car si on veut ajouter/modifier une fonctionnalité à un LL, souvent on veut l’intégrer à l’upstream pour éviter d’avoir à gérer un fork ad vitam æternam. Or, si l’upstream limite, refuse ou ralentit l’intégration des contributions extérieures, ou si la genèse des builds est compliquée, voilà qui demande un fournir une somme de travail « déraisonnable » ou au moins non négligeable.
Ensuite, tu as aussi des gens pour qui les CLA sont apparemment rédhibitoires. Qu’on juge ça bien ou mal, une fois de plus, je m’en moque. Mais il y a bien limitation à la contribution par diverses méthodes plus ou moins volontaires. Le cas OOo est bien sûr loin d’être aussi radical par rapport à ce que le journal évoque, mais les pratiques choisies ont quand même eu un impact sur le développement communautaire.
OpenOffice.org, c’était un cas limite, qu’il me semblait intéressant de rapporter. Comme dit le journal, « quelqu’un ne veut pas que les libertés soient trop utilisées »…
Enfin, sache tout de même que j’ai failli ne pas répondre à ton message et que si je prends cette peine (cette réponse n’apportant rien de vraiment important à mon commentaire précédent, seulement des précisions), c’est seulement pour te demander ce que tu espères à t’élever au rang de tribunal comme tu le fais régulièrement ici, à te dresser en inquisiteur, à exiger des réponses comme si on te devait quelque chose, en imputant, semble-t-il, des propos à tes adversaires qu’ils ne défendent pas nécessairement. Ce n’est pas la première fois que tu me fais le coup, je crois me souvenir (mais j’avais peut-être un autre pseudo à l’époque). Tes “rappels à l’ordre” désobligeants frappent un peu tout le monde de toute façon. Bref, sérieusement, qu’est-ce que tu attends de nous du haut de la chaire où tu t’es hissée ?
Parce que mon propos est globalement assez anodin, je ne faisais que rapporter des événements, des faits, ainsi que des choses lues ici et là. Je me suis contenté de douter que les CLA soient propices au développement d’une communauté (ce qui n’est pas un jugement de valeur sur les CLA), et voilà que tu me lances ta foudre. Sérieusement, WTF ?
Mozilla demande un CLA, OK. Mais Mozilla n’est pas Sun, ou Oracle, ou Microsoft. Et même là, rien ne garantit que ça ne rebute personne non plus. Bref, toi non plus, « tu ne sais pas ».
[^] # Re: HS CLA
Posté par Zenitram (site web personnel) . Évalué à -1.
Bah… Comme des gens qui envoient un patch GPLv3 quand le projet et GPLv2+ et qui disent qu'il n'est pas acceptable pour eux que leur code soit dans TiVo, ça n'est pas vraiment un argument pour dire que ça gène ou pas : ici, c'est autre chose qui gène, pas une volonté de bloquer de la part de l'upstream. Et tant que tu mélangeras les 2 sujets (un désaccord sur des idées contre une volonté de gérer des personnes), on n'y arrivera pas à débattre.
Je ne sais pas, en effet. Comme toi. Mais toi te permet d'affirmer que c'est plus gênant qu'utile, en critiquant bien les CLA, surtout en de grandes phrases "ça plait à l'entreprise mais bof pour le logiciel". Désolé, mais je réagis face à ça.
Mais sinon, rigolo tu viens juste de te contredire en laissant Mozilla pas dérangeant à faire un CLA : tu montres que ce n'est pas un problème du libre ou de la contribution en général.
Euh… Je réagis surtout quand il y a des affirmations "c'est comme ça, pas bien parce que moi j'ai décidé", exemple ici avec les CLA. Pour indiquer aux autres surtout que c'est loin d'etre la vérité absolue comme c'est balancé.
Je n'exige rien, je réagis juste, après ça peut ne pas te plaire, forcément je contredis la personne qui affirme des choses :-D, la personne doit défendre alors ses idées et la ça coince souvent (avoir des idées c'est facile, les confronter c'est une autre paire de manches).
J'ai un fantasme que les gens ne considère pas leur point de vue comme la seule vérité. Par exemple ici les CLA sont montré comme pas bien, alors que ça dépend énormément des gens (et ça peut être bien pour le projet, scoop : c'est même pour ça que des gens font des CLA).
Bon, la on part dans les attaques personnelles alors que j'attaquais les idées, il est temps de laisser tomber le "débat" (attaquer la personne est banalement classique quand on n'a un soucis à attaquer les idées). Oui, j'espère aussi avoir des débats d'idées… Ce qui n'est pas facile quand ça part en attaque personnelles.
[^] # Re: Autre plus subtil: trop complexe à modifier pour le public du projet
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 7.
ça semble normal pour n'importe quel projet, hein. Si tu ne fais pas ça, un contributeur de ton projet peut venir 15 ans après et dire "hey j'ai changé d'avis, vous pouvez plus utiliser mon code". Ou si tu décides un jour de changer la licence pour les versions futures, tu dois contacter tous les contributeurs un par un pour demander s'ils sont d'accord. Ce qui est un gros bazar sur un projet comme OpenOffice, ou tu vas probablement te retrouver avec des adresses mail qui marchent plus, etc.
Donc la solution, c'est de faire signer un CLA, ou chaque contributeur dit "ok, si vous voulez changer la licence dans le futur, je dis tout de suite que je suis d'accord". ça semble être la moindre des précautions à prendre pour que la chose reste gérable.
[^] # Re: Autre plus subtil: trop complexe à modifier pour le public du projet
Posté par Olivier . Évalué à 2.
C’est tellement normal que LibreOffice y a renoncé et ne s’en porte pas plus mal. Au contraire, l’abandon de la signature du Contributor Agreement lui a fait gagner beaucoup de contributeurs, qui visiblement n’en voulaient pas.
Apache y a renoncé aussi.
Et pour autant que je sache, la plupart des projets FLOSS n’exigent rien de tel.
[^] # Re: Autre plus subtil: trop complexe à modifier pour le public du projet
Posté par Albert_ . Évalué à 2.
Mouhais les projets fsf le demande… En tout cas pour gcc c'était le cas il n'y a pas si longtemps (j'ai la flemme de chercher si cela changé)
[^] # Re: Autre plus subtil: trop complexe à modifier pour le public du projet
Posté par gUI (Mastodon) . Évalué à 4.
Oui enfin il y a une nuance avec le sujet du journal (qui est de pouvoir profiter de ses libertés).
Admettons une entreprise qui commercialise un logiciel "Bidule", sous licence libre. Ca signifie que n'importe qui peut lire, modifier et exécuter le logicel. N'importe qui peut également le dériver en un logiciel "Truc".
Mais ça ne signifie en rien que Bidule est communautaire, que n'importe qui peut faire ce qu'il veut de Bidule. C'est l'entreprise qui en fait ce que bon lui semble, c'est tout.
Et si elle ne veut pas de contributions, ça n'enlève strictement rien aux libertés à l'utilisateur final du logiciel Bidule.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Autre plus subtil: trop complexe à modifier pour le public du projet
Posté par Thomas Douillard . Évalué à 2.
Je suis intrigué.
C’est supposé passer par quel biais? Utilisation d’outils de génie logiciels pas standards ou avancés sous licences pas gratuites, ou qui nécessitent des connaissances particulières?
Plus qu’une volonté de faire en sorte que seuls des pros puissent contribuer, ce serait pas simplement contribuer en s’assurant que ses devs puissent utiliser leur outils et méthode habituels?
[^] # Re: Autre plus subtil: trop complexe à modifier pour le public du projet
Posté par Jean Gabes (site web personnel) . Évalué à 2.
Non c'est plus simple et efficace que ça: juste complexifier le code à l’extrême. Là où par exemple tu as un cas d'utilisation assez simple, bah tu vas utiliser 36 libs tierces pour obtenir le même résultat, et là bon courage si tu ne connais pas les subtilités de ces libs, comment (bien) les imbriquer etc etc.
ou alors mettre 4 niveaux de classes là où tu sais pertinemment que tu n'auras jamais besoin de créer de nouvelles classes filles. Etc etc.
En fait c'est assez simple comme méthode: tu prends tout le bon sens qui te fais dire en général: "non là c'est too much, ça va devenir imbitable à maintenir et débugger", bah tu le supprime. Tu auras un code certe open, mais good luck a qui veux le modifier s'il n'est pas parmi ceux qui l'ont complexifier juste pour le complexifier.
[^] # Re: Autre plus subtil: trop complexe à modifier pour le public du projet
Posté par Albert_ . Évalué à 4.
Oui enfin ca c'est aussi (surtout?) utiliser dans les entreprises qui font du closed-source par certains devs pour se rendre "indispensable" c'est tres tres loin d'etre limite a l'opensource.
[^] # Re: Autre plus subtil: trop complexe à modifier pour le public du projet
Posté par Jean Gabes (site web personnel) . Évalué à 2.
Oui oui, juste que ça peux l'être aussi en Open Source de manière consciente et calculée :)
[^] # Re: Autre plus subtil: trop complexe à modifier pour le public du projet
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 2.
JE crois me souvenir que l'ancien driver "nv" de nvidia étais livré de cette manière. Il y avait 2 drivers produit par nvidia:
- Le propriétaire
- le driver open source compatible avec le noyau, mais en réalité illisible par un être humain.
[^] # Re: Autre plus subtil: trop complexe à modifier pour le public du projet
Posté par arnaudus . Évalué à 2.
C'est en tout cas interdit pas la GPL. Il faut fournir le code source réel, celui qui est la forme privilégiée pour être lue et modifiée par un être humain.
[^] # Re: Autre plus subtil: trop complexe à modifier pour le public du projet
Posté par arnaudus . Évalué à 3.
Mouais, les cas que tu cites semblent contribuer à pourrir le logiciel, ses performances, et son évolutivité, plus qu'autre chose. Ça m'étonnerait que ça puisse être une stratégie consciente ; il y a beaucoup plus facile à faire pour empêcher la réutilisation d'un logiciel que de le transformer en bloatware lent et impossible à débugger. C'est juste une manière de rendre son activité non-compétitive et de perdre ses clients…
[^] # Re: Autre plus subtil: trop complexe à modifier pour le public du projet
Posté par Jean Gabes (site web personnel) . Évalué à 2.
Nop, car in fine les perfs ne sont pas trop impactées, et ça faisait augmenter artificiellement le nombre de commits de cette société et donc leur lisibilité.
Je t'assure que je l'ai pris pleine face lors d'un call, que c'était un choix réfléchi et conscient :)
(ils n'étaient pas lead du projet, donc plus rude de pourrir le reste, la doc étant déjà présente etc etc).
[^] # Re: Autre plus subtil: trop complexe à modifier pour le public du projet
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3.
ça va te coûter plus cher de maintenir ton code, qu'à quelqu'un d'autre de faire un fork et de passer un peu de temps à le nettoyer. Et en plus le fork sera 10 fois moins lourd, aura moins de bugs, etc.
Je ne vois pas comment cette recette peut être gagnante.
[^] # Re: Autre plus subtil: trop complexe à modifier pour le public du projet
Posté par Jean Gabes (site web personnel) . Évalué à 3.
Oui, si il y en a qui veulent forker. Dans les faits, beaucoup en parlent, très (très) peu le font ^
[^] # Re: Autre plus subtil: trop complexe à modifier pour le public du projet
Posté par gouttegd . Évalué à 6.
Ça me fait penser à ce billet de « Jean-Pierre Troll » (aussi paru dans GNU/Linux Magazine France) : Comment être indispensable à un projet
# Quelques mélanges
Posté par Zenitram (site web personnel) . Évalué à 5.
Pas mal… Mais un bémol :
Je trouve qu'il y a un mélange entre 2 cas en grosse maille :
- Le fournisseur cache quelque chose
- Le fournisseur ne cache rien
Dans le deuxième cas, tu n'aimes pas mais même l'esprit du libre est respecté : l'idée est qu'on te fournisse ce qui a été utilisé pour compilé, pour que tu sois à armes égales. Si les répertoires sont codés en dur, si le code dépend d'un environnement précis, ça reste dans l'idée du libre car on t'as fourni ce qui a été utilisé. C'est orthogonal au libre, c'est plus lié à une façon de développer.
Donc à ne pas mettre dans le même sac vis à vis du libre.
Tout à fait, ce n'est pas l'idée, l'idée est de fournir ce qui a été utilisé (facile ou pas, le but n'est pas d'ajouter des contraintes).
Mais note que des libristes l'oublient souvent, et hurlent que c'est horrible quand une boite pose le code qu'il ont (tout le code, projets compris) en libre suite à des demandes. C'est à mon avis très contre-productif (j'ai entendu des dizaines de fois des gens dirent qu'ils n'ont rien contre le libre, mais qu'ils n'ont pas envie de devoir mettre au propre et gérer les réactions, et du coup on perd du code libre comme ça, à demander aux gens de travailler plus que poser le workspace), d'où ma remarque sur séparer entre les gens cachant des choses et des gens posant en l'état leur code.
[^] # Re: Quelques mélanges
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10.
On a aussi l'inverse, des gens qui disent "je publierai mon code quand il sera propre et fini". Et ça n'arrive souvent jamais.
Donc oui, merci aux gens qui publient leur code, même sale, même chiant à compiler, même pas fini, même si c'est un truc qui n'a pas servi depuis 15 ans (coucou Autodesk Animator). C'est toujours mieux que de repartir de rien.
[^] # Re: Quelques mélanges
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 2.
En fait, je pense qu'on dit bien la même chose. Mon journal part du constat « naturel » de base de quelqu'un qui connait de loin le monde du libre sans s'intéresser aux détails, et conclut sur ce que c'est vraiment qu'un projet libre du point de vue de la réutilisabilité.
La connaissance libre : https://zestedesavoir.com
# Mettre à dispo du code coûte cher
Posté par damaki . Évalué à 3. Dernière modification le 13 juin 2018 à 15:58.
Pour avoir déjà eu l'intention de mettre du code à disposition en entreprise et abandonné, faute de moyens, c'est loin d'être gratuit. La question devient donc : vaut-il mieux ne pas mettre à disposition du code que de mal le faire ? Bref, on a un fork de dbdeploy compatible avec SQL Server qui ne sera jamais partagé.
Hors entreprise, j'avoue aussi avoir mis en ligne pas très exploitable sur github. On en revient au même problème : publier du code coûte du temps et/ou de l'argent. Si l'argent ne sort pas d'une stratégie de communication, de recrutement ou d'une volonté d'attirer des contributions externes gratuites, ça me semble frêle.
Cependant, là il faut être un peu positif ; ça n'est pas parce que le code n'est pas directement utilisable qu'il ne le sera jamais. Il est souvent possible de demander un peu d'aide aux mainteneurs du repo ou du projet, puis de leur offrir la doc qu'on a ainsi faite. Et s'il n'y a ni doc ni mainteneurs actifs, eh bien qu'il crève ce code. C'est tout ce qu'il mérite.
[^] # Re: Mettre à dispo du code coûte cher
Posté par Marotte ⛧ . Évalué à 4. Dernière modification le 13 juin 2018 à 21:45.
Ça demande du travail mais est-ce si important que ça ?
Tu parles d’un fork… c’est donc que les sources de ce programme sont déjà dans un dépôt Git, que vous utilisez en interne pour le développer ?
En quoi cela représente un travail supplémentaire d’avoir ce dépôt accessible par n’importe qui plutôt qu’accessible uniquement par une équipe en interne ?
Sans parler d’étudier et éventuellement accepter les propositions venues de l’extérieur, juste la publication en elle-même… elle ne coûte pas grand chose.
Je ne sais pas ce qu’il en est aujourd’hui mais en 2009 des gens cherchaient à utiliser dbdeploy avec SQL Server. Si votre fork est fonctionnel et utilisé dans votre structure il y a une chance qu’il y ait au moins une autre structure dans le monde que ça puisse intéresser.
[^] # Re: Mettre à dispo du code coûte cher
Posté par Context . Évalué à -1.
Perso j'évoquerais bien les termes de coûts en terme d'image: je place mon code sous licence(s) libre(s) comme ça j'ai belle figure ! J'irais même jusqu'à dire que le placement sous licence libre serait une stratégie marketing ! Car comment évoquer des coûts d'écriture en tel langage moins courant, moins réversible, mais plus long à écrire, plutôt que dans tel autres plus simple, ou encore d'autres stratégies très bien décrites par SpaceFox, sinon par un désir de jouer à la cachouille ?
Juste envie de dire qu'en matière de liberté on ne peut pas parler de coût, car la liberté n'a pas de prix. On peut parler de contraintes, d'implications, de retours… mais pas d'argent, désolé.
Soit on joue le jeu de la liberté, soit on ne le joue pas !
Soit on accepte de travailler avec la communauté et on place son travail dans le domaine public en commençant par le commenter proprement et on attire de la collaboration, soit on joue la cachouille en adoptant une licence proprio ou même en se faufilant entre les licences libres, mais après faut pas s'étonner si on reste seul sur le projet !
Les logiciels intéressants c'est aujourd'hui que l'on en a besoin, pas demain !
Tiens ça me rappelle début des années 2000 les startupeurs qui vilipendaient le libre :D
[^] # Re: Mettre à dispo du code coûte cher
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 2.
Si, mettre du code sous licence libre a un coût. Tu ne peux pas le nier sinon ça va jamais marcher en entreprise. Par contre, tu peux le justifier et le "vendre": expliquer les bénéfices (en termes d'image, de contributions externes, etc) et montrer que finalement, le coût initial n'est pas si important que ça en regard.
Mais si tu essaies de faire du libre sans investir sérieusement dedans, ça ne marchera pas. Et le décideur pressé va retenir ça: "le libre, ça marche pas on a essayé". Ne gâche pas ta chance et fait les choses proprement dès le début, merci :)
[^] # Re: Mettre à dispo du code coûte cher
Posté par Zenitram (site web personnel) . Évalué à 2.
Vous pouvez dire lequel? Vou parle de coût, mais désolé je ne vois pas : mettre un fichier de licence, pusher sur le Git public plutôt que privé, écrire "posé la, faite ce que vous voulez mais ne m'emmerdez pas avec", bloquer les trackers sur GitHub, et basta, ça coûte tant que ça pour vous?
Tu parles de libre, ou d'autre chose? quoi "ça marche pas"? Je ne vois pas de quoi tu parles, le libre c'est fournir le code, il n'y a rien à faire marcher pour l'entreprise.
Si tu parles de "retour sur investissent" (des commits en retour), ce n'est pas du libre.
Pour ne pas gâcher, il faut commencer à expliquer ce qu'est le libre, et le libre n'a rien à voir avec un truc qui marcherait ou pas (ou file surtout ce qu'on a, avec une licence).
Bref, il faudrait surtout commencer à ne pas parler du libre comme quelque chose qu'il n'est pas.
[^] # Re: Mettre à dispo du code coûte cher
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 7. Dernière modification le 14 juin 2018 à 14:18.
En fonction du projet, oui, libérer du code source, ça a un coût. Par exemple, pour libérer du code, on peut devoir :
Bref, ça peut être un boulot énorme. Et bien sûr, qui dit suppression de code ou autre info confidentielle, veut dire publier les sources sur un nouveau dépôt sans l'historique de la période "proprio". Cela peut avoir des répercussions sur l'intégration continue ou je ne sais quoi d'autres…
Je ne parle pas non plus des coûts liés à l'administratif dans les grosses boites, genre la demande "bonjour, je veux pouvoir poser ce tar.gz sur le serveur XY" qui doit passer par un mille-feuille administratif, ensuite passer par le service admin système pour ouvrir des accés, préparer l'hebergement etc…
Bref, des raisons de coûts, on peut en trouver plein, en fonction de la complexité du projet, de son historique, de la taille de la boite, de la volonté de faire bien les choses ou pas etc..
Et si tu n'es pas convaincu, je te propose de voir (ou revoir) Code Rush, le documentaire qui retrace la libération de Netscape 4, qui devint alors le projet Mozilla. Typique d'une libération d'un projet qui contient du code proprio que l'on ne veut pas libérer, qu'il faut pouvoir compiler avec des outils open-sources, avec en plus ici (un peu particulier certes), l'ouverture aux outils d'intégration continue, au bug tracker, sans compter l'ouverture d'un site dédié etc..
[^] # Re: Mettre à dispo du code coûte cher
Posté par Zenitram (site web personnel) . Évalué à 2.
La, je suis d'accord, ça bouffe (beaucoup) de temps.
Tu prend le dernier master, et tu pushes qu'un commit "global", pas long. décorrélé du libre.
La, je ne suis pas du tout d'accord, c'est décorrélé du libre justement. C'est en associant les deux qu'on démotive des entreprise à libérer, alors que ça n'a pas grand chose à voir (le libre est mettre à disposition ce qui a été utilisé pour compiler, chemins en dur si c'est dans le code, rien ne dit que ce n'est pas libre si chemins en dur). On peut libérer sans vouloir gérer, ou libérer en proposant un écosystème, c'est un choix et non une obligation.
[^] # Re: Mettre à dispo du code coûte cher
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à -1.
Tu peux expliquer dans ce cas, quel est l'intérêt de faire du libre si on ne veut rien gérer? J'ai un peu de mal à voir ce que ça peut apporter dans ce cas?
[^] # Re: Mettre à dispo du code coûte cher
Posté par Zenitram (site web personnel) . Évalué à 5.
Tu peux expliquer dans ce cas, quel est le rapport avec le libre si on ne veut rien gérer?
Rappel : le libre s’intéresse à celui qui reçoit un code, et pas un autre code (bref, les 4 libertés du logiciel libre). Il n'a rien à faire de celui qui développe, parler d'un retour vers le développeur est hors sujet par rapport au libre.
Récupérer des patchs, de testeurs, des retours utilisateurs, ça se fait en non libre genre CC-ND-NC, ça n'a rien à voir avec le libre, c'est justement le message que je passe depuis le début : vous mélangez libre d'un côté et communautaire / retours attendus de l'autre, et c'est bien ma critique (comme ma critique dans le journal mis en lien, on peut essayer de choper des patchs de la communauté sans faire de libre).
Bref, je te défie de me démontrer le rapport entre ce dont vous parlez et le libre.
Ps : pour l’intérêt, ben ce sont les arguments classiques sur le libre (qui ne sont pas des arguments sur des retours de patchs).
[^] # Re: Mettre à dispo du code coûte cher
Posté par Guillaume Denry (site web personnel) . Évalué à 6.
Quelque chose que je ne sais pas évaluer : la réputation de l'entreprise qui libère un code crade et non utilisable tel quel.
[^] # Re: Mettre à dispo du code coûte cher
Posté par Zenitram (site web personnel) . Évalué à 3.
Tu marques un point.
Avec quelques bémols :
- Vu ce qu'on nous pond comme code des fois pour remplir les obligations de la GPL (c'est à dire que les gens ne voulaient pas ouvrir mais ont dû), il y a de la marge sur les critiques de qualité :).
- Ca va être plus sensible si c'est une assez grosse boite, pour la "réputation" à cause des râleurs qui vont trouver une cible. Pour une petite boite, je dirai que tout le monde s'en fou. Mon code est pas propre / tout pourri, et on ne m'a jusqu'à maintenant pas fait de remarques à part des gens voulant faire des attaques personnelles, une paire de fois (non, je ne penses pas à des gens de LinuxFr…)
Après, oui, je comprend que "risque sur réputation" contre "à quoi ça me sert si je pose juste comme ça", ça peut faire pencher la balance sur ne pas ouvrir. Les quelques cas (en dehors des "GitHub c'est pratique, je te pose le truc la pour l'hébergement gratos, le plus classique quand même) où j'ai vu une entreprise changer de position sur la libéralisation est quand un gros client a demandé en libre (le code lui même ne vaut pas grand chose, c'est la maintenance qui rapporte, alors tant qu'à faire, autant filer à tout le monde).
Bref, bonne raison de ne pas le faire mais sur laquelle on peut faire changer une entreprise pas grosse sur le sujet, question de "sensibilité" sur le sujet.
[^] # Re: Mettre à dispo du code coûte cher
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 1.
Certes. Tu peux faire un "lancer de code" avec une licence sur Github et on en parle plus. Mais dans ce cas il ne faut pas s'attendre à avoir automagiquement des retours positifs et plein de gens qui contribuent. Je suis d'accord, c'est quand même du libre on a rien à reprocher et c'est déjà très bien.
Mais si on veut profiter des retours de la communauté, des contributions d'autres gens, etc, il faut s'investir un peu plus que ça. ça n'est pas nécessaire, mais ça peut être une bonne justification pour faire du logiciel libre.
[^] # Re: Mettre à dispo du code coûte cher
Posté par Zenitram (site web personnel) . Évalué à 0.
Ca tombe bien, ce n'est pas le but du libre.
Je n'ai pas dit le contraire, mais tu mélanges beaucoup de choses très orthogonales : tout ce dont tu parles n'a pas besoin de libre (du CC-ND-NC va très bien pour).
Ben non, c'est se tromper sur ce qu'est le libre. Ce n'est pas parce que tu "vends" le libre avec des arguments hors sujet que je dis amen fonce. J'aime bien ne pas mentir aux gens.
Si une entreprise veut profiter des retours de la communauté, des contributions d'autres gens, etc, pas la peine de faire du libre (ce n'est pas le sujet, on peut filer moins de libertés si c'est juste ça le but, ça évite les forks tout en ayant les contributions).
Désolé, mais je croyais qu'on parlait de mettre en libre, donc j'ai répondu en pensant au libre, pas à d'autres choses orthogonales (qui ne demandent pas de faire du libre), faudrait préciser que vous parlez hors sujet sinon on s'y pomme.
# Valeur pécuniaire du logiciel libre
Posté par Marotte ⛧ . Évalué à 7.
Ou qui propose un service payant, notamment l’intégration de leur produit. Un logiciel libre ayant un coût de licence égal à zéro, il faut bien gagner de l’argent quelque part.
Ardour demande par exemple de payer pour avoir le binaire pour Windows. Ils pourraient très certainement le fournir gratuitement, mais personnellement ça ne me choque absolument pas qu’ils facturent ça. Et pourquoi pas ? C’est libre donc toujours éligible au DIY si on tient absolument à ne pas rémunérer l’éditeur du logiciel.
Idem pour la documentation… Où est le problème à ne fournir gratuitement qu’une doc d’installation succincte, que seule une personne très compétente sera en mesure d’utiliser, et faire payer pour un manuel détaillé pas-à-pas, qui permet à tout un chacun d’installer le soft en autonomie ?
[^] # Re: Valeur pécuniaire du logiciel libre
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 2.
Oui, c'est bien ce que je dis en conclusion.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Valeur pécuniaire du logiciel libre
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3.
ça me rappelle les histoires avec XChat qui a voulu faire payer les binaires Windows. Sauf que c'est un logiciel libre et qu'une autre personne (silverex) fournissait déjà gratuitement les dits binaires. ça s'est mal fini et ça a forké, et maintenant tout le monde utilise hexchat à la place.
Ce modèle ne me semble pas être le plus malin. Je me dirigerais plus volontiers vers la vente de support, et éventuellement le financement du développement de nouvelles fonctionnalités. Faire payer le travail des devs plutôt que le produit fini, donc.
[^] # Re: Valeur pécuniaire du logiciel libre
Posté par Zenitram (site web personnel) . Évalué à 2.
Il l'est si tu as un plus, par exemple une réputation, un nom (dont tu as déposé le trademark, de préférence).
GCompris le fait et à ma connaissance la version recompilée Windows sans limitations n'est pas la plus téléchargée. Pareil pour Ardour.
[^] # Re: Valeur pécuniaire du logiciel libre
Posté par Marotte ⛧ . Évalué à 4. Dernière modification le 14 juin 2018 à 19:02.
Fournir un binaire pour un système donné ce n’est rien de plus que du support. C’est comme si tu fournissais le support facilitant l’utilisation (la compilation peut être assimilée à de l’utilisation si on réduit le logiciel à son code source), car le coût de la compilation et de l’hébergement du fichier en eux-mêmes sont négligeables. Toute la valeur est dans le savoir-faire.
Le libre exige de donner accès au code source, c’est une condition nécessaire pour exercer les droits procurés par la licence, mais elle n’exige finalement rien d’autre ! Du coup la méthode : « les sources sont là, démerde-toi, si tu as besoin d’aide il va falloir nous payer! » est tout à fait dans l’esprit du libre. Même si le retrait du Makefile ou assimilé est quand même limite…
J’ai l’impression que c’est souvent le binaire pour Windows pour lequel on demande une participation. C’est peut-être une idée que je me fais mais la compilation d’un programme sous Windows est plus complexe, nécessite plus de compétences que sous Linux. J’ajoute que si ça peut inciter des gens à utiliser GNU/Linux à la place de Windows sur leur PC c’est très bien aussi :)
Par ailleurs, les utilisateurs, ces victimes rackettées par des gangs de barbus de garage qui leur extorquent jusqu’à leur slip, peuvent toujours se tourner vers d’autres pour obtenir cette aide pour utiliser le programme Machin sur leur Windows adoré. Ce n’est quand même pas aussi contraignant qu’un logiciel propriétaire qui t’interdit tout simplement d’aller chercher de l’aide ailleurs…
En ce moment j’utilise Sky. Je n’ai jamais creusé la question, ou été confronté au problème, mais je ne serais pas vraiment étonné que le binaire que j’installe puisse avoir des fonctionnalités limités et qu’ils fassent de la double licence. J’ai décidé de leur faire confiance, il n’y a pas l’air d’y avoir trop le choix pour Skype sous Linux en dehors de cette boîte.
[^] # Re: Valeur pécuniaire du logiciel libre
Posté par Zenitram (site web personnel) . Évalué à 4.
C'est un préjugé, c'est aussi simple différemment : pas de ligne de commande à se taper, télécharger/installer le compilateur, double-clic sur le fichier projet, cliquer sur "compiler", et attendre que ça compile (on s'emmerde avec les dépendances d'une manière différente aussi, mais pareille "simplicité").
Juste que :
- Il y a 50x plus d'utilisateurs Windows que Linux
- Une bonne partie de ces utilisateurs déjà peu nombreux savent compiler contrairement aux utilisateurs Windows un peu moins habitués, et en plus les repos aident à se passer du dev' pour le binaire.
Donc autant se focaliser sur la grosse partie en premier.
A noter que Ardour par exemple fait payer tout le monde.
[^] # Re: Valeur pécuniaire du logiciel libre
Posté par Marotte ⛧ . Évalué à 4.
Ça j’y pensais… mais je me suis dit qu’en fait non. L’utilisateur de Linux représentatif c’est un simple geek qui va installer une distribution et jamais compiler un seul programme de sa vie, ou alors un seul, en recopiant trois commandes sans chercher à comprendre. Ou encore un non geek, à qui on aura installé ce système, qui ne saura jamais ce qu’est une compilation ou un code source.
Quand toi et moi on a découvert Linux, c’était obligatoire de le recompiler, pour un nombre extraordinaire de bonnes raisons, à commencer par faire fonctionner son matos… rien que ça… Peut-être que tu as même connu la période pré-package, où compiler était la méthode principale pour installer un programme. GNU/Linux ce n’est plus ça, c’est rien de moins que l’OS universel de demain ;)
Un compilateur libre ? gratuit ?
Quand le fichier INSTALL te donne la liste des packages pour au moins deux ou trois grosse distro il n’y a qu’une commande à lancer pour installer toutes les dépendances. Pour Windows je doute que ce soit aussi simple, à moins d’utiliser un gestionnaire comme Chocolatey ou autre, et même là…
Oui… En plus la compilation pour les autres systèmes (FreeBSD et MacOS notamment) est assez similaire à celle pour GNU/Linux, alors que celle pour Windows est particulière à ce système. La charge de travail pour fournir les binaires (et la CI…) change quasiment pas si on continue de proposer le binaire pour Windows et qu’on arrête pour un UNIX-like quelconque. En abandonnant tout ce qui est autour de ces précieux binaires pour Windows par contre, ça retire pas mal de travail.
[^] # Re: Valeur pécuniaire du logiciel libre
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 2.
La vraie raison c'est qu'il y a des distributions Linux qui vont gérer la compilation et le packaging. Donc peu de projets ont besoin de le faire d'eux-même.
# Des exemples ?
Posté par Kerro . Évalué à 0.
Qui a des exemples ?
N'étant pas développeur, je tombe plutôt sur des cas où le logiciel (parfois hyper à la mode) est installable au prix de longues heures de recherche et d'essais/erreurs. Le tuto officiel ne fonctionne pas (souvent dans les 5 premières lignes c'est déjà mort), ou les explications sont hypers légères, ou autres choses.
Parfois je sais que c'est volontaire, souvent je sais que c'est juste un problème de temps/ressources.
Et une fois que tu as bien perdu du temps à faire fonctionner le bouzin, tu te rends compte en 20 minutes qu'il ne tient pas la charge, ou que tu tombes sur des bugs hyper évidents, etc (encore une fois, y compris des trucs à la mode).
Exemple d'il y a environ un an : InfluxDB. Nous avons fait planter la partie serveur de manière répétable avec une requête relativement basique dans les 10 premières minutes d'expérimentation. Donc forcément un bug évident.
[^] # Re: Des exemples ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 6.
Les bugs ne sont jamais "hyper évidents". Je suis dev, je teste mon code autant que je peux mais j'ai pas un temps infini, et dans la plupart des projets il n'y a pas d'équipe QA. Donc c'est souvent moins léché qu'un truc développé correctement par une entreprise (on essaie d'améliorer ça mais c'est loin d'être facile).
Donc, contribue: plains toi que la doc est moisie, que ça plante dans tous les sens et que ça tient pas la charge. Avec des exemples précis. Y'a des chances que tu tombes sur un dev qui sera content de t'aider à régler les problèmes (c'est la contrepartie de ne pas avoir d'équipe QA ou support: tu as une ligne directe pour discuter avec les devs du projet, alors profites-en).
[^] # Re: Des exemples ?
Posté par Zenitram (site web personnel) . Évalué à 3.
Bof, ton cas n'est pas le cas des autres, c'est tout, pas la peine de crasher sur le logiciel que tu n'as pas payé.
Si tu veux un fix pour ton cas, tu peux toujours prendre un contrat de support, et je parie que ça sera fixé vite.
[^] # Re: Des exemples ?
Posté par Kerro . Évalué à 0.
Du coup, personne n'a d'exemple.
Donc faux problème ?
[^] # Re: Des exemples ?
Posté par GuieA_7 (site web personnel) . Évalué à 2.
J'avoue j'aimerai aussi des exemples concrets. Certes en faisant attention à ce qu'on dit (pas de procès d'intention), j'aimerai éviter aux admins LinuxFR le stress d'une nouvelle mise en demeure, mais des exemples de softs avec des pratiques douteuses à priori constatées.
Parce que c'est déjà difficile de faire passer le message du "logiciel libre c'est bien" aux décideurs ; mais si en plus on rajoute un "attention il y a des arnaques, mais vous devrez vous plonger dans la technique pour les débusquer", ça rend la chose impossible.
[^] # Re: Des exemples ?
Posté par Kerro . Évalué à 1.
Nous ne sommes pas sur un forum de décideurs, donc tu peux y aller tranquillement en donnant des exemples, personne ne va avoir peur du logiciel libre à cause de cela.
[^] # Re: Des exemples ?
Posté par GuieA_7 (site web personnel) . Évalué à 1.
Je me suis peut-être mal exprimé ; ou tu as lu trop vite. Je réessaie.
Il y a sûrement des gens qui font plus ou moins semblant que faire du libre (ou dont les pratiques derrière annihilent au moins une partie des 4 libertés). Ça serait une bonne chose d'avoir une liste de ces mauvais acteurs.
L'idée n'était pas de taire ces noms (vu que je demande moi aussi des exemples) pour ne pas faire peur aux décideurs, mais plutôt d'avoir une liste de logiciels/boîtes à éviter (liste qui pourrait servir entre autres à rassurer des décideurs sur leur choix, qu'ils viennent eux-même ici ou pas).
[^] # Re: Des exemples ?
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 16 juin 2018 à 22:04.
Il y avait un moment où une personne s'était lancé dans une notation "niveau de liberté" de chaque projet.
Problème : ça posait plus de questions qu'autre chose.
Car déjà, si tu lis ici les réactions, tu vois que plein de monde mélange libre (donc les 4 libertés) avec communautaire (faudrait un forum, du support, faut l'historique du code…), donc les "décideurs" auraient un rapport sur un truc qui n'a rien à voir avec le libre mais avec un jugement subjectif.
Pour de l'objectif, c'est très difficile de noter, car le libre demande surtout que tu fournisses ce que tu as utilisé (si le code contient des chemins en dur, ce n'est pas contraire au libre car le fournisseur a peut-être utilisé ça lui aussi, donc c'est le code en libre en entier, point), mais comment savoir si le fournisseur ne cache rien?
[^] # Re: Des exemples ?
Posté par GuieA_7 (site web personnel) . Évalué à 3.
Je suis contre l'idée d'une note (et encore plus de seulement une note), mais plutôt une liste de points factuels et vérifiables. Les notes sont pratiques car très synthétiques, mais elles cachent en effet beaucoup trop les nuances sous-jacentes, et vont alors être bien souvent trop subjectives.
Ça serait sûrement perfectible (qu'est-ce qui ne l'est pas ?), mais on nous a parlé de boites qui ne fournissent pas de makefile ou cachent des dépendances propriétaires (ce qui dans mon échelle de valeurs libriste est plus grave que les chemins en dur, pour reprendre ton exemple), mais on attend toujours des exemples.
[^] # Re: Des exemples ?
Posté par Kerro . Évalué à 0.
Toujours est-il qu'il y a pour le moment zéro personne en mesure de dire « tel logiciel pose problème comme exposé dans ce journal ». Alors que nous savons très bien qu'il en existe, dont pas mal qui sont très connus et très à la mode.
Conclusions possibles :
- ça n'intéresse que très peu de gens
- très peu de gens se coltinent l'installation de logiciel non présents dans les dépôts (pour ma part j'ai quasi arrêté car presqu'à chaque fois ça débouche sur des produits hyper mal conçus. C'est peut-être pour cela que non présents dans les dépôts)
- ces logiciels sont complexes à installer en raison du manque de moyens (par exemple c'est une petite structure qui s'en occupe, ils n'ont pas envie de passer des centaines d'heures à faire quelque chose de nickel alors qu'ils peinent à se développer financièrement). Comme ils sont sympas et ouverts, on n'a pas envie de les « dénoncer »
- … ?
[^] # Re: Des exemples ?
Posté par Krunch (site web personnel) . Évalué à 3.
Pour le cas du « faux dépôt de sources » ça m'a fait penser au kernel Red Hat (depuis RHEL6 je pense) : https://www.theregister.co.uk/2011/03/04/red_hat_twarts_oracle_and_novell_with_change_to_source_code_packaging/
(je travaillais cher Red Hat à l'époque, je n'ai pas été impliqué dans cette décision et elle a compliqué mon travail aussi)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Variant observée: projet dont tout les commentaires ont été supprimés
Posté par reno . Évalué à 4.
Par "coïncidence", l'université qui a crée le projet vend du support..
Non, les 2 n'ont aucun rapport bien sûr..
[^] # Re: Variant observée: projet dont tout les commentaires ont été supprimés
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 3.
Si je considère ce que j'ai vu passer dans ma vie professionnelle, c'est peut-être tout simplement développé sans commentaires.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Variant observée: projet dont tout les commentaires ont été supprimés
Posté par xcomcmdr . Évalué à 2.
You only code once !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Variant observée: projet dont tout les commentaires ont été supprimés
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4.
Ma code review préférée:
[^] # Re: Variant observée: projet dont tout les commentaires ont été supprimés
Posté par reno . Évalué à 2.
Je déteste cette mode "moderne", mais non ça n'était pas le cas: le script a remplacé les commentaires par des lignes blanches, donc il restait "l'empreinte" des commentaires..
# Zeste de savoir
Posté par Faya . Évalué à 3.
Pas grand chose à voir avec le sujet du journal… mais je découvre ton site et le logiciel qui le fait tourner; et je suis fan. En plus la doc est très propre et très complète. Ça me donnerait presqu'envie de me mettre à Python (enfin plus sérieusement que mes quelques hacks sales)
Bref, merci et félicitations.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.