[Token-all] FW: [Token] Important issues with D6.3

[Carlo Harpes]

Dear Token Partner,

The main object of this delivery is according to the statement of work: "Definition of the legal vehicle to evolve and maintain BCPaaS"

We have been less active on the governance report since we first draw it, but notice that by the end of the project, we received little input on how the different partner indent to evolve and maintain the result after the project.
That's why it is essential that the next plenary take a clear decision on this.

We try to summarise the situation from our intuitive understanding. Feel free to clarify this, but ideally NOT in an email answer, but as a contribution to the D6.2. introduction delivery:

The original hope was (and maybe still is) that project partner will join a legal entity that feels responsible to support the project outcomes after the project. Even it the outcome are published as Open Source, this entity comes with an economic model, including governance rule (to be defined in D6.3) to ensure continuous use and maintenance of the project outcomes.

However, to create this entity, we need commitments: Which partner is willing to invest with resources (time, money), in these activities (and based on which rationale . what are their expected outcomes).
These entities have to lead us though the open questions of D6.3, and Infrachain mainly can acts as Consultant, but not as decision maker for the content of a governance.
As next input, we need a list of commitment and other partners.

Plan B: If such an entity is NOT created (due to lake of interest or commitment by the partner or success of the current tools, the document may collapse to a general document on how open-source can be maintained on the individual (or multiparty) interest, by benevolent contributions, without a legal entity in charge...

In this case each partner should give us a written (as long as possible) statement on how he intends to maintain his contribution to the project. Can we get this by mid of December at latest?

Infrachain needs to know in which direction to finalize the report. That's why a decision (based on partners' commitment in case of option 1), ideally at the meeting next Thursday is needed.

For more info, see:
https://docs.google.com/document/d/1arjE9QianN8vGmO7pRh2tgw9dmpkeAj1/edit?usp=share_link&ouid=105858417297487388990&rtpof=true&sd=true
on page:
https://drive.google.com/drive/folders/110DQeMQ-YB08WJWTLVD64mHZQObCaEaz

Plan C:
As there is no legal entity, Uwe uni.lu) suggest creating a kind of decision tree when setting up a DLT project (and thus not to focus on the maintenance of our BCPaaS) but on governance of DLT projects in general.
I like to get your decision, whether you agree on this, and if yes, who can contribute to this (because this significantly deviates from our objectives, and we need to bear the risk of reviewers' criticism jointly. However, if the project fails to create such a legal entity, why describing its governance, and not do something similar and useful...

Here is Uwe's detailed suggestions:

"Why not see all your work (main document plus supporting documents) as a source of modules and building blocks, without making assumptions on blockchain consortia, open-source consortia, or other types of structures.

With questions that you ask at the beginning of the document, you decide on which modules or building blocks someone would need to setup the legal organizational framework and to provide the paragraphs of the laws that they must consider and the tests that the legal entity must execute to be compliant with standards. Not all GDPR, NIS laws are relevant in all cases. The same for the questions of the ISO standard. It would help to know only the relevant, depending on the case of governance.

Questions could be like these questions (likely not complete):


  *   Do you plan to govern the TOKEN platform as a service? If yes: Use these modules from the main document and test these modules from the supporting documents : [list of modules, list of paragraphs of NIS/GDRP, list of tests of standard]
     *   Do you plan to manage the underlying blockchain as a consortium blockchain: If yes: [list]
     *   Do you plan to include additional external partners in your consortium blockchain: If yes: [list]
     *   ...


  *   Do you plan to govern/publish the TOKEN software/PUC software as open source? If yes: [list]
     *   Do you plan to manage the software as an open-source project? If yes: [list]
     *   Do you plan to manage an open-source community with external partners: If yes: : [list]
     *   ...


  *   Do you plan to govern your PUC? platform ? If yes: [list]
     *   Do you use a TOKEN service in your PUC: ? If yes: [list]
     *   Do you use the TOKEN service as a third-party service:  If yes: [list]
     *   Do you setup your own TOKEN service platform:  If yes: [list]
        *   Do you plan to manage the underlying blockchain as a consortium blockchain: If yes: [list]
        *   Do you plan to include additional external partners in your consortium blockchain: If yes: [list]
     *   Do you use additional blockchain in your PUC? If yes: [list]
     *   Do you plan to manage one of these blockchain as a consortium blockchain: If yes: : [list]
     *   Do you plan to include additional partners in your consortium blockchain: If yes: : [list]
     *   ...

With such a decision tree, you would provide all options to those who want to govern the results of TOKEN, but you would not have to figure out, if and how they actually want to do it."

Thanks for early feedback, and you final point of view in the meeting on Thursday,
Carlo


PS: Reminder: Extract from the Proposal relate to the content of this document
The aim of this task is to define the rules that will guide the evolution and maintenance of the TOKEN
BCPaaS beyond the project. This includes the definition of the legal vehicle that should handle the ownership of the
TOKEN BCPaaS beyond the project. At the moment of proposal submission, we envision that a TOKEN Association
will be established as the body that will handle the operations beyond the project. This will be an independent NGO to
support the community and network activities of the project. To enable this activity a bylaw will be created establishing
the founding members and the rights and obligations of the different types of membership as well as the rules to decide
on the technical evolution of the technological stack that will work as a DAO (Decentralized Autonomous Organization).
These members will be public organizations and public service operators, who will deploy Validator Nodes or Regular
Nodes within the TOKEN BCPaaS. Other routes for shaping a formal body that will take care of the TOKEN BCPaaS
beyond the project, like joining an existing body or establishing a MoU, will also be explored during the execution of
this task. The implementation of this task will lead to the definition of the TOKEN Governance Model [D.6.3.]
INF will lead the task bringing knowledge and experience in establishing governance rules and associations on DLT
systems, under the leadersship of Linked Third Party ITR and involving othr INF Linked Third Parties (SNT, SCO). ALL
the partners will contribute to this task by participating in one dedicated session, in the context of workshop organised by
FBR to discuss BCPaaS Business & Governance Models (See Task 6.2) (M18) and 2 webinars (M24, M32) organized

by INF (Linked Third Party: ITR) for discussing and validating the Governance Model beyond the project.

(...)
D6.3. TOKEN Governance Model. Definition of the legal vehicle to evolve and maintain BCPaaS; INF (Led by

Linked Third Party ITR, including multiple contributions); M34

(...)

D6.3. Definition of the legal vehicle to evolve and maintain BCPaaS.

___________________________________________
Carlo Harpes
Managing Director
itrust consulting s.à r.l.

Office building: 55, rue Gabriel Lippmann L-6947 Niederanven
Phone: +352 2617 6212 (Reception)
mobile: +352 621  45 19 45
Headquarter: 18, Steekaul;  L-6831 Berbourg
Web:     www.itrust.lu<http://www.itrust.lu/>
mailto:  harpes at itrust.lu<mailto:harpes at itrust.lu>
r.c. lux B123183 - VAT: LU 21534655
___________________________________________
This message is restricted and may contain personal data; any unauthorized disclosure, use or dissemination, either whole or partial, is prohibited.
If you are not the intended recipient of the message, please notify the sender immediately.
itrust consulting s.à r.l. does not accept liability for any errors, omissions or even commitment in the contents of this message, except where supported by a written agreement with the receiver.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/token-all/attachments/20221128/78d23d6a/attachment-0001.html>