« Guide de gouvernance/en » : différence entre les versions

De Wiki Campus Cyber
Aller à :navigation, rechercher
(Page créée avec « At the end of each financial year, contributors produce a statement of their achievements in the form of a Recapitulative Statement of Contributions (RSC / SoC). »)
Balise : translate-translation-pages
(Mise à jour pour être en accord avec la nouvelle version de la source de la page)
 
(36 versions intermédiaires par un autre utilisateur non affichées)
Ligne 1 : Ligne 1 :
<languages/>
The governance guide is a product of the "Shared Resources" working group. The aim is to provide a framework for reflection and the main principles followed by the Campus Cyber in setting up the governance of a cyber community.
The governance guide is a product of the "Shared Resources" working group. The aim is to provide a framework for reflection and the main principles followed by the Campus Cyber in setting up the governance of a cyber community.


<div lang="fr" dir="ltr" class="mw-content-ltr">
This doctrine may change over time.
Cette doctrine pourra être amenée à évoluer dans le temps.
</div>


<span id="Les_principes_de_la_gouvernance"></span>
== Governance principles ==
== Governance principles ==


Ligne 136 : Ligne 132 :
At the end of each financial year, contributors produce a statement of their achievements in the form of a Recapitulative Statement of Contributions (RSC / SoC).
At the end of each financial year, contributors produce a statement of their achievements in the form of a Recapitulative Statement of Contributions (RSC / SoC).


<div lang="fr" dir="ltr" class="mw-content-ltr">
Contributions are subject to economic evaluation.
Les contributions doivent faire l’objet d’une évaluation économique.
</div>


<div lang="fr" dir="ltr" class="mw-content-ltr">
These two statements must be provided at least one month before the annual governance meeting called to decide on the pool's budget for the year just ended and for the year to come. In this way, the teams in charge of managing the pool will be able to issue an opinion on the achievement of contributions, provide a history of annual contributions and provide a forecast of 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.
</div>


<div lang="fr" dir="ltr" class="mw-content-ltr">
Other models can be tested where appropriate, and incorporated into possible future modalities.
D’autres modèles pourront être expérimentés le cas échéant et intégrés dans les futures modalités possibles.
=== Reciprocity models ===
</div>
Allocations are made following validation of contributions for the previous reference period. The reference period is the Campus Cyber financial year.
<div lang="fr" dir="ltr" class="mw-content-ltr">
=== Modèles de Réciprocité ===
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.
</div>


<div lang="fr" dir="ltr" class="mw-content-ltr">
Each common must guarantee its own operation and evolution.
Chaque commun doit garantir son propre fonctionnement et ses évolutions.
</div>


<div lang="fr" dir="ltr" class="mw-content-ltr">
Example of reciprocity matching
Exemple correspondance de réciprocité
{| class="wikitable table-responsive table-responsive"
{| class="wikitable table-responsive table-responsive"
|Echelle de contribution
|Contribution scale
|Echelle de contrepartie
|Counterpart Scale
|Exemples de contrepartie
|Examples of reciprocity
|-
|-
|< 5 000€
|< 5 000€
|Contrepartie  1
|Counterparty 1
|Remerciement / Badge
|Thank you / Badge
|-
|-
|< 10 000€
|< 10 000€
|Contrepartie 2
|Contrepartie 2
|Réduction / RFA sur CA
|Discount / RFA on sales
|-
|-
|< 50 000€
|< 50 000€
|Contrepartie  3
|Party 3
|Réduction / RFA sur CA / Gratuité
|Discount / RFA on sales / Free of charge
|-
|-
|> 50 000€
|> 50 000€
|Contrepartie  4
|Party 4
|Réduction / RFA sur CA / Gratuité / Porte parole du Commun
|Reduction / RFA on sales / Free / Commun spokesperson
|}
|}
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.
A possible complementary approach to recognizing contributions would be to create a "badge" to show an entity's participation in the production or use of a commons.
</div>
=== Licence model ===
<div lang="fr" dir="ltr" class="mw-content-ltr">
WIP
=== Modèle de licence ===
En cours de construction, V1 prévue pour T4 2022
</div>


