Deitos Network Application

[Ernih]

Project Abstract

Please replace these instructions with a brief description of your project summarising key points (1-2 paragraphs).

If your application is a follow-up to a previous grant, please mention which one in the first line of the abstract and include a link to previous pull requests if applicable.

Grant level

• Level 1: Up to $10,000, 2 approvals
• Level 2: Up to $30,000, 3 approvals
• Level 3: Unlimited, 5 approvals (for >$100k: Web3 Foundation Council approval)

Application Checklist

• The application template has been copied and aptly renamed (project_name.md).
• I have read the application guidelines.
• Payment details have been provided (bank details via email or Polkadot (USDC & USDT) or BTC address in the application).
• The software delivered for this grant will be released under an open-source license specified in the application.
• The initial PR contains only one commit (squash and force-push if needed).
• The grant will only be announced once the first milestone has been accepted (see the announcement guidelines).
• I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: @_______:matrix.org (change the homeserver if you use a different one)

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[Ernih]

I have read and hereby sign the Contributor License Agreement.

[Ernih]

Hello @keeganquigley,

I have added the comment "I have read and hereby sign the Contributor License Agreement." as requested but it does not seem to be working. Is there anything else i should do in order to complete this step?

Thanks!

[semuelle]

I have added the comment "I have read and hereby sign the Contributor License Agreement." as requested but it does not seem to be working. Is there anything else i should do in order to complete this step?

@rvalera is the author of the commits in this PR, thus they need to sign the CLA.

[rvalera]

I have read and hereby sign the Contributor License Agreement.

[Noc2]

Thanks a lot for the application. This sounds really interesting and very similar to Arweave. Have you looked at it? How is your solution different? One concern I always had in regard to Arweave is that you don't have any incentive to actually share the data with others (at least the last time I looked into it). You only have an incentive to share the hashes to get the rewards. How do you plan to address this? Could you add more technical details to the milestone specification?

[Ernih]

Thanks a lot for the application. This sounds really interesting and very similar to Arweave. Have you looked at it? How is your solution different? One concern I always had in regard to Arweave is that you don't have any incentive to actually share the data with others (at least the last time I looked into it). You only have an incentive to share the hashes to get the rewards. How do you plan to address this? Could you add more technical details to the milestone specification?

Thank you very much for your interest and insights in our application @Noc2 !

While Deitos Network shares similarities with platforms such as Crust, Arweave, and IPFS, our primary focus is distinct. We emphasize the processing, structuring, and utilization of data. Our direction leans more towards Big Data and AI functionalities than acting as a descentralized storage service.

Though storage is a crucial component, it's not our sole emphasis. Currently, our efforts for this grant are channeled towards the foundational aspects of Infrastructure Providers and Consumers, with a significant focus on storage. As we progress, we intend to extend the agreement between Providers/Consumers with computational resources (such as vCPU and RAM), besides the storage services. Additionally, we plan to add more components to our security framework with advanced privacy features. However these two phases will not be part of the deliverables included in this grant.

One concern I always had in regard to Arweave is that you don't have strong incentives to share the actual data with others (at least from my last understanding). The primary lure seems to be sharing data identifiers to earn rewards. How do you intend to navigate this issue?

Regarding your observation on Arweave: You've pinpointed a valid concern. Certain platforms may lack compelling incentives to promote data sharing among users. However, for Deitos Network, our objective isn't necessarily broad data sharing among all participants. Our model aims to facilitate a collaborative yet private interaction between Infrastructure Providers and Consumers, all under the Deitos Network umbrella. This approach not only diversifies the options available to consumers but also fosters healthy competition among Providers. This is a stark contrast to the present scenario where a handful of dominant entities, such as AWS and Google Cloud.

It's important to highlight that we haven't established any specific policies or incentive mechanisms for data sharing among actors. This omission is intentional given that the data analysis industry frequently deals with sensitive and private information, where stakeholders typically prefer it not be shared or publicly exposed. The configuration for the infrastructure provider will encrypt data by default. However, within our protocol design, we're considering the possibility of providers holding public data as an open service, encouraging contributions to datasets or raw files.

Distinctly, a primary divergence between our model and existing decentralized storage solutions like Arweave or IPFS is that once the agreed-upon duration between the infrastructure provider and the consumer expires, the data is deleted. This action ensures that providers can liberate their storage space for other consumers' utilization.

