[Trad Gnu] Traduction de "Why hackathons should insist on free software"

[Nicola Spanti <nicola.spanti AT ecole.ensicaen.fr>]

Bonjour/Bonsoir.

J'ai fait une traduction de "Why hackathons should insist on free
software" (du projet GNU).
https://framasphere.org/posts/3951842
https://nl.movim.eu/?blog/rydroid%40movim.eu/71bfde49-0aa3-457d-82ae-cc318016b72a
Je vous ai joint la version en syntaxe markdown. Au besoin, vous pouvez
automatiquement faire une conversion en HTML avec markdown ou pandoc.

Cordialement.
https://www.gnu.org/philosophy/hackathons.html


# Pourquoi les hackathons devrait insister sur le logiciel libre

Les hackathons sont une méthode acceptée pour aider une communauté dans le développement de ses projets numériques. La communauté invite des développeurs et développeuses à se joindre à un événement qui offre un cadre encourageant, quelques ressources utiles, et l'opportunité de travailler sur des projets utiles. La plupart des hackathons choisissent les projets qu'ils supportent, sur la base de critères énoncés.

Les hackathons sont dans un esprit de communauté dans lequel les gens ont une attitude de coopération et de respect des autres. Le logiciel qui va avec cet esprit est [le logiciel libre](https://www.gnu.org/philosophy/free-sw.html). Chaque logiciel libre a une licence qui donne la liberté de coopérer à ses utilisateurs et utilisatrices (ainsi qu'à ses développeurs et développeuses). En cela, les hackathons font sens dans la communauté du logiciel libre. [Les projets de plans libres pour le matériel](https://www.gnu.org/philosophy/free-hardware-designs.html) peuvent et doivent aussi être libres.

Le respect de la liberté ne peut être pris comme acquis. Au contraire, nous sommes entourés par des entreprises qui sans honte publient du logiciel privateur (de libertés), disponible uniquement pour l'usage qui vont succomber à leur pouvoir. Ces entreprises développent du logiciel comme un [moyen de domination et de contrôle des autres](https://www.gnu.org/philosophy/free-software-even-more-important.html).

Le succès nocif de ces entreprises inspire de jeunes développeurs et développeuses à suivre leur exemple en développant leur propres programmes ou matériels qui dominent les utilisateurs et utilisatrices. Ils et elles amènent parfois leurs projets à des hackathons, sollicitant l'aide de la communauté tout en rejetant l'esprit de la communauté : ils et elles n'ont aucune intention de coopérer en retour de la coopération. Les hackathons qui acceptent cela sape l'esprit de la communauté sur lequel ils se basent.

Des hackathons pervers sont spécifiquement dédiés à aider l'informatique de certaines entreprises (par exemple des [banques européennes](https://www.beyondhackathon.com/en) et [canadiennes](http://www.hackathon.io/rbc-digital), et [Expedia](http://expediaconnectivity.com/blog#madrid-hackathon-winners)). Bien qu'ils ne l'affirment pas explicitement, les annonces donnent l'impression qu'ils ont pour but le développement de certains logiciels non libres, et que les participant·e·s sont supposé·e·s aider ces projets de non-charité.

Ces exemples montrent à quel point la pente des hackathons peut mener bien bas. Retournons à une cas plus commun d'un hackathon qui n'est pas spécifiquement commercial, mais accepte des projets qui sont privateurs.

Quand un développeur ou une développeuse apporte un projet à un hackathon, et ne dit pas s'il est libre, ce n'est pas une opposition manifeste contre l'esprit de la communauté, mais cela sape l'esprit. Les hackathons devraient renforcer l'esprit de communauté sur lequel ils se basent, en insistant que les projets du hackathon s'engagent à publier d'une façon qui est en accord avec cet esprit.

Cela signifie dire aux développeurs et développeuses, "Pour que tu mérites notre soutien et notre aide, tu dois accepter de donner à la communauté le droit d'utiliser librement les résultats de ton projet, si un jour tu les considères assez bons pour être utilisés ou publiés."

En tant que simple participant ou participante à un hackathon, vous pouvez suivre et encourager ce principe : avant de se joindre à un projet de hackathon, demandez "Sous quelle(s) licence(s) allez vous publier ? Je veux être sûr que cela va être libre avant de me joindre pour le développement." Si les développeurs et développeuses du projet disent qu'illes choisiront la licence ou les licences plus tard, vous pouvez répondre que vous déciderez plus tard si vous participez. Ne soyez pas timides, si d'autres entendent cette discussion, ils pourraient décider de suivre le même chemin.

Pour voir quelles licences sont libres, vous pouvez consulter [la liste de licences du projet GNU](https://www.gnu.org/licenses/license-list.html). La plus part des licences "open source" sont libres, mais [quelques licences open source sont non libres à cause de trop de restrictions](https://www.gnu.org/philosophy/open-source-misses-the-point.html).

La fermeté des individus a un effet, mais une règle du hackathon lui-même aura plus d'effet. Les hackathons devraient demander à chaque projet qui participe de s'engager à suivre cette règle :

> Si vous publiez ou utilisez ce code ou plan, vous publierez les sources correspondantes sous une licence libre (ou plusieurs). Si vous distribuez sous une forme exécutable, vous le rendrez aussi libre.

Beaucoup de hackathons sont sponsorisés ou hébergés par des écoles, ce qui fait une raison de plus pour suivre cette règle. Le logiciel libre est une contribution au savoir commun, tandis que le logiciel non libre refuse le savoir au public. En conséquence, [le logiciel libre est en cohérence avec l'esprit de l'éducation, tandis que le logiciel privateur s'y oppose](https://www.gnu.org/education/edu-schools.html). Les écoles devraient insister que tous leurs développements logiciels soient du logiciel libre, y compris ceux que les hackathons accompagnent.