<div lang="fr" dir="ltr" class="mw-content-ltr">
Ressources: https://chooser-beta.creativecommons.org/
Ressources pour les licences en creative commons : https://chooser-beta.creativecommons.org/
</div>


<div lang="fr" dir="ltr" class="mw-content-ltr">
== Examples of Business Models ==
== Exemples de Modèles d'affaire ==
The business models presented below are neither exhaustive nor exclusive. Nevertheless, these models form part of the common licenses and conditions of use.
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.
</div>


<div lang="fr" dir="ltr" class="mw-content-ltr">
Business models may evolve upon proposal by the production or operations team and validation by governance.
Les modèles d’affaires pourront évoluer sur proposition de l’équipe de production ou d’exploitation et validation par la gouvernance.
</div>


<div lang="fr" dir="ltr" class="mw-content-ltr">
The business models presented below are sources of inspiration drawn from practices observed in the open source world.
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.
</div>


<div lang="fr" dir="ltr" class="mw-content-ltr">
'''Dual-license approach''': The dual-license mechanism consists of offering software under both a free license and distinct proprietary conditions. The proprietary version can then be sold to finance the ongoing development of the free version.
'''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.
</div>


<div lang="fr" dir="ltr" class="mw-content-ltr">
'''Professional Services Sales Approach''': Revenues are derived from the sale of services, such as training, technical support or consulting, rather than from the sale of the software itself.
'''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.
</div>


<div lang="fr" dir="ltr" class="mw-content-ltr">
'''Approaches Selling certificates and trademark use:''' The business model is based on a network of commercial partners who are certified and authorized to use the name and logo. In exchange, they pay back a share of their revenues, which finances the development of the core software (e.g. 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).
</div>


<div lang="fr" dir="ltr" class="mw-content-ltr">
'''Approaches Selling software as a service Software as a Service''': Corresponds to the sale of subscriptions to customers for remote access.
'''Approches Vente de logiciel comme service Software as a Service''' : Correspond à la vente de souscriptions à des clients pour des accès distants.
</div>


<div lang="fr" dir="ltr" class="mw-content-ltr">
'''Partnership approaches with funding bodies''': Business models are based on partnerships with other companies.
'''Approches Partenariats avec des organismes de financement''' : Des modèles économiques sont basés sur des partenariats avec d’autres entreprises.
</div>


<div lang="fr" dir="ltr" class="mw-content-ltr">
'''Approaches Voluntary donations''': Establishment of a system of user donations and identification of recognized benefactors.
'''Approches Dons volontaires''' : Mise en place d’un système de don de la part des usagers et identification de bienfaiteurs reconnues.
</div>


<div lang="fr" dir="ltr" class="mw-content-ltr">
'''Participatory production approaches''': Participatory production is proposed through open calls for contributions. The realization of a task of variable complexity and modularity, in which the group must participate by contributing work, financial resources, knowledge and/or experience, always implies mutual benefit.
'''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.
</div>


<div lang="fr" dir="ltr" class="mw-content-ltr">
'''Advertising-financed approaches''': In order to bring new products to market, many companies have shifted their business model to advertising-financed software.
'''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é.
</div>


<div lang="fr" dir="ltr" class="mw-content-ltr">
'''Approaches Selling optional proprietary extensions''': Some companies sell optional extensions, modules, plugins or add-ons. This approach is a variant of the freemium business model. Paid and/or proprietary extensions can be designed to enable customers to derive greater benefit from their data, infrastructure or platform, e.g., make it run more efficiently, manage it better, secure it better. Some companies reinvest part of their financial profits in open source infrastructure.  
'''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.
</div>


<div lang="fr" dir="ltr" class="mw-content-ltr">
'''Approaches Selling essential proprietary components of a software product''': A variant of the above approach is to keep restrictive essential data and content of a software product while releasing the source code. Users must purchase the content in order to obtain a complete, functional solution. Restrictive licenses may also apply to the content, preventing redistribution or resale of the complete software.  
'''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.
</div>