Moreover, with minor adjustments, the toolset for data scientists remains largely unchanged. This means they won't be burdened with learning specialized software to access and use the data.

Could you add more technical details to the milestone specification?

This is a refined specification of the milestones, enhanced with additional technical details. Please consider that certain implementation specifics are left out as they might change during the development process. Could you please confirm if this aligns with your expectations? Once confirmed, I'll move forward with updating the PR content:

Milestone 1 — Initial setup and infrastructure provider pallet.

• Estimated duration: 6 weeks
• FTE: 3
• Costs: 15,000 USD

Number	Deliverable	Specification
0a.	License	The project will utilize the Apache 2.0 license.
0b.	Documentation	Given that this milestone doesn’t encompass a UI or client interface, comprehensive user guidelines will be provided. These guidelines will detail how to initiate the network and interact with the modules developed in this milestone.
1.	Substrate Node with BABE consensus	1) Reconfiguration of the node to employ the BABE consensus protocol in place of the Aura consensus. 2) Integration of the respective VRF setup for BABE consensus. 3) Proper configurations on the node side like integrating the BabeBlockImport, initiating BABE workers, and setting inherents from sp_consensus_babe on the node service.rs file beyond just embedding the pallet-babe in the runtime
2.	Pallet Deitos foundation (pallet-deitos)	1) Introduction of foundational elements of the pallet, incorporating storage items for cataloging Provider data, the specifics of agreements between Providers and Consumers, the reputation system and the data integrity protocol. 2) Framework scaffolding for future enhancements. 3) Groundwork for the data integrity protocol to be executed by this pallet's off-chain worker.
3.	Registration of Infrastructure Provider (pallet-deitos)	1) Mechanism for infrastructure provider registration within the pallet-deitos. 2) Requirement of reserving a certain amount of funds. 3) Groundwork for attestation process initiation for new entrants. This will be completed in the next milestone with the data integrity protocol.
4.	Agreements Module (pallet-deitos)	1) Functionality to define agreements between users and infrastructure providers. 2) Outline of storage quotas and its duration based on block by block reward dynamics. 3) Introduction of pertinent extrinsics, storage components, and events for agreements. 4) Mechanism where the consumer reserves a value based on the agreement's terms, leveraging either the ReservedCurrency trait from pallet-balances or the MutateHold trait from Fungibles depending of the pallet-balances migration status.
5.	Agreements termination and on-chain reputation (pallet-deitos)	1) Termination agreement procedure where consumer's data and corresponding resources get free from the infrastructure provider. 2) Data Integrity protocol clean up. 3) On chain reputation module based on feedback from the other party.
6.	Docker file	1) Provision of a comprehensive Docker file encapsulating all essential services. 2) Streamlined deployment of services: Hadoop, Spark, Hive, YARN, Llama v2, and the substrate node. 3) A docker-compose file to simplify onboarding and integration for providers.

Milestone 2 — Proxy, file uploader and data integrity protocol.

• Estimated duration: 6 weeks
• FTE: 3
• Costs: 15,000 USD

Number	Deliverable	Specification
0a.	License	The project will utilize the Apache 2.0 license.
0b.	Documentation	Building upon the documentation provided in the first milestone, this milestone will introduce a new set of user guidelines. These guidelines will detail the steps necessary to interact with the modules introduced in this phase.
1.	Proxy Development	1) Complete development and deployment of the described proxy ensuring interaction between infrastructure providers, consumers and the substrate node. 2) Mechanism to reserve resources on the infrastructure provider for a consumer upon agreement commitment. 3) A system focused on storage where user segmentation is achieved through dynamic users generated on Hadoop. 4) Authentication derived from a signed transaction initiated by the pallet-deitos pallet. 5) Development of a module to validate consumer signatures and commit actions upon successful verification, ensuring no traditional passwords are stored in the system.
2.	File Uploads (Client Interface)	1) Delivery of a client interface to facilitate file content splitting and hash calculation. 2) Creation of a generic algorithm to uniformly split files and calculate segment hashes. 3) Mechanism for producing and publishing signed transactions reflecting the computed results.
3.	File Upload Verification (Provider Side)	1) Using the previously generic algorithm to uniformly split files and calculate segment hashes for each file or part upon receiving the consumer's signed transaction. Files are marked as 'verified' post successful hash validation. 3) Constant monitoring of blocks to detect unverified files, triggering an OCW for hash verification based on consumer transactions.
4.	Data Integrity Protocol	1) Comprehensive development and deployment of the Data Integrity Protocol. 2) Utilizing BABE-generated randomness to select files/parts, directing infrastructure providers to create and validate respective hashes. 3) In case of hash mismatches during the data integrity protocol, a system to penalize the provider by reducing their staked amount.

