Je sais que les temps sont durs pour gagner de l'argent avec du libre et que l'anticapitalisme est un obscurantisme, mais je ne suis pas très enthousiaste en lisant ça…
(…) there are a few corporations (with revenues that are greater than some countries GDP) are building on Gitea for core products without even contributing back enhancements.
…suivi de ça :
To preserve the community aspect of Gitea we are experimenting with creating a decentralized autonomous organization where contributors would receive benefits based on their participation (…)
Je sais que le modèle économique "société à but lucratif + communauté de contributeurs" est assez répandu dans le libre, je sais aussi qu'on reproche à Canonical, Muse Group ou la Mozilla Corp. de flinguer leurs produits (j'en parlais vite fait ici). Je me demande si ce genre de décisions foireuses est un risque inhérent à un tel montage, ou si en fin de compte, ce n'est pas l'apanage des "corporations" de promouvoir des idées chelou pour rétribuer le travail des développeurs libres.
C'est marrant, parce que les commentaires sur HN parlent aussi de ce point. Je sais pas si DAO implique un truc basé sur une blockchain, ou si c'est juste un terme générique.
Ensuite, dans le cas de Mozilla, j'ai quand même le sentiment qu'il y a beaucoup de critiques qui sont vachement virulente sans que ça soit justifié. Quand ça arrive, j'ai le sentiment qu'il y a eu des disputes passés et qu'une partie des personnes impliqués n'a juste pas digéré.
Et j'ai le sentiment que c'est pareil pour Canonical (j'ai vu des gens être assez ordurier vis à vis de snap, mais personne explique vraiment le souci, à part "c'est différent, et je pige pas"). J'ai pas le sentiment que c'est le fait d'avoir snap par défaut, ou les qualités de snap, mais plus divers décisions prises par le passé (du style communication de Canonical et de Mark Shuttleworth, la dissolution du community council, ou ce genre de chose).
Je suis du coup pas super convaincu des exemples, même si de toute façon, le financement des gens dans le libre, ça va toujours être tendu vu que personne ne veut vraiment payer le tarif des devs.
Et une entreprise, c'est pratique, ça n'a pas de visage, donc on peut se laisser aller et râler dessus en oubliant qu'il y a des humains derriére. C'est largement socialement moins admis d'aller râler sur un projet de bénévoles, sauf si il est suffisamment gros pour être "déshumaniser" (wikipedia est l'exemple qui me vient à l'esprit, pour tout un tas de raisons)
(j'ai vu des gens être assez ordurier vis à vis de snap, mais personne explique vraiment le souci, à part "c'est différent, et je pige pas").
J'ai essayé une fois, ça ne m'a pas plu parce que ça me créait 3 ou 4 partitions par logiciel.
J'ai essayé de virer et nettoyer, et j'ai fini par formater tout le système pour y parvenir.
J'ai lu une méthode pour retirer snap, et c'est long et fastidieux… ça prends des heures.
C'est quoi l'intérêt de snap devant tout ces défauts? (en plus d'avoir éventuellement des logiciels qui sont plus lents, mais pas toujours)
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
C'est quoi l'intérêt de snap devant tout ces défauts?
Donc que je récapitule, les défauts, c'est:
- ça crée trop de partitions, et je cite "ça m'a pas plu"
- c'est dur à virer
Je confirme, je pige toujours pas. Je passe pas mon temps à regarder mount donc le fait de faire des partitions ne me parait pas un souci énorme. Je peux voir comment ça peut faire râler un peu, mais bon, c'est pas comme si c'était pas déjà une cause perdu comme le montre ça sur une Fedora 35:
$ mount | wc -l
34
(en plus d'avoir éventuellement des logiciels qui sont plus
lents, mais pas toujours)
Alors de ce que j'ai vu, c'est lié à l'usage d'un fichier squashfs. Canonical a commencé à bosser dessus, et ça semble aller mieux.
Mais vraiment, ça n'a pas l'air de justifier des propos comme ce que j'ai pu lire, surtout si c'est juste au lancement.
Quand j'ai besoin de recompiler un paquet Debian pour faire un petit changement, je peux. C'est pas facile, d'ailleurs, je le fais pas souvent, mais je peux. Le système ne râle pas quand je l'installe. Apparemment, avec snap, les paquets doivent être signés, donc il faut rajouter --dangerous.
Et si je veux distribuer des paquets snap à d'autres personnes, et qu'ils puissent avoir des mises-à-jour, il n'est pas possible de passer par autre chose que le magasin centralisé de Canonical. C'est de la perte de liberté contre un peu de sécurité. Les magasins centralisés existent déjà (packages.debian.org est centralisé, je lui fais confiance), mais si je veux, je peux faire confiance à quelqu'un d'autre. Pas avec snap, c'est donc une sorte de privation.
Bah, c'est pas parce que des exemples nombreux de foirages existent que Gitea va suivre la même route. Par contre, autant gagner de l'argent avec du support ou de l'hébergement, ça me va, autant :
An enhanced enterprise version
Là je sens que ça va mal finir… Ça va finir par mettre des fonctionnalités de manière arbitraire dans une version payante :( Enfin, j'espère être pessimiste, tout simplement.
Là je sens que ça va mal finir… Ça va finir par mettre des fonctionnalités de manière arbitraire dans une version payante :( Enfin, j'espère être pessimiste, tout simplement.
Oui, tout le reste, pourquoi pas, mais le coup de la version entreprise, en général accompagné de double licence, c'est triste. D'ailleurs c'est marrant mais ils citent le passage de Blender à Gitea, clairement une Success Story dont ils sont très fiers (en tous cas, c'est la seule qu'ils citent), surtout quand tous semblent passer à Gitlab ces dernières années.
Or si on lit le blog post de Blender mais surtout les commentaires ou les divers liens du post qui expliquent les raisons du choix, le fait que Gitea fait du tout-libre était clairement le gros point qui a fait basculer le choix. Ce n'est pas les fonctionnalités (même s'ils citent des fonctionnalités manquantes dans certains commentaires), car on voit clairement qu'ils n'ont pas peur de patcher si nécessaire. Par contre ils notent que certaines des fonctionnalités qu'ils veulent existent déjà dans la version "entreprise" et que ça veut dire qu'ils referont un travail en double, qui a peu de chance de se voir accepter dans la version communautaire (j'ai pas trop suivi, mais apparemment y a déjà eu ce genre de problème avec Gitlab qui veut garder sa version entreprise "attrayante") et ils devront donc maintenir un set de patchs à mettre à jour à chaque nouvelle sortir.
En outre, ils répètent encore et toujours que leur but est d'améliorer l'écosystème FLOSS.
Enfin bon, tout ça sont des raisons auxquels j'adhère à 100% aussi. C'est donc super dommage si Gitea se mettent à suivre la même voie (enfin pour nous du moins; pour eux, ça leur fera peut-être un financement plus durable; c'est juste dommage qu'ils n'aient pas réussi à trouver un modèle plus vertueux si vraiment le double édition/licence est ce vers quoi ils se dirigent).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je peux comprendre la peur, mais je crois pas que ça soit une riche idée pour un logiciel en go.
J'imagine que ça va plutôt s'orienter vers une LTS, ou un binaire avec des options de compilation spécifiques (vu qu'un des soucis avec le go, c'est de tout faire à la compilation).
(…) there are a few corporations (with revenues that are greater than some countries GDP) are building on Gitea for core products without even contributing back enhancements.
Ben ça me fait rire jaune. Quand on choisit une license MIT, on ouvre la porte à ce genre de comportement.
Elle est rigolote cette manie de cracher sur le copyfree en laissant croire que le copyleft serait serait mieux.
Le libre, MIT ou GPL, s'intéresse à celui qui reçoit et seulement lui, les 2 ont absolument rien à faire de l'auteur du développement, aucun des 2 n'oblige à contribuer. Ça serait GPL que ça ne changerait rien à leur problème (la GPL n'oblige pas non plus à filer les modifs à l'upstream et on peut cacher aussi ces modifs vu que l'obligation est de fournir le code a celui qui reçoit la version modifiée et lui seul).
Je te corrige donc : Quand on choisit une licence libre, on ouvre la porte à ce genre de comportement.
Si tu n'aimes pas ce comportement, c'est tout le libre qui n'est pas fait pour toi, le libre pensant à celui qui reçoit et non pas celui qui fournit.
et on peut cacher aussi ces modifs vu que l'obligation est de fournir le code a celui qui reçoit la version modifiée et lui seul
Vraie question, ça se pratique souvent ça, de "cacher" des modifs faites sous GPL ? J'imagine que c'est techniquement possible si tu fais comme les constructeurs de smartphones chinois et que tu ne fournis le code que si quelqu'un vient débarquer physiquement dans tes locaux avec une facture. Mais dans la situation de Gitea, s'ils étaient sous une licence copyleft, ne serait-il pas plus probable que les sociétés "au PIB plus grand que certains pays" joueraient le jeu et publieraient leurs contributions sur Internet, comme avec Blender ou le noyau Linux ? N'y a t-il vraiment aucune différence avec les licences permissives ?
Vraie question, ça se pratique souvent ça, de "cacher" des modifs faites sous GPL ?
Tu as les modifs de Google sur le noyau Linux? Voila :).
En pratique : tu ne peux pas savoir, car par définition ce n'est pas public. Je peux juste dire que ça se fait.
Mais en fait cacher n'est pas le sujet. Le sujet est que seuls ceux qui reçoivent le binaire ont le droit d'avoir le source, et dans la définition c'est clair : absolument rien à faire de l'auteur original. L'auteur original n'aura les modif qui si il prend le rôle de receveur, si il peut.
joueraient le jeu et publieraient leurs contributions sur Internet
Le sujet n'est pas la. Ils peuvent publier, comme plein de gens font, à ceux qui reçoivent. Ca n'est pas une contribution upstream, avec GPL tu peux faire tes règles, tes modifs, rien à faire d'être intégré par l'upstream, du coup il restera un travail énorme pour intégrer et pouvoir maintenir, même si tu as le code. Il y a plein de fork de Linux incompatibles entre eux, à la qualité pourrie, la GPL ne dit rien sur contribuer upstream.
Fournir les sources de ton travail != contribuer upstream.
N'y a t-il vraiment aucune différence avec les licences permissives ?
Il y en a… Mais pas du tout vers l'upstream, dont le libre se fout complet (son objectif est mettre d'en être indépendant), copyfree ou copyleft.
Beaucoup mélangent libre et communautaire/contribution, ce sont 2 sujets très différents. On peut faire du communautaire non libre (repo sous CC NC par exemple) ou du libre non communautaire (code fourni avec le binaire et pas ailleurs).
Cas simple, tu t'appelles Google, tu modifies Linux pour tes serveurs et tu ne publies pas le travail effectué à l'extérieur. Comme le code est purement interne, la GPL n'oblige rien.
Et les grosses structures ont très probablement beaucoup de code interne amélioré depuis une base GPL sans que cela ne sorte de l'entreprise. Parfois car le travail est probablement difficile à publier (pas bonne qualité, mauvaise intégration avec l'existant, travail trop spécifique), et probablement aussi pour des raisons de confidentialité et de concurrence.
Le résultat peut être pareil pour un produit vendu dans le commerce. Ils modifient Linux pour gérer le dernier téléphone de la gamme, mais le code source n'est pas forcément librement accessible par défaut sur Internet.
Le résultat peut être pareil pour un produit vendu dans le commerce. Ils modifient Linux pour gérer le dernier téléphone de la gamme, mais le code source n'est pas forcément librement accessible par défaut sur Internet.
Mais dans ce cas si je le demande au constructeur ils doivent fournir le code modifié, non ?
Je me demandais aussi si les ingénieurs Google ont ce genre de droits : je suis dev chez Google, on me fournit une machine avec un Linux modifié. Est-ce que je peux demander à Google de me fournir les sources ? Ou bien je suis considéré comme faisant partie de l'entité Google donc pas dans le cas de "personne qui reçoit" (Google n'a pas à fournir à Google) ?
Mais dans ce cas si je le demande au constructeur ils doivent fournir le code modifié, non ?
Oui, et après ?
Comme le souligne Zenitram, ce n'est pas parce que tu as le code en tant que client que s'en servir est trivial.
Pour travailler dans l'embarqué, je vois la problématique régulièrement. Les concepteurs de puce ou de matériels font des correctifs maison plus ou moins propres, sur des versions plus ou moins anciennes par ailleurs. Si tu veux pousser ce travail aux projets d'origine, ce n'est pas trivial du tout.
Je me souviens d'une époque où Marvell (ou Texas Instruments) je crois fournissais des pilotes Linux qui réinventait presque toute l'API I2C du noyau… Du coup si tu voulais pousser ce pilote avec toutes les fonctionnalités, tu devais réécrire pas mal de morceaux avant.
Et ça aucune licence ne peut l'empêcher. Cela commence à faire pas mal d'obstacles en la vision "le code est sous licence copyleft, donc tout changement effectué bénéficie au projet d'origine".
Je me demandais aussi si les ingénieurs Google ont ce genre de droits : je suis dev chez Google, on me fournit une machine avec un Linux modifié. Est-ce que je peux demander à Google de me fournir les sources ? Ou bien je suis considéré comme faisant partie de l'entité Google donc pas dans le cas de "personne qui reçoit" (Google n'a pas à fournir à Google) ?
Si le matériel appartient à l'entreprise (ce qui est fortement probable), je doute que tu aies le droit à quoique ce soit.
Si le matériel appartient à l'entreprise (ce qui est fortement
probable), je doute que tu aies le droit à quoique ce soit.
En pratique, Google doit sans doute publier les sources quelque part en interne, parce qu'il y a une demande sans doute des ingés capables de corriger ça. Et je pense qu'il y a sans doute un vide juridique/aucune jurisprudence/aucune interpretation sur le sujet pour dire quoi faire.
Oui, et après ?
[…] Cela commence à faire pas mal d'obstacles en la vision "le code est sous licence copyleft, donc tout changement effectué bénéficie au projet d'origine".
Et après rien. Je n'essayais pas de démontrer que le copyleft bénéficie à l'upstream, je posais une question. Merci pour les explications.
La GPL ne "fonctionne" que lors de la distribution du logiciel. Si on fournit à quelqu'un une copie du logiciel, alors cette copie doit contenir le code source, et le récepteur a le droit de modifier et redistribuer avec les mêmes conditions.
Pour un logiciel tournant sur un serveur comme Gitea, il n'y a pas de distribution vers les utilisateurs: le code reste sur le serveur. Donc tu ne peux pas demander l'accès au code source d'un site web que tu as simplement visité ou utilisé.
La license AGPL existe pour ce cas d'usage: elle permet à unsimple visiteur du site de demander l'accès aux sources.
Il y a plein d'autres cas ou la GPL n'oblige pas à tout rendre public. Par exemple dans plusieurs de mes projets pro on a utilisé Wireshark et développé plein de plugins sous license GPL. La conséquence est que on livre ces plugins à nos clients, avec les sources, sous license GPL. Pas qu'on doit les rendre publics ou les renvoyer aux développeurs de Wireshark.
(on a choisi, en accord avec nos clients, de contribuer à Wireshark certains plugins qui décodaient des protocoles standards ou normalisés, mais pas ceux implémentant des protocoles internes pour le projet)
Posté par orfenor .
Évalué à 4.
Dernière modification le 28 octobre 2022 à 13:28.
Je n'ai pas compris. Qui crache sur quoi ? Et qui laisse croire que la GPL serait mieux ?
C'est gentil de vouloir me corriger, mais pourquoi donc ? c'est eux qu'il faut corriger puisqu'ils se plaignent, pas moi. Ils semblent découvrir que des gens «se servent» sans contribuer, alors qu'on en parle depuis… pfouuuu… 1992 ? on se moquait déjà sur Usenet de ceux qui remerciaient en termes assez crus les gens qui ne faisaient aucun retour. Bref, au lieu de se plaindre, ils auraient du faire du proprio (l'auteur de Gogs, ne se plaint pas, lui).
Donc le projet a clarifié sur twitter que y a rien de prévu impliquant de la crypto (eg, pas de NFT ni rien), que le terme DAO était à prendre au sens premier (ie, pas avec de la crypto) et que c'est pour le moment exploratoire.
Ensuite, je trouve un peu hypocrite de râler sur le fait d'utiliser le trademark comme une possession personnelle quand on fait pareil avec une forge vielle d'il y a 5 ans, cf le renommage de hostea en Gna.
# "decentralized autonomous organization" ?
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 3.
Je sais que les temps sont durs pour gagner de l'argent avec du libre et que l'anticapitalisme est un obscurantisme, mais je ne suis pas très enthousiaste en lisant ça…
…suivi de ça :
Je sais que le modèle économique "société à but lucratif + communauté de contributeurs" est assez répandu dans le libre, je sais aussi qu'on reproche à Canonical, Muse Group ou la Mozilla Corp. de flinguer leurs produits (j'en parlais vite fait ici). Je me demande si ce genre de décisions foireuses est un risque inhérent à un tel montage, ou si en fin de compte, ce n'est pas l'apanage des "corporations" de promouvoir des idées chelou pour rétribuer le travail des développeurs libres.
[^] # Re: "decentralized autonomous organization" ?
Posté par Misc (site web personnel) . Évalué à 7.
C'est marrant, parce que les commentaires sur HN parlent aussi de ce point. Je sais pas si DAO implique un truc basé sur une blockchain, ou si c'est juste un terme générique.
Ensuite, dans le cas de Mozilla, j'ai quand même le sentiment qu'il y a beaucoup de critiques qui sont vachement virulente sans que ça soit justifié. Quand ça arrive, j'ai le sentiment qu'il y a eu des disputes passés et qu'une partie des personnes impliqués n'a juste pas digéré.
Et j'ai le sentiment que c'est pareil pour Canonical (j'ai vu des gens être assez ordurier vis à vis de snap, mais personne explique vraiment le souci, à part "c'est différent, et je pige pas"). J'ai pas le sentiment que c'est le fait d'avoir snap par défaut, ou les qualités de snap, mais plus divers décisions prises par le passé (du style communication de Canonical et de Mark Shuttleworth, la dissolution du community council, ou ce genre de chose).
Je suis du coup pas super convaincu des exemples, même si de toute façon, le financement des gens dans le libre, ça va toujours être tendu vu que personne ne veut vraiment payer le tarif des devs.
Et une entreprise, c'est pratique, ça n'a pas de visage, donc on peut se laisser aller et râler dessus en oubliant qu'il y a des humains derriére. C'est largement socialement moins admis d'aller râler sur un projet de bénévoles, sauf si il est suffisamment gros pour être "déshumaniser" (wikipedia est l'exemple qui me vient à l'esprit, pour tout un tas de raisons)
Donc il y a peut être aussi un effet à ce niveau.
[^] # Re: "decentralized autonomous organization" ?
Posté par GG (site web personnel) . Évalué à 7.
J'ai essayé une fois, ça ne m'a pas plu parce que ça me créait 3 ou 4 partitions par logiciel.
J'ai essayé de virer et nettoyer, et j'ai fini par formater tout le système pour y parvenir.
J'ai lu une méthode pour retirer snap, et c'est long et fastidieux… ça prends des heures.
C'est quoi l'intérêt de snap devant tout ces défauts? (en plus d'avoir éventuellement des logiciels qui sont plus lents, mais pas toujours)
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: "decentralized autonomous organization" ?
Posté par Misc (site web personnel) . Évalué à 5.
Donc que je récapitule, les défauts, c'est:
- ça crée trop de partitions, et je cite "ça m'a pas plu"
- c'est dur à virer
Je confirme, je pige toujours pas. Je passe pas mon temps à regarder mount donc le fait de faire des partitions ne me parait pas un souci énorme. Je peux voir comment ça peut faire râler un peu, mais bon, c'est pas comme si c'était pas déjà une cause perdu comme le montre ça sur une Fedora 35:
Alors de ce que j'ai vu, c'est lié à l'usage d'un fichier squashfs. Canonical a commencé à bosser dessus, et ça semble aller mieux.
Mais vraiment, ça n'a pas l'air de justifier des propos comme ce que j'ai pu lire, surtout si c'est juste au lancement.
[^] # Re: "decentralized autonomous organization" ?
Posté par Glandos . Évalué à 6.
Moi j'ai un problème conceptuel avec Snap.
Quand j'ai besoin de recompiler un paquet Debian pour faire un petit changement, je peux. C'est pas facile, d'ailleurs, je le fais pas souvent, mais je peux. Le système ne râle pas quand je l'installe. Apparemment, avec snap, les paquets doivent être signés, donc il faut rajouter
--dangerous.Et si je veux distribuer des paquets snap à d'autres personnes, et qu'ils puissent avoir des mises-à-jour, il n'est pas possible de passer par autre chose que le magasin centralisé de Canonical. C'est de la perte de liberté contre un peu de sécurité. Les magasins centralisés existent déjà (packages.debian.org est centralisé, je lui fais confiance), mais si je veux, je peux faire confiance à quelqu'un d'autre. Pas avec snap, c'est donc une sorte de privation.
[^] # Re: "decentralized autonomous organization" ?
Posté par Glandos . Évalué à 4.
Bah, c'est pas parce que des exemples nombreux de foirages existent que Gitea va suivre la même route. Par contre, autant gagner de l'argent avec du support ou de l'hébergement, ça me va, autant :
Là je sens que ça va mal finir… Ça va finir par mettre des fonctionnalités de manière arbitraire dans une version payante :( Enfin, j'espère être pessimiste, tout simplement.
[^] # Re: "decentralized autonomous organization" ?
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
Oui, tout le reste, pourquoi pas, mais le coup de la version entreprise, en général accompagné de double licence, c'est triste. D'ailleurs c'est marrant mais ils citent le passage de Blender à Gitea, clairement une Success Story dont ils sont très fiers (en tous cas, c'est la seule qu'ils citent), surtout quand tous semblent passer à Gitlab ces dernières années.
Or si on lit le blog post de Blender mais surtout les commentaires ou les divers liens du post qui expliquent les raisons du choix, le fait que Gitea fait du tout-libre était clairement le gros point qui a fait basculer le choix. Ce n'est pas les fonctionnalités (même s'ils citent des fonctionnalités manquantes dans certains commentaires), car on voit clairement qu'ils n'ont pas peur de patcher si nécessaire. Par contre ils notent que certaines des fonctionnalités qu'ils veulent existent déjà dans la version "entreprise" et que ça veut dire qu'ils referont un travail en double, qui a peu de chance de se voir accepter dans la version communautaire (j'ai pas trop suivi, mais apparemment y a déjà eu ce genre de problème avec Gitlab qui veut garder sa version entreprise "attrayante") et ils devront donc maintenir un set de patchs à mettre à jour à chaque nouvelle sortir.
En outre, ils répètent encore et toujours que leur but est d'améliorer l'écosystème FLOSS.
Enfin bon, tout ça sont des raisons auxquels j'adhère à 100% aussi. C'est donc super dommage si Gitea se mettent à suivre la même voie (enfin pour nous du moins; pour eux, ça leur fera peut-être un financement plus durable; c'est juste dommage qu'ils n'aient pas réussi à trouver un modèle plus vertueux si vraiment le double édition/licence est ce vers quoi ils se dirigent).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: "decentralized autonomous organization" ?
Posté par Misc (site web personnel) . Évalué à 4.
Je peux comprendre la peur, mais je crois pas que ça soit une riche idée pour un logiciel en go.
J'imagine que ça va plutôt s'orienter vers une LTS, ou un binaire avec des options de compilation spécifiques (vu qu'un des soucis avec le go, c'est de tout faire à la compilation).
Ensuite, il suffit d'aller demander sur https://discourse.gitea.io/t/open-source-sustainment-and-the-future-of-gitea-blog/6136 ou sur matrix.
[^] # Re: "decentralized autonomous organization" ?
Posté par orfenor . Évalué à 4.
Ben ça me fait rire jaune. Quand on choisit une license MIT, on ouvre la porte à ce genre de comportement.
[^] # Re: "decentralized autonomous organization" ?
Posté par Glandos . Évalué à 2.
Je sais pas s'ils ont choisi. C'est un fork de Gogs, qui était sous licence MIT.
[^] # Re: "decentralized autonomous organization" ?
Posté par abriotde (site web personnel, Mastodon) . Évalué à 7.
Justement avec la licence MIT tu fais ce que tu veux. Tu peux changer la licence pour proprio ou GPL..
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: "decentralized autonomous organization" ?
Posté par Zenitram (site web personnel) . Évalué à 5.
Elle est rigolote cette manie de cracher sur le copyfree en laissant croire que le copyleft serait serait mieux.
Le libre, MIT ou GPL, s'intéresse à celui qui reçoit et seulement lui, les 2 ont absolument rien à faire de l'auteur du développement, aucun des 2 n'oblige à contribuer. Ça serait GPL que ça ne changerait rien à leur problème (la GPL n'oblige pas non plus à filer les modifs à l'upstream et on peut cacher aussi ces modifs vu que l'obligation est de fournir le code a celui qui reçoit la version modifiée et lui seul).
Je te corrige donc : Quand on choisit une licence libre, on ouvre la porte à ce genre de comportement.
Si tu n'aimes pas ce comportement, c'est tout le libre qui n'est pas fait pour toi, le libre pensant à celui qui reçoit et non pas celui qui fournit.
[^] # Re: "decentralized autonomous organization" ?
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 27 octobre 2022 à 09:23.
Vraie question, ça se pratique souvent ça, de "cacher" des modifs faites sous GPL ? J'imagine que c'est techniquement possible si tu fais comme les constructeurs de smartphones chinois et que tu ne fournis le code que si quelqu'un vient débarquer physiquement dans tes locaux avec une facture. Mais dans la situation de Gitea, s'ils étaient sous une licence copyleft, ne serait-il pas plus probable que les sociétés "au PIB plus grand que certains pays" joueraient le jeu et publieraient leurs contributions sur Internet, comme avec Blender ou le noyau Linux ? N'y a t-il vraiment aucune différence avec les licences permissives ?
[^] # Re: "decentralized autonomous organization" ?
Posté par Zenitram (site web personnel) . Évalué à 2.
Tu as les modifs de Google sur le noyau Linux? Voila :).
En pratique : tu ne peux pas savoir, car par définition ce n'est pas public. Je peux juste dire que ça se fait.
Mais en fait cacher n'est pas le sujet. Le sujet est que seuls ceux qui reçoivent le binaire ont le droit d'avoir le source, et dans la définition c'est clair : absolument rien à faire de l'auteur original. L'auteur original n'aura les modif qui si il prend le rôle de receveur, si il peut.
Le sujet n'est pas la. Ils peuvent publier, comme plein de gens font, à ceux qui reçoivent. Ca n'est pas une contribution upstream, avec GPL tu peux faire tes règles, tes modifs, rien à faire d'être intégré par l'upstream, du coup il restera un travail énorme pour intégrer et pouvoir maintenir, même si tu as le code. Il y a plein de fork de Linux incompatibles entre eux, à la qualité pourrie, la GPL ne dit rien sur contribuer upstream.
Fournir les sources de ton travail != contribuer upstream.
Il y en a… Mais pas du tout vers l'upstream, dont le libre se fout complet (son objectif est mettre d'en être indépendant), copyfree ou copyleft.
Beaucoup mélangent libre et communautaire/contribution, ce sont 2 sujets très différents. On peut faire du communautaire non libre (repo sous CC NC par exemple) ou du libre non communautaire (code fourni avec le binaire et pas ailleurs).
[^] # Re: "decentralized autonomous organization" ?
Posté par Renault (site web personnel) . Évalué à 5.
Cas simple, tu t'appelles Google, tu modifies Linux pour tes serveurs et tu ne publies pas le travail effectué à l'extérieur. Comme le code est purement interne, la GPL n'oblige rien.
Et les grosses structures ont très probablement beaucoup de code interne amélioré depuis une base GPL sans que cela ne sorte de l'entreprise. Parfois car le travail est probablement difficile à publier (pas bonne qualité, mauvaise intégration avec l'existant, travail trop spécifique), et probablement aussi pour des raisons de confidentialité et de concurrence.
Le résultat peut être pareil pour un produit vendu dans le commerce. Ils modifient Linux pour gérer le dernier téléphone de la gamme, mais le code source n'est pas forcément librement accessible par défaut sur Internet.
[^] # Re: "decentralized autonomous organization" ?
Posté par Faya . Évalué à 3.
Mais dans ce cas si je le demande au constructeur ils doivent fournir le code modifié, non ?
Je me demandais aussi si les ingénieurs Google ont ce genre de droits : je suis dev chez Google, on me fournit une machine avec un Linux modifié. Est-ce que je peux demander à Google de me fournir les sources ? Ou bien je suis considéré comme faisant partie de l'entité Google donc pas dans le cas de "personne qui reçoit" (Google n'a pas à fournir à Google) ?
[^] # Re: "decentralized autonomous organization" ?
Posté par Renault (site web personnel) . Évalué à 5.
Oui, et après ?
Comme le souligne Zenitram, ce n'est pas parce que tu as le code en tant que client que s'en servir est trivial.
Pour travailler dans l'embarqué, je vois la problématique régulièrement. Les concepteurs de puce ou de matériels font des correctifs maison plus ou moins propres, sur des versions plus ou moins anciennes par ailleurs. Si tu veux pousser ce travail aux projets d'origine, ce n'est pas trivial du tout.
Je me souviens d'une époque où Marvell (ou Texas Instruments) je crois fournissais des pilotes Linux qui réinventait presque toute l'API I2C du noyau… Du coup si tu voulais pousser ce pilote avec toutes les fonctionnalités, tu devais réécrire pas mal de morceaux avant.
Et ça aucune licence ne peut l'empêcher. Cela commence à faire pas mal d'obstacles en la vision "le code est sous licence copyleft, donc tout changement effectué bénéficie au projet d'origine".
Si le matériel appartient à l'entreprise (ce qui est fortement probable), je doute que tu aies le droit à quoique ce soit.
[^] # Re: "decentralized autonomous organization" ?
Posté par Misc (site web personnel) . Évalué à 5.
En pratique, Google doit sans doute publier les sources quelque part en interne, parce qu'il y a une demande sans doute des ingés capables de corriger ça. Et je pense qu'il y a sans doute un vide juridique/aucune jurisprudence/aucune interpretation sur le sujet pour dire quoi faire.
De plus, Google emploie aussi des sous traitants (donc pas dans l'entité Google par définition), ce qui est peut être la raison pour eux d'interdire l'AGPL en interne
[^] # Re: "decentralized autonomous organization" ?
Posté par Faya . Évalué à 2.
Et après rien. Je n'essayais pas de démontrer que le copyleft bénéficie à l'upstream, je posais une question. Merci pour les explications.
[^] # Re: "decentralized autonomous organization" ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 5.
La GPL ne "fonctionne" que lors de la distribution du logiciel. Si on fournit à quelqu'un une copie du logiciel, alors cette copie doit contenir le code source, et le récepteur a le droit de modifier et redistribuer avec les mêmes conditions.
Pour un logiciel tournant sur un serveur comme Gitea, il n'y a pas de distribution vers les utilisateurs: le code reste sur le serveur. Donc tu ne peux pas demander l'accès au code source d'un site web que tu as simplement visité ou utilisé.
La license AGPL existe pour ce cas d'usage: elle permet à unsimple visiteur du site de demander l'accès aux sources.
Il y a plein d'autres cas ou la GPL n'oblige pas à tout rendre public. Par exemple dans plusieurs de mes projets pro on a utilisé Wireshark et développé plein de plugins sous license GPL. La conséquence est que on livre ces plugins à nos clients, avec les sources, sous license GPL. Pas qu'on doit les rendre publics ou les renvoyer aux développeurs de Wireshark.
(on a choisi, en accord avec nos clients, de contribuer à Wireshark certains plugins qui décodaient des protocoles standards ou normalisés, mais pas ceux implémentant des protocoles internes pour le projet)
[^] # Re: "decentralized autonomous organization" ?
Posté par orfenor . Évalué à 4. Dernière modification le 28 octobre 2022 à 13:28.
Je n'ai pas compris. Qui crache sur quoi ? Et qui laisse croire que la GPL serait mieux ?
C'est gentil de vouloir me corriger, mais pourquoi donc ? c'est eux qu'il faut corriger puisqu'ils se plaignent, pas moi. Ils semblent découvrir que des gens «se servent» sans contribuer, alors qu'on en parle depuis… pfouuuu… 1992 ? on se moquait déjà sur Usenet de ceux qui remerciaient en termes assez crus les gens qui ne faisaient aucun retour. Bref, au lieu de se plaindre, ils auraient du faire du proprio (l'auteur de Gogs, ne se plaint pas, lui).
[^] # Re: "decentralized autonomous organization" ?
Posté par Misc (site web personnel) . Évalué à 3.
Donc le projet a clarifié sur twitter que y a rien de prévu impliquant de la crypto (eg, pas de NFT ni rien), que le terme DAO était à prendre au sens premier (ie, pas avec de la crypto) et que c'est pour le moment exploratoire.
Cf https://twitter.com/giteaio/status/1585297381926793216 , pointé par un membre du projet sur
https://discourse.gitea.io/t/open-source-sustainment-and-the-future-of-gitea-blog/6136
# More drama
Posté par Misc (site web personnel) . Évalué à 4.
Pendant ce temps, il y a aussi des discussions sur ForgeFriends, et sur le fediverse.
Ensuite, je trouve un peu hypocrite de râler sur le fait d'utiliser le trademark comme une possession personnelle quand on fait pareil avec une forge vielle d'il y a 5 ans, cf le renommage de hostea en Gna.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.