<div lang="fr" dir="ltr" class="mw-content-ltr">
'''Approaches Selling proprietary update systems''': Another variant of the above business model, used in particular for data-intensive software or software whose architecture is centered on data management, is to keep each version of the software under an open source license, but refrain from publishing update scripts from version n to 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.
</div>


<div lang="fr" dir="ltr" class="mw-content-ltr">
Users can still deploy and run the open source software. However, upgrading to a higher version requires the user to:
Les utilisateurs peuvent encore déployer et faire fonctionner le logiciel open source. Cependant, toute mise à jour à une version supérieure impose à l’utilisateur :
</div>


<div lang="fr" dir="ltr" class="mw-content-ltr">
* either subscribe to a closed service or acquire an update system under a proprietary license ;
* soit de souscrire à un service fermé ou d’acquérir un système de mises à jour sous licence propriétaire ;
* export all data, install the new version, then re-import the data into the new version;
* soit d’exporter la totalité des données, installer la nouvelle version, puis réimporter les données dans cette nouvelle version ;
* or study the source code of both versions and recreate the required scripts yourself.
* soit d’étudier le code source des deux versions et de recréer lui-même les scripts requis.
</div>




<div lang="fr" dir="ltr" class="mw-content-ltr">
'''Redistribution approaches under proprietary license''': If a software product uses only software licensed under a permissive software license, another company can redistribute the resulting software produced under a proprietary license and sell it without the source code or software freedoms. For example, Apple Inc. is a fervent user of this approach, exploiting source code and software from open source projects.  
'''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.
</div>


<div lang="fr" dir="ltr" class="mw-content-ltr">
'''Source code offuscation approaches''': Source code offuscation is an approach to enabling commercialization under an open source license while protecting crucial business secrets, intellectual property and technical know-how.
'''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.
</div>


<div lang="fr" dir="ltr" class="mw-content-ltr">
'''Delayed open source release approaches''': Some companies only supply the latest available version of their software to paying customers. A vendor forks a non-copyleft software project and adds closed components before selling the resulting software. This business model is called "version delay".<blockquote>Information source: 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>
== Glossary ==
</div>
'''Beneficiaries: '''refers to the end users of the resource.
<div lang="fr" dir="ltr" class="mw-content-ltr">
== Glossaire ==
'''Bénéficiaires :  '''désigne les utilisateurs finaux de la ressource.
</div>


<div lang="fr" dir="ltr" class="mw-content-ltr">
'''Common:''' means the combination of rules, governance and resource.
'''Commun :''' désigne l’association des règles, de la gouvernance et de la ressource.
</div>


<div lang="fr" dir="ltr" class="mw-content-ltr">
'''Agreement:''' means this license agreement, any subsequent versions and appendices, documentation, as they exist at the time of acceptance of the Agreement by the Licensee.
'''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é.
</div>


<div lang="fr" dir="ltr" class="mw-content-ltr">
'''Contributor:''' means a natural or legal person who has made at least one contribution.
'''Contributeur :''' désigne une personne physique ou morale auteur d'au moins une contribution.
</div>


<div lang="fr" dir="ltr" class="mw-content-ltr">
'''Contribution:''' refers to all modifications, corrections, translations, adaptations and/or new functionalities integrated into the resource and recognized by governance.
'''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.
</div>


<div lang="fr" dir="ltr" class="mw-content-ltr">
'''Operator:''' refers to the licensee responsible for maintaining and integrating changes to the resource.
'''Exploitant :''' désigne le licencié en charge de maintenir et d’intégrer les évolutions de la ressource.
</div>


<div lang="fr" dir="ltr" class="mw-content-ltr">
'''Licensee:''' refers to the contractual user(s) of the resource.
'''Licencié :''' désigne le ou les utilisateur(s) contractuel(s) de la ressource.
</div>


<div lang="fr" dir="ltr" class="mw-content-ltr">
'''Parties:''' refers to all beneficiaries, licensees and contributors.
'''Parties :''' désigne l’ensemble des bénéficiaires, licenciés et contributeurs.
</div>

Dernière version du 31 octobre 2024 à 15:46