Milestone 3 — Disputes resolving and protocol documentation.

• Estimated duration: 4 weeks
• FTE: 3
• Costs: 10,000 USD

Number	Deliverable	Specification
0a.	License	The project will utilize the Apache 2.0 license.
0b.	Documentation	As the grant approaches its conclusion and all implementation details are settled, we will provide thorough protocol documentation.
1.	Dispute Resolution Committee	1) Use pallet-collectives to establish a specific collective for the resolution committee. 2) Introduce a candidate proposal mechanism for community voting and selection. 3) Onboard and remove committee members based on voting outcomes.
2.	Dispute Triggers (pallet-disputes)	1) Enable providers/consumers to initiate disputes. 2) Implement a system to adjudicate disputes.
3.	Dispute Resolution (pallet-disputes)	1) Introduce a voting system for the committee to resolve disputes in favor of or against the prevailing party. 2) Develop mechanisms for punishments and rewards based on dispute resolution outcomes. 3) Establish a reward system to compensate the committee for their efforts in handling the case.
4.	Benchmarking	1) Establish benchmarks for all the extrinsics in all the pallets.
5.	Testing and Testing Guide	This milestone will deliver the necessary tools to establish a local testing environment, allowing for comprehensive testing of all functionalities.

[Noc2]

Thanks for the update and the detailed reply. Feel free to integrate these details into the application. If I understand you correctly, your solution will rely mostly on a Dispute Resolution Committee and/or the on-chain reputation system. Have you already looked into potential attacks of such systems and how to address these?

[Ernih]

Hello @Noc2!

Thank you for your feedback and your insightful question.

As agreed, we have updated the milestones section with all the technical details.

If I understand you correctly, your solution will rely mostly on a Dispute Resolution Committee and/or the on-chain reputation system. Have you already looked into potential attacks of such systems and how to address these?

When considering dispute resolution and on-chain reputation systems, we analyzed scenarios like collusion and reputation gaming manipulation which could affect the fairness of dispute resolution processes and the accuracy of reputation scores.

For the on-chain reputation system, it's noteworthy that scoring for a provider/consumer can only occur after the agreement has concluded and if no disputes arose during the agreement. This design makes Sybil attacks, where a group aims to prejudice an actor, costly and time-consuming as multiple agreements are a prerequisite. Although not foolproof, this design mitigates some risks associated with reputation manipulation.

It's crucial to note that while our governance model is still in the design phase, the overarching goal for Deitos is to establish a decentralized governance system. We're looking to draw significant inspiration from Polkadot's Referendum chamber, aiming to embody a community-driven decision-making and decentralized approach.

Regarding dispute resolution, our vision is that if the Dispute Resolution Committee is found to be acting inappropriately, the aggrieved party can escalate the case to a Referendum. However, this step is not encouraged within Deitos network actors due to the costly coordination and discussion it requires among all token holders. Escalation to a referendum necessitates a significant amount of locked tokens (configurable and adjustable by Referendum) and is only permissible within a specified timeframe post-dispute resolution. Post this period, escalation to a referendum is disallowed. This entire mechanism will be cautiously implemented once the governance model of the network is designed, agreed upon and implemented, given the tight relationship between these two components.

At present, our primary objective in this initial project stage is to assemble all protocol components, meticulously measure, and validate our assumptions for optimal functionality. We observe parallels with Polkadot's iterative evolution concerning governance and collective roles. Currently, our dispute resolution module and on-chain reputation system are initial proposals, subject to refinement as the project progresses.

[Noc2]

Thanks again for the update. In this case, removing the last milestone for now might make sense. This way, it's also only a level 2 grant. Apart from this, I have one more question before I share it with the rest of the team: Usually, the deliverables 0c and 0d. as well as 0e. for the last milestone of our template are mandatory. Could you add them again to the application or provide a reason why you removed them?

[Ernih]

Hello David! Thanks again for your message.

