J'ai essayé je ne sais combien de générateurs de sites statiques dans l'idée de commencer un blog.
J'ai jamais fait ce blog. Maaaaais, j'ai essayé des générateurs.
Cette pratique de tester un tas d'outils sans jamais leur trouver un projet doit sûrement avoir un nom. Et je ne pense pas être seul à la pratiquer.
C'est drôle, j'ai toujours détesté Spip, ses boucles et sa documentation en tant que créateur de site, mais j'admirai son interface au point d'abandonner mon propre CMS lorsque Spip est sorti. J'en ai fait migrer des gens vers Spip! et chaque fois je me maudissais de cette idée à la con puisque je me retrouvais piégé dans la doc et les boucles.
Encore maintenant je trouve son interface bien conçu pour les gens qui travaillent en petites structures sans compétence informatique.
C’est marrant, c’est justement le langage de gabarits qui m’a séduit : on pouvait enfin faire du MVC ; et on évite les trucs que je voyais avec Joomla et Wordpress quand des gens qui n’ont pas assez de compétence en PHP et en codage doivent refaire l’habillage du site.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Comme quoi…
Mais je n'ai pas de bons arguments contre le système de Spip. Si ça se trouve j'ai détesté parce que la première fois il faisait trop chaud dans le bureau, le modem déconnectait tout le temps, etc. Et depuis quand je m'y replonge ça me fait comme les devoirs de méca du vendredi après-midi en pleine digestion avec le reflet du soleil sur la feuille et l'envie de laisser tomber les études. :-)
T’inquiètes, il n’y a pas de bons ou de mauvais arguments quand on aime ou pas (ne dit-on pas que des goûts et des couleurs discutables ?) ;-) Et tu fais la distinction entre ton aversion personnel et les besoins des autres (ce qui t’amène à l’installer pour les autres si tu estimes que ça répond à leurs besoins et qu’il n’y a pas d’allergie) ; une noblesse qui se perd je trouve. :-)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Est-ce que ce générateur peut se générer lui même où est-ce que l'himanité est condamnée à se reposer sur une pile infinie de tortue géantes (de plus) ?
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.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
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 ?
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
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.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Posté par raphj .
Évalué à 8.
Dernière modification le 06 janvier 2024 à 05:23.
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.
Ça me surprend. Tu vas faire tourner le code GPL chez toi (sur ton ordi de dev, dans la CI ou sur le serveur), et pas chez les gens qui visitent le site. Tu peux tout à fait l'étendre ou l'adapter sans jamais devoir redistribuer les modifications parce que l'outil reste de ce fait interne. Le code GPL ne semble jamais exécuté chez l'utilisateur, seul le résultat de l'exécution (le site généré, HTML) lui est transmis et n'hérite pas de la GPL, tout comme un binaire compilé avec GCC n'est pas nécessairement sous GPL. Tout comme tu aurais le droit de prendre un WordPress sous GPL et de le modifier à ta sauce et garder tes modifications pour toi. En revanche, si tu veux redistribuer tes extensions à d'autres gens, là oui, il faut que ça soit GPL. (ce serait probablement différent avec AGPL qui donnerait plus de contrainte : là, il faudrait certainement redistribuer les sources aux gens qui visitent le site et ça serait très contraignant).
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. Dans un monde où tout nous pousse à utiliser du copyfree parce que ça arrange bien les boites pas réellement attachées au libre (attention, je ne dis pas que c'est le cas de toutes les boites qui choisissent du copyfree - j'ai mon garde fou Zenitram qui s'excite dans ma tête - oui, chaque phrase que je formule au sujet du copyfree/copyleft passe par ce filtre), utiliser la GPL est probablement un choix réfléchi et pas un choix par défaut. Tout le monde ne veut pas faciliter la tâche des éditeurs de logiciels propriétaires gratuitement / dans leur temps libre. Il y en a qui parle de "cuck licence" (https://wiki.installgentoo.com/wiki/Cuck_license, https://lukesmith.xyz/articles/why-i-use-the-gpl-and-not-cuck-licenses/, https://old.reddit.com/r/linuxmasterrace/comments/rox22n/cuck_license/, https://linuxfr.org/users/hellpe/liens/why-i-use-the-gpl-and-not-cuck-licenses). Pas fan du mélange de sujets avec le terme cuck, mais j'avoue plutôt aimer l'aspect provocant qu'il porte. Évidemment, ce serait justifié si ça impactait le code de ton site ou ta cuisine interne, mais je ne pense pas que ça soit le cas.
Les templates, si pas spécifique au site de Jonathan, c'est un moins cool en NC en revanche en effet. Pas d'utilisation commerciale, ça veut dire pas d'utilisation sur un site commercial. J'ai énormément de mal avec le NC, au delà du fait que ce n'est pas libre, son champ d'application est potentiellement très large. C'est plus ou moins du code que personne ne peut réutiliser. Aussi bien, "pas d'utilisation sur un site commercial" pourrait vouloir dire "pas d'utilisation sur un site". Potentiellement, il suffit de vendre un t-shirt ou un mug via le site pour que ça ne marche plus.
Par contre, en effet, si le générateur de site statique est destiné à être utilisé par d'autres gens, le séparer du contenu d'un site en particulier paraîtrait plus malin.
je ne connais pas vite
C'est l'outil de build frontend du moment :-) C'est utilisé par Svelte par exemple.
(ce serait probablement différent avec AGPL qui donnerait plus de contrainte : là, il faudrait certainement redistribuer les sources aux gens qui visitent le site et ça serait très contraignant).
Ben je ne suis pas sûr. La licence AGPL a vraiment été pensé pour les logiciels de type services avec lequel l'utilisateur final interagis, ce qui n'est pas le cas de JSSG dans son usage normal. (tu PEUX l'utiliser en mode serveur pour dev comme une app Django normale, mais ce n'est pas recommandé de l'utiliser en prod pour ça)
Par contre, en effet, si le générateur de site statique est destiné à être utilisé par d'autres gens, le séparer du contenu d'un site en particulier paraîtrait plus malin.
Pour l'instant, c'est avant tout pour mon usage perso.
J'en ai parlé ici pour faire un retour d'expérience de «oui, aussi con que puisse paraître l'idée, il est possible et même facile de faire un générateur static avec Django, et voilà comment j'ai fait» parce que je sais qu'il y a toujours quelqu'un d'intéressé par mes expérimentations idiotes.
Les templates, si pas spécifique au site de Jonathan, c'est un moins cool en NC en revanche en effet. Pas d'utilisation commerciale, ça veut dire pas d'utilisation sur un site commercial. J'ai énormément de mal avec le NC, au delà du fait que ce n'est pas libre, son champ d'application est potentiellement très large. C'est plus ou moins du code que personne ne peut réutiliser. Aussi bien, "pas d'utilisation sur un site commercial" pourrait vouloir dire "pas d'utilisation sur un site". Potentiellement, il suffit de vendre un t-shirt ou un mug via le site pour que ça ne marche plus.
Les templates sont spécifique à mon site. Mais il est vrai que je les avais foutu dans la base de code du générateur pour me simplifier la vie, ce qui peut porter à confusion.
Hier soir, j'ai extrait tout mon contenu perso du générateur; il ne devrait plus y avoir de problème de contamination par la CC-BY-NC-SA.
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.
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.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
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.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
J'ai regardé tardivement et le fait que ce soit une techno Django a induit ma réflexion en erreur.
Tkt, moi aussi ça m'a pas mal perturbé pendant le dev.
"Alors si je fais comment ça ça m'arrangera beaucoup pour l'écriture du contenu mais ça va me niquer les perfs sur la prod. réalisation wait, y'aura pas de code sur la prod, j'mef des perfs !"
Posté par raphj .
Évalué à 4.
Dernière modification le 06 janvier 2024 à 17:15.
J'ai l'impression que tu penses la GPL plus contraignante qu'elle ne l'est. Même si le code était déployé sur le serveur, la licence GPL te contraint finalement très peu sur les cas d'utilisations qui t'intéressent probablement.
[9.] If I write a module or theme, do I have to license it under the GPL?
Yes. […but…] You are not required to distribute them at all, however. (See question 8 below.) [sic. c'est probablement 10]
[10.] If I write a module or theme, do I have to give it away to everyone?
No.
…
[12.] Is an agency, or service provider 'distributing code' on behalf of a client when under contract?
No, an agency, freelancer, or other service provider is acting as the customer's agent when assembling a code base, and not distributing the code in the sense intended by the GPL. Therefore service providers can use GPL code together with GPL-incompatible code for a client, but cannot redistribute that code to the public.
…
[14.] Do I have to give my web site's code to anyone who visits it?
No
…
[4.] Can Drupal projects depend on or link to GPL-incompatible code? (3rd-party libraries, APIs, etc)
Yes, the GPL does not restrict the use of code under incompatible licenses, only the packaging or distribution of it with GPL software. Drupal.org cannot host this incompatible code, but installing those dependencies with a tool like Composer is okay.
Dans tous les cas, tu peux :
écrire ton code en copyfree
utiliser une extension copyfree ou propriétaire sur ta propre installation
avoir du contenu pas sous licence libre (typiquement ND peut-être une bonne clause pour un texte d'opinion ou marketing qu'on ne veut pas voir modifié par exemple)
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)
Tu es limité dans ce que tu peux redistribuer :
tu peux distribuer ton extension au projet GPL en copyfree ou en non libre / GPL incompatible
tu peux distribuer tes modif au projet GPL sous GPL et seulement sous GPL
tu ne peux pas distribuer le moteur en GPL + ton extension sous licence incompatible avec la GPL - mais tu peux permettre à tes utilisateurs de l'installer eux-même avec un gestionnaire de paquet.
Évidemment c'est vrai pour le backend. En frontend, envoyer du code au navigateur c'est potentiellement le distribuer si ce n'est pas un outil interne, il ne peut pas contenir du code GPL et du code incompatible GPL dans ce cas. Tu peux développer un frontend mélangeant les deux tant que ça reste un outil interne (chez toi ou chez ton client) - dans ce cas, il n'est pas distribué puisque ça reste "chez toi", ou "chez le client" avec toi son agent).
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)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Posté par raphj .
Évalué à 4.
Dernière modification le 07 janvier 2024 à 11:33.
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)
On est d'accord :-)
Malgré tout le sujet plus généralement me parait important, peut-être encore plus pour toi que pour moi.
si le client souhaite que tu lui fournisses les sources, tu es obligé.
Oui. Mais ce n'est pas une distribution au sens de la GPL. C'est une utilisation interne. C'est plus clair en se plaçant du point de vue du client.
Supposons que tu aies un besoin qui dépend d'un code GPL :
tu bricoles une solution que tu gardes pour toi. Pas de distribution, tu fais ce que tu veux.
tu paies un prestataire pour bricoler une solution que tu gardes pour toi. Pas de distribution, tu fais ce que tu veux.
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.
C'est justement pour moi la force principale du logiciel libre : tu as un outil libre à ta disposition mais tu as un besoin un peu spécifique ou le monde a un peu changé : tu peux l'adapter pour tes besoins perso sans conditions (autres que la loi). Tu peux le faire toi même, ou, plus probablement, si tu n'en as pas les compétences ou les moyens, payer quelqu'un pour le faire. Dans ce cas, il n'y a pas de distribution au sens de la GPL et personne ne te force à distribuer ton code. Autrement dit : La GPL force un auteur de logiciel à distribuer le code sous copyleft à son utilisateur. Mais dans le cas d'une prestation, le client est "auteur" (au sens où il a les droits patrimoniaux sur le code, puisqu'il a payé la prestation) ET utilisateur. Le prestataire n'est qu'un "détail d'implémentation" (no offense). Il a écrit le code, mais pour le compte du client.
C'est d'ailleurs pour ça que le projet GNU et la plupart des distributions Linux ne considèrent pas la licence du compilateur du bios de virtualbox comme libre (la licence Sybase) :
This is not a free software license. It requires you to publish the source code publicly whenever you “Deploy” the covered software, and “Deploy” is defined to include many kinds of private use.
Tu n'as pas le droit de modifier ce code et l'utiliser en privé (dans trop de cas) sans le redistribuer, ce qui est trop restrictif.
Ça fait de la GPL une licence en réalité très raisonnable, même (et surtout) pour l'éditeur de logiciel ou le prestataire : on peut réutiliser son travail, mais il a la garantie de bénéficier des modifications de quelqu'un qui distribuerait le logiciel largement (caveat pour les situations à la red hat).
Alors que pour du code MIT, une telle garantie n'existe pas. En revanche, tu n'attireras pas les contributions de quelqu'un qui voudrais fermer ton code pour le distribuer à des utilisateurs finaux mais qui serait enclin à contribuer upstream puisqu'il ne pourrait pas utiliser ton code GPL pour ça.
C'est évidemment une histoire de compromis et je comprendrais très bien quelqu'un qui choisisse MIT dans l'espoir que plus de contributions arrivent, ou parce qu'il fait du business sur ce code et veut quand même des contributions externes. Il faut bien garder en tête que ça peut se retourner contre soi sévèrement. L'alternative serait GPL + CLA, mais c'est beaucoup moins accepté que contribuer à un projet sous MIT (certainement parce que d'un coup, la boite est la seule à pouvoir fermer le code comme bon lui semble, alors qu'en MIT, tout le monde peut le faire - c'est précisément le cas où je vois quelqu'un choisir une licence permissive pour des raisons philosophiques, et c'est probablement la position des projets *BSD).
D'autres cas méritent une licence permissive, comme les codecs. Tu veux que ton format se diffuse le plus largement possible, tant mis s'il atterrit dans un logiciel propriétaire : au moins, il y a un peu d’interopérabilité et une adoption du format.
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)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
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
Ah yes, les règles sont peut-être différentes sans cette clause, peut-être que tu te retrouves effectivement à distribuer au sens de la GPL dans ce cas.
À 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.
É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)
À 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.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Posté par raphj .
Évalué à 3.
Dernière modification le 08 janvier 2024 à 14:48.
c'est peut-être ça l'astuce
Ouaip. Il y a moyen que ça puisse marcher comme ça.
Je n'ai jamais suffisamment creusé comment ça marche côté WordPress, j'avais toujours supposé que le code des extensions payantes est en fait libre mais que soit :
l'extension dépend d'un service qui nécessite une sorte de clé qu'on a en payant
une partie (premium) du code est gardé à coup de if (licence valide) { ... }
Chez XWiki, on vend des extensions libres avec cette dernière méthode. Les gens pourraient venir chercher le code source, retirer la gestion de la licence, compiler et installer l'extension manuellement eux-mêmes, mais en fait c'est tellement plus simple de juste cliquer et payer + avoir un peu de support que les boites font juste ça. Et c'est plus facile à justifier auprès de la compta qu'un don pour les entreprises conscientes qu'un code, même libre, ça ne se développe pas tout seul.
ç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.
C'est une dépendance faible à Django 5. J'ai pinné sur les dernières versions disponibles. Mais vu que je n'utilise rien de spécifique à la 5, ça devrait assez bien tourner avec la 4.
il y a des migrations et une base SQLite. Je ne m'y attendais pas (c'est pas fondamentalement un problème)
euh… non ? Enfin, ça fait toujours très plaisir à django que tu fasses ./manage.py migrate avant le ./manage.py runserver. Mais sinon, je n'ai pas de migrations et je n'utilise pas la db.
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.
pour mon cas d'usage, ça m'arrange d'avoir le front géré par Vite plutôt que par Django. Et ouais, Django grogne quand npm run vite n'est pas lancé.
Tu peux désactiver ça en ne chargeant pas l'app django_vite_pluginlà.
Faudra aussi remplacer dans les templates les {% vite 'bla' %} par des `{% static 'bla' %}
C'est d'autant plus perturbant que le debug est désactivé par défaut
C'est géré par la var env DJANGO_DEBUG qui doit être à true pour activer le debug :
DJANGO_DEBUG=true ./manage.py
Si tu as direnv d'installé, la variable est appliquée automatiquement qrace à ça ce fichier. (et en plus, il crée et charge automatiquement le venv. N'est-ce pas magnifique ?)
la licence est problématique pour l'usage que j'envisage (sites pro algoo) :
Comme indiqué par raphj ("Tu vas faire tourner le code GPL chez toi (sur ton ordi de dev, dans la CI ou sur le serveur), et pas chez les gens qui visitent le site. Tu peux tout à fait l'étendre ou l'adapter sans jamais devoir redistribuer les modifications parce que l'outil reste de ce fait interne."), je ne pense pas que la GPL soit bloquante pour que vous pussiez utiliser et modifier le générateur.
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.
effectivement, les templates font plus partis du contenus que du générateur et seraient donc plutôt sous CC-BY-NC-SA. Mais honnêtement, je ne suis pas sûr qu'il y ai assez de truc dedans pour que ça qualifie pour une véritable protection de ma propriété intellectuelle.
Au pire, cadeau, 2 templates sous licence Unlicense :
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.
ouais. À la base, c'était le dépôt du site lui même. Pis j'ai fini par y ajouter le générateur quand j'ai vu que je ne trouvais pas mon bonheur parmis les outils existant.
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)
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
J'ai réorganisé le dépot pour déplacer tout mon contenu perso en dehors du sous dossier jssg pour faciliter la réutilisation par autrui.
À terme, le générateur finira probablement dans son propre dépot. Mais pour l'instant, ça m'était plus simple de faire un mono-dépot.
(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).
Semi-réfléchi. Par défaut, j'ai une politique de «j'ai pas de problème à coder gratuitement pour enrichir les bien communs, mais j'ai pas envie que quelqu'un puisse se faire des montagnes de fric en privatisant mes conneries».
Ou comme le dit raphj, «Tout le monde ne veut pas faciliter la tâche des éditeurs de logiciels propriétaires gratuitement / dans leur temps libre».
Posté par raphj .
Évalué à 2.
Dernière modification le 07 janvier 2024 à 11:46.
Félicitations pour le partage et je te souhaite plein de fun, peut-être à base de contributions extérieures :-)
Pour une certaine raison, GitHub est perdu pour déterminer la licence de ton projet, je n'ai cependant que très peu d'expérience en la matière pour aider sur la question.
# Je me demande si...
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 7.
La morale est "il ne faut pas coder bourré" ou, au contraire "bourré, coder il faut".
Je me demande aussi s'il y a des gens qui collectionnent les générateurs de sites statiques. Mais pourquoi pas.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Je me demande si...
Posté par jtremesay (site web personnel) . Évalué à 4.
Il faut le bon dosage. Ça demande des années de pratique pour le trouver !
[^] # Re: Je me demande si...
Posté par zephyr32 . Évalué à 8.
J'ai essayé je ne sais combien de générateurs de sites statiques dans l'idée de commencer un blog.
J'ai jamais fait ce blog. Maaaaais, j'ai essayé des générateurs.
Cette pratique de tester un tas d'outils sans jamais leur trouver un projet doit sûrement avoir un nom. Et je ne pense pas être seul à la pratiquer.
[^] # Re: Je me demande si...
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 3.
J'avais fait ça avec les CMS avant, finalement, de retomber sur SPIP avec bonheur.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Je me demande si...
Posté par orfenor . Évalué à 3.
C'est drôle, j'ai toujours détesté Spip, ses boucles et sa documentation en tant que créateur de site, mais j'admirai son interface au point d'abandonner mon propre CMS lorsque Spip est sorti. J'en ai fait migrer des gens vers Spip! et chaque fois je me maudissais de cette idée à la con puisque je me retrouvais piégé dans la doc et les boucles.
Encore maintenant je trouve son interface bien conçu pour les gens qui travaillent en petites structures sans compétence informatique.
[^] # Re: Je me demande si...
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 5.
C’est marrant, c’est justement le langage de gabarits qui m’a séduit : on pouvait enfin faire du MVC ; et on évite les trucs que je voyais avec Joomla et Wordpress quand des gens qui n’ont pas assez de compétence en PHP et en codage doivent refaire l’habillage du site.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Je me demande si...
Posté par orfenor . Évalué à 3.
Comme quoi…
Mais je n'ai pas de bons arguments contre le système de Spip. Si ça se trouve j'ai détesté parce que la première fois il faisait trop chaud dans le bureau, le modem déconnectait tout le temps, etc. Et depuis quand je m'y replonge ça me fait comme les devoirs de méca du vendredi après-midi en pleine digestion avec le reflet du soleil sur la feuille et l'envie de laisser tomber les études. :-)
[^] # Re: Je me demande si...
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
T’inquiètes, il n’y a pas de bons ou de mauvais arguments quand on aime ou pas (ne dit-on pas que des goûts et des couleurs discutables ?) ;-) Et tu fais la distinction entre ton aversion personnel et les besoins des autres (ce qui t’amène à l’installer pour les autres si tu estimes que ça répond à leurs besoins et qu’il n’y a pas d’allergie) ; une noblesse qui se perd je trouve. :-)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Je me demande si...
Posté par jseb . Évalué à 3. Dernière modification le 06 janvier 2024 à 08:32.
Spirou n'a pas trop râlé ?
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
[^] # Re: Je me demande si...
Posté par Pol' uX (site web personnel) . Évalué à 10.
À ce stade il serait intéressant de développer un générateur de générateur de site statique. Avec django et cookiecutter ça doit être gérable.
Adhérer à l'April, ça vous tente ?
[^] # Re: Je me demande si...
Posté par Thomas Douillard . Évalué à 6.
Est-ce que ce générateur peut se générer lui même où est-ce que l'himanité est condamnée à se reposer sur une pile infinie de tortue géantes (de plus) ?
[^] # Re: Je me demande si...
Posté par cg . Évalué à 5.
J'ai appris il y a peu le terme de Quine, qui désigne un programme qui se reproduit lui-même (pas un virus).
Et donc il y a le quine-relay, qui fait ça au travers d'une centaine de langages.
Ceci dit, je n'ai rien contre le fait de m'asseoir sur une tortue, surtout si elle est programmable en Logo :).
# Je vais regarder ça, ça m'intéresse bien...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 4.
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.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Je vais regarder ça, ça m'intéresse bien...
Posté par jtremesay (site web personnel) . Évalué à 2. Dernière modification le 05 janvier 2024 à 18:00.
jssg propulsant galae ? :)
en théorie, tu dois pouvoir faire des
extends/blockdans les .md, mais j'ai pas testé.[^] # Re: Je vais regarder ça, ça m'intéresse bien...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
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 ?
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Je vais regarder ça, ça m'intéresse bien...
Posté par jtremesay (site web personnel) . Évalué à 5.
j'accepte les abonnements galae start en pourboire ;)
"oui et non". Non parce que je n'utilise pas ce genre de chose.
Mais oui vu que chaque document peut contenir des meta-data et être accesible dans les templates
Genre là je défini le title de la page en utilisant le document courant.
Du coup, dans ton ma_page.md :
et dans ton base.html :
[^] # Re: Je vais regarder ça, ça m'intéresse bien...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 4.
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 ?
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Je vais regarder ça, ça m'intéresse bien...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 8.
Bon, j'ai fait tourner le code en clonant le repo de ton site.
Retours à chaud :
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 :
Ce qui m'intéresse particulièrement dans JSSG :
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.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Je vais regarder ça, ça m'intéresse bien...
Posté par raphj . Évalué à 8. Dernière modification le 06 janvier 2024 à 05:23.
Ça me surprend. Tu vas faire tourner le code GPL chez toi (sur ton ordi de dev, dans la CI ou sur le serveur), et pas chez les gens qui visitent le site. Tu peux tout à fait l'étendre ou l'adapter sans jamais devoir redistribuer les modifications parce que l'outil reste de ce fait interne. Le code GPL ne semble jamais exécuté chez l'utilisateur, seul le résultat de l'exécution (le site généré, HTML) lui est transmis et n'hérite pas de la GPL, tout comme un binaire compilé avec GCC n'est pas nécessairement sous GPL. Tout comme tu aurais le droit de prendre un WordPress sous GPL et de le modifier à ta sauce et garder tes modifications pour toi. En revanche, si tu veux redistribuer tes extensions à d'autres gens, là oui, il faut que ça soit GPL. (ce serait probablement différent avec AGPL qui donnerait plus de contrainte : là, il faudrait certainement redistribuer les sources aux gens qui visitent le site et ça serait très contraignant).
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. Dans un monde où tout nous pousse à utiliser du copyfree parce que ça arrange bien les boites pas réellement attachées au libre (attention, je ne dis pas que c'est le cas de toutes les boites qui choisissent du copyfree - j'ai mon garde fou Zenitram qui s'excite dans ma tête - oui, chaque phrase que je formule au sujet du copyfree/copyleft passe par ce filtre), utiliser la GPL est probablement un choix réfléchi et pas un choix par défaut. Tout le monde ne veut pas faciliter la tâche des éditeurs de logiciels propriétaires gratuitement / dans leur temps libre. Il y en a qui parle de "cuck licence" (https://wiki.installgentoo.com/wiki/Cuck_license, https://lukesmith.xyz/articles/why-i-use-the-gpl-and-not-cuck-licenses/, https://old.reddit.com/r/linuxmasterrace/comments/rox22n/cuck_license/, https://linuxfr.org/users/hellpe/liens/why-i-use-the-gpl-and-not-cuck-licenses). Pas fan du mélange de sujets avec le terme cuck, mais j'avoue plutôt aimer l'aspect provocant qu'il porte. Évidemment, ce serait justifié si ça impactait le code de ton site ou ta cuisine interne, mais je ne pense pas que ça soit le cas.
Les templates, si pas spécifique au site de Jonathan, c'est un moins cool en NC en revanche en effet. Pas d'utilisation commerciale, ça veut dire pas d'utilisation sur un site commercial. J'ai énormément de mal avec le NC, au delà du fait que ce n'est pas libre, son champ d'application est potentiellement très large. C'est plus ou moins du code que personne ne peut réutiliser. Aussi bien, "pas d'utilisation sur un site commercial" pourrait vouloir dire "pas d'utilisation sur un site". Potentiellement, il suffit de vendre un t-shirt ou un mug via le site pour que ça ne marche plus.
Par contre, en effet, si le générateur de site statique est destiné à être utilisé par d'autres gens, le séparer du contenu d'un site en particulier paraîtrait plus malin.
C'est l'outil de build frontend du moment :-) C'est utilisé par Svelte par exemple.
[^] # Re: Je vais regarder ça, ça m'intéresse bien...
Posté par jtremesay (site web personnel) . Évalué à 3.
Ben je ne suis pas sûr. La licence AGPL a vraiment été pensé pour les logiciels de type services avec lequel l'utilisateur final interagis, ce qui n'est pas le cas de JSSG dans son usage normal. (tu PEUX l'utiliser en mode serveur pour dev comme une app Django normale, mais ce n'est pas recommandé de l'utiliser en prod pour ça)
Pour l'instant, c'est avant tout pour mon usage perso.
J'en ai parlé ici pour faire un retour d'expérience de «oui, aussi con que puisse paraître l'idée, il est possible et même facile de faire un générateur static avec Django, et voilà comment j'ai fait» parce que je sais qu'il y a toujours quelqu'un d'intéressé par mes expérimentations idiotes.
Les templates sont spécifique à mon site. Mais il est vrai que je les avais foutu dans la base de code du générateur pour me simplifier la vie, ce qui peut porter à confusion.
Hier soir, j'ai extrait tout mon contenu perso du générateur; il ne devrait plus y avoir de problème de contamination par la CC-BY-NC-SA.
[^] # Re: Je vais regarder ça, ça m'intéresse bien...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 4.
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.
Ça impacte tous les utilisateurs du code en leur imposant d'utiliser la GPL V3.
Ç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 :
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.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Je vais regarder ça, ça m'intéresse bien...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 4.
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.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Je vais regarder ça, ça m'intéresse bien...
Posté par jtremesay (site web personnel) . Évalué à 3.
Tkt, moi aussi ça m'a pas mal perturbé pendant le dev.
"Alors si je fais comment ça ça m'arrangera beaucoup pour l'écriture du contenu mais ça va me niquer les perfs sur la prod. réalisation wait, y'aura pas de code sur la prod, j'mef des perfs !"
[^] # Re: Je vais regarder ça, ça m'intéresse bien...
Posté par raphj . Évalué à 4. Dernière modification le 06 janvier 2024 à 17:15.
J'ai l'impression que tu penses la GPL plus contraignante qu'elle ne l'est. Même si le code était déployé sur le serveur, la licence GPL te contraint finalement très peu sur les cas d'utilisations qui t'intéressent probablement.
https://fr.wordpress.org/about/license/ lie vers https://www.drupal.org/about/licensing#non-code-assets
…
…
…
Dans tous les cas, tu peux :
Tu es limité dans ce que tu peux redistribuer :
Évidemment c'est vrai pour le backend. En frontend, envoyer du code au navigateur c'est potentiellement le distribuer si ce n'est pas un outil interne, il ne peut pas contenir du code GPL et du code incompatible GPL dans ce cas. Tu peux développer un frontend mélangeant les deux tant que ça reste un outil interne (chez toi ou chez ton client) - dans ce cas, il n'est pas distribué puisque ça reste "chez toi", ou "chez le client" avec toi son agent).
[^] # Re: Je vais regarder ça, ça m'intéresse bien...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 3.
La notion de distribution n'est pas une question de distribution publique mais de distribution à tes utilisateurs / clients.
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)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Je vais regarder ça, ça m'intéresse bien...
Posté par raphj . Évalué à 4. Dernière modification le 07 janvier 2024 à 11:33.
On est d'accord :-)
Malgré tout le sujet plus généralement me parait important, peut-être encore plus pour toi que pour moi.
Oui. Mais ce n'est pas une distribution au sens de la GPL. C'est une utilisation interne. C'est plus clair en se plaçant du point de vue du client.
Supposons que tu aies un besoin qui dépend d'un code GPL :
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.
C'est justement pour moi la force principale du logiciel libre : tu as un outil libre à ta disposition mais tu as un besoin un peu spécifique ou le monde a un peu changé : tu peux l'adapter pour tes besoins perso sans conditions (autres que la loi). Tu peux le faire toi même, ou, plus probablement, si tu n'en as pas les compétences ou les moyens, payer quelqu'un pour le faire. Dans ce cas, il n'y a pas de distribution au sens de la GPL et personne ne te force à distribuer ton code. Autrement dit : La GPL force un auteur de logiciel à distribuer le code sous copyleft à son utilisateur. Mais dans le cas d'une prestation, le client est "auteur" (au sens où il a les droits patrimoniaux sur le code, puisqu'il a payé la prestation) ET utilisateur. Le prestataire n'est qu'un "détail d'implémentation" (no offense). Il a écrit le code, mais pour le compte du client.
C'est d'ailleurs pour ça que le projet GNU et la plupart des distributions Linux ne considèrent pas la licence du compilateur du bios de virtualbox comme libre (la licence Sybase) :
https://www.gnu.org/licenses/license-list.html#Watcom
Tu n'as pas le droit de modifier ce code et l'utiliser en privé (dans trop de cas) sans le redistribuer, ce qui est trop restrictif.
Ça fait de la GPL une licence en réalité très raisonnable, même (et surtout) pour l'éditeur de logiciel ou le prestataire : on peut réutiliser son travail, mais il a la garantie de bénéficier des modifications de quelqu'un qui distribuerait le logiciel largement (caveat pour les situations à la red hat).
Alors que pour du code MIT, une telle garantie n'existe pas. En revanche, tu n'attireras pas les contributions de quelqu'un qui voudrais fermer ton code pour le distribuer à des utilisateurs finaux mais qui serait enclin à contribuer upstream puisqu'il ne pourrait pas utiliser ton code GPL pour ça.
C'est évidemment une histoire de compromis et je comprendrais très bien quelqu'un qui choisisse MIT dans l'espoir que plus de contributions arrivent, ou parce qu'il fait du business sur ce code et veut quand même des contributions externes. Il faut bien garder en tête que ça peut se retourner contre soi sévèrement. L'alternative serait GPL + CLA, mais c'est beaucoup moins accepté que contribuer à un projet sous MIT (certainement parce que d'un coup, la boite est la seule à pouvoir fermer le code comme bon lui semble, alors qu'en MIT, tout le monde peut le faire - c'est précisément le cas où je vois quelqu'un choisir une licence permissive pour des raisons philosophiques, et c'est probablement la position des projets *BSD).
D'autres cas méritent une licence permissive, comme les codecs. Tu veux que ton format se diffuse le plus largement possible, tant mis s'il atterrit dans un logiciel propriétaire : au moins, il y a un peu d’interopérabilité et une adoption du format.
[^] # Re: Je vais regarder ça, ça m'intéresse bien...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 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)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Je vais regarder ça, ça m'intéresse bien...
Posté par raphj . Évalué à 3.
Ah yes, les règles sont peut-être différentes sans cette clause, peut-être que tu te retrouves effectivement à distribuer au sens de la GPL dans ce cas.
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.
Absolument.
[^] # Re: Je vais regarder ça, ça m'intéresse bien...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 3.
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.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Je vais regarder ça, ça m'intéresse bien...
Posté par raphj . Évalué à 3. Dernière modification le 08 janvier 2024 à 14:48.
Ouaip. Il y a moyen que ça puisse marcher comme ça.
Je n'ai jamais suffisamment creusé comment ça marche côté WordPress, j'avais toujours supposé que le code des extensions payantes est en fait libre mais que soit :
l'extension dépend d'un service qui nécessite une sorte de clé qu'on a en payant
une partie (premium) du code est gardé à coup de
if (licence valide) { ... }Chez XWiki, on vend des extensions libres avec cette dernière méthode. Les gens pourraient venir chercher le code source, retirer la gestion de la licence, compiler et installer l'extension manuellement eux-mêmes, mais en fait c'est tellement plus simple de juste cliquer et payer + avoir un peu de support que les boites font juste ça. Et c'est plus facile à justifier auprès de la compta qu'un don pour les entreprises conscientes qu'un code, même libre, ça ne se développe pas tout seul.
[^] # Re: Je vais regarder ça, ça m'intéresse bien...
Posté par jtremesay (site web personnel) . Évalué à 7.
(dernière version connue qui marche)
C'est une dépendance faible à Django 5. J'ai pinné sur les dernières versions disponibles. Mais vu que je n'utilise rien de spécifique à la 5, ça devrait assez bien tourner avec la 4.
euh… non ? Enfin, ça fait toujours très plaisir à django que tu fasses
./manage.py migrateavant le./manage.py runserver. Mais sinon, je n'ai pas de migrations et je n'utilise pas la db.pour mon cas d'usage, ça m'arrange d'avoir le front géré par Vite plutôt que par Django. Et ouais, Django grogne quand
npm run viten'est pas lancé.Tu peux désactiver ça en ne chargeant pas l'app
django_vite_pluginlà.Faudra aussi remplacer dans les templates les
{% vite 'bla' %}par des `{% static 'bla' %}C'est géré par la var env
DJANGO_DEBUGqui doit être àtruepour activer le debug :Si tu as
direnvd'installé, la variable est appliquée automatiquement qrace à ça ce fichier. (et en plus, il crée et charge automatiquement le venv. N'est-ce pas magnifique ?)Comme indiqué par raphj ("Tu vas faire tourner le code GPL chez toi (sur ton ordi de dev, dans la CI ou sur le serveur), et pas chez les gens qui visitent le site. Tu peux tout à fait l'étendre ou l'adapter sans jamais devoir redistribuer les modifications parce que l'outil reste de ce fait interne."), je ne pense pas que la GPL soit bloquante pour que vous pussiez utiliser et modifier le générateur.
effectivement, les templates font plus partis du contenus que du générateur et seraient donc plutôt sous CC-BY-NC-SA. Mais honnêtement, je ne suis pas sûr qu'il y ai assez de truc dedans pour que ça qualifie pour une véritable protection de ma propriété intellectuelle.
Au pire, cadeau, 2 templates sous licence Unlicense :
page.html:post.html:ouais. À la base, c'était le dépôt du site lui même. Pis j'ai fini par y ajouter le générateur quand j'ai vu que je ne trouvais pas mon bonheur parmis les outils existant.
J'ai rien inventé, j'ai volé l'idée chez Hugo
J'ai réorganisé le dépot pour déplacer tout mon contenu perso en dehors du sous dossier
jssgpour faciliter la réutilisation par autrui.À terme, le générateur finira probablement dans son propre dépot. Mais pour l'instant, ça m'était plus simple de faire un mono-dépot.
Semi-réfléchi. Par défaut, j'ai une politique de «j'ai pas de problème à coder gratuitement pour enrichir les bien communs, mais j'ai pas envie que quelqu'un puisse se faire des montagnes de fric en privatisant mes conneries».
Ou comme le dit raphj, «Tout le monde ne veut pas faciliter la tâche des éditeurs de logiciels propriétaires gratuitement / dans leur temps libre».
# jssg
Posté par jtremesay (site web personnel) . Évalué à 4.
Jusque là, jssg était hébergé dans le dépot de mon site.
Pour simplifier la réutilisation par autrui, je lui ai crée un dépôt dédié.
J'ai viré l'intégration de vite/typescript pour simplifier le truc.
Du contenu d'exemple a été fourni sous la très libérale licence CC0.
Have fun!
[^] # Re: jssg
Posté par raphj . Évalué à 2. Dernière modification le 07 janvier 2024 à 11:46.
Félicitations pour le partage et je te souhaite plein de fun, peut-être à base de contributions extérieures :-)
Pour une certaine raison, GitHub est perdu pour déterminer la licence de ton projet, je n'ai cependant que très peu d'expérience en la matière pour aider sur la question.
# Je reviens un peu tardivement sur ce sujet ...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
J'ai un peu trainé, mes exploré pas mal de choses ici et là. J'ai lutté avec le repo dédié. J'ai laissé tomber … et je viens de m'y remettre.
Je vais expérimenter (en local) une version jssg du site galae.
Je te tiens au courant ; j'ai qques PR prévues (doc pour le moment).
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Je reviens un peu tardivement sur ce sujet ...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
s/mes exploré/mais exploré/#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.