> For the complete documentation index, see [llms.txt](https://docs.cdpi.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cdpi.dev/initiatives/dpi-as-a-packaged-solution-daas/faqs-on-daas/ecosystem-participation-terms-faqs.md).

# 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:

1. DaaS Country Partner: the country department which is executing the DaaS package.
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.
4. Advisor: the partner covering all advisory matters related to DaaS, including managerial, technical, and legal aspects. For the first cohort, this will be the Centre for DPI.

These parties interact with each other in the following ways:

1. LoI or MOU between DaaS Country Partner and DaaS DPG Partner
2. Ecosystem Participation Terms signed by all SPs and DPGs that are 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, and other elements which would typically be covered under a special contracting clause.

<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.
2. It will prevent the country or DPG from switching service providers mid-way in case of any contingency.
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.

<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.

<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.\
\ <br>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.cdpi.dev/initiatives/dpi-as-a-packaged-solution-daas/faqs-on-daas/ecosystem-participation-terms-faqs.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.