In this case, removing the last milestone for now might make sense. This way, it's also only a level 2 grant.

Understood. We think your advice is very valid and we've decided to remove the milestone related to the Dispute protocol and downgrade the current grant to Level 2 as suggested.

Since the disputes protocol is a key part in our design, we are sure that the development of this protocol could be tackled in future grants after the successful delivery of this grant.

Apart from this, I have one more question before I share it with the rest of the team: Usually, the deliverables 0c and 0d. as well as 0e. for the last milestone of our template are mandatory. Could you add them again to the application or provide a reason why you removed them?

We have updated the deliverables items 0(a/b/c/d) for both milestones according to the template provided. Also the 0e was added for the second and last milestone as well.

Please let us know if any other remaining topic should be discussed or addressed. We would be more than pleased to answer them.

Thanks.

[takahser]

@Ernih thanks, that looks interesting. However, I've got a couple of questions as well:

• What's the "YARN" component in the storage section of the architecture diagram about? Are you referring to the yarn dependency tool or something else here?
• We've recently signed a similar grant, could you compare your scope to theirs and add the analysis to the proposal? Also, it'd be good if the market analysis would include Arweave as well, so feel free to integrate what's been discussed into this proposal.
• Do you require the infrastructure provider to run some kind of service that measures certain metrics, like uptime, workload, specs, etc. on the host machine? Or how would the dispute resolver committee be able to fairly resolve conflicts? For example, the consumers could just rent a bunch of computation power and (for example) after 80% of the rental period complain that there is a breach of contract and request a refund, although there was non and their model already has been trained successfully. How would you prevent or mitigate such a scenario? I assume, the consumer doesn't need to have a reputation to start renting, right? And if that's wrong, how would he reach it and at what cost?
• What are "block by block reward dynamics"?

  Outline of storage quotas and its duration based on block by block reward dynamics

• Are any restrictions imposed in terms of the data, tools, or ML workflows that consumers can bring and run as per their specific use cases? For example, you mention Spark and Llama, but what if a consumer wants to use TensorFlow or PyTorch instead?

[Ernih]

Hello @takahser,

We appreciate your interest in the application. Below you have the answers for your questions:

What's the "YARN" component in the storage section of the architecture diagram about? Are you referring to the yarn dependency tool or something else here?

Actually, the YARN in our context is not the JavaScript package manager, but it does share the same acronym. We're referring to Apache Hadoop YARN (Yet Another Resource Negotiator).

Apache Hadoop YARN is the resource management and job scheduling technology in the Hadoop Distributed Processing Framework. As one of the core components of Apache Hadoop, YARN is responsible for allocating system resources to the various applications running in a Hadoop cluster and scheduling tasks to run on different cluster nodes.

We've recently signed a similar grant, could you compare your scope to theirs and add the analysis to the proposal?

Given the limited details available from the project described in their grant, an in-depth comparison is challenging. Nonetheless, based on the grant information, it appears there are parallels in terms of decentralizing machine learning model training, where rewards are based on data model training contributions and parameter adjustments by governance.

Our approach, however, adopts a distinct architecture and game theory strategy. We focus on infrastructure providers offering private services, competing to deliver optimal solutions to consumers. In future developments, these providers may also engage in maintaining and utilizing a shared public dataset, rewarded for hosting this data and processing consumer requests. This aspect, though, is not covered in the current grant scope as previously mentioned.

Another difference is that our project is not only related to machine learning or AI, but also provides business intelligence capabilities such as data analytics, predictive modeling, and customized reporting. These features enable businesses to gain deeper insights from their data, supporting more informed decision-making and strategic planning.

Also, it'd be good if the market analysis would include Arweave as well, so feel free to integrate what's been discussed into this proposal.

Acknowledged. We've included a supplementary section on Arweave in the proposal, specifically addressing the distributed storage aspect of our project. While there are overlaps between Arweave and Deitos, it's important to note that Deitos is primarily geared towards processing and training data. In contrast, Arweave's focus is predominantly on distributed storage solutions.

Do you require the infrastructure provider to run some kind of service that measures certain metrics, like uptime, workload, specs, etc. on the host machine? Or how would the dispute resolver committee be able to fairly resolve conflicts? For example, the consumers could just rent a bunch of computation power and (for example) after 80% of the rental period complain that there is a breach of contract and request a refund, although there was non and their model already has been trained successfully. How would you prevent or mitigate such a scenario? I assume, the consumer doesn't need to have a reputation to start renting, right? And if that's wrong, how would he reach it and at what cost?

