Le post de @Tiger222 est intéressant en lui-même et donne le sentiment que Microsoft s'intéresse enfin (après 30 ans) à l'avis de ses utilisateurs, oui mais...

Quand nous allons sur le répo GitHub dont il est question, nous pouvons constater que tous les projets listés :

• Windows Terminal / Console / command-line
• Windows Subsystem for Linux (WSL)
• PowerShell
• PSReadLine
• OpenSSH for Windows
• .NET Core runtime & libraries
• ASP.NET Core
• Roslyn (C# & Visual BASIC Compiler Platform)
• Windows Presentation Foundation (WPF)
• WinForms
• WinUI
• Winget package manager app
• Winget package repo
• PowerToys
• Project Reunion

sont sous la licence MIT.

Mais quel pourrait être le problème avec cette licence se demandent sûrement certains ?

Tout simplement que la licence MIT est une licence libre mais du point de vue d'une entreprise commerciale à but lucratif seulement (pléonasme) et non du point de vue des citoyens que nous sommes. C'est-à-dire qu'elle permet à quiconque réutilisant du source sous licence MIT d'en faire soit un logiciel open-source, soit un logiciel close-source.

C'est un débat que j'ai longtemps eu que avec @Kysofer et @Tarq. À l'époque, mon point de vue était de dire : "oui mais avec une licence MIT ou Apache 2.0, je suis plus libre parce que je peux faire de l'open-source OU du close-source, alors que les GPL et AGPL permettent de ne faire QUE de l'open-source. En réalité la GPL et la AGPL sont moins ouvertes et confèrent moins de libertés aux développeurs que les licences MIT et Apache 2.0".

SPOILER : j'avais tort !

Les deux ont argumenté pendant des mois et ont fini par me convaincre avec les propos suivants :

1. Les licence MIT et Apache 2.0 permettent de faire sur close-source mais ceci est uniquement dans l'intérêt de sociétés commerciales, toi en tant qu'individu tu n'es pas une entreprise, ce n'est donc pas la liberté d'entreprendre et de faire de l'argent qui devrait primer de ton point de vue mais la liberté d'utiliser et d'être tranquille dans ta vie de tous les jours lorsque tu utilises un logiciel.

2. Le logiciel libre se finance de plusieurs manières :

   • En lui donnant de l'argent.
   • En contribuant à son développement (code, traduction, documentation, etc).
   • En animant sa communauté.
   • En assurant son support.

Par contre, utiliser les sources d'un logiciel libre pour en faire du close-source ce n'est pas contribué ni financer ce logiciel. À l'opposé, toute personne qui modifie un logiciel libre et qui se retrouve obligée de diffuser le code source modifié aura contribué à ce logiciel, cette personne n'aura pas payé avec de l'argent mais payé avec son temps et la redistribution de ses modifications.

Si une entreprise ne souhaite pas contribuer à un logiciel libre avec du temps et du code source, alors elle doit le payer avec de l'argent. À cet instant, c'est la stratégie de la double licence qui devrait être mise en place :

• Par défaut les sources sont sous GPL ou AGPL et celles-ci sont gratuites mais toute modification doit être redistribuée à la communauté.
• Si une entreprise commerciale souhaite faire du close-source, alors elle achète les sources sous une licence propriétaire et commerciale qui le lui permet avec un partie de l'argent qu'elle espère gagner du projet modifié, ça s'appelle invertir et c'est la raison même d'exister d'une entreprise.

Dans la démarche de Microsoft, je vois seulement une entreprise commerciale, richissime, littéralement ennemie du libre depuis sa création (cf. tous les posts de @Sebsauvage sur la question), qui obtient de la part de développeurs charitables du travail bénévole et des trésors d'innovations qu'elle pourra close-sourcer à volonté plus tard... Comment vous dire ? Merci mais non merci.

Nous ne sommes pas des personnes morales mais des personnes physiques, en tant qu'êtres humains nous n'avons pas les mêmes intérêts que des entreprises, en ce sens ne nous prenons pas pour des personnes morales en nous imaginant générer du profit à outrance à partir du travail gratuit et bénévole d'une communauté de passionnés.

Le meilleur c'est que je défends à présent cette idée en étant actuellement à mon compte et donc en disposant déjà d'une structure juridique me permettant de commercialiser ce que je voudrais. Or ceux qui ont le fantasme de développer un produit miracle à close-sourcer en spoliant les trésors d'ingéniosité des logiciels libres, sont pour certains d'entre-eux des salariés enchaînés à une clause d'exclusivité totale intégrée à leur contrat de travail, rendant caduque l'idée même de développer un produit avant même qu'un début de réalisation ne soit amorcé.

Bref, si j'étais une développeuse qui souhaite contribuer par des tickets à amélioration d'un logiciel, j'irai voir du côté de Linux Mint ou des GNU tools ou encore de Mozilla, MyPaint, WineHQ, GTK, OpenJDK, PHP, bref tout mais pas quelque chose sous licence Apache 2.0 ou MIT.

En voulant rendre accessible une application Web de l'extérieur en passant par un reverse proxy apache, je me suis aperçu que les liens vers les fichiers CSS [...] étaient en dur.

Bon, comment réécrire dynamiquement les URL absolues, c'est-à-dire de la forme http(s)://host:port/path à la place de /path, dans vos pages (#MauvaisePratique) avec Apache.

Je ne suis pas une grande fana de Gradle (je n'aime pas avoir du code dans ma configuration de build, parce que cela transforme ma configuration tout bête et déclarative, en un script avec du code potentiellement très compliqué dedans).

Apache Buildr reprend les bonnes pratiques de Maven c'est-à-dire :

• Séparer la partie du build qui exécute quelque chose (les plugins)
• De la partie qui dit quoi exécuter et quand (le pom.xml)

L'autre bénéfice, c'est que cela vous pousse à simplifier votre processus de build plutôt que de couvrir votre dette technique avec un script Groovy/Gradle par-dessus : on ne résout pas un problème d'organisation avec du code, il faut être soit débile (cf. écrits de Deleuze) soit un gros nerd à moitié taré pour penser ça car ce faisant on ne remonte pas à la root cause du problème. #MonPointDeVue #SiTuTeSensViséTesKunKon.

Gradle promeut cette croyance de noob qui dit que fusionner la préoccupation de workflow de build avec la préoccupation d'exécution (c'est-à-dire avec du code, avec des if-then-else, while-for, throw-catch...) c'est jeun's, cool, rebelle et vachement-plus-rapide-nempêche. Or si vous m'avez suivi jusque-là, vous comprenez en quoi il est essentiel de séparer ces préoccupations !

C'est pour cela que Maven force les gens à développer des plugins, pour que ce travers de tout mélanger par fainéantise ne vous gagne pas. Une dette technique impardonnable en Java depuis 2010, c'est bien celle qui se situe au niveau du build, alors en 2016, c'est juste une honte.

Chlouchloutte, tu me posais la question de comment faire une appli mobile multi-plateformes et sans se prendre la tête.

Je te laisse me dire ce que tu penses de Cordova.

via : http://user23.net/links/index.php?g7BerQ (qui fournit une explication de comment installer l'outil)

Les différentes méthodes de chargement des CSS en Tapestry. (oui je travaille avec cette techno en ce moment :D).

Coudifié