DPG x SP MOU FAQs
Please see the MOU template here
Q. What’s the overall legal framework of DaaS?
A. There are 4 parties involved in DaaS:
DaaS Implementer - the Country department which is executing the DaaS package
DaaS Partner - the DPG which is providing the DaaS product to be deployed in the country
Service Provider(s) - the entity(ies) that will deploy, maintain and provide the technical support during the pilot of DaaS
Advisor - the partner covering all advisory (managerial, technical, legal, etc.) related to DaaS. For the first cohort, this will be the Centre for DPI.
These parties interact with each other in the following ways:
MOU between the DaaS Implementer (Country Dep’t) and the DaaS Partner (DPG)
MOU between the DaaS Partner (DPG) and the Service Provider
MOU or LoI between the DaaS Implementer and the Advisor
Q: Why have an MOU between a country and a DPG, when it is not the DPG who will ultimately implement the product in the country, but rather the DPG will outsource it to a third party (service provider)?
The DPG is the ‘DaaS Partner’ which means that it is the responsibility of the DPG to support implementation of the DaaS package in the country. To do so, it may utilise the support of a SP or multiple SPs to help with capacity building and technical execution through a separate MOU. Since the DaaS product is owned by the DPG, they will be responsible for training the SPs and ensuring that the deployment adheres to best practices.
A: There are multiple reasons for this:
1. Countries are assured to get long term support on the open source software like communications on sunset versions, backward compatibility upgrades on support community versions, community connects, etc. that can help ensure that the product is always adhering to the latest technology standards and industry best practices.
2. In the current DaaS design funders can’t directly fund countries and the money shall be routed through the DPGs to DPG trained and implementing svc partners. In future, there can be other models to route funds and similar MoU templates will emerge.
3. In this model, countries don’t have to go through time consuming RFP routes to pick implementation partners. They can quickly deploy DPI pilots to demonstrate proof of concept and proof of success for the products in their own contexts. Post the pilot, countries are expected to find long term svc partners as per countries processes.
4. DaaS is about packaging policy, procurement, core product software, pre-built / configured solutions, training etc. This MoU is a template to expedite roll out with equal balance of speed and of ensuring that a country's independence and sovereignty is protected.
5. In the current design, Svc Providers have a back to back MoU agreement with DPGs to ensure all obligations are delivered through them. This keeps all 3 parties (country + DPG + svc) aligned on the same track and moving efficiently.
Q. Why does the MOU restrict Service Providers from using code under their own IP that is not available through open source?
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:
The country may get locked-in to that particular service provider since a new vendor will not have access to that code or IP
It will prevent the country or DPG from switching service providers mid-way in case of any contingency
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
Q. So can I as a Service Provider take the base-line open source product and pitch it to countries myself without DaaS?
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.
Last updated