Your question raises key concerns about fairness and conflict resolution in computational resource rental scenarios.

Apache Hadoop YARN will play a key role by providing logs of resource usage, which can be accessed by the Dispute Resolution Committee to inform their decisions. This grant is primarily focused on developing the storage layer and establishing the foundational data model, encompassing elements like network actor registration, agreement mechanisms, and data integrity protocols.
Details about the Dispute Resolution mechanism, vital for mediating conflicts, will be covered in a future grant application as per @Noc2's request.

The development stages envisioned for the network are as follows:

1. Development of the storage layer and data model foundations, which is the current grant's focus.
2. Addition of the execution aspects for agreements and the dispute resolution mechanism.
3. Implementation of security measures such as infrastructure provider attestation to ensure execution integrity and reliability.

The execution aspect in this application is highlighted to provide a clear roadmap towards achieving the first usable version of the protocol. This aspect is a crucial element of the project's second stage of development.

What are "block by block reward dynamics"?
Outline of storage quotas and its duration based on block by block reward dynamics

"Block by block reward dynamics" refers to the mechanism where the reward for infrastructure providers is allocated per block, based on the terms of an agreement with a consumer. For instance, in a scenario where a consumer and an infrastructure provider agree on a resource rental for 144,000 blocks (equivalent to roughly 10 days at a 6-second block time) at a total cost of 10,000 tokens, the provider would earn approximately 0.069444444444 tokens per block. As the project progresses, we anticipate refining and optimizing this mechanism to reduce computational costs while maintaining its effectiveness.

Are any restrictions imposed in terms of the data, tools, or ML workflows that consumers can bring and run as per their specific use cases? For example, you mention Spark and Llama, but what if a consumer wants to use TensorFlow or PyTorch instead?

The technology stack available on infrastructure providers is determined by the network to facilitate environment attestation, ensuring applications run as expected. This control is necessary to prevent issues like misreporting of resource allocation. However, if there's a community demand for additional tools like TensorFlow, the process involves raising the issue, discussing it within the network governance, and reaching a consensus. Once agreed upon, the integration and attestation of the new application are developed, allowing it to be included in the official tech stack.

Please let us know if there are any additional topics that need to be discussed or addressed. If there are no further concerns, our team is eager to commence work on the milestones and make a meaningful contribution to the ecosystem.

[takahser]

@Ernih thanks for your detailed answers, that's very helpful.

Your question raises key concerns about fairness and conflict resolution in computational resource rental scenarios.

Apache Hadoop YARN will play a key role by providing logs of resource usage, which can be accessed by the Dispute Resolution Committee to inform their decisions. This grant is primarily focused on developing the storage layer and establishing the foundational data model, encompassing elements like network actor registration, agreement mechanisms, and data integrity protocols.
Details about the Dispute Resolution mechanism, vital for mediating conflicts, will be covered in a future grant application as per @Noc2's request.

The development stages envisioned for the network are as follows:

1. Development of the storage layer and data model foundations, which is the current grant's focus.
2. Addition of the execution aspects for agreements and the dispute resolution mechanism.
3. Implementation of security measures such as infrastructure provider attestation to ensure execution integrity and reliability.

The execution aspect in this application is highlighted to provide a clear roadmap towards achieving the first usable version of the protocol. This aspect is a crucial element of the project's second stage of development.

Could you integrate this information into the proposal, maybe into the Mid-Term Plans section?

Given the limited details available from the project described in their grant, an in-depth comparison is challenging. Nonetheless, based on the grant information, it appears there are parallels in terms of decentralizing machine learning model training, where rewards are based on data model training contributions and parameter adjustments by governance.

Could you integrate this part as well? I think it'd be useful for other readers to be aware of this, even if you're not planning to make an in-depth comparison.

Considering the comprehensive nature and the interesting use case of your grant proposal, along with @kalaninja's proven expertise as evidenced in the previous grant for the substrate java client I'm fine with adding my approval to this proposal, once you've integrated the missing information. Meanwhile, I'll mark it as ready for review and share it with the rest of the committee.

[Ernih]

