# Ecosystem Participation Terms FAQs

Please see the DaaS legal framework [here ](https://docs.google.com/document/d/1WjoUDT0IB9Jcel5eyA1q0279UJj_cYmhLxlFJE9hsv4/edit?pli=1\&tab=t.0#heading=h.k552y4umgrjn)

<mark style="background-color:purple;">Q. What’s the overall legal framework of DaaS?</mark>&#x20;

A. There are 4 parties involved in DaaS:&#x20;

1. DaaS Country Partner - the Country department which is executing the DaaS package&#x20;
2. DaaS DPG Partner - the DPG which is providing the DaaS product to be deployed in the country
3. Service Provider(s) - the entity(ies) that will deploy, maintain and provide the technical support during the pilot of DaaS&#x20;
4. Advisor - the partner covering all advisory ( managerial, technical, legal  etc)related to DaaS. For the first cohort, this will be the Centre for DPI. &#x20;

These parties interact with each other in the following ways:&#x20;

1. LoI or MOU between DaaS Country Partner and DaaS DPG Partner
2. Ecosystem Participation Terms signed by all SPs and DPGs part of the DaaS ecosystem
3. MOU or LoI between the DaaS Country Partner and the Advisor (optional)&#x20;

<mark style="background-color:purple;">Q. Why have ecosystem participation terms instead of bilateral contracts between the DPG and SP?</mark>

A. Bilateral contracts usually undergo lengthy negotiation processes before each signing and due to this, the terms agreed to by different DPGs and SPs would differ. Due to this, the countries would have no common bar on how to assess the offerings by the DPGs and the SP selection committee would have no common bar on how to judge the SPs bidding for a project. The goal of the EPT is to align all parties into basic foundational clauses such as cyber security, data portability, open source code etc. to adhere to the 'rapid deployment' and 'standardisation' goals of DaaS.&#x20;

<mark style="background-color:purple;">Q. Will SPs still need an additional bilateral contract to close on compensation and other details of implementation that cannot be standardised?</mark>&#x20;

A. The 'contract' in this case is a multi-party contract termed as Ecosystem Participation Terms that lay out the general contracting clauses of any DaaS implementation. The country-specific implementation details are governed by the 'Country Scope Document' which is signed off on by the Country and DPG, and signed by the implementing SP - this also indicates the compensation amount, deliverables, payment schedules etc. which would typically be covered under a special contracting clause.&#x20;

<mark style="background-color:purple;">Q. When do EPT terms kick in?</mark>&#x20;

A. The EPT comes into force only for the DPG and SP chosen for a particular implementation post the signing of the country scope document.&#x20;

\
<mark style="background-color:purple;">Q. Why does the MOU restrict Service Providers from using code under their own IP that is not available through open source?</mark>&#x20;

A. The principle behind DaaS is standardisation and productization. This means that all the products available through the DaaS program must be exactly replicable and rapidly executable for multiple countries, hence it involves standard legal frameworks, product kits, funding amounts etc. If a service provider brings in their own proprietary code or IP into the execution cycle, multiple  scenarios separate from the best practices of DaaS may play out:&#x20;

1. The country may get locked-in to that particular service provider since a new vendor will not have access to that code or IP&#x20;
2. It will prevent the country or DPG from switching service providers mid-way in case of any contingency&#x20;
3. The same DaaS product if deployed in another country with another service provider will see a different execution with different features since the code will not be replicable and it will defeat the purpose of DaaS&#x20;

<mark style="background-color:purple;">Q. So can I as a Service Provider take the base-line open source product and pitch it to countries myself without DaaS?</mark>&#x20;

A. Of course! In the initial cohorts of DaaS, the DPGs provide training and capacity building for service providers on their products. Once a service provider feels sufficiently empowered, they are free to approach countries directly and deploy the open source code on their own, enhanced by their own IP as they see fit.&#x20;

<mark style="background-color:purple;">Q. Why aren't cloud providers included in the EPT?</mark>&#x20;

A. Cloud providers typically have back-to-back contractual agreements with the SP to support on country deployment. From a DaaS implementation perspective, we did not want to distribute the accountability among various participating entities so we restricted it to SPs who receive the compensation from the DPGs for implementation and are thus, responsible for its timely execution. Cloud providers would operate as an entity under the SPs.

However, similar to SPs, cloud providers are also empowered to individually utilise DaaS artefacts and open source DPG code to implement independently in countries. \
\
\
