LeBouquetin a écrit 1906 commentaires

Je me pose la question de la suivre ; tu la conseilles ?

C'est un prix normal pour une formation professionnelle de qualité.

La communauté LinuxFR est plutôt férue de techniques informatiques,

C'est réducteur et relativement faux.

Je suis d'accord que le contenu est plutôt léger mais ça n'a rien à voir avec parler de la techno plutôt que de l'outil.

Personnellement ça m'intéresse de voir qu'il y a des nouveautés dans le domaine du logiciel libre sans savoir comment ça tourne. Si je veux creuser les technos, j'approfondirai.

À noter que la GPL impose la licence du logiciel qui en dépend

Tout a fait. Je persiste cependant à penser que la FAQ de Drupal est solide et elle dit "service providers can use GPL code together with GPL-incompatible code for a client, but cannot redistribute that code to the public.", et donc ça n'importe finalement pas tellement.

Je pense aussi que la FAQ Drupal est solide - c'est pas un projet qui débarque à l'improviste. C'est peut-être lié à la réglementation en vigueur, mais c'est vrai aussi que l'écosystème Wordpress est empli de modules propriétaires ; hors le moteur Wordpress est sous GPL …

Ça m'intrigue, je vais creuser.

Je me demande si c'est pas juste une question de distribution du package : genre le vendeur du module ne vend pas "un wordpress avec son module intégré" mais "son module, que le client lui-même peut intégrer dans un logiciel GPL"… c'est peut-être ça l'astuce.

En tant que prestataire, tu es un agent du client, tu n'es pas un éditeur de logiciel qui distribue un logiciel. C'est en fait la freedom 1 qui s'applique, pas la freedom 3.

Attention : sur le plan juridique, par défaut le client n'est pas propriétaire de la propriété intellectuelle du code même si c'est lui qui paie. Il faut une clause explicite de session de droit d'auteur pour cela. Beaucoup de prestataires profitent d'ailleurs de cette incompréhension pour facturer des frais de licence sur les travaux qu'ils ont financés (cas typique : le contrat original définit un cas d'usage et le client veut sortir du cas initial).

Pour le reste je suis d'accord ; j'ai évoqué MIT mais comme dit par ailleurs LGPL convient bien aussi pour les dépendances.