Thank you very much @takahser! The latest information we discussed has been incorporated into the application as suggested. We agree that the application now appears much more informative following all the feedback we've received. Please let us know us if there's anything else we need to do on our end.

[takahser]

Thx, I added 2 more inline comments, other than that LGTM.

[Ernih]

Thx, I added 2 more inline comments, other than that LGTM.

Hello @takahser ! we have merged your inline comments and as the content of the PR was changed, your approval has gone. Could you please re-approve?

Thanks.

[keeganquigley]

Thanks @Ernih for your thorough answers, and for the deep dives @Noc2 @takahser this proposal looks really interesting and I don't have further questions so I'm happy to support it as well.

[Ernih]

Thank you very much, @takahser, @Noc2, and @keeganquigley, for your valuable feedback, support, and approval of this application. We understand that we have now achieved the required number of approvals, is that correct?

I would like to point out that the PR currently indicates that at least 5 approvals are needed for merging this application. This might be due to the initial submission being for a level 3 grant, which required 5 approvals. I'm unsure if any manual intervention is needed for this specific case.

Please let us know if there's any further action required from our side.

[github-actions]

Congratulations and welcome to the Web3 Foundation Grants Program! Please refer to our Milestone Delivery repository for instructions on how to submit milestones and invoices, our FAQ for frequently asked questions and the support section of our README for more ways to find answers to your questions.

Before you start, take a moment to read through our announcement guidelines for all communications related to the grant or make them known to the right person in your organisation. In particular, please don't announce the grant publicly before at least the first milestone of your project has been approved. At that point or shortly before, you can get in touch with us at [email protected] and we'll be happy to collaborate on an announcement about the work you’re doing.

Lastly, please remember to let us know in case you run into any delays or deviate from the deliverables in your application. You can either leave a comment here or directly request to amend your application via PR. We wish you luck with your project! 🚀

[Ernih]

Hello everyone, we are excited to announce that Hector Bulgarini (@hbulgarini) has recently joined the Deitos Network team in a leadership role.

If any action is needed to update the team information for the grant, please let us know.

Thank you.

[takahser]

@Ernih thanks for letting us know. It'd be good if you could amend the proposal accordingly. The approval process is the same as for the initial approval, but more minor changes (like this one) are usually very easy to approve, hence the approval duration can expected to be much shorter.

[Ernih]

@Ernih thanks for letting us know. It'd be good if you could amend the proposal accordingly. The approval process is the same as for the initial approval, but more minor changes (like this one) are usually very easy to approve, hence the approval duration can expected to be much shorter.

No problem, we are happy to do whatever is required to reflect the change.
Should we create a PR to the already merged application so we add Hector in the team?

[takahser]

@Ernih yes, that would be the best way forward. 👍 You can find more info about amendments on our README, but feel free to ping me here in case you have specific questions.

[hbulgarini]

Hello @Noc2, @takahser, @keeganquigley,

We're reaching out to inform you that the Deitos team's operations were limited over the holiday period. As a result, we'll be delivering Milestone 1 on January 10th.

Thank you for your understanding!

[takahser]

@hbulgarini thanks for the heads-up; that's no problem at all. Happy new year to you and the team!

[hbulgarini]

Hello @Noc2, @takahser, @keeganquigley,

We have conducted research on licensing and we are considering adopting the GPLv3 license for all work related to the Deitos Network. Additionally, we have observed that this license is the preferred choice among parachain teams.

Given that Apache v2 was specified in the application, we would like to inquire whether the grant program permits the delivery of milestones and code under the GPLv3 license.

Thank you!

[takahser]

@hbulgarini changing the license to GPLv3 is not a problem, since it's one of our supported licenses. However, it'd be good if you could make an amendment PR, where you update the license in your milestone deliverables. This kind of amendment is usually merged rather quickly.

[hbulgarini]

@hbulgarini changing the license to GPLv3 is not a problem, since it's one of our supported licenses. However, it'd be good if you could make an amendment PR, where you update the license in your milestone deliverables. This kind of amendment is usually merged rather quickly.

Thank you @takahser for the answer! @Ernih will proceed with the amendment PR.

[Ernih]

@hbulgarini changing the license to GPLv3 is not a problem, since it's one of our supported licenses. However, it'd be good if you could make an amendment PR, where you update the license in your milestone deliverables. This kind of amendment is usually merged rather quickly.

#2171