« Guide de gouvernance » : différence entre les versions
mAucun résumé des modifications |
(Cette version a été marquée à traduire) |
||
| (4 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 1 : | Ligne 1 : | ||
<translate> | |||
<!--T:1--> | |||
Le guide de la gouvernance est une production du groupe de travail "Ressources Mutualisées". L'objectif est de donner un cadre de réflexion et les grands principes suivis par le Campus Cyber sur la constitution de la gouvernance d'un commun de la cyber. | Le guide de la gouvernance est une production du groupe de travail "Ressources Mutualisées". L'objectif est de donner un cadre de réflexion et les grands principes suivis par le Campus Cyber sur la constitution de la gouvernance d'un commun de la cyber. | ||
<!--T:2--> | |||
Cette doctrine pourra être amenée à évoluer dans le temps. | Cette doctrine pourra être amenée à évoluer dans le temps. | ||
</translate> | |||
== Les principes de la gouvernance == | <translate> | ||
== Les principes de la gouvernance == <!--T:3--> | |||
=== Rôle de la gouvernance === | === Rôle de la gouvernance === <!--T:4--> | ||
Le Campus Cyber préconise que la gouvernance se concentre sur le suivi des objectifs d’impacts. Il est nécessaire que l’équipe projet conserve un bon niveau d’autonomie dans ses décisions technico-fonctionnelles et la gestion de ses priorités. | Le Campus Cyber préconise que la gouvernance se concentre sur le suivi des objectifs d’impacts. Il est nécessaire que l’équipe projet conserve un bon niveau d’autonomie dans ses décisions technico-fonctionnelles et la gestion de ses priorités. | ||
<!--T:5--> | |||
Le cas échant, la gouvernance pourra préconiser des orientations techniques ou demander la mise en place d’un comité technique pour assurer un suivi continu des choix de l’équipe projet. | Le cas échant, la gouvernance pourra préconiser des orientations techniques ou demander la mise en place d’un comité technique pour assurer un suivi continu des choix de l’équipe projet. | ||
<!--T:6--> | |||
D’une manière générale, la gouvernance doit concentrer son action sur les éléments suivants : | D’une manière générale, la gouvernance doit concentrer son action sur les éléments suivants : | ||
<!--T:7--> | |||
* Définir ses modalités de prise de décision et de révision | * Définir ses modalités de prise de décision et de révision | ||
* Définir les orientations stratégiques de la ressource | * Définir les orientations stratégiques de la ressource | ||
| Ligne 19 : | Ligne 27 : | ||
* Définir et réviser les objectifs d’impacts | * Définir et réviser les objectifs d’impacts | ||
* Suivre de la valeur marché de la ressource | * Suivre de la valeur marché de la ressource | ||
</translate> | |||
<translate> | |||
<!--T:8--> | |||
La gouvernance est de réviser annuellement les objectifs du commun, son périmètre, les objectifs d’impact et les évolutions de modèle d’affaire et de réciprocité. | La gouvernance est de réviser annuellement les objectifs du commun, son périmètre, les objectifs d’impact et les évolutions de modèle d’affaire et de réciprocité. | ||
=== Composition de la gouvernance === | === Composition de la gouvernance === <!--T:9--> | ||
Le Campus Cyber préconise la mise en place d’une gouvernance légère, adaptée à la temporalité et au rôle du commun. La gouvernance ne saurait excéder neuf membres permanents. Le Campus Cyber propose à titre d’exemple les trois typologies suivantes, réparties comme suit : | Le Campus Cyber préconise la mise en place d’une gouvernance légère, adaptée à la temporalité et au rôle du commun. La gouvernance ne saurait excéder neuf membres permanents. Le Campus Cyber propose à titre d’exemple les trois typologies suivantes, réparties comme suit : | ||
<!--T:10--> | |||
* Bénéficiaires – 20% à 30% des sièges | * Bénéficiaires – 20% à 30% des sièges | ||
<!--T:11--> | |||
* Licenciés – 20% à 30 % des sièges | * Licenciés – 20% à 30 % des sièges | ||
* Contributeurs – 20% à 30% des sièges | * Contributeurs – 20% à 30% des sièges | ||
<!--T:12--> | |||
Chaque commun définira les typologies adaptées à son activité. Néanmoins, les typologies resteront exclusives, chaque acteur doit proposer sa typologie qui doit être validée par les membres de la gouvernance. | Chaque commun définira les typologies adaptées à son activité. Néanmoins, les typologies resteront exclusives, chaque acteur doit proposer sa typologie qui doit être validée par les membres de la gouvernance. | ||
<!--T:13--> | |||
Le Campus Cyber impose l’ajout à la gouvernance d’une typologie d’acteur dite neutre par rapport au commun. Ce membre dit “membre éthique” est un membre du Campus Cyber qui n’a pas d'implication directe avec le commun mais fait partie de la commission de déontologie (voir gestion des conflits ci-dessous). Dans un cas exceptionnel, ce membre éthique peut être un membre de l’équipe Campus Cyber. | Le Campus Cyber impose l’ajout à la gouvernance d’une typologie d’acteur dite neutre par rapport au commun. Ce membre dit “membre éthique” est un membre du Campus Cyber qui n’a pas d'implication directe avec le commun mais fait partie de la commission de déontologie (voir gestion des conflits ci-dessous). Dans un cas exceptionnel, ce membre éthique peut être un membre de l’équipe Campus Cyber. | ||
<!--T:14--> | |||
Le “membre éthique” doit disposer d’un siège. Sa voix a le même poids que celle des autres membres de la gouvernance. Le « membre éthique » est soumis aux mêmes règles que les autres membres de la gouvernance. | Le “membre éthique” doit disposer d’un siège. Sa voix a le même poids que celle des autres membres de la gouvernance. Le « membre éthique » est soumis aux mêmes règles que les autres membres de la gouvernance. | ||
</translate> | |||
=== Condition d’accès et de maintien dans la gouvernance === | <translate> | ||
=== Condition d’accès et de maintien dans la gouvernance === <!--T:15--> | |||
Les entités ayant participé à la coordination du GT à l’origine de la création d’un commun ont une place prioritaire dans la gouvernance, pour garantir la continuité et la transmission du GT vers le commun. | Les entités ayant participé à la coordination du GT à l’origine de la création d’un commun ont une place prioritaire dans la gouvernance, pour garantir la continuité et la transmission du GT vers le commun. | ||
<!--T:16--> | |||
De la même manière, il convient de proposer l’accès à la gouvernance en premier lieu aux membres actifs du GT tout en garantissant les proportions citées dans le chapitre « Composition de la gouvernance ». La gouvernance doit refléter la diversité des collèges impliqués. | De la même manière, il convient de proposer l’accès à la gouvernance en premier lieu aux membres actifs du GT tout en garantissant les proportions citées dans le chapitre « Composition de la gouvernance ». La gouvernance doit refléter la diversité des collèges impliqués. | ||
<!--T:17--> | |||
L’accès à la gouvernance peut se faire par une nomination ou élection au sein des collèges. | L’accès à la gouvernance peut se faire par une nomination ou élection au sein des collèges. | ||
Critère obligatoire pour accéder à la gouvernance : | Critère obligatoire pour accéder à la gouvernance : | ||
<!--T:18--> | |||
* Être Membre du Campus Cyber | * Être Membre du Campus Cyber | ||
<!--T:19--> | |||
Chaque membre de la gouvernance se doit de respecter les principes suivants : | Chaque membre de la gouvernance se doit de respecter les principes suivants : | ||
<!--T:20--> | |||
* Être assidu | * Être assidu | ||
* Se conformer à la charte du Campus Cyber | * Se conformer à la charte du Campus Cyber | ||
* Respecter les conditions d’utilisation du commun (CGU) | * Respecter les conditions d’utilisation du commun (CGU) | ||
</translate> | |||
<translate> | |||
<!--T:21--> | |||
Le non-respect de ces principes peut conduire à l’exclusion de la gouvernance. De même que la sortie du Campus Cyber. | Le non-respect de ces principes peut conduire à l’exclusion de la gouvernance. De même que la sortie du Campus Cyber. | ||
=== Mandature === | === Mandature === <!--T:22--> | ||
Pour garantir un renouvellement sain, tout en assurant la continuité des travaux du commun, la mandature ne doit pas excéder 3 années, renouvelable une fois. | Pour garantir un renouvellement sain, tout en assurant la continuité des travaux du commun, la mandature ne doit pas excéder 3 années, renouvelable une fois. | ||
<!--T:23--> | |||
Le renouvellement des mandatures doit être partiel (par 1/3 ou 1/2). Ainsi, dès le premier mandat, certains sièges auront une durée écourtée pour permettre la mise en place du modèle de renouvellement. | Le renouvellement des mandatures doit être partiel (par 1/3 ou 1/2). Ainsi, dès le premier mandat, certains sièges auront une durée écourtée pour permettre la mise en place du modèle de renouvellement. | ||
=== Modalité de prise de décision === | === Modalité de prise de décision === <!--T:24--> | ||
Chaque gouvernance peut choisir une modalité de prise de décisions qui lui est propre. Néanmoins, le Campus Cyber permet la mise en place de plusieurs modalités de prise de décision en fonction de la criticité de l’arbitrage. | Chaque gouvernance peut choisir une modalité de prise de décisions qui lui est propre. Néanmoins, le Campus Cyber permet la mise en place de plusieurs modalités de prise de décision en fonction de la criticité de l’arbitrage. | ||
<!--T:25--> | |||
* '''Majorité absolue :''' Les votants doivent représenter la moitié plus 1 voix pour qu’une décision soit validée. | * '''Majorité absolue :''' Les votants doivent représenter la moitié plus 1 voix pour qu’une décision soit validée. | ||
* '''Majorité qualifiée :''' Les votant doivent représenter au moins 2/3 des voix pour qu’une décision soit validée. | * '''Majorité qualifiée :''' Les votant doivent représenter au moins 2/3 des voix pour qu’une décision soit validée. | ||
* '''Vote par valeur :''' Les votants doivent donner leur avis sur 5 niveaux (Rejeter, Préciser, Neutre, Poursuivre, Valider). Les avis peuvent être accompagnés de questions ou remarques. L’ensemble des avis donne lieu à une note. La somme des notes doit représenter 2/3 des points pour valider la proposition. | * '''Vote par valeur :''' Les votants doivent donner leur avis sur 5 niveaux (Rejeter, Préciser, Neutre, Poursuivre, Valider). Les avis peuvent être accompagnés de questions ou remarques. L’ensemble des avis donne lieu à une note. La somme des notes doit représenter 2/3 des points pour valider la proposition. | ||
<!--T:26--> | |||
* '''Processus Consentement :''' La prise de décision suit un processus qui consiste à valider une décision si aucun membre du groupe ne s’y est opposé. La prise de décision se fait de manière participative et implique que la décision sera validée lorsque plus aucune objection raisonnable ne sera énoncée. | * '''Processus Consentement :''' La prise de décision suit un processus qui consiste à valider une décision si aucun membre du groupe ne s’y est opposé. La prise de décision se fait de manière participative et implique que la décision sera validée lorsque plus aucune objection raisonnable ne sera énoncée. | ||
</translate> | |||
== Gestion des conflits == | <translate> | ||
== Gestion des conflits == <!--T:27--> | |||
La conduite des communs nécessite d’anticiper un processus de gestion des conflits claire et économique. | La conduite des communs nécessite d’anticiper un processus de gestion des conflits claire et économique. | ||
<!--T:28--> | |||
La gestion des conflits est basée sur deux fonctions essentielles. La fonction de rapporteur est à la charge du “membre éthique” qui doit faire le lien avec la commission de déontologie. | La gestion des conflits est basée sur deux fonctions essentielles. La fonction de rapporteur est à la charge du “membre éthique” qui doit faire le lien avec la commission de déontologie. | ||
<!--T:29--> | |||
La fonction de médiation est portée par la commission de déontologie. | La fonction de médiation est portée par la commission de déontologie. | ||
=== Commission de déontologie === | === Commission de déontologie === <!--T:30--> | ||
La commission de déontologie est composée de membres de chaque collège. Chaque collège doit identifier au moins deux volontaires qui intégreront le groupe des déontologues. Les membres du groupe de déontologues sont les membres éthiques dans les instances de gouvernance. | La commission de déontologie est composée de membres de chaque collège. Chaque collège doit identifier au moins deux volontaires qui intégreront le groupe des déontologues. Les membres du groupe de déontologues sont les membres éthiques dans les instances de gouvernance. | ||
<!--T:31--> | |||
La commission de déontologie a pour rôle de réviser la charte éthique, de suivre sa mise en application et d'avoir un rôle de conseil auprès des instances de gouvernance des communs de la cyber. | La commission de déontologie a pour rôle de réviser la charte éthique, de suivre sa mise en application et d'avoir un rôle de conseil auprès des instances de gouvernance des communs de la cyber. | ||
<!--T:32--> | |||
Dans le cas de saisine pour la gestion d’un conflit, cinq membres de la commission de déontologie seront mandatés pour arbitrer le dossier. Aucun des membres de la commission ne devra avoir de lien avec les parties prenantes ou avec le commun concerné par le conflit. | Dans le cas de saisine pour la gestion d’un conflit, cinq membres de la commission de déontologie seront mandatés pour arbitrer le dossier. Aucun des membres de la commission ne devra avoir de lien avec les parties prenantes ou avec le commun concerné par le conflit. | ||
<!--T:33--> | |||
La commission pourra se rassembler et auditionner les différentes parties autant que nécessaire pour résoudre le conflit. La commission devra statuer dans un délai maximum de deux mois suite à la saisine, la première réunion de présentation conflit faisant office de lancement du dispositif. | La commission pourra se rassembler et auditionner les différentes parties autant que nécessaire pour résoudre le conflit. La commission devra statuer dans un délai maximum de deux mois suite à la saisine, la première réunion de présentation conflit faisant office de lancement du dispositif. | ||
<!--T:34--> | |||
La commission doit produire un rapport d’activité annuel constitué de l’historique des décisions et des changements de la charte. | La commission doit produire un rapport d’activité annuel constitué de l’historique des décisions et des changements de la charte. | ||
</translate> | |||
=== Processus de saisine === | <translate> | ||
=== Processus de saisine === <!--T:35--> | |||
Le processus de saisine de la commission de déontologie doit passer par la gouvernance du commun pour être entérinée. | Le processus de saisine de la commission de déontologie doit passer par la gouvernance du commun pour être entérinée. | ||
<!--T:36--> | |||
Toute partie prenante en lien avec le commun peut demander à inscrire à l’ordre de la gouvernance un sujet de conflit pour arbitrage. | Toute partie prenante en lien avec le commun peut demander à inscrire à l’ordre de la gouvernance un sujet de conflit pour arbitrage. | ||
<!--T:37--> | |||
Lors des délibérations de la gouvernance, il peut être décidé d’ouvrir un processus de gestion de conflit. Le processus de gestion de conflit peut être initié car un préjudice perçu ne trouve pas de solutions via la gouvernance. | Lors des délibérations de la gouvernance, il peut être décidé d’ouvrir un processus de gestion de conflit. Le processus de gestion de conflit peut être initié car un préjudice perçu ne trouve pas de solutions via la gouvernance. | ||
<!--T:38--> | |||
Dès lors, le membre éthique devient rapporteur pour la commission de déontologie. Le membre éthique doit réunir une commission éthique de cinq membres. | Dès lors, le membre éthique devient rapporteur pour la commission de déontologie. Le membre éthique doit réunir une commission éthique de cinq membres. | ||
<!--T:39--> | |||
Le membre éthique doit constituer le dossier de suivi du conflit qui doit contenir a minima : | Le membre éthique doit constituer le dossier de suivi du conflit qui doit contenir a minima : | ||
<!--T:40--> | |||
* Explication du contexte | * Explication du contexte | ||
* Description du préjudice perçu | * Description du préjudice perçu | ||
* Requêtes et position des différents partis | * Requêtes et position des différents partis | ||
* Demande de délai de résolution | * Demande de délai de résolution | ||
</translate> | |||
<translate> | |||
<!--T:41--> | |||
Le dossier de suivi du conflit devra comporter une synthèse des délibérations et des décisions de la commission de déontologie. Suite à la résolution, la commission de déontologie devra alimenter un référentiel de traitement des conflits de manière à disposer d’un historique des décisions antérieures. | Le dossier de suivi du conflit devra comporter une synthèse des délibérations et des décisions de la commission de déontologie. Suite à la résolution, la commission de déontologie devra alimenter un référentiel de traitement des conflits de manière à disposer d’un historique des décisions antérieures. | ||
<!--T:42--> | |||
Dans un premier temps, les parties s’engagent, de bonne foi, à respecter le processus de résolution défini avant de recourir à toute autre instance de résolution. | Dans un premier temps, les parties s’engagent, de bonne foi, à respecter le processus de résolution défini avant de recourir à toute autre instance de résolution. | ||
<!--T:43--> | |||
Dans le cas où la médiation interne portée par la commission de déontologie n’aboutit pas à une résolution satisfaisante pour l’ensemble des parties, il est possible de se faire accompagner par une médiation externe. La commission de déontologie peut librement décider de financer l’accompagnement par le commun ou de faire porter la médiation par les parties impliquées dans le conflit. | Dans le cas où la médiation interne portée par la commission de déontologie n’aboutit pas à une résolution satisfaisante pour l’ensemble des parties, il est possible de se faire accompagner par une médiation externe. La commission de déontologie peut librement décider de financer l’accompagnement par le commun ou de faire porter la médiation par les parties impliquées dans le conflit. | ||
== Licence et CGU == | == Licence et CGU == <!--T:44--> | ||
Cette partie vise à définir la licence utilisée par le commun pour gérer l’exploitation et la commercialisation. | Cette partie vise à définir la licence utilisée par le commun pour gérer l’exploitation et la commercialisation. | ||
<!--T:45--> | |||
L’objectif est d’avoir un jeu de licences qui favorise la propagation du commun pour former, développer les connaissances, renforcer les avantages concurrentiels de l’écosystème et qui garantit l’évolution et la pérennité de ce même commun. L’exploitation commerciale doit être autorisée et encouragée à tous ceux qui le souhaite, tout en reconnaissant les contributions qui font évoluer le communs permettant la mise en place de forme de réciprocité. | L’objectif est d’avoir un jeu de licences qui favorise la propagation du commun pour former, développer les connaissances, renforcer les avantages concurrentiels de l’écosystème et qui garantit l’évolution et la pérennité de ce même commun. L’exploitation commerciale doit être autorisée et encouragée à tous ceux qui le souhaite, tout en reconnaissant les contributions qui font évoluer le communs permettant la mise en place de forme de réciprocité. | ||
<!--T:46--> | |||
La licence devra préciser les modalités de contraintes d’accès au commun et les règles de commercialisation afférentes. | La licence devra préciser les modalités de contraintes d’accès au commun et les règles de commercialisation afférentes. | ||
<!--T:47--> | |||
Ainsi cette licence différenciera la participation créatrice de la participation économique. Dans ce contexte, la notion de contribution reconnait exclusivement la participation créatrice. | Ainsi cette licence différenciera la participation créatrice de la participation économique. Dans ce contexte, la notion de contribution reconnait exclusivement la participation créatrice. | ||
<!--T:48--> | |||
L’implication dans la gouvernance du commun n’est pas considérée comme une contribution. | L’implication dans la gouvernance du commun n’est pas considérée comme une contribution. | ||
<!--T:49--> | |||
Chaque commun doit définir son modèle de réciprocité mettant en lien les contreparties commerciales (cf. Tableau des contreparties) au regard de contributions reconnues. | Chaque commun doit définir son modèle de réciprocité mettant en lien les contreparties commerciales (cf. Tableau des contreparties) au regard de contributions reconnues. | ||
=== Définition des contributions === | === Définition des contributions === <!--T:50--> | ||
Une contribution désigne l'ensemble des modifications, corrections, traductions, adaptations et/ou nouvelles fonctionnalités intégrées dans la ressource et reconnue par la gouvernance. | Une contribution désigne l'ensemble des modifications, corrections, traductions, adaptations et/ou nouvelles fonctionnalités intégrées dans la ressource et reconnue par la gouvernance. | ||
<!--T:51--> | |||
Une contribution peut prendre la forme de développement logiciel, de jeu de données, de documentation, alimentation par des flux, etc. Une contribution doit apporter de la valeur au commun. Une contribution est considérée comme effective à la suite de sa livraison et validée par l’équipe en charge de la gestion du commun. | Une contribution peut prendre la forme de développement logiciel, de jeu de données, de documentation, alimentation par des flux, etc. Une contribution doit apporter de la valeur au commun. Une contribution est considérée comme effective à la suite de sa livraison et validée par l’équipe en charge de la gestion du commun. | ||
=== Lancement des contributions === | === Lancement des contributions === <!--T:52--> | ||
La gouvernance peut définir les contreparties et réciprocités au regard de l’investissement de chaque membre dans les phases amont de la mise à disposition de la ressource. | La gouvernance peut définir les contreparties et réciprocités au regard de l’investissement de chaque membre dans les phases amont de la mise à disposition de la ressource. | ||
=== Reconnaissance des contributions === | === Reconnaissance des contributions === <!--T:53--> | ||
De manière à rendre la reconnaissance des contributions la plus souple possible pour la gouvernance du commun, nous proposons de suivre un modèle qui s’appuie sur les contributions réalisées. | De manière à rendre la reconnaissance des contributions la plus souple possible pour la gouvernance du commun, nous proposons de suivre un modèle qui s’appuie sur les contributions réalisées. | ||
<!--T:54--> | |||
Pour chaque début d’exercice, les contributeurs produisent une déclaration des prévisions de contribution à travers un Etat des Prévisions de Contribution (EPC). | Pour chaque début d’exercice, les contributeurs produisent une déclaration des prévisions de contribution à travers un Etat des Prévisions de Contribution (EPC). | ||
<!--T:55--> | |||
Pour chaque fin d’exercice, les contributeurs produisent une déclaration des réalisations à travers un Etat Récapitulatif Des Contributions (ERC). | Pour chaque fin d’exercice, les contributeurs produisent une déclaration des réalisations à travers un Etat Récapitulatif Des Contributions (ERC). | ||
<!--T:56--> | |||
Les contributions doivent faire l’objet d’une évaluation économique. | Les contributions doivent faire l’objet d’une évaluation économique. | ||
<!--T:57--> | |||
Ces deux états doivent être fournis au moins un mois avant la réunion annuelle de gouvernance appelée à statuer sur le budget du commun de l’année écoulée et à venir. Ainsi les équipes en charge de la gestion du commun pourront émettre un avis sur la réalisation des contributions, fournir un historique des contributions annuelles et fournir un prévisionnel des contributions. | Ces deux états doivent être fournis au moins un mois avant la réunion annuelle de gouvernance appelée à statuer sur le budget du commun de l’année écoulée et à venir. Ainsi les équipes en charge de la gestion du commun pourront émettre un avis sur la réalisation des contributions, fournir un historique des contributions annuelles et fournir un prévisionnel des contributions. | ||
<!--T:58--> | |||
D’autres modèles pourront être expérimentés le cas échéant et intégrés dans les futures modalités possibles. | D’autres modèles pourront être expérimentés le cas échéant et intégrés dans les futures modalités possibles. | ||
</translate> | |||
=== Modèles de Réciprocité === | <translate> | ||
=== Modèles de Réciprocité === <!--T:59--> | |||
L’attribution des contreparties fait suite à la validation des contributions de la période référence précédente. La période de référence est l’exercice comptable du Campus Cyber. | L’attribution des contreparties fait suite à la validation des contributions de la période référence précédente. La période de référence est l’exercice comptable du Campus Cyber. | ||
<!--T:60--> | |||
Chaque commun doit garantir son propre fonctionnement et ses évolutions. | Chaque commun doit garantir son propre fonctionnement et ses évolutions. | ||
<!--T:61--> | |||
Exemple correspondance de réciprocité | Exemple correspondance de réciprocité | ||
{| class="wikitable table-responsive table-responsive" | {| class="wikitable table-responsive table-responsive" | ||
| Ligne 177 : | Ligne 229 : | ||
|} | |} | ||
Une approche envisageable complémentaire pour la reconnaissance des contributions, serait de la création d’un « badge » permettant de montrer la participation d’une entité à la production ou l’usage d'un commun. | Une approche envisageable complémentaire pour la reconnaissance des contributions, serait de la création d’un « badge » permettant de montrer la participation d’une entité à la production ou l’usage d'un commun. | ||
</translate> | |||
=== Modèle de licence === | <translate> | ||
=== Modèle de licence === <!--T:62--> | |||
En cours de construction, V1 prévue pour T4 2022 | En cours de construction, V1 prévue pour T4 2022 | ||
<!--T:63--> | |||
Ressources pour les licences en creative commons : https://chooser-beta.creativecommons.org/ | Ressources pour les licences en creative commons : https://chooser-beta.creativecommons.org/ | ||
== Exemples de Modèles d'affaire == | == Exemples de Modèles d'affaire == <!--T:64--> | ||
Les modèles d’affaires présentés dessous ne sont pas exhaustifs ni exclusif. Néanmoins, ces modèles sont constitutifs des licences et conditions d’usages du commun. | Les modèles d’affaires présentés dessous ne sont pas exhaustifs ni exclusif. Néanmoins, ces modèles sont constitutifs des licences et conditions d’usages du commun. | ||
<!--T:65--> | |||
Les modèles d’affaires pourront évoluer sur proposition de l’équipe de production ou d’exploitation et validation par la gouvernance. | Les modèles d’affaires pourront évoluer sur proposition de l’équipe de production ou d’exploitation et validation par la gouvernance. | ||
<!--T:66--> | |||
Les modèles d’affaires présentés ci-dessous sont des sources d’inspiration issues des pratiques observées dans le monde de l’open source. | Les modèles d’affaires présentés ci-dessous sont des sources d’inspiration issues des pratiques observées dans le monde de l’open source. | ||
<!--T:67--> | |||
'''Approche de la double licence''' : Le mécanisme de la double licence consiste à proposer le logiciel à la fois sous une licence libre et à des conditions propriétaires distinctes. La version propriétaire peut ainsi être vendue pour financer le développement continu de la version libre gratuite. | '''Approche de la double licence''' : Le mécanisme de la double licence consiste à proposer le logiciel à la fois sous une licence libre et à des conditions propriétaires distinctes. La version propriétaire peut ainsi être vendue pour financer le développement continu de la version libre gratuite. | ||
<!--T:68--> | |||
'''Approche Vente de services professionnels''' : Les revenus proviennent de la vente de services, tels que la fourniture de formations, de support technique ou de prestations conseil, plutôt que de la vente du logiciel lui-même. | '''Approche Vente de services professionnels''' : Les revenus proviennent de la vente de services, tels que la fourniture de formations, de support technique ou de prestations conseil, plutôt que de la vente du logiciel lui-même. | ||
<!--T:69--> | |||
'''Approches Vente de certificats et d’usage de marque :''' Le modèle d’affaires est basé sur un réseau de partenaires commerciaux qui sont certifiés et autorisés à utiliser le nom et le logo, en échange ils reversent une part de leurs revenus qui finance le développement du cœur du logiciel (ex : Moodle). | '''Approches Vente de certificats et d’usage de marque :''' Le modèle d’affaires est basé sur un réseau de partenaires commerciaux qui sont certifiés et autorisés à utiliser le nom et le logo, en échange ils reversent une part de leurs revenus qui finance le développement du cœur du logiciel (ex : Moodle). | ||
<!--T:70--> | |||
'''Approches Vente de logiciel comme service Software as a Service''' : Correspond à la vente de souscriptions à des clients pour des accès distants. | '''Approches Vente de logiciel comme service Software as a Service''' : Correspond à la vente de souscriptions à des clients pour des accès distants. | ||
<!--T:71--> | |||
'''Approches Partenariats avec des organismes de financement''' : Des modèles économiques sont basés sur des partenariats avec d’autres entreprises. | '''Approches Partenariats avec des organismes de financement''' : Des modèles économiques sont basés sur des partenariats avec d’autres entreprises. | ||
<!--T:72--> | |||
'''Approches Dons volontaires''' : Mise en place d’un système de don de la part des usagers et identification de bienfaiteurs reconnues. | '''Approches Dons volontaires''' : Mise en place d’un système de don de la part des usagers et identification de bienfaiteurs reconnues. | ||
<!--T:73--> | |||
'''Approches Production participative''' : La production participative est proposée, par l’intermédiaire d’appels ouverts à contributions. La réalisation de la tâche de complexité et modularité variables, à laquelle le groupe doit participer en apportant travail, ressources financières, savoirs et/ou expérience implique toujours un bénéfice mutuel. | '''Approches Production participative''' : La production participative est proposée, par l’intermédiaire d’appels ouverts à contributions. La réalisation de la tâche de complexité et modularité variables, à laquelle le groupe doit participer en apportant travail, ressources financières, savoirs et/ou expérience implique toujours un bénéfice mutuel. | ||
<!--T:74--> | |||
'''Approches Financement par la publicité''' : Afin de commercialiser des de nombreuses entreprises ont fait évoluer leur modèle d’affaires vers des logiciels financés par la publicité. | '''Approches Financement par la publicité''' : Afin de commercialiser des de nombreuses entreprises ont fait évoluer leur modèle d’affaires vers des logiciels financés par la publicité. | ||
<!--T:75--> | |||
'''Approches Vente d’extensions propriétaires optionnelles''' : Certaines entreprises vendent des extensions, modules, plugins ou add-ons optionnels. Cette approche est une variante du modèle d’affaires freemium. Les extensions payantes et/ou propriétaires peut être conçu pour permettre aux clients de tirer un avantage supérieur de leurs données, infrastructure ou plate-forme, par exemple, les faire fonctionner plus efficacement, mieux les gérer, mieux les sécuriser. Certaines entreprises réinvestissent une partie de leurs bénéfices financiers dans l’infrastructure open source. | '''Approches Vente d’extensions propriétaires optionnelles''' : Certaines entreprises vendent des extensions, modules, plugins ou add-ons optionnels. Cette approche est une variante du modèle d’affaires freemium. Les extensions payantes et/ou propriétaires peut être conçu pour permettre aux clients de tirer un avantage supérieur de leurs données, infrastructure ou plate-forme, par exemple, les faire fonctionner plus efficacement, mieux les gérer, mieux les sécuriser. Certaines entreprises réinvestissent une partie de leurs bénéfices financiers dans l’infrastructure open source. | ||
<!--T:76--> | |||
'''Approches Vente de composants propriétaires indispensables d’un produit logiciel''' : Une variante de l’approche ci-dessus consiste à garder restrictive des données et contenus indispensables d’un produit logiciel tout en libérant le code source. Les utilisateurs doivent acheter le contenu afin de disposer d’une solution complète et fonctionnelle. Des licences restrictives peuvent en outre s’appliquer au contenu, ce qui empêche la redistribution ou la revente du logiciel complet. | '''Approches Vente de composants propriétaires indispensables d’un produit logiciel''' : Une variante de l’approche ci-dessus consiste à garder restrictive des données et contenus indispensables d’un produit logiciel tout en libérant le code source. Les utilisateurs doivent acheter le contenu afin de disposer d’une solution complète et fonctionnelle. Des licences restrictives peuvent en outre s’appliquer au contenu, ce qui empêche la redistribution ou la revente du logiciel complet. | ||
<!--T:77--> | |||
'''Approches Vente de systèmes de mise à jour propriétaires''' : Une autre variante du modèle d’affaires ci-dessus, utilisé notamment pour des logiciels traitant beaucoup de données ou dont l’architecture est centrée sur la gestion de données, est le fait de conserver chaque version du logiciel sous une licence open source, mais de s’abstenir de publier les scripts de mise à jour d’une version n à une version n+1. | '''Approches Vente de systèmes de mise à jour propriétaires''' : Une autre variante du modèle d’affaires ci-dessus, utilisé notamment pour des logiciels traitant beaucoup de données ou dont l’architecture est centrée sur la gestion de données, est le fait de conserver chaque version du logiciel sous une licence open source, mais de s’abstenir de publier les scripts de mise à jour d’une version n à une version n+1. | ||
<!--T:78--> | |||
Les utilisateurs peuvent encore déployer et faire fonctionner le logiciel open source. Cependant, toute mise à jour à une version supérieure impose à l’utilisateur : | Les utilisateurs peuvent encore déployer et faire fonctionner le logiciel open source. Cependant, toute mise à jour à une version supérieure impose à l’utilisateur : | ||
<!--T:79--> | |||
* soit de souscrire à un service fermé ou d’acquérir un système de mises à jour sous licence propriétaire ; | * soit de souscrire à un service fermé ou d’acquérir un système de mises à jour sous licence propriétaire ; | ||
* soit d’exporter la totalité des données, installer la nouvelle version, puis réimporter les données dans cette nouvelle version ; | * soit d’exporter la totalité des données, installer la nouvelle version, puis réimporter les données dans cette nouvelle version ; | ||
| Ligne 219 : | Ligne 288 : | ||
<!--T:80--> | |||
'''Approches Redistribution sous licence propriétaire''' : Si un produit logiciel utilise uniquement des logiciels par une licence de logiciel permissive une autre entreprise peut redistribuer le logiciel obtenu produit sous une licence propriétaire et le vendre sans le code source ou les libertés logicielles. Par exemple, Apple Inc. est un fervent utilisateur de cette approche et exploite le code source et les logiciels de projets open source. | '''Approches Redistribution sous licence propriétaire''' : Si un produit logiciel utilise uniquement des logiciels par une licence de logiciel permissive une autre entreprise peut redistribuer le logiciel obtenu produit sous une licence propriétaire et le vendre sans le code source ou les libertés logicielles. Par exemple, Apple Inc. est un fervent utilisateur de cette approche et exploite le code source et les logiciels de projets open source. | ||
<!--T:81--> | |||
'''Approches Offuscation de code source''' : L’offuscation de code source est une approche pour permettre la commercialisation sous une licence open source tout en protégeant des secrets d’affaires cruciaux, des éléments de propriété intellectuelle et des savoir-faire techniques. | '''Approches Offuscation de code source''' : L’offuscation de code source est une approche pour permettre la commercialisation sous une licence open source tout en protégeant des secrets d’affaires cruciaux, des éléments de propriété intellectuelle et des savoir-faire techniques. | ||
<!--T:82--> | |||
'''Approches Publication en open source retardée''' : Certaines entreprises ne fournissent la dernière version disponible de leur logiciel qu’aux clients payants. Un vendeur forke un projet logiciel non copyleft et y ajoute des composants fermés avant de vendre le logiciel qui résulte de cet ajout. Ce modèle économique est appelé "retard de version".<blockquote>Source d’information : https://fr.google-info.org/11294521/1/modeles-economiques-des-logiciels-open-source.html</blockquote> | '''Approches Publication en open source retardée''' : Certaines entreprises ne fournissent la dernière version disponible de leur logiciel qu’aux clients payants. Un vendeur forke un projet logiciel non copyleft et y ajoute des composants fermés avant de vendre le logiciel qui résulte de cet ajout. Ce modèle économique est appelé "retard de version".<blockquote>Source d’information : https://fr.google-info.org/11294521/1/modeles-economiques-des-logiciels-open-source.html</blockquote> | ||
</translate> | |||
== Glossaire == | <translate> | ||
== Glossaire == <!--T:83--> | |||
'''Bénéficiaires : '''désigne les utilisateurs finaux de la ressource. | '''Bénéficiaires : '''désigne les utilisateurs finaux de la ressource. | ||
<!--T:84--> | |||
'''Commun :''' désigne l’association des règles, de la gouvernance et de la ressource. | '''Commun :''' désigne l’association des règles, de la gouvernance et de la ressource. | ||
<!--T:85--> | |||
'''Contrat :''' désigne le présent contrat de licence, ses éventuelles versions postérieures et annexes, documentation, dans leur état au moment de l'acceptation du Contrat par le Licencié. | '''Contrat :''' désigne le présent contrat de licence, ses éventuelles versions postérieures et annexes, documentation, dans leur état au moment de l'acceptation du Contrat par le Licencié. | ||
<!--T:86--> | |||
'''Contributeur :''' désigne une personne physique ou morale auteur d'au moins une contribution. | '''Contributeur :''' désigne une personne physique ou morale auteur d'au moins une contribution. | ||
<!--T:87--> | |||
'''Contribution :''' désigne l'ensemble des modifications, corrections, traductions, adaptations et/ou nouvelles fonctionnalités intégrées dans la ressource et reconnues par la gouvernance. | '''Contribution :''' désigne l'ensemble des modifications, corrections, traductions, adaptations et/ou nouvelles fonctionnalités intégrées dans la ressource et reconnues par la gouvernance. | ||
<!--T:88--> | |||
'''Exploitant :''' désigne le licencié en charge de maintenir et d’intégrer les évolutions de la ressource. | '''Exploitant :''' désigne le licencié en charge de maintenir et d’intégrer les évolutions de la ressource. | ||
<!--T:89--> | |||
'''Licencié :''' désigne le ou les utilisateur(s) contractuel(s) de la ressource. | '''Licencié :''' désigne le ou les utilisateur(s) contractuel(s) de la ressource. | ||
<!--T:90--> | |||
'''Parties :''' désigne l’ensemble des bénéficiaires, licenciés et contributeurs. | '''Parties :''' désigne l’ensemble des bénéficiaires, licenciés et contributeurs. | ||
</translate> | |||
Dernière version du 31 octobre 2024 à 15:46
Le guide de la gouvernance est une production du groupe de travail "Ressources Mutualisées". L'objectif est de donner un cadre de réflexion et les grands principes suivis par le Campus Cyber sur la constitution de la gouvernance d'un commun de la cyber.
Cette doctrine pourra être amenée à évoluer dans le temps.
Les principes de la gouvernance[modifier | modifier le wikicode]
Rôle de la gouvernance[modifier | modifier le wikicode]
Le Campus Cyber préconise que la gouvernance se concentre sur le suivi des objectifs d’impacts. Il est nécessaire que l’équipe projet conserve un bon niveau d’autonomie dans ses décisions technico-fonctionnelles et la gestion de ses priorités.
Le cas échant, la gouvernance pourra préconiser des orientations techniques ou demander la mise en place d’un comité technique pour assurer un suivi continu des choix de l’équipe projet.
D’une manière générale, la gouvernance doit concentrer son action sur les éléments suivants :
- Définir ses modalités de prise de décision et de révision
- Définir les orientations stratégiques de la ressource
- Valider la définition d’une contribution et son suivi
- Valider les évolutions de licence
- Définir les modalités de gestion des conflits et d’exclusion
- Définir et réviser les objectifs d’impacts
- Suivre de la valeur marché de la ressource
La gouvernance est de réviser annuellement les objectifs du commun, son périmètre, les objectifs d’impact et les évolutions de modèle d’affaire et de réciprocité.
Composition de la gouvernance[modifier | modifier le wikicode]
Le Campus Cyber préconise la mise en place d’une gouvernance légère, adaptée à la temporalité et au rôle du commun. La gouvernance ne saurait excéder neuf membres permanents. Le Campus Cyber propose à titre d’exemple les trois typologies suivantes, réparties comme suit :
- Bénéficiaires – 20% à 30% des sièges
- Licenciés – 20% à 30 % des sièges
- Contributeurs – 20% à 30% des sièges
Chaque commun définira les typologies adaptées à son activité. Néanmoins, les typologies resteront exclusives, chaque acteur doit proposer sa typologie qui doit être validée par les membres de la gouvernance.
Le Campus Cyber impose l’ajout à la gouvernance d’une typologie d’acteur dite neutre par rapport au commun. Ce membre dit “membre éthique” est un membre du Campus Cyber qui n’a pas d'implication directe avec le commun mais fait partie de la commission de déontologie (voir gestion des conflits ci-dessous). Dans un cas exceptionnel, ce membre éthique peut être un membre de l’équipe Campus Cyber.
Le “membre éthique” doit disposer d’un siège. Sa voix a le même poids que celle des autres membres de la gouvernance. Le « membre éthique » est soumis aux mêmes règles que les autres membres de la gouvernance.
Condition d’accès et de maintien dans la gouvernance[modifier | modifier le wikicode]
Les entités ayant participé à la coordination du GT à l’origine de la création d’un commun ont une place prioritaire dans la gouvernance, pour garantir la continuité et la transmission du GT vers le commun.
De la même manière, il convient de proposer l’accès à la gouvernance en premier lieu aux membres actifs du GT tout en garantissant les proportions citées dans le chapitre « Composition de la gouvernance ». La gouvernance doit refléter la diversité des collèges impliqués.
L’accès à la gouvernance peut se faire par une nomination ou élection au sein des collèges. Critère obligatoire pour accéder à la gouvernance :
- Être Membre du Campus Cyber
Chaque membre de la gouvernance se doit de respecter les principes suivants :
- Être assidu
- Se conformer à la charte du Campus Cyber
- Respecter les conditions d’utilisation du commun (CGU)
Le non-respect de ces principes peut conduire à l’exclusion de la gouvernance. De même que la sortie du Campus Cyber.
Mandature[modifier | modifier le wikicode]
Pour garantir un renouvellement sain, tout en assurant la continuité des travaux du commun, la mandature ne doit pas excéder 3 années, renouvelable une fois.
Le renouvellement des mandatures doit être partiel (par 1/3 ou 1/2). Ainsi, dès le premier mandat, certains sièges auront une durée écourtée pour permettre la mise en place du modèle de renouvellement.
Modalité de prise de décision[modifier | modifier le wikicode]
Chaque gouvernance peut choisir une modalité de prise de décisions qui lui est propre. Néanmoins, le Campus Cyber permet la mise en place de plusieurs modalités de prise de décision en fonction de la criticité de l’arbitrage.
- Majorité absolue : Les votants doivent représenter la moitié plus 1 voix pour qu’une décision soit validée.
- Majorité qualifiée : Les votant doivent représenter au moins 2/3 des voix pour qu’une décision soit validée.
- Vote par valeur : Les votants doivent donner leur avis sur 5 niveaux (Rejeter, Préciser, Neutre, Poursuivre, Valider). Les avis peuvent être accompagnés de questions ou remarques. L’ensemble des avis donne lieu à une note. La somme des notes doit représenter 2/3 des points pour valider la proposition.
- Processus Consentement : La prise de décision suit un processus qui consiste à valider une décision si aucun membre du groupe ne s’y est opposé. La prise de décision se fait de manière participative et implique que la décision sera validée lorsque plus aucune objection raisonnable ne sera énoncée.
Gestion des conflits[modifier | modifier le wikicode]
La conduite des communs nécessite d’anticiper un processus de gestion des conflits claire et économique.
La gestion des conflits est basée sur deux fonctions essentielles. La fonction de rapporteur est à la charge du “membre éthique” qui doit faire le lien avec la commission de déontologie.
La fonction de médiation est portée par la commission de déontologie.
Commission de déontologie[modifier | modifier le wikicode]
La commission de déontologie est composée de membres de chaque collège. Chaque collège doit identifier au moins deux volontaires qui intégreront le groupe des déontologues. Les membres du groupe de déontologues sont les membres éthiques dans les instances de gouvernance.
La commission de déontologie a pour rôle de réviser la charte éthique, de suivre sa mise en application et d'avoir un rôle de conseil auprès des instances de gouvernance des communs de la cyber.
Dans le cas de saisine pour la gestion d’un conflit, cinq membres de la commission de déontologie seront mandatés pour arbitrer le dossier. Aucun des membres de la commission ne devra avoir de lien avec les parties prenantes ou avec le commun concerné par le conflit.
La commission pourra se rassembler et auditionner les différentes parties autant que nécessaire pour résoudre le conflit. La commission devra statuer dans un délai maximum de deux mois suite à la saisine, la première réunion de présentation conflit faisant office de lancement du dispositif.
La commission doit produire un rapport d’activité annuel constitué de l’historique des décisions et des changements de la charte.
Processus de saisine[modifier | modifier le wikicode]
Le processus de saisine de la commission de déontologie doit passer par la gouvernance du commun pour être entérinée.
Toute partie prenante en lien avec le commun peut demander à inscrire à l’ordre de la gouvernance un sujet de conflit pour arbitrage.
Lors des délibérations de la gouvernance, il peut être décidé d’ouvrir un processus de gestion de conflit. Le processus de gestion de conflit peut être initié car un préjudice perçu ne trouve pas de solutions via la gouvernance.
Dès lors, le membre éthique devient rapporteur pour la commission de déontologie. Le membre éthique doit réunir une commission éthique de cinq membres.
Le membre éthique doit constituer le dossier de suivi du conflit qui doit contenir a minima :
- Explication du contexte
- Description du préjudice perçu
- Requêtes et position des différents partis
- Demande de délai de résolution
Le dossier de suivi du conflit devra comporter une synthèse des délibérations et des décisions de la commission de déontologie. Suite à la résolution, la commission de déontologie devra alimenter un référentiel de traitement des conflits de manière à disposer d’un historique des décisions antérieures.
Dans un premier temps, les parties s’engagent, de bonne foi, à respecter le processus de résolution défini avant de recourir à toute autre instance de résolution.
Dans le cas où la médiation interne portée par la commission de déontologie n’aboutit pas à une résolution satisfaisante pour l’ensemble des parties, il est possible de se faire accompagner par une médiation externe. La commission de déontologie peut librement décider de financer l’accompagnement par le commun ou de faire porter la médiation par les parties impliquées dans le conflit.
Licence et CGU[modifier | modifier le wikicode]
Cette partie vise à définir la licence utilisée par le commun pour gérer l’exploitation et la commercialisation.
L’objectif est d’avoir un jeu de licences qui favorise la propagation du commun pour former, développer les connaissances, renforcer les avantages concurrentiels de l’écosystème et qui garantit l’évolution et la pérennité de ce même commun. L’exploitation commerciale doit être autorisée et encouragée à tous ceux qui le souhaite, tout en reconnaissant les contributions qui font évoluer le communs permettant la mise en place de forme de réciprocité.
La licence devra préciser les modalités de contraintes d’accès au commun et les règles de commercialisation afférentes.
Ainsi cette licence différenciera la participation créatrice de la participation économique. Dans ce contexte, la notion de contribution reconnait exclusivement la participation créatrice.
L’implication dans la gouvernance du commun n’est pas considérée comme une contribution.
Chaque commun doit définir son modèle de réciprocité mettant en lien les contreparties commerciales (cf. Tableau des contreparties) au regard de contributions reconnues.
Définition des contributions[modifier | modifier le wikicode]
Une contribution désigne l'ensemble des modifications, corrections, traductions, adaptations et/ou nouvelles fonctionnalités intégrées dans la ressource et reconnue par la gouvernance.
Une contribution peut prendre la forme de développement logiciel, de jeu de données, de documentation, alimentation par des flux, etc. Une contribution doit apporter de la valeur au commun. Une contribution est considérée comme effective à la suite de sa livraison et validée par l’équipe en charge de la gestion du commun.
Lancement des contributions[modifier | modifier le wikicode]
La gouvernance peut définir les contreparties et réciprocités au regard de l’investissement de chaque membre dans les phases amont de la mise à disposition de la ressource.
Reconnaissance des contributions[modifier | modifier le wikicode]
De manière à rendre la reconnaissance des contributions la plus souple possible pour la gouvernance du commun, nous proposons de suivre un modèle qui s’appuie sur les contributions réalisées.
Pour chaque début d’exercice, les contributeurs produisent une déclaration des prévisions de contribution à travers un Etat des Prévisions de Contribution (EPC).
Pour chaque fin d’exercice, les contributeurs produisent une déclaration des réalisations à travers un Etat Récapitulatif Des Contributions (ERC).
Les contributions doivent faire l’objet d’une évaluation économique.
Ces deux états doivent être fournis au moins un mois avant la réunion annuelle de gouvernance appelée à statuer sur le budget du commun de l’année écoulée et à venir. Ainsi les équipes en charge de la gestion du commun pourront émettre un avis sur la réalisation des contributions, fournir un historique des contributions annuelles et fournir un prévisionnel des contributions.
D’autres modèles pourront être expérimentés le cas échéant et intégrés dans les futures modalités possibles.
Modèles de Réciprocité[modifier | modifier le wikicode]
L’attribution des contreparties fait suite à la validation des contributions de la période référence précédente. La période de référence est l’exercice comptable du Campus Cyber.
Chaque commun doit garantir son propre fonctionnement et ses évolutions.
Exemple correspondance de réciprocité
| Echelle de contribution | Echelle de contrepartie | Exemples de contrepartie |
| < 5 000€ | Contrepartie 1 | Remerciement / Badge |
| < 10 000€ | Contrepartie 2 | Réduction / RFA sur CA |
| < 50 000€ | Contrepartie 3 | Réduction / RFA sur CA / Gratuité |
| > 50 000€ | Contrepartie 4 | Réduction / RFA sur CA / Gratuité / Porte parole du Commun |
Une approche envisageable complémentaire pour la reconnaissance des contributions, serait de la création d’un « badge » permettant de montrer la participation d’une entité à la production ou l’usage d'un commun.
Modèle de licence[modifier | modifier le wikicode]
En cours de construction, V1 prévue pour T4 2022
Ressources pour les licences en creative commons : https://chooser-beta.creativecommons.org/
Exemples de Modèles d'affaire[modifier | modifier le wikicode]
Les modèles d’affaires présentés dessous ne sont pas exhaustifs ni exclusif. Néanmoins, ces modèles sont constitutifs des licences et conditions d’usages du commun.
Les modèles d’affaires pourront évoluer sur proposition de l’équipe de production ou d’exploitation et validation par la gouvernance.
Les modèles d’affaires présentés ci-dessous sont des sources d’inspiration issues des pratiques observées dans le monde de l’open source.
Approche de la double licence : Le mécanisme de la double licence consiste à proposer le logiciel à la fois sous une licence libre et à des conditions propriétaires distinctes. La version propriétaire peut ainsi être vendue pour financer le développement continu de la version libre gratuite.
Approche Vente de services professionnels : Les revenus proviennent de la vente de services, tels que la fourniture de formations, de support technique ou de prestations conseil, plutôt que de la vente du logiciel lui-même.
Approches Vente de certificats et d’usage de marque : Le modèle d’affaires est basé sur un réseau de partenaires commerciaux qui sont certifiés et autorisés à utiliser le nom et le logo, en échange ils reversent une part de leurs revenus qui finance le développement du cœur du logiciel (ex : Moodle).
Approches Vente de logiciel comme service Software as a Service : Correspond à la vente de souscriptions à des clients pour des accès distants.
Approches Partenariats avec des organismes de financement : Des modèles économiques sont basés sur des partenariats avec d’autres entreprises.
Approches Dons volontaires : Mise en place d’un système de don de la part des usagers et identification de bienfaiteurs reconnues.
Approches Production participative : La production participative est proposée, par l’intermédiaire d’appels ouverts à contributions. La réalisation de la tâche de complexité et modularité variables, à laquelle le groupe doit participer en apportant travail, ressources financières, savoirs et/ou expérience implique toujours un bénéfice mutuel.
Approches Financement par la publicité : Afin de commercialiser des de nombreuses entreprises ont fait évoluer leur modèle d’affaires vers des logiciels financés par la publicité.
Approches Vente d’extensions propriétaires optionnelles : Certaines entreprises vendent des extensions, modules, plugins ou add-ons optionnels. Cette approche est une variante du modèle d’affaires freemium. Les extensions payantes et/ou propriétaires peut être conçu pour permettre aux clients de tirer un avantage supérieur de leurs données, infrastructure ou plate-forme, par exemple, les faire fonctionner plus efficacement, mieux les gérer, mieux les sécuriser. Certaines entreprises réinvestissent une partie de leurs bénéfices financiers dans l’infrastructure open source.
Approches Vente de composants propriétaires indispensables d’un produit logiciel : Une variante de l’approche ci-dessus consiste à garder restrictive des données et contenus indispensables d’un produit logiciel tout en libérant le code source. Les utilisateurs doivent acheter le contenu afin de disposer d’une solution complète et fonctionnelle. Des licences restrictives peuvent en outre s’appliquer au contenu, ce qui empêche la redistribution ou la revente du logiciel complet.
Approches Vente de systèmes de mise à jour propriétaires : Une autre variante du modèle d’affaires ci-dessus, utilisé notamment pour des logiciels traitant beaucoup de données ou dont l’architecture est centrée sur la gestion de données, est le fait de conserver chaque version du logiciel sous une licence open source, mais de s’abstenir de publier les scripts de mise à jour d’une version n à une version n+1.
Les utilisateurs peuvent encore déployer et faire fonctionner le logiciel open source. Cependant, toute mise à jour à une version supérieure impose à l’utilisateur :
- soit de souscrire à un service fermé ou d’acquérir un système de mises à jour sous licence propriétaire ;
- soit d’exporter la totalité des données, installer la nouvelle version, puis réimporter les données dans cette nouvelle version ;
- soit d’étudier le code source des deux versions et de recréer lui-même les scripts requis.
Approches Redistribution sous licence propriétaire : Si un produit logiciel utilise uniquement des logiciels par une licence de logiciel permissive une autre entreprise peut redistribuer le logiciel obtenu produit sous une licence propriétaire et le vendre sans le code source ou les libertés logicielles. Par exemple, Apple Inc. est un fervent utilisateur de cette approche et exploite le code source et les logiciels de projets open source.
Approches Offuscation de code source : L’offuscation de code source est une approche pour permettre la commercialisation sous une licence open source tout en protégeant des secrets d’affaires cruciaux, des éléments de propriété intellectuelle et des savoir-faire techniques.
Approches Publication en open source retardée : Certaines entreprises ne fournissent la dernière version disponible de leur logiciel qu’aux clients payants. Un vendeur forke un projet logiciel non copyleft et y ajoute des composants fermés avant de vendre le logiciel qui résulte de cet ajout. Ce modèle économique est appelé "retard de version".
Source d’information : https://fr.google-info.org/11294521/1/modeles-economiques-des-logiciels-open-source.html
Glossaire[modifier | modifier le wikicode]
Bénéficiaires : désigne les utilisateurs finaux de la ressource.
Commun : désigne l’association des règles, de la gouvernance et de la ressource.
Contrat : désigne le présent contrat de licence, ses éventuelles versions postérieures et annexes, documentation, dans leur état au moment de l'acceptation du Contrat par le Licencié.
Contributeur : désigne une personne physique ou morale auteur d'au moins une contribution.
Contribution : désigne l'ensemble des modifications, corrections, traductions, adaptations et/ou nouvelles fonctionnalités intégrées dans la ressource et reconnues par la gouvernance.
Exploitant : désigne le licencié en charge de maintenir et d’intégrer les évolutions de la ressource.
Licencié : désigne le ou les utilisateur(s) contractuel(s) de la ressource.
Parties : désigne l’ensemble des bénéficiaires, licenciés et contributeurs.