The governance guide is a product of the "Shared Resources" working group. The aim is to provide a framework for reflection and the main principles followed by the Campus Cyber in setting up the governance of a cyber community.

This doctrine may change over time.

Governance principles

Role of governance

Campus Cyber recommends that governance focus on monitoring impact objectives. The project team must retain a high degree of autonomy in its technical and functional decisions, and in the management of its priorities.

If necessary, the governance committee can recommend technical guidelines or ask for a technical committee to be set up to ensure ongoing monitoring of the project team's choices.

Generally speaking, governance should focus on the following elements:

  • Define its decision-making and review procedures
  • Define the strategic orientations of the resource
  • Validate the definition of a contribution and its follow-up
  • Validate license evolutions
  • Define conflict management and exclusion procedures
  • Define and revise impact objectives
  • Monitor the market value of the resource

Governance involves an annual review of the common objectives, scope, impact targets and changes to the business model and reciprocity.

Governance composition

Campus Cyber advocates a light governance structure, adapted to the timeframe and role of the community. Governance should not exceed nine permanent members. By way of example, the Cyber Campus proposes the following three typologies, distributed as follows:

  • Beneficiaries - 20% to 30% of seats
  • Licensees - 20% to 30% of seats
  • Contributors - 20% to 30% of seats

Each community will define the typologies best suited to its activity. Nevertheless, the typologies will remain exclusive, and each player must propose its own typology, which must be validated by the members of the governance committee.

The Cyber Campus requires the addition to its governance of a type of actor who is neutral in relation to the common good. This member, known as an "ethical member", is a member of Campus Cyber who has no direct involvement with the commons, but is a member of the deontology commission (see conflict management below). In exceptional cases, this ethical member may be a member of the Campus Cyber team.

The "ethical member" must have one seat. His/her vote has the same weight as that of the other members of the Board of Directors. The "ethical member" is subject to the same rules as the other governance members.

Conditions for accessing and maintaining governance

The entities that participated in the coordination of the WG at the origin of the creation of a common have a priority place in governance, to guarantee continuity and transmission from the WG to the common.

In the same way, it is advisable to offer access to governance primarily to active members of the WG, while guaranteeing the proportions cited in the "Composition of governance" chapter. Governance must reflect the diversity of the colleges involved.

Access to governance can be by nomination or election within the colleges. Mandatory criteria for access to governance :

  • Being a Campus Cyber's Member

Each member of the governance team must respect the following principles:

  • Be assiduous
  • Comply with the Campus Cyber chart
  • Respect the terms of use (CGU)

Failure to comply with these principles may result in exclusion from governance. The same applies to leaving the Campus Cyber.

Term of office

To guarantee a healthy renewal, while ensuring the continuity of the Common's work, the term of office must not exceed 3 years, renewable once.

The renewal of mandates must be partial (by 1/3 or 1/2). This means that, from the first term, some seats will be shortened to allow the renewal model to be implemented.

Decision-making methods

Each governance can choose its own decision-making method. However, the Cyber Campus allows several decision-making methods to be used, depending on the criticality of the arbitration.

  • Absolute majority:' Voters must represent half plus 1 vote for a decision to be validated.
  • Qualified majority: Voters must represent at least 2/3 of the votes for a decision to be validated.
  • Vote by value: Voters must give their opinion on 5 levels (Reject, Clarify, Neutral, Proceed, Validate). Opinions may be accompanied by questions or comments. All opinions are combined to produce a score. The sum of the scores must represent 2/3 of the points to validate the proposal.
  • Consent Process:' Decision-making follows a process that involves validating a decision if no member of the group has objected to it. Decision-making is a participatory process, which means that the decision will be validated when no further reasonable objections are raised.

Conflict management

Managing common ground requires a clear, cost-effective conflict management process.

Conflict management is based on two essential functions. The "ethics member" is responsible for acting as rapporteur and liaising with the ethics commission.

The mediation function is carried out by the Commission de déontologie.

Commission of Ethics

The ethics commission is made up of members from each college. Each college must identify at least two volunteers to join the group of deontologists. The members of the group of deontologists are the ethical members of the governance bodies.

