Vers un wiki mutualisé des fabriques

De Communauté de la Fabrique des Mobilités
Aller à :navigation, rechercher

Page importé depuis ce pad le 23 / 10 / 2024 . Pensez à mettre à jour la pad si des modifications sont intervenues sur le pad.

tags: inter-fabriques wiki coopération

Vers un wiki mutualisé des fabriques ?

0- À propos

Ce document de prise de notes soutient les discussions autour d'une mutualisation de wikis entre plusieurs réseaux et communautés qui cultivent des ressources ouvertes partagées.

:::success

1- Acteurs

1.1- ++Réseaux et fabriques++

  • Matéi (Réseau Fr des FabLabs)
  • Simon (Réseau Fr des FabLabs)
  • Hugues (Réseau Fr des FabLabs)
  • Nicolas (Oxamyne, FabEnergies)
  • Rieul (Oxamyne, FabEnergies)
  • Mael (Fabrique des Mobilités)
  • Gabriel (ADEME, FabMob)
  • Thomas (Faire Ecole Ensemble)
  • Michel (Riposte Creative, etc.)

1.2- ++Personnes-ressources++

  • Simon (Opteos, TILIOS)
  • Clément (Dokit)
  • Gautier (Dokit)
  • Nicolas (Wiki Valley)
  • Timothée (Indie.Host)
  • Pierre (Indie.Host)

2- Les wikis

2.1- ++FabMob++