À noter que la GPL impose la licence du logiciel qui en dépend, elle n'impose pas seulement qu'il soit libre (et personnellement c'est là où je bloque dans le cas où tu fais du "sur mesure" en intégrant du code GPL).

Également, il me semble qu'un code propriétaire qui dépendrait exclusivement d'un code GPL ne peut pas être diffusé, c'est la raison de l'apparition de la LGPL (tu peux t'appuyer sur une brique libre et la modifier mais tes modifs de cette brique doivent être diffusées)

faire un projet client avec un truc en GPL lié avec du code incompatible GPL tant que tu ne le distribues pas publiquement (et lui non plus)

La notion de distribution n'est pas une question de distribution publique mais de distribution à tes utilisateurs / clients.

dans ce cas, il n'est pas distribué puisque ça reste "chez toi", ou "chez le client" avec toi son agent).

Je suis dubitatif sur cette partie : si le client souhaite que tu lui fournisses les sources, tu es obligé.

Pour moi, si tu développes un outil qui s'appuie sur un moteur livré sous licence GPL et que tu veux le diffuser (publiquement ou non) tu dois diffuser sous licence GPL.

Il y a plusieurs licences libres qui ne sont pas compatibles GPL ; je ne souhaite pas diffuser des logiciels pour lesquels je n'ai pas pu choisir la licence de mon travail (c'est pour cette raison que MIT fonctionne, mais que LGPL fonctionne aussi)

Maintenant, comme dit dans un autre commentaire, dans le contexte de ce projet, ce n'est pas un sujet car l'outil est sous GPL mais c'est le résultat qu'on diffuse (et le résultat est sous la licence que l'on souhaite)

En fait je viens de percuter sur le sujet de la licence qui est un faux sujet : le code du moteur n'est pas déployé. Ça reste un outil de génération de code, pas un moteur de site.

Il faut juste distinguer clairement le contenu (éditorial + templates), ce qui est fait.

J'ai regardé tardivement et le fait que ce soit une techno Django a induit ma réflexion en erreur.

Du coup je vais creuser.

Pour être honnête, je ne trouve pas ça super cool cette manière que tu as de pousser les gens choisissant la GPL de passer à une license copyfree, qui présente des problèmes évidents que ces gens cherchent souvent à ne pas avoir en choisissant la GPL.

Je ne pousse personne à changer de licence, j'expose ma position par rapport à l'utilisation (et donc contribution) de ce projet.

J'ai eu l'occasion d'échanger avec des utilisateurs qui mettaient GPL sans avoir réfléchi au sujet copyright/copyleft/copyfree et d'autres qui y ont réfléchi et qui ont donc choisi en connaissance de cause.

Les dépendances GPL sont contraignantes quand elles sont au coeur d'un projet car ça contamine tout le projet.

Tout le monde ne veut pas faciliter la tâche des éditeurs de logiciels propriétaires gratuitement / dans leur temps libre.

Ça impacte tous les utilisateurs du code en leur imposant d'utiliser la GPL V3.

si ça impactait le code de ton site ou ta cuisine interne, mais je ne pense pas que ça soit le cas.

Ça l'impacte : tout le code qui doit donc être GPLv3, qu'il soit public ou pas.

Exemple de cas qui pourrait être problématique avec WordPress : https://fr.wordpress.org/about/license/

Enfin bon, ce qui compte :

• un projet a une licence,
• le projet m'intéresse vivement,
• la licence n'est pas en phase avec ce que je cherche
• j'évoque le point avec l'auteur.

Mais c'est pas "cool" ou "pas cool" : j'évoque juste un intérêt et une synergie potentielle.

Au final l'auteur a fait un choix de licence conscient et donc mon point n'a pas lieu.

Note : j'ai évoqué MIT qui est effectivement très permissif - c'est typiquement ce qu'on utilise sur des dépendances car ça s'adapte à tous projets (la question est : que cherche-t-on en publiant) ; ça pourrait être qqchose comme LGPL dans mon cas ; ce que je veux c'est que le code que j'écris ai la licence que je décide moi (et en l'occurrence, je publie généralement soit en MIT soit AGPL, donc ça peut potentiellement passer mais potentiellement pas).

Le NC sur les templates est moins problématique car les templates ça se réécrit plus facilement que le cœur (qui va évoluer de toute façon).

Dans tous les cas, chacun fait ce qu'il veut et c'est très bien ainsi.

Bon, j'ai fait tourner le code en clonant le repo de ton site.

Retours à chaud :

• ça nécessite Django 5 (et donc visiblement python 3.10) ; c'est un frein. A priori en mettant comme dépendance Django 4.2.9 ça semble opérationnel.
• il y a des migrations et une base SQLite. Je ne m'y attendais pas (c'est pas fondamentalement un problème)
• je ne connais pas vite, je m'attendais à ne pas avoir besoin de la partie "js" pour une utilisation basique mais ça plante directement avec une erreur 500, ce qui est perturbant. C'est d'autant plus perturbant que le debug est désactivé par défaut (j'ai bien compris que pour la prod c'est mieux - et je suis d'accord ;) et donc qu'on ne trouve pas spontanément d'où vient le problème. Pour quelqu'un qui connait Django c'est pas un problème, pour un pythoniste "de base" ça peut être bloquant
• la licence est problématique pour l'usage que j'envisage (sites pro algoo) :
  • ce qui m'intéresse sur un tel outil c'est principalement le moteur qui est GPL v3 et qui va donc "contaminer" tout le code si je veux l'utiliser. Je me serais attendu à du MIT (c'est généralement ce qu'on trouve sur ce genre de fonctionnalité).
  • ce qui peut m'intéresser ce sont aussi les templates de base qui sont si j'ai bien compris sous licence CC-BY-NC-SA. Je ne peux donc pas partir de ces templates pour faire un site professionnel : je dois réécrire le code.
  • la licence des contenus eux-même n'est pas un problème : c'est ton site, j'ai aucune ambition d'exploiter ce contenu.

J'imagine que le sujet de la licence est lié au fait que la techno (le moteur JSSG) et le contenu éditorial sont dans un repo unique.

---

Le projet pour lequel je suis potentiellement intéressé est le suivant : à algoo on exploite différents sites (algoo.fr, tracim.fr, galae.net et quelques autres) et je cherche à rationaliser l'ensemble de ces sites :

• un moteur unique, idéalement statique car il s'agit principalement de sites vitrine
• la techno python car c'est ce qu'on exploite au quotidien donc on sera à l'aise avec ça
• la gestion d'une bibliothèque de "modules visuels" (ce que je ferais avec des templatetag) qui permettrait d'avoir des blocs facilement réutilisables d'un site à un autre, d'une page à une autre, avec un rendu "globalement similaire" mais personnalisable avec quelques règles CSS.

Ce qui m'intéresse particulièrement dans JSSG :

• la rédaction de contenus en markdown car c'est facile et rapide et exploitable par des personnes non expertes
• l'intégration des métadonnées dans les contenus directement (j'avais prototypé qqchose de similaire il y a quelques temps mais je n'étais pas allé au bout de la démarche - ce que tu as fait)
• la détection des liens morts
• le processus de déploiement déjà pensé (tu développes en local, puis t'as une CI qui pousse vers une préprod voire une prod)
• la gestion des liens entre pages
• la gestion statique des pages (c'est pas rédhibitoire pour moi, mais c'est gage de performance)
• le fait que ça s'appuie sur django permet facile d'envisager des parties plus dynamiques pour des mécanismes qui le nécessiteraient
• la gestion des flux RSS

Aujourd'hui on est sur des sites "purement statique" (galae) et python/flask pour les deux autres, avec un backoffice de gestion/rédaction et un stockage fichier pour les médias et pages, et en base SQLite pour les articles du blog algoo.

---

Si un changement de licence est envisageable vers une licence type MIT (pour le moteur, et pour des templates "de base"), ça pourrait bien être la base de mon projet (et donc qu'on y contribue).

J'imagine très aisément ce changement de licence en séparant le repo "moteur JSSG" (avec un squelette de site qui serait neutre) et le repo "site" (ton site) ; je ne sais pas si c'est qqchose qui t'intéresse et/ou que tu es prêt à faire (et dans tous les cas, les licences que tu as choisies pour le moteur et pour les templates sont peut-être bien réfléchies et que tu ne souhaites pas les modifier).

Au plaisir d'avoir un retour de ta part en tout cas.

L'idée c'est quoi ? On forke le repo de ton site https://github.com/jtremesay/jtremesay.org et on remplace le contenu ? Si c'est ça, l'idée de faire des contributions n'est pas dans le pipe ?

C'est plus vaste que ça … Je vais jeter un coup d'œil et je te redis.

Tu gères les meta,opengraph etc comme méta données ?

Tout est dit.

Il me manque "juste" la gestion des blocs à intégrer dans les pages, mais j'ai l'impression que les template tags pourraient répondre à l'usage que j'envisage.

Justement : l'augmentation de revenus qui n'a aucune logique liée à la performance est symptomatique de ce que tu évoques. Donc on est bien d'accord que le sujet n'est pas la rémunération de la PDG, mais la politique de rémunération est la preuve que c'est pas juste une incompréhension (ou alors il y a des projets secrets qui justifient cela mais vu l'historique je pense juste que l'organisation est pourrie).

La dernière fois que le sujet a été abordé sur Linuxfr, j'ai cherché des infos sur le board, sa nomination etc et je n'ai rien trouvé.

Dans ma modeste expérience professionnelle, j'ai jamais vu d'augmentation pour atteinte des objectifs :

• des primes très attrayantes oui - mais ça veut dire retourner au charbon l'année suivante,
• des réévaluations de salaire conséquentes oui - mais c'est généralement lié à des changements de postes et de responsabilités.

Là c'est juste "bravo. Objectif atteint. On te récompense pour toute la suite de ta carrière dans l'organisation, même si tu arrêtes de faire des efforts".

Ok j'ai jamais été à ce niveau de responsabilités ni à ce niveau de gestion. Mais les mécanismes de récompenses qui fonctionnent bien sont relativement universels.

Et ça rejoint la question de l'éthique : c'est pas parce que des organisations commerciales ont cette démarche qu'il faut la reproduire - a fortiori quand ton positionnement est non lucratif (ou alors il faut revoir la raison d'être d'une fondation ?)

Tu cherches à résoudre le mauvais problème. Le problème à résoudre est plutôt : si je devais refaire le même choix aujourd'hui, avec les éléments que j'ai désormais en main, est-ce que je ferais le même choix ou pas ?

Se rassurer sur ce qui a été fait ne changera rien : tu ne peux pas refaire l'histoire. Ce que tu peux faire en revanche, c'est progresser et ne pas refaire les même erreurs (sur ce que tu considères comme une erreur).

Les choix rationnels ne sont pas forcément les meilleurs.

Il faut "juste" analyser et chercher à progresser.

Les décisions sont prises dans un contexte, avec des éléments en main.

Après coup, il est toujours plus facile de juger. C'est valable dans la vie personnelle, professionnelle.

L'idée d'éviter les regrets est un bon moyen de décider à mon sens pour ne pas souffrir après coup des décisions qu'on a prises par le passé.

De là à dire qu'il s'agit des bonnes décisions … Il y a un pas que je ne franchirai pas.

De toute façon, bonnes ou mauvaises, les décisions peuvent avoir des conséquences positives ou négatives …

C'est une solution. Une autre est de faire du "freelance". Ça dépend de la réglementation des pays concernés.

Je pensais que le "full remote" depuis l'étranger n'était pas légal en France (on ne peut pas embaucher un salarié en CDI sous contrat de travail français s'il ne se trouve pas sur le territoire français) ; visiblement il y a un flou juridique et quoi qu'il en soit, la situation ne semble pas simple. Cf. cet article que j'ai trouvé durant la rédaction de ce commentaire : https://culture-rh.com/teletravail-etranger-loi/

De celles que je connais, elles n'appliquent pas de baisse de salaire (ce qui serait illégal, ou alors signé d'un commun accord entre l'entreprise et le salarié) mais un gel d'évolution de salaire.

Je pense que si tu peux faire du full remote depuis la France ce sera sur la base des standards de rémunération de ces localisations.

Dans tous les cas c'est une manière de se définir par la négation d'autre chose au lieu de dire ce que c'est vraiment. Et du coup c'est un fourre-tout.

Les migrations auto générées peuvent être problématiques en terme de performance.

Mais tu le dis toi-même : il faut faire des migrations (SQL ou python, peu importe). Et la structure des bases SQL assuré l'intégrité des données largement mieux que des migrations écrites à la main et garantes de l'intégrité et de la cohérence des données.

À l'époque j'avais regardé orientdb qui était séduisant notamment pour son approche orientée graphe, mais au final je suis resté sur Postgresql et ça répond à tous les besoins auxquels j'ai eu à faire face.

Les projets sur lesquels j'ai vu du Mongo ont migré sur des solutions SQL dès qu'il a fallu s'assurer de l'intégrité forte des données.

J'ai vu des projets utiliser efficacement du Redis (-valeur) voire Elastic search comme base.

Le principe de se définir en "non quelque chose" n'a pas de sens pour moi : une base orientée graphe ne réponds pas aux mêmes usages qu'une base orientée documents ou une clé valeur.

À mon sens (rôle d'architecte logiciel) le sujet des migrations est le dernier des arguments pour choisir une base NoSQL : l'intégrité et la cohérence des données doit être assurée dans une application pérenne, et SQL est le meilleur outil pour que ces qualités soient assurées (bien plus que la performance des ingénieurs qui vont écrire les migrations).

Dernier retour d'expérience : avec le JSON embarqué dans Postgresql, tu peux faire du requêtage spécifique du coup je n'ai pas en tête de cas de figure où Postgresql ne répondrait pas.

Note : tout ce que je dis ici n'intègre pas les problématiques de scalabilité mais uniquement les problématiques de stockage, requêtage, d'intégrité des données et de maintenabilité du code associé.

Je ne crois pas plus à CalVer qu’aux bonnes résolutions du nouvel an. ^{^}

C'est pas une croyance c'est une stratégie de sorties :

• soit tu établis une roadmap basée sur des fonctionnalités dans des versions et du coup tu sais ce que va contenir telle ou telle version mais tu ne sais pas quand elle va sortir
• soit tu établis une roadmap et un rythme de versions et tu sais qu'elles sont les priorités, à quelle date sortent les versions mais tu ne sais pas quelle fonctionnalité arrive dans quelle version.

Un logiciel n'étant jamais terminé, le rythme régulier semble une bonne stratégie.

Quelques années en arrière, rappelons nous des versions Debian qui sortaient quand elles sortaient… Un certain nombre ont migré vers d'autres distributions faute de nouveauté disponible dans Debian stable.

Si l'on s'intéresse à la valeur apportés aux utilisateurs, il vaut mieux sortir des versions souvent car à chaque fois on apporte un peu plus de valeur (même s'il s'agit "juste" de quelques corrections de bugs) plutôt que des gros apports mais qui tardent à arriver.

Évidemment que ça ne remet pas en cause le fait de faire des notes de release.

Ce que je dis c'est que les clients qui sont en SaaS ils se fichent de la numérotation.

Les clients on premise veulent savoir que ça bouge et quand. Les livraisons régulières sont là pour ça ; une numérotation des versions basée sur la date va dans le même sens.

Contrairement à ce que tu dis une numérotation temporelle aide les clients à voir que ça bouge car à tout moment ils peuvent faire le lien spontanément entre la date courante et la date de sortie de la dernière version. Ce n'est pas le cas avec notre numérotation actuelle.

C'est là toute la subtilité de ce type de nommage des versions : pas besoin de connaître la stratégie de sortie des versions pour savoir de quand ça date. C'est intuitif et immédiat.

• on sort des versions de développement toutes les 2 ou 4 semaines
• on sort des versions officielles chaque trimestre
• les migrations de données sont intégrées à chaque version officielle
• les migrations de configuration sont documentées à chaque version officielle
• on ne casse les APIs qu'exceptionnellement - ça peut se documenter (c'est d'ailleurs ce qu'on fait)
• les clients "on premise" veulent des mises à jour et des notes de release pour les nouveautés. Un versioning ou un autre n'a jamais été réclamé
• les clients "SAAS" ne se posent pas de questions : ils ne s'intéressent pas aux numéros de version.
• même pour nous, on ne sait pas de quelle version vient une fonctionnalité : on se rappelle grosso modo quand elle a été développée mais impossible de faire un lien spontané avec un numéro de version - il faut passer par les notes de release.

En écrivant ce commentaire ça me conforte encore un peu plus d'aller vers ce type de numérotation…

Aucun problème de réputation IP n'est insolvable ; tout dépend du temps et de l'énergie que tu as pour le résoudre.

Sur les IPs fournies par des hébergeurs, l'historique qui te précède a un impact et ça ne se résoud pas nécessairement en 1 clic ou 2.