The role of the ethics commission is to review the ethics charter, monitor its application and advise the governance bodies of the cyber commons.

In the event of a conflict management referral, five members of the deontology commission will be mandated to arbitrate the case. None of the members of the commission shall have any connection with the parties involved or with the community concerned by the conflict.

The commission can meet and hear the various parties as often as necessary to resolve the conflict. The commission must reach a decision within a maximum of two months of the referral, with the first conflict presentation meeting serving as the launch of the system.

The commission is required to produce an annual activity report containing a history of decisions and changes to the chart.

Referral process

The referral process to the deontology commission must go through the common governance to be ratified.

Any stakeholder with an interest in the common may request that a dispute be placed on the governance agenda for arbitration.

During governance deliberations, it may be decided to initiate a conflict management process. The conflict management process may be initiated because a perceived prejudice cannot be resolved through governance.

From then on, the ethics member becomes rapporteur for the ethics commission. The ethics member must convene a five-member ethics commission.

The ethical member must compile the conflict follow-up file, which must contain at least :

  • Explanation of the context
  • Description of the perceived damage
  • Requests and positions of the various parties
  • Request for resolution timeframe

The conflict follow-up file should include a summary of the deliberations and decisions of the ethics commission. Once the conflict has been resolved, the ethics commission will need to feed a conflict handling repository with a history of previous decisions.

As a first step, the parties undertake, in good faith, to comply with the defined resolution process before resorting to any other resolution body.

If the internal mediation carried out by the ethics commission does not lead to a satisfactory resolution for all parties, it is possible to be accompanied by an external mediator. The deontology commission is free to decide whether to finance the support provided by the joint body, or to have the mediation carried out by the parties involved in the conflict.

== License and T&Cs The purpose of this section is to define the license used by the common to manage exploitation and commercialization.

The aim is to have a set of licenses that encourages the propagation of the commons to train, develop knowledge and reinforce the competitive advantages of the ecosystem, while guaranteeing the evolution and durability of the commons itself. Commercial exploitation must be authorized and encouraged for all those who wish to do so, while recognizing contributions that help the commons to evolve, enabling the establishment of a form of reciprocity.

The license must specify the terms and conditions governing constraints on access to the common and the related marketing rules.

This license differentiates between creative and economic participation. In this context, the notion of contribution recognizes only creative participation.

Involvement in the governance of the commons is not considered a contribution.

Each community must define its own reciprocity model, linking commercial benefits (see Table of benefits) to recognized contributions.

Definition of contributions

A contribution refers to all modifications, corrections, translations, adaptations and/or new functionalities integrated into the resource and recognized by governance.

A contribution can take the form of software development, datasets, documentation, feeds, and so on. A contribution must bring value to the common good. A contribution is considered effective once it has been delivered and validated by the team in charge of managing the commons.

Launch of contributions

Governance can define compensation and reciprocity for each member's investment in the upstream phases of making the resource available.

Recognition of contributions

In order to make the recognition of contributions as flexible as possible for the governance of the commons, we propose to follow a model based on realized contributions.

At the start of each financial year, contributors produce a statement of projected contributions in the form of a Statement of Projected Contributions (EPC / SPC).

At the end of each financial year, contributors produce a statement of their achievements in the form of a Recapitulative Statement of Contributions (RSC / SoC).

Contributions are subject to economic evaluation.

These two statements must be provided at least one month before the annual governance meeting called to decide on the pool's budget for the year just ended and for the year to come. In this way, the teams in charge of managing the pool will be able to issue an opinion on the achievement of contributions, provide a history of annual contributions and provide a forecast of contributions.

Other models can be tested where appropriate, and incorporated into possible future modalities.

Reciprocity models

Allocations are made following validation of contributions for the previous reference period. The reference period is the Campus Cyber financial year.

Each common must guarantee its own operation and evolution.

Example of reciprocity matching

Contribution scale Counterpart Scale Examples of reciprocity
< 5 000€ Counterparty 1 Thank you / Badge
< 10 000€ Contrepartie 2 Discount / RFA on sales
< 50 000€ Party 3 Discount / RFA on sales / Free of charge
> 50 000€ Party 4 Reduction / RFA on sales / Free / Commun spokesperson