:::info

  • Github FabMob : https://github.com/fabmob/wiki/issues

  • Mises à jour : https://pad.fabmob.io/COT0Fz0_R6uR5jXGmvxJzw

  • Contributeurs

    • Salariés FabMob et réseau des FabMobs (Québec surtout)
    • Bénévolat : reconnaissance par les open badges par ex
    • "Commoneurs" : co-rémunération testé dans MoviLab.
      • Cf. et exemple de doc d'autodéclaration des heures
      • Cela permet d'avoir des personnes bien investies
      • Partage des connaissances, appropriation du wiki
    • Prestations : en fonction des disponibilités et des compétences

  • Méthodologie

    • Clé répartition des priorités (asso FabMob + contributeurs)
    • Clé de répartition entre les différentes types de contributeurs
    • Transparence sur les clés de répartition des contributeurs
      • Éventuels biais du fait des principaux contributeurs

  • Processus de décision

    • Publication sur le github > hiérarchisation et priorisation
    • Interne (à l'association/communauté) Fabmob si pas possible =>
    • Action de Simon (Sarazin) et/ou d'autres commoners
    • Si pas possible, décision de la Fabmob pour faire une prestation

2.2- ++FabEnergies++

2.3- ++RFFlabs++

  • Dans le réseau, les wikis sont utilisés pour documenter la vie de chaque FabLab.
  • Complément d'Hugues (vice-président du RFFlab), par mail (le 30 juin 2020) :
    • Apres échange avec Matei et vu la charge (et aussi un peu de fatigue, je pense) côté RFFLabs, je propose que par chez nous on relance l'utilisation du wiki du RFFlabs mais de manière à préparer l'inter-opérabilité avec les wikis des fabriques si cela est possible, en accélérant le contenu dans une session de documentation et une rencontre inter-projets à Octobermake (octobre 2020, Toulouse) lors de la rencontre annuelle des (fab)labs. Par chez nous, c'est du mediawiki. Du coup cela permettrait de préparer le terrain à une syndication de contenu dans votre chouette dynamique d'une part, et même de pouvoir extraire une Fabrique de la Santé le moment venu (?).
    • A l'échelle internationale, pour le moment, une grande partie des contenus à valeur ajoutée des collectifs de makers/coro/open sante internationaux sont sous forme PDF, sites web avec bases d'objets, et avec des canaux d'échanges communautaires + greniers de stockage de fichiers. Ce n'est pas facilement itérable et traduisible. Il n'y a pas de wiki commun, alors qu'il y a un fort enjeu de mise à jour, traduction, etc. Il me semble évident qu'au moins un wiki/une plateforme international(e) va surgir pour partager notamment les objets de santé open-hardware, les fiches d'allégation de ces objets et les informations "locales" (process des autorités sanitaires, etc).
    • Je l'ai dit à Matei, je crois beaucoup dans la charte, le fonctionnement et l'outillage de la fabrique des mobilités. C'est clair en terme d'intention, de fabrication de communs, il y a une économie pour payer du temps et l'éventail méthodo et outillage est duplicable. Par contre il a raison sur le fait qu'on a besoin de quelques semaines.
    • Seriez-vous partants pour qu'on organise cette session inter-wikis sur octobermake et que je commence à recruter et rassembler d'ici là sur la thématique santé ?
    • De mon côté je réfléchis à quels sont les acteurs possibles pour soutenir ce type de projets dans le registre de la santé. Pour le moment, il n'y en a pas encore beaucoup côté secteur privé dans l'openess... [@Nico L : à discuter avec Hack your Research ?].

2.4- ++Open Santé++

:::info Open Santé est un projet pour avoir des Fablab orientés vers le milieu du soin. :::

  • En cours "de route" au niveau international. Devrait être opérationnel cet automne
  • Coté USA : base de données des protos, recommandations, équipe de traducteurs
  • Coté Afrique et Asie : liste des fablabs et d'hopitaux qui sont en coopération

2.5- ++Faire École++

3- Scénarii

3.1- ++Contexte (été 2020)++

3.2- ++Schéma (théorique)++

:::warning Cette architecture est une proposition pour : 1/ une autonomie des communautés (pour leurs communications) 2/ une mutualisation d'outils relevant de pratiques partagées. :::

digraph hierarchy {

                nodesep=0.5 // increases the separation between nodes

                node [color=Red,fontname=Courier,shape=box] //All nodes will this shape and colour
                edge [color=Blue, style=dashed] //All the lines look like this

                "Spécifique 
communauté"->{"Chats à fédérer
Ferme de chats
Indiehost" "Sites web
Ferme de sites
LSC"}
                "Chats à fédérer
Ferme de chats
Indiehost"->{"chat.fabenergies.cc" "chat.fabmob.io" "..."}
                "Sites web
Ferme de sites
LSC"->{"fabenergies.cc" "lafabriquedesmobilites.fr" "...."}
                {rank=same; "fabenergies.cc" "lafabriquedesmobilites.fr" "...."}  // Put them on the same level
}
digraph hierarchy {

                nodesep=0.5 // increases the separation between nodes

                node [color=Red,fontname=Courier,shape=box] //All nodes will this shape and colour
                edge [color=Blue, style=dashed] //All the lines look like this
                "Mutualisatble par les communautés"->{PAD WIKI Cloud Forum}
                WIKI->{"wiki.fabco.org"}
                "wiki.fabco.org"->{"energies.wiki.fabco.org" "mobilités.wiki.fabco.org" "educations.wiki.fabco.org" "..."}
                PAD->{"pad.fabco.org"}
                Cloud->{"cloud.fabco.org"}
                Forum->{"discourse.fabco.org"}
              {rank=same;"energies.wiki.fabco.org" "mobilités.wiki.fabco.org" "educations.wiki.fabco.org" "..."}  // Put them on the same level
}

4- Échanges

10/05/2021

Présent·es

  • Simon Sarazin
  • Gabriel Plassat
  • Nicolas Loubet
  • Malou Charenton
  • Benjamin Gentils
  • Tristan Bouvon

Sujets du jour

  • Organisation d'un séminaire chez Simon
    • Amélioration de l'outil mediawiki
    • Montée en compétences collective

Discussion

:::info Pad dédié à la résidence : https://pad.fabmob.io/BtCy6OapRty2bDcCwY17gw?view :::

  • Simon : on peut accueillir jusqu'à 14 personnes. Par contre, il y a besoin de caler vite les dates et de participer aux frais (tarif / personne). Nous avons un petit budget à l'ANIS de 1k€. Pour les repas, quelqu'un peut être en support et il y a possiblité d'avoir un traiteur.

  • Gabriel : l'objectif est de s'engager dans une démarche d'amélioration. Dans le cas où le wiki FabMob devient inter-fabriques, il s'agira de réduire la présence de la FabMob.

  • Benjamin : mon agenda n'esst pas encore clair. L'association pourra faire une invitation aux membres. A moyen terme, FEE serait dédié exlusivement à faciliter la documentation.

  • Malou : si je suis dans cet échange, c'est parce que je fais le lien avec la Fabrique de la Logistique. Je vois des liens à faire avec la Fabrique des Santés. Pour la FabMob, ce serait chouette d'avoir 2 personnes de l'équipe (pour monter en compétences sur le jardinage).

  • Tristan : +1 sur la pratique du jardinage. Ce ne sera pas forcèment moi, mais Julien ou Victor qui font l'animation de la FabLog. Ils sont davantage au contact des communautés.

  • Simon : on peut convier Benjamin (Opteos), Sébastien/Nicolas (WikiValley), Clément (Dokit)

  • Gabriel : sur ce séminaire, on peut travailler des cas pratiques. Nous avons deux grand sscénarii : 1/ centralisation sur un wiki 2/ fédération de wikis. La question, c'est comment tester simplement cette notion d'inter-wikis (dans une logique d'archipel informationnel).

30/04/2021

Présent·es

  • Simon Louvet
  • Simon Sarazin

Sujets

  • Réflexion sur l'interopérabilité des wikis

Discussion

  • Prmière étape : avoir une fiche Coopcyle sur le wiki de l'appel à communs de la résilience et voir si les wiki de la FabMob ou Movilab peuvent la lire et l'afficher sans souci.
  • Mediawiki est un logiciel qui n'est pas encore basée sur les "normes sémantiques". Si les normes LDP du W3C ne sont pas respectées, il convient d'avoir recours au bus sémantique.

:::info ++Intéropérer++ :

  • (1) Lier une donnée d'un outil à celle d'un autre outil : la fiche du wiki 1 est réalisée par l'entreprise du wiki 2 ; il y a un lien entre concepts sur 2 serveurs différents
  • (2) Naviguer de manière transparente : si on suit ce lien, l'interface du serveur continue et affiche la data du serveur
  • (3) URI : dans un outil, je veux ne pas créer de nouvelle fiche, cf. celle du 2 dans l'interface 1
  • (4) Synchronisation : copie de l'information avec une propriété qui repointe vers l'information d'origine ; c'est la fiche maitre qui est modifée
  • (5) Activity Pub : j'informe de ce qui se passe sur un serveur et les personnes qui le veulent le sont. Quelles sont les actions qui se passent ? Cela ne préjuge pas que c'est en sémantique.

Questions sur les noeuds

  • Serveur maitre sans duplication physique. Quand tu références une donnée, copie en local sur le serveur 1. Ex : j'ai une donnée en local qui synchronise. Le serveur qui produit la donnée est responsable. Chacun doit se mettre à jour : soit le fork est une copie et on garde la trace vers l'origine. Soit on synchronise : on garde le même état entre les deux.
  • WebACL permet de dire qui a accès à quoi. Mécanisme d'autentification commun à tous : Oauth / Oidc. C'est un tiers de confiance qui apporte l'authentification. Cela n'empêche pas d'avoir des fiches user sur des serveurs sémantiques. Login.lescommuns.org.
  • Solid est basé sur Webid/Oidc. Chaque serveur sémantique peut être un serveur OIDC. L'autentification est distribuée, chaque serveur est maitre de son authentification. Quand tu t'enregistres ailleurs, il a l'information et s'autorise à vérifier que tu peux bien t'authentifier.
  • Quoi qu'il arrive, il y aura besoin d'un mécanisme d'authentification À chaque fois qu'on va accéder à une donnée, il faut savoir qui tu es, si tu es en droit d'y accéder (webacl).
  • Il y a des interfaces visuelles pour SemApps (react admin) et Startinblox (webcomponent).

2 serveur wiki + 1 SemApps

  • On commence à se dire que d'envoyer l'info dans une base de donnée en semapps, à partir de laquelle on informe de qui est maître de la donnée dans le réseau, pourrait être un moyen de commencer à interopérer des informations. On renseigne que telle fiche du mediawiki 1 est la même chose sur un autre serveur mediawiki 2, mais mediawiki 1 est maitre de la fiche et mediawiki 2 n'est qu'une copie qui se mettrait à jour quand mediawiki 1 est modifiée. Quand un user veut éditer la fiche du mediawiki 2, on l’emmène dans le mediawiki 1. Et tout cela se ferait au sein d'une base de donnée partagée sur une plateforme basée sur SemApps qui fait les liens. Si on consulte les fiches sur SemApps, on peut se balader de serveur en serveur. On ne respecte pas les classes OWL avec Cargo.

Deux pistes à l'étude

  • On peut migrer vers du sémantique (via Cargo ou Semapps). Il y a un chantier d'intégration du chat dans SemApps - si on crée des canaux dans d'autres serveurs, on les voit et on peut intéragir. Sur un serveur tiers, on peut pas interagir. On peut opérer la migration d'authentification (quelqu'un valide qui tu es) et ne pas migrer l'identification (LDP Sparkl).

:::info ++Autre pistes sur l'interopérabilité pour mediawiki :++

31/03/2021

Présent·es

  • Hélène Gadenne (FEE)
  • Tristan Bourvon (ADEME/FabLog)
  • Benjamin Gentils (FEE)
  • Gabriel Plassat (ADEME/FabMob)
  • Nicolas Loubet (Oxamyne/FabEn)
  • Julien Darthout (FabLog / CPV)
  • Julien Lecaille (ANIS, Opteos)

Sujets du jour

  • Tour des présent·es
  • Besoins court terme
  • Options envisagées
  • Actions faisables

:::warning ++Lignes directrices++

  • 1/ Accueillir un séminaire sur les wikis des fabriques, chez Simon (à Auttin)
  • 2/ Organiser un cycle de formation inter-fabriques à l'utilisation de mediawiki
  • 3/ Co-financer (FabMob, FabEn) un cycle de résidences sur le modèle de Movilab
  • 4/ Financer des formations avec du budget de formation pro (cf. agréments)
  • 5/ Déposer un dossier France Relance, à soumettre au ministères éduc + éco

Discussion

  • Benjamin : 1/ il y a un besoin de formation des contributeurs à mediawiki. Cela peut être mutualisé. 2/ comment créer de l'interopérabilité entre wikis dans les communs ?

  • Hélène : je suis engagé dans des démarches de recherche-action. Je suis contributrice au wiki de FEE. Aux côtés de Michel Briand sur les Riposte Creative et l'agora des archipels.

  • Nicolas : j'ai été très pro-actif au démarrage de Faire Ecole (entre mars et juin 2020), je suis engagé dans la préfiguration de la FabEnergies depuis 1 an. En appétit pour travailler sur un cycle de résidences contributives (orientée vers la pratique de la documentation avec mediawiki), comme cela s'est fait avec Movilab au cours de l'année 2020.

  • Julien : je participe à la Fabrique de la logistique qui est en structuration (organisation, outillage, etc), avec un accompagnement de la FabMob. Notre priorité : le wiki.

  • Tristan : avec Julien sur la Fab Logistique (sur le développement et l'accompagnement)

  • Julien Lecaille : je fais de la mise en place, de la maintenance et animation de wiki

  • Gabriel : à l'origine de la FabMob et de l'AAC ADEME sur la résilience des territoires.

:::warning

  • ++Sujets++ : 1/ Formations 2/ Est-ce qu'on se dirige vers une capacité à synchroniser des wikis (interopérabilité). Ou Wiki multi-entrées des communs multi-acteurs, dans différents secteurs (fiches, sujets, ressources concernant les communs)

  • ++Proposition++ : se présenter au guichet France Relance, avec des acteurs publics (Ministère de l'Ecologie et de l'Éducation). On peut introduire une formation multi-communautés.

  • ++Rappel de Nicolas sur le cycle de résidences Movilab 2020++ : 1/ un temps convivial récurrent d'une journée (premier lundi du mois) a été instauré à la suite d'un séminaire de deux jours (organisé mi-mars 2020) 2/ ce temps récurrent permet d'accueillir des contributeurs, de jardiner des pages, d'améliorer le wiki (typologie, ergonomie, expérience...). C'est un protocole motivant et engageant. Dans le cas de la FabEnergies, nous avons une communauté latente, mais il y a encore un effet "page blanche". C'est ca qui a été a débloqué avec les résidences mensuelles movilab, à la suite du séminaire de mars.

  • Gabriel : quelles sont de votre expérience les différences entre MediaWiki et YesWiki ?

    • Nicolas : YesWiki est davantage utilisé pour des petits sites. Ex ferme des colibris
    • Hélène : gros travail d'accompagnement de la part de Laurent et Michel sur YesWiki
    • Nicolas : pour moi, MediaWiki s'inscrit dans une perspective encyclopédique et je perçois une "puissance technique" dédiée à la structuration de corpus de savoirs. Sur YesWiki, je ressens bien davantage une filiation coopérative, avec une "dynamique de compagnonage", en articulation avec la communauté (de formateurices) Animacoop.
    • Hélène : ce sont les utilisateurices qui décident au final, au regard de leur adoption...

  • Gabriel : j'identifie une problématique : remplir la même fiche sur plusieurs (media)wikis.

    • Benjamin : Xavier C semblait dire que c'était possible de redonder sur plusieurs wikis
    • Gabriel : je verrais bien un système de portails, thématisés, avec des fiches uniques

:::success ++Ligne de force++

  • Le choix d'architecture des wikis est un grand sujet - archipels ou portail(s) ?
    • C'est peut être aussi une différence temporel ou de projets à adresser
  • La question de la formation (par compagnonnage) est indispensable. ~10 contributeurs actifs (par wiki) = premier palier (plutôt que de s'appuyer sur UN super contributeur)
    • Voir avec Sébastien (Wikivalley) : 06.73.10.97.88 | sebastien.beyou@wikimedia.fr

    • Organisation des résidences de contribution pour faire communauté autour du wiki (avec un budget pour les animateurs). 6 résidences sur 1 semestre : ~ 10 à 50k€

++Prochaines étapes++

  • Petit doc pour lancer la dynamique + mail d'invitation vers les communautés
  • Candidature en consortium (FabFob, FEE, FabEn, FabLog) à l'AAP de la FDF
  • Exposer les différents types de connexion possibles (inter-wiki, yeswiki-mediawiki)
    • (Premier) temps de 2h à caler avec Simon S, Julien L, laurent M, Michel B
  • Explorer une solution alternative et qui semble répondre à l’esprit d’archipel sans les contraintes de synchronisation évoquées lors de la réunion : ferme de wikis.
  • Explorer la possibilité de faire de l'URL-rewriting pour pouvoir utiliser des adresses qui persistent dans la barre d'adresse - du type https://wiki.lafabriquedelalogistique.fr/, pointant cependant sur des wikis qui sont hébergés sur le même serveur.

10/02/2021

Présent·es

  • Benjamin Gentils
  • Michel Briand
  • Simon Sarazin
  • Gabriel Plassat
  • Nicolas Loubet

:::warning

  • ++Objectif++ : ne pas demander aux acteurs de créer une fiche à chaque fois qu'il arrivent sur un wiki (Résilience, FabEnergies, FabMob, etc.). Idem pour les communs.
  • ++Question++ : comment synchroniser un YesWiki Riposte Créative, les MediaWikis de FEE et Résilience sur le champ "résilience & éducation", dans le contexte de l’AaC ADEME ?

Discussion

  • Michel : je ne crois pas au wiki central et je suis favorable à une logique d'archipels. L'enjeux est pour moi de faire circuler les connaissances d'un espace à un autre

  • Gabriel : +1 sur la capacité à avoir plusieurs wikis qui communiquent entre eux.

  • Gabriel : Travail de Mael : script pour aller chercher divers pages de notre wiki pour notre site. C'est stratégique. L'enjeu est de rendre nécessaire la mise à jour des wikis. Et sur un site institutionnel, il devient possible d'aller chercher des infos pour un wiki .

  • Michel : en Bretagne, avoir de l'interopérabilité dans les deux sens (wiki, site) est très utile. Quand je fais un article sur un wiki Riposte Creative, cela apparait automatiquement sur le site Bretagne Educative. Les informations circulent automatiquement d'un espace à l'autre.

:::info

  • ++D'un blog vers un yeswiki++

  • ++De yeswiki vers un blog++

  • Michel : je fonctionne en flux RSS par mots clés, je maitrise peu le sémantique. J'utilise le système de publication SPIP. Les abonnés peuvent être des humains ou des machines. On n'est pas sur des flux RSS incomplet avec les 3 premières lignes mais complets.

  • Simon : on pourrait se brancher sur une technologie d'interopérabilité comme SemApps (cf. l'expérience de cartographie du wiki FabMob). La donnée doit être créé à un endroit. Elle est ensuite dupliquée ou on vient la lire (ce qu'on commence à faire avec gogocarto). La partie script pour duplication n'est pas très compliquée, mais ça va rester du bidouillage.

  • Michel : je démarre une gare d'aiguillage pour la Région Bretagne. La plupart des communs en Bretagne n'intéresseront pas la communauté de l'appel à communs Résilience des territoires. Comment filtrer ? Par mots clés ? Quelles relations d'un wiki à un autre ?

  • Michel : Bretagne creative est source de données pour Transciscope mais Transiscope n'autorise pas les communs dont une collectivité est acteur. Je dois filtrer à la main.

  • Simon : techniquement, c'est de l'interopérabilité, pas de la synchronisation

    • Gabriel : la synchronisation, c'est si tu mets à jour une ressource à un endroit donné, les autres endroits qui ont cette ressource sont également mis à jour
    • Michel : je ne connais que BAT à Montpellier qui réalise cela aujourd'hui
    • Simon : besoin de s'accorder sur l'endroit où les fiches se mettent à jour

  • Michel : le premier sujet, c'est comment unifier les comptes entre les mediawiki (FabMob, FabEnergies, Résilience, FEE) avant d'aller vers les relations entre mediaswiki et yeswiki

  • Gabriel : on pourrait commencer par un système d'alerte quand on créé une page proche ou similaire d'une page existante (connecteur SSO + alerte quand on créé un doublon).

  • Simon : venir brancher d'autres solutions est une bonne idée (ex avec le graphe).

  • Michel : Yeswiki a un bon outil de carto (gratuit). A voir avec Florian quels liens faire.

  • Simon : une autre piste serait de créér de nouveaux outils pour répondre à des besoins

  • Ben : est-ce qu'une occasion est à saisir avec le concours annuel de la fondation la France s'engage ? Pour rappel, pour répondre, il faut 80k€ de budget annuel. On peut aussi répondre en consortium. Une présentation du concours a lieu ce vendredi à 12h.

    • Michel : faire circuler l'information entre fabriques, ce serait éligible ?
    • Benjamin : sous le prisme de l'essaimage territorial des actions en fabrique, cela nécessite de pouvoir travailler sur l'info. Déjà entre mediawiki des fabriques.

<img style="display: block; margin: 0 auto;" src="https://s3.standard.indie.host/pad-fabmob-io/uploads/upload_da693325254498061d7cc88e8257475f.png" width="60%">

  • simon : il faut sortir de la technique, traduire ce qu'on fait et le rendre communicable.

  • Michel : les plateformes d'innovation sociale ne répondent pas aux logiques de communs.

  • Gabriel : dans l'administration, la mise en commun de l'informaton, c'est marginal. Ça va prendre du temps. Il ne faut pas s'attendre à être soutenu mais le faire quand même.

30/06/2020

Présent·es

  • Matéi
  • Simon
  • Clément
  • Gautier
  • Nicolas
  • Simon
  • Nicolas
  • Rieul
  • Gabriel

Discussion

  • Gautier : il est possible de gérer plusieurs wikis. A distinguer :
    • la mutualisation ou fédération du contenu (textes, fichiers, données)
    • la gestion et maintenance de l'infrastructure logicielle
  • Il est possible d'avoir une gestion commune des comptes utilisateurs
  • Nicolas (wiki valley) : une piste est wikibase (utilisé par Wikidata)
    • Avec des données maitres sur une seule plateforme (Wikibase).
    • Chaque wiki va chercher les données maîtres de Wikibase.
    • Installé à la BNF par Sébastien. Mais lourd à installer.
  • Semantic extra query lookup > pour faire des requêtes de données
  • Semantic Mediawiki et Wikibase sont cumulables (cf. cette page)
  • Chaque page est un formulaire. Rajout d'une propriété et sa valeur
  • Compte utilisateur > gestion commune des comptes multi-mediawiki
    • Base de données d'utilisateur partagée entre plusieurs wikis)
    • Avec choix d'un wiki maître (voir la compatibilité avec le SSO)
  • Nicolas L : il y a une co-évolution des usages et de l'architecture

:::info Rédiger les besoins, cas d'usages, parcours utilisateurs, liste des données à mutualiser coté "fabriques" pour faire une étude des différentes options par Dokit/Wiki Valley. :::

5- Ressources

<center>

Cette production est régie par les termes de la Peer Production Licence This production is under the Peer Production Licence terms

:::success La licence Peer Production est une licence de la famille des licences Copyfair, selon laquelle seuls les comm4oners, coopératives et autres organisations à but non lucratif peuvent partager et réutiliser ce matériaux, les entités commerciales qui ont vocation, par utilisation de ce matériaux, à faire profit sur la base de ce commun se doivent de discuter et d'acter explicitement les réciprocités avec les auteur·e·s de ce matériaux.

The peer production license is an example of the Copyfair type of license, in which only other commoners, cooperatives and nonprofits can share and re-use the material, but not commercial entities intent on making profit through the commons without explicit reciprocity

</center>

Récupérée de « https://wiki.lafabriquedesmobilites.fr/index.php?title=Vers_un_wiki_mutualisé_des_fabriques&oldid=52719 »

À propos

Navigation

Bonjour

Creative Commons Attribution
Powered by MediaWiki
Powered by Semantic MediaWiki