A possible complementary approach to recognizing contributions would be to create a "badge" to show an entity's participation in the production or use of a commons.

Licence model

WIP

Ressources: https://chooser-beta.creativecommons.org/

Examples of Business Models

The business models presented below are neither exhaustive nor exclusive. Nevertheless, these models form part of the common licenses and conditions of use.

Business models may evolve upon proposal by the production or operations team and validation by governance.

The business models presented below are sources of inspiration drawn from practices observed in the open source world.

Dual-license approach: The dual-license mechanism consists of offering software under both a free license and distinct proprietary conditions. The proprietary version can then be sold to finance the ongoing development of the free version.

Professional Services Sales Approach: Revenues are derived from the sale of services, such as training, technical support or consulting, rather than from the sale of the software itself.

Approaches Selling certificates and trademark use: The business model is based on a network of commercial partners who are certified and authorized to use the name and logo. In exchange, they pay back a share of their revenues, which finances the development of the core software (e.g. Moodle).

Approaches Selling software as a service Software as a Service: Corresponds to the sale of subscriptions to customers for remote access.

Partnership approaches with funding bodies: Business models are based on partnerships with other companies.

Approaches Voluntary donations: Establishment of a system of user donations and identification of recognized benefactors.

Participatory production approaches: Participatory production is proposed through open calls for contributions. The realization of a task of variable complexity and modularity, in which the group must participate by contributing work, financial resources, knowledge and/or experience, always implies mutual benefit.

Advertising-financed approaches: In order to bring new products to market, many companies have shifted their business model to advertising-financed software.

Approaches Selling optional proprietary extensions: Some companies sell optional extensions, modules, plugins or add-ons. This approach is a variant of the freemium business model. Paid and/or proprietary extensions can be designed to enable customers to derive greater benefit from their data, infrastructure or platform, e.g., make it run more efficiently, manage it better, secure it better. Some companies reinvest part of their financial profits in open source infrastructure.

Approaches Selling essential proprietary components of a software product: A variant of the above approach is to keep restrictive essential data and content of a software product while releasing the source code. Users must purchase the content in order to obtain a complete, functional solution. Restrictive licenses may also apply to the content, preventing redistribution or resale of the complete software.

Approaches Selling proprietary update systems: Another variant of the above business model, used in particular for data-intensive software or software whose architecture is centered on data management, is to keep each version of the software under an open source license, but refrain from publishing update scripts from version n to version n+1.

Users can still deploy and run the open source software. However, upgrading to a higher version requires the user to:

  • either subscribe to a closed service or acquire an update system under a proprietary license ;
  • export all data, install the new version, then re-import the data into the new version;
  • or study the source code of both versions and recreate the required scripts yourself.


Redistribution approaches under proprietary license: If a software product uses only software licensed under a permissive software license, another company can redistribute the resulting software produced under a proprietary license and sell it without the source code or software freedoms. For example, Apple Inc. is a fervent user of this approach, exploiting source code and software from open source projects.

Source code offuscation approaches: Source code offuscation is an approach to enabling commercialization under an open source license while protecting crucial business secrets, intellectual property and technical know-how.

Delayed open source release approaches: Some companies only supply the latest available version of their software to paying customers. A vendor forks a non-copyleft software project and adds closed components before selling the resulting software. This business model is called "version delay".

Information source: https://fr.google-info.org/11294521/1/modeles-economiques-des-logiciels-open-source.html

Glossary

Beneficiaries: refers to the end users of the resource.

Common: means the combination of rules, governance and resource.

Agreement: means this license agreement, any subsequent versions and appendices, documentation, as they exist at the time of acceptance of the Agreement by the Licensee.

Contributor: means a natural or legal person who has made at least one contribution.

Contribution: refers to all modifications, corrections, translations, adaptations and/or new functionalities integrated into the resource and recognized by governance.

Operator: refers to the licensee responsible for maintaining and integrating changes to the resource.

Licensee: refers to the contractual user(s) of the resource.

Parties: refers to all beneficiaries, licensees and contributors.