Common use of AS WITNESS Clause in Contracts

AS WITNESS. The Parties have caused this Consortium Agreement to be duly signed by the undersigned authorised representatives in separate signature pages the day and year first above written. It is too impractical for all Parties to sign the same document at the same time. The procedure proposed for the signatures is widely used: Each Party signs a separate signature page as many times as there are Parties (it is also possible to sign only 1 or 2 originals as only one fully signed copy is necessary according to Belgian Law). The Coordinator gathers all originals and then delivers the whole package consisting of the text and all signatures (original or copies) to all Parties. [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [Attachment 1: Background included] According to the Grant Agreement (Article 24) Background is defined as “data, know-how or information (…) that is needed to implement the action or exploit the results”. Because of this need, Access Rights have to be granted in principle, but parties must identify and agree amongst them on the Background for the project. This is the purpose of this attachment. !! Beware – Attachment 1 is a vital document – check what your project partners are listing and (more importantly) not listing!! Earlier framework programmes required the parties to define Background and to make any exclusions "specific". This was translated into the Consortium Agreements by having Background exclusion lists, mostly in addition to the list of Background Included. The new MGA for H2020 obliges the parties to “identify and agree” upon the Background for the Project. Therefore, DESCA2020 proposes to work with actively listed Background. It is the responsibility of the parties to make this ‘agreement on Background’. It seems reasonable to expect that if parties know of a specific need for access rights to specific Background, they will be able to identify this up front (potentially with limitations). In any case, such a duty to inform is explicitly mentioned in Article 25.2 and 25.3 of the MGA) and this information needs to be shared before accession to the GA. The counterpart of working with a positive list is that the parties fully accept that anything not listed simply IS no Background, and that therefore, there is no reason to “exclude” it. That is the reason why there is no need any more to explicitly exclude background in Attachment 1 such as the background of research units not involved in the Project as was usual in FP7 Consortium Agreements. PARTY 1 As to [NAME OF THE PARTY], it is agreed between the parties that, to the best of their knowledge (please choose),

AS WITNESS. The Parties have caused this Consortium Agreement to be duly signed by the undersigned authorised representatives in separate signature pages the day and year first above written. [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [It is too impractical recommended to insert a new page for all Parties to sign the same document at the same time. The procedure proposed for the signatures is widely used: Each Party signs a separate signature page as many times as there are Parties (it is also possible to sign only 1 or 2 originals as only one fully signed copy is necessary according to Belgian Law). The Coordinator gathers all originals and then delivers the whole package consisting of the text and all signatures (original or copies) to all Parties. each signature.] [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [Attachment 1: Background included] included According to the Grant Agreement (Article 2416.1) Background is defined as “data, know-how or information (…) that is (…) needed to implement the action Action or exploit the results”. Because of this need, Access Rights have to be granted in principle, but parties Parties must identify and agree amongst them on the Background for the projectProject. This is the purpose of this attachment. !! Beware – Attachment 1 is a vital document – check what your project partners are listing and (more importantly) not listing!! Earlier framework programmes required the parties to define Background and to make any exclusions "specific". This was translated into the Consortium Agreements by having Background exclusion lists, mostly in addition to the list of Background Included. The new MGA for H2020 obliges the parties to “identify and agree” upon the Background for the Project. Therefore, DESCA2020 proposes to work with actively listed Background. It is the responsibility of the parties to make this ‘agreement on Background’. It seems reasonable to expect that if parties know of a specific need for access rights to specific Background, they will be able to identify this up front (potentially with limitations). In any case, such a duty to inform is explicitly mentioned in Article 25.2 and 25.3 of the MGA) and this information needs to be shared before accession to the GA. The counterpart of working with a positive list is that the parties fully accept that anything not listed simply IS no Background, and that therefore, there is no reason to “exclude” it. That is the reason why there is no need any more to explicitly exclude background in Attachment 1 such as the background of research units not involved in the Project as was usual in FP7 Consortium Agreements. PARTY 1 As to [NAME OF THE PARTY], it is agreed between the parties Parties that, to the best of their knowledge knowledge, [insert the relevant option here]. [Option 1 start] the following Background is xxxxxx identified and agreed upon for the Project. Specific limitations and/or conditions, shall be as mentioned hereunder: Describe Background Specific restrictions and/or conditions for implementation (please chooseArticle 16.4 Grant Agreement and its Annex 5, Section “Access rights to results and background”, sub-section “Access rights to background and results for implementing the Action”) Specific restrictions and/or conditions for Exploitation (Article 16.4 Grant Agreement and its Annex 5, Section “Access rights to results and background”, sub-section “Access rights for exploiting the results”) [Option 1 end] [Option 2 start] Option 2: No data, know-how or information of [NAME OF THE PARTY] is Needed by another Party for implementation of the Project (Article 16.1 and its Annex 5 Grant Agreement, Section “Access rights to results and background”, sub-section “Access rights to background and results for implementing the action”) or Exploitation of that other Party’s Results (Article 16.1 and its Annex 5 Grant Agreement, Section “Access rights to results and background”, sub-section “Access rights for exploiting the results”),. [Option 2 end] This represents the status at the time of signature of this Consortium Agreement. [Same for PARTY 2, PARTY 3, etc] Attachment 2: Accession document ACCESSION of a new Party to [Acronym of the Project] Consortium Agreement, version […, YYYY-MM-DD] [OFFICIAL NAME OF THE NEW PARTY AS IDENTIFIED IN THE Grant Agreement] hereby consents to become a Party to the Consortium Agreement identified above and accepts all the rights and obligations of a Party starting [date]. [OFFICIAL NAME OF THE COORDINATOR AS IDENTIFIED IN THE Grant Agreement] hereby certifies that the consortium has accepted in the meeting held on [date] the accession of [the name of the new Party] to the consortium starting [date]. This Accession document has been done in 2 originals to be duly signed by the undersigned authorised representatives. [Date and Place] [INSERT NAME OF THE NEW PARTY] Signature(s) Name(s) Title(s) [Date and Place] [INSERT NAME OF THE COORDINATOR] Signature(s) Name(s) Title(s) Attachment 3: List of third parties for simplified transfer according to Section 8.3.2. [Option: Attachment 4: Identified entities under the same control according to Section 9.5] [Option: Attachment 5: NDA for External Expert Advisory Board agreed under Section 6] [Option: Module GOV LP] Governance structure for Medium and Large Projects [To use the following paragraphs it is recommended to do as follows:

AS WITNESS. The Parties have caused this Consortium Agreement PCA to be duly signed by the undersigned authorised representatives in separate signature pages causing this Agreement to be in effect as from the day and year first above writtenEffective Date. It is too impractical for all Parties to sign The signature of a Party via a scanned or digitized image of a handwritten signature (e.g. scan in PDF format) or an electronic signature (e.g. via AdobeSign), shall have the same document at the same time. The procedure proposed force and effect as an original handwritten signature for the signatures is widely used: purposes of validity, enforceability and admissibility. Each Party signs receives a separate signature page as many times as there are Parties (it is also possible to sign only 1 or 2 originals as only one fully signed copy is necessary according to Belgian Law)of this PCA. The Coordinator gathers all originals and then delivers the whole package consisting Delivery of the text fully signed copy via e-mail or via an electronic signature system shall have the same force and all signatures (legal effect as delivery of an original or copies) to all Partieshard copy of the PCA. [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [Attachment 11A: Background includedincluded [Retain or Delete as per Section 9.1 of this PCA, dependent on Option selected] According to It is agreed between the Grant Agreement (Article 24) Background is defined as “Parties that the following data, information or know-how or information (…) that is needed to implement the action or exploit the results”. Because of this need, Access Rights have to be granted in principle, but parties must identify and agree amongst them on the Background for the project. This is the purpose of this attachment. !! Beware – Attachment 1 is a vital document – check what your project partners are listing and (more importantly) not listing!! Earlier framework programmes required the parties to define Background and to make any exclusions "specific". This was translated introduced by [NAME OF THE PARTY] into the Consortium Agreements by having Action as Background exclusion lists, mostly in addition Describe Background included Specific limitations and/or conditions for implementation (Article 16.1 with reference to Annex 5 of the list Grant Agreement) (if any) Specific limitations and/or conditions for Exploitation (Article 16.1 with reference to Annex 5 of Background Included. The new MGA for H2020 obliges the parties to “identify and agree” upon the Background for the Project. Therefore, DESCA2020 proposes to work with actively listed Background. Grant Agreement) (if any) … … … … … … It is agreed between the responsibility of the parties to make this ‘agreement on Background’. It seems reasonable to expect that if parties know of a specific need for access rights to specific Background, they will be able to identify this up front (potentially with limitations). In any case, such a duty to inform is explicitly mentioned in Article 25.2 and 25.3 of the MGA) and this information needs to be shared before accession to the GA. The counterpart of working with a positive list is Parties that the parties fully accept that anything not listed simply IS no Backgroundfollowing data, and that therefore, there information or know-how is no reason to “exclude” it. That is the reason why there is no need any more to explicitly exclude background in Attachment 1 such as the background of research units not involved in the Project as was usual in FP7 Consortium Agreements. PARTY 1 As to introduced by [NAME OF THE PARTY], it into the Action as Background Describe Background included Specific limitations and/or conditions for implementation (Article 16.1 with reference to Annex 5 of the Grant Agreement) (if any) Specific limitations and/or conditions for Exploitation (Article 16.1 with reference to Annex 5 of the Grant Agreement) (if any) … … … … … … Attachment 1B: Background excluded [Retain or Delete as per Section 9.1 dependent on Option selected] It is agreed between the parties Parties that, the following data, information or know-how is excluded from Background as referred to in Section 9.1.1 [NAME OF THE PARTY] Describe Background excluded (if any) … … It is agreed between the Parties that, the following data, information or know-how is excluded from Backghround, as referred to in Section 9.1.1 [NAME OF THE PARTY Describe Background excluded (if any) … … Attachment 2: Declaration of Accession DECLARATION OF ACCESSION of a new Party to [Acronym of the Action] GA No [INSERT NUMBER] Dated [INSERT DATE] PCA, dated [INSERT DATE] [OFFICIAL NAME OF THE NEW PARTY AS IDENTIFIED IN THE Grant Agreement] Hereby consents to become a Party to the best PCA identified above and accepts all the rights and obligations of their knowledge a Party starting [date], “the Accession Date”. [OFFICIAL NAME OF THE COORDINATOR AS IDENTIFIED IN THE Grant Agreement] hereby certifies that the Consortium has accepted in the meeting held on [date] the accession of [the name of the new Party] to the Consortium starting at the Accession Date. This Accession document has been executed in 2 originals duly signed by the undersigned authorised representatives. [Date and Place] [INSERT NAME OF THE NEW PARTY] Signature(s) Name(s) Title(s) [Date and Place] [INSERT NAME OF THE COORDINATOR] Signature(s) Name(s) Title(s) Attachment 3: List of Third Parties for simplified transfer according to Section 8.3.2. of this PCA Attachment 4: List of any additional Affiliate pursuant to Article 1’s definition of Affiliate Attachment 5: Template for Non-Disclosure Agreement in case OPTION for Section 6.5 is chosen. This NON-DISCLOSURE AGREEMENT (please choose“NDA”) is for the [Acronym of the Action] Consortium’s External Advisory Group and it is entered into by and between [The Coordinator], a legal entity validly organized and existing under the laws of [Country], having its principal place of [Address] (“Coordinator”),, on behalf of the members of the [Acronym of the Action] Consortium (each “[Acronym of the Action] Member”, together “[Acronym of the Action] Members”); and; [XXX], a legal entity validly organized and existing under the laws of [XXX], having its principal place of business at [XXX] (“EEAB Member”) hereinafter referred individually to as “Party” or together as “Parties” respectively : [Acronym of the Action] Members have elected to institute a special External Expert Advisory Board (EEAB). For the purpose of participation of the EEAB Member in the [Acronym of the Action] External Advisory Group (hereinafter "Purpose"), [Acronym of the Action] Member(s) may, in conjunction with the Purpose disclose to the EEAB Member Confidential Information which the [Acronym of the Action] Member regards as confidential and the EEAB Member is willing to undertake to restrict the use and further disclosure of such Confidential Information.

AS WITNESS. The Parties have caused this Consortium Agreement to be duly signed by the undersigned authorised representatives in separate signature pages the day and year first above written. [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [It is too impractical recommended to insert a new page for all Parties to sign the same document at the same time. The procedure proposed for the signatures is widely used: Each Party signs a separate signature page as many times as there are Parties (it is also possible to sign only 1 or 2 originals as only one fully signed copy is necessary according to Belgian Law). The Coordinator gathers all originals and then delivers the whole package consisting of the text and all signatures (original or copies) to all Parties. each signature.] [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [Attachment 1: Background included] included According to the Grant Agreement (Article 2416.1) Background is defined as “data, know-how or information (…) that is (…) needed to implement the action Action or exploit the results”. Because of this need, Access Rights have to be granted in principle, but parties Parties must identify and agree amongst them on the Background for the projectProject. This is the purpose of this attachment. !! Beware – Attachment 1 is a vital document – check what your project partners are listing and (more importantly) not listing!! Earlier framework programmes required the parties to define Background and to make any exclusions "specific". This was translated into the Consortium Agreements by having Background exclusion lists, mostly in addition to the list of Background Included. The new MGA for H2020 obliges the parties to “identify and agree” upon the Background for the Project. Therefore, DESCA2020 proposes to work with actively listed Background. It is the responsibility of the parties to make this ‘agreement on Background’. It seems reasonable to expect that if parties know of a specific need for access rights to specific Background, they will be able to identify this up front (potentially with limitations). In any case, such a duty to inform is explicitly mentioned in Article 25.2 and 25.3 of the MGA) and this information needs to be shared before accession to the GA. The counterpart of working with a positive list is that the parties fully accept that anything not listed simply IS no Background, and that therefore, there is no reason to “exclude” it. That is the reason why there is no need any more to explicitly exclude background in Attachment 1 such as the background of research units not involved in the Project as was usual in FP7 Consortium Agreements. PARTY 1 As to [NAME OF THE PARTY], it is agreed between the parties Parties that, to the best of their knowledge knowledge, [insert the relevant option here]. [Option 1 start] the following Background is xxxxxx identified and agreed upon for the Project. Specific limitations and/or conditions, shall be as mentioned hereunder: Describe Background Specific restrictions and/or conditions for implementation (please chooseArticle 16.4 Grant Agreement and its Annex 5, Section “Access rights to results and background”, sub-section “Access rights to background and results for implementing the Action”) Specific restrictions and/or conditions for Exploitation (Article 16.4 Grant Agreement and its Annex 5, Section “Access rights to results and background”, sub-section “Access rights for exploiting the results”) [Option 1 end] [Option 2 start] Option 2: No data, know-how or information of [NAME OF THE PARTY] is Needed by another Party for implementation of the Project (Article 16.1 and its Annex 5 Grant Agreement, Section “Access rights to results and background”, sub-section “Access rights to background and results for implementing the action”) or Exploitation of that other Party’s Results (Article 16.1 and its Annex 5 Grant Agreement, Section “Access rights to results and background”, sub-section “Access rights for exploiting the results”),. [Option 2 end] This represents the status at the time of signature of this Consortium Agreement. [Same for PARTY 2, PARTY 3, etc] Attachment 2: Accession document ACCESSION of a new Party to [Acronym of the Project] Consortium Agreement, version […, YYYY-MM-DD] [OFFICIAL NAME OF THE NEW PARTY AS IDENTIFIED IN THE Grant Agreement] hereby consents to become a Party to the Consortium Agreement identified above and accepts all the rights and obligations of a Party starting [date]. [OFFICIAL NAME OF THE COORDINATOR AS IDENTIFIED IN THE Grant Agreement] hereby certifies that the consortium has accepted in the meeting held on [date] the accession of [the name of the new Party] to the consortium starting [date]. This Accession document has been done in 2 originals to be duly signed by the undersigned authorised representatives. [Date and Place] [INSERT NAME OF THE NEW PARTY] Signature(s) Name(s) Title(s) [Date and Place] [INSERT NAME OF THE COORDINATOR] Signature(s) Name(s) Title(s) Attachment 3 (Template for Career Development Plan) under Section 4.3 [To be updated in view of the needs of the researchers in accordance with the Grant Agreement, Annex 5, Art. 18] Name of Doctoral Candidate: Department: Name of Supervisor: Date: Brief overview of research project and major accomplishments expected (half page should be sufficient): Long-term career objectives (over 5 years): Goals: What further research activity or other training is needed to attain these goals? Short-term objectives (1-2 years):13 Research results Anticipated publications: Anticipated conference, workshop attendance, courses, and /or seminar presentations: Research Skills and techniques: Training in specific new areas, or technical expertise etc: Research management: Fellowship or other funding applications planned (indicate name of award if known; include fellowships with entire funding periods, grants written/applied for/received, professional society presentation awards or travel awards, etc.) Communication skills: Other professional training (course work, teaching activity): Anticipated networking opportunities Other activities (community, etc) with professional relevance: Date & Signature of Doctoral Candidate: Date & Signature of supervisor Career Development Plan Guidance on some of the competencies expected The following points are a non-exhaustive series of aspects that could be covered by the career development plan, and it is relevant to the short-term objectives that will be set by the researcher and the reviewer at the beginning of the fellowship period. The objectives should be set with respect to the skills and experience that each researcher should acquire at a given time of his/her career. These objectives should be revised at the end of the fellowship and should be used as a pro-active monitoring of progress in the researcher’s career.

AS WITNESS. The Parties have caused this Consortium Agreement to be duly signed by the undersigned authorised representatives in separate signature pages the day and year first above written. [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [It is too impractical recommended to insert a new page for all Parties to sign the same document at the same time. The procedure proposed for the signatures is widely used: Each Party signs a separate signature page as many times as there are Parties (it is also possible to sign only 1 or 2 originals as only one fully signed copy is necessary according to Belgian Law). The Coordinator gathers all originals and then delivers the whole package consisting of the text and all signatures (original or copies) to all Parties. each signature.] [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [Attachment 1: Background included] included According to the Grant Agreement (Article 2416.1) Background is defined as “data, know-how or information (…) that is (…) needed to implement the action Action or exploit the results”. Because of this need, Access Rights have to be granted in principle, but parties Parties must identify and agree amongst them on the Background for the projectProject. This is the purpose of this attachment. !! Beware – Attachment 1 is a vital document – check what your project partners are listing and (more importantly) not listing!! Earlier framework programmes required the parties to define Background and to make any exclusions "specific". This was translated into the Consortium Agreements by having Background exclusion lists, mostly in addition to the list of Background Included. The new MGA for H2020 obliges the parties to “identify and agree” upon the Background for the Project. Therefore, DESCA2020 proposes to work with actively listed Background. It is the responsibility of the parties to make this ‘agreement on Background’. It seems reasonable to expect that if parties know of a specific need for access rights to specific Background, they will be able to identify this up front (potentially with limitations). In any case, such a duty to inform is explicitly mentioned in Article 25.2 and 25.3 of the MGA) and this information needs to be shared before accession to the GA. The counterpart of working with a positive list is that the parties fully accept that anything not listed simply IS no Background, and that therefore, there is no reason to “exclude” it. That is the reason why there is no need any more to explicitly exclude background in Attachment 1 such as the background of research units not involved in the Project as was usual in FP7 Consortium Agreements. PARTY 1 As to [NAME OF THE PARTY], it is agreed between the parties Parties that, to the best of their knowledge knowledge, [insert the relevant option here]. [Option 1 start] the following Background is hereby identified and agreed upon for the Project. Specific limitations and/or conditions, shall be as mentioned hereunder: Describe Background Specific restrictions and/or conditions for implementation (please chooseArticle 16.4 Grant Agreement and its Annex 5, Section “Access rights to results and background”, sub-section “Access rights to background and results for implementing the Action”) Specific restrictions and/or conditions for Exploitation (Article 16.4 Grant Agreement and its Annex 5, Section “Access rights to results and background”, sub-section “Access rights for exploiting the results”) [Option 1 end] [Option 2 start] Option 2: No data, know-how or information of [NAME OF THE PARTY] is Needed by another Party for implementation of the Project (Article 16.1 and its Annex 5 Grant Agreement, Section “Access rights to results and background”, sub-section “Access rights to background and results for implementing the action”) or Exploitation of that other Party’s Results (Article 16.1 and its Annex 5 Grant Agreement, Section “Access rights to results and background”, sub-section “Access rights for exploiting the results”),. [Option 2 end] This represents the status at the time of signature of this Consortium Agreement. [Same for PARTY 2, PARTY 3, etc] Attachment 2: Accession document ACCESSION of a new Party to [Acronym of the Project] Consortium Agreement, version […, YYYY-MM-DD] [OFFICIAL NAME OF THE NEW PARTY AS IDENTIFIED IN THE Grant Agreement] hereby consents to become a Party to the Consortium Agreement identified above and accepts all the rights and obligations of a Party starting [date]. [OFFICIAL NAME OF THE COORDINATOR AS IDENTIFIED IN THE Grant Agreement] hereby certifies that the consortium has accepted in the meeting held on [date] the accession of [the name of the new Party] to the consortium starting [date]. This Accession document has been done in 2 originals to be duly signed by the undersigned authorised representatives. [Date and Place] [INSERT NAME OF THE NEW PARTY] Signature(s) Name(s) Title(s) [Date and Place] [INSERT NAME OF THE COORDINATOR] Signature(s) Name(s) Title(s) Attachment 3: List of third parties for simplified transfer according to Section 8.3.2. [Option: Attachment 4: Identified entities under the same control according to Section 9.5] [Option: Attachment 5: NDA for External Expert Advisory Board agreed under Section 6] [Option: Module GOV LP] Governance structure for Medium and Large Projects

AS WITNESS. The Parties have caused this Consortium Agreement to be duly signed by the undersigned authorised representatives in separate signature pages the day and year first above written. It is too impractical for all Parties to sign the same document at the same time. The procedure proposed for the signatures is widely used: Each Party signs a separate signature page as many times as there are Parties (it is also possible to sign only 1 or 2 originals as only one fully signed copy is necessary according to Belgian Law). The Coordinator gathers all originals and then delivers the whole package consisting of the text and all signatures (original or copies) to all Parties. [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [Attachment 1: Background included] According to the Grant Agreement (Article 24) Background is defined as “data, know-how or information (…) that is needed to implement the action or exploit the results”. Because of this need, Access Rights have to be granted in principle, but parties must identify and agree amongst them on the Background for the project. This is the purpose of this attachment. !! Beware – Attachment 1 is a vital document – check what your project partners are listing and (more importantly) not listing!! Earlier framework programmes required the parties to define Background and to make any exclusions "specific". This was translated into the Consortium Agreements by having Background exclusion lists, mostly in addition to the list of Background Included. The new MGA for H2020 obliges the parties to “identify and agree” upon the Background for the Project. Therefore, DESCA2020 proposes to work with actively listed Background. It is the responsibility of the parties to make this ‘agreement on Background’. It seems reasonable to expect that if parties know of a specific need for access rights to specific Background, they will be able to identify this up front (potentially with limitations). In any case, such a duty to inform is explicitly mentioned in Article 25.2 and 25.3 of the MGA) and this information needs to be shared before accession to the GA. The counterpart of working with a positive list is that the parties fully accept that anything not listed simply IS no Background, and that therefore, there is no reason to “exclude” it. That is the reason why there is no need any more to explicitly exclude background in Attachment 1 such as the background of research units not involved in the Project as was usual in FP7 Consortium Agreements. PARTY 1 As to [NAME OF THE PARTY], it is agreed between the parties that, to the best of their knowledge (please choose),, Option 1: The following background is hereby identified and agreed upon for the Project. Specific limitations and/or conditions, shall be as mentioned hereunder: Describe Background Specific limitations and/or conditions for implementation (Article 25.2 Grant Agreement) Specific limitations and/or conditions for exploitation (Article 25.3 Grant Agreement) … … ..

AS WITNESS. The Parties have caused this Consortium Agreement to be duly signed by the undersigned authorised representatives in separate signature pages the day and year first above written. It is too impractical for all Parties to sign the same document at the same time. The procedure proposed for the signatures is widely used: Each Party signs a separate signature page as many times as there are Parties (it is also possible to sign only 1 or 2 originals as only one fully signed copy is necessary according to Belgian Law). The Coordinator gathers all originals and then delivers the whole package consisting of the text and all signatures (original or copies) to all Parties. [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [Attachment 1: Background included] According to the Grant Agreement (Article 24) Background is defined as “data, know-how or information (…) that is needed to implement the action or exploit the results”. Because of this need, Access Rights have to be granted in principle, but parties Parties must identify and agree amongst them on the Background for the project. This is the purpose of this attachment. !! Beware Be aware – Attachment 1 is a vital document – check what your project partners are listing and (more importantly) not listing!! Earlier framework programmes required the parties to define Background and to make any exclusions "specific". This was translated into the Consortium Agreements by having Background exclusion lists, mostly in addition to the list of Background Included. The new MGA for H2020 obliges the parties to “identify and agree” upon the Background for the Project. Therefore, DESCA2020 proposes to work with actively listed Background. It is the responsibility of the parties to make this ‘agreement on Background’. It seems reasonable to expect that if parties know of a specific need for access rights to specific Background, they will be able to identify this up front (potentially with limitations). In any case, such a duty to inform is explicitly mentioned in Article 25.2 and 25.3 of the MGA) and this information needs to be shared before accession to the GA. The counterpart of working with a positive list is that the parties fully accept that anything not listed simply IS no Background, and that therefore, there is no reason to “exclude” it. That is the reason why there is no need any more to explicitly exclude background in Attachment 1 such as the background of research units not involved in the Project as was usual in FP7 Consortium Agreements. The annotated MGA also allows for negative list. You may wish to refer to the FP7 DESCA if you prefer this approach. PARTY 1 As to [NAME OF THE PARTY], it is agreed between the parties Parties that, to the best of their knowledge (please choose),

AS WITNESS. The Parties have caused this Consortium Agreement to be duly signed by the undersigned authorised representatives in separate signature pages the day and year first above written. It is too impractical for all Parties to sign the same document at the same time. The procedure proposed for the signatures is widely used: Each Party signs a separate signature page as many times as there are Parties (it is also possible to sign only 1 or 2 originals as only one fully signed copy is necessary according to Belgian Law). The Coordinator gathers all originals and then delivers the whole package consisting of the text and all signatures (original or copies) to all Parties. [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [Attachment 1: Background included] According Access Rights to Background made available to the Grant Agreement (Article 24) Background is defined as “data, know-how or information (…) that is needed to implement Parties: a. b. ... This represents the action or exploit status at the results”. Because time of signature of this need, Consortium Agreement. [Attachment 2: Background excluded] Background excluded from Access Rights have to be granted in principle, but parties must identify and agree amongst them on Rights: a. b. ... This represents the Background for status at the project. This is the purpose time of signature of this attachmentConsortium Agreement. !! Beware – [Attachment 1 is 3: Accession document] ACCESSION of a vital document – check what your project partners are listing and (more importantly) not listing!! Earlier framework programmes required the parties new Party to define Background and to make any exclusions "specific". This was translated into the Consortium Agreements by having Background exclusion lists, mostly in addition to the list [Acronym of Background Included. The new MGA for H2020 obliges the parties to “identify and agree” upon the Background for the Project. Therefore] Consortium Agreement, DESCA2020 proposes to work with actively listed Background. It is the responsibility of the parties to make this ‘agreement on Background’. It seems reasonable to expect that if parties know of a specific need for access rights to specific Backgroundversion […, they will be able to identify this up front (potentially with limitations). In any case, such a duty to inform is explicitly mentioned in Article 25.2 and 25.3 of the MGA) and this information needs to be shared before accession to the GA. The counterpart of working with a positive list is that the parties fully accept that anything not listed simply IS no Background, and that therefore, there is no reason to “exclude” it. That is the reason why there is no need any more to explicitly exclude background in Attachment 1 such as the background of research units not involved in the Project as was usual in FP7 Consortium Agreements. PARTY 1 As to YYYY-MM-DD] [OFFICIAL NAME OF THE PARTY], it is agreed between the parties that, NEW PARTY AS IDENTIFIED IN THE EC-GA] hereby consents to become a Party to the best Consortium Agreement identified above and accepts all the rights and obligations of a Party starting [date]. [OFFICIAL NAME OF THE COORDINATOR AS IDENTIFIED IN THE EC-GA] hereby certifies that the Consortium has accepted in the meeting held on [date] the accession of [the name of the new Party] to the Consortium starting [date]. This Accession document has been done in 2 originals to be duly signed by the undersigned authorised representatives. [Date and Place] [INSERT NAME OF THE NEW PARTY] Signature(s) Name(s) Title(s) [Date and Place] [INSERT NAME OF THE COORDINATOR] Signature(s) Name(s) Title(s) [Attachment 4: Listed Affiliated Entities] If you have used option 1 in Art. 9.5, Attachment 4 shall be deleted [Attachment 5: List of Third Parties] List of Third Parties to which transfer of Foreground is possible with prior notice to the other Parties and for which the other Parties have waived their knowledge right to object. [Module GOV SP] Governance structure for Small Collaborative Projects Choose [Module GOV SP] for Small Projects with a simple governance structure: only one governance board (please chooseGeneral Assembly),. Main difference: [Module GOV LP] has two governance boards (General Assembly and Executive Board)

AS WITNESS. The Parties have caused this Consortium Agreement to be duly signed by the undersigned authorised representatives in separate signature pages the day and year first above written. It is too impractical CSC-TIETEEN TIETOTEKNIIKAN OY (“CSC”) _____________________________ Xxxxx Xxxxx CEO Date: OPETUSHALLITUS (“OPH”) _____________________________ Olli-Xxxxx Xxxxxxxx Director General Date: OULUN YLIOPISTO (“UOulu”) _____________________________ Helka-Xxxxx Xxxxxxx Vice Xxxxxx for all Parties to sign the same document at the same time. The procedure proposed EducationKoulutusrehtori Date: JYVASKYLAN KOULUTUSKUNTAYHTYMA (“JEC”) _____________________________ Xxxx Xxxxxxxxxx Director Date: XX XXXXX DER NEDERLANDEN, represented by MINISTER VAN ONDERWIJS, CULTUUR EN WETENSCHAP, for the signatures is widely usedthis: Each Party signs a separate signature page as many times as there are Parties Dienst Uitvoering Onderwijs (it is also possible to sign only 1 or 2 originals as only one fully signed copy is necessary according to Belgian Law). The Coordinator gathers all originals “DUO”) _____________________________ Xxx Xxxxxxxxxx Chief executive Financials, Services and then delivers the whole package consisting of the text and all signatures (original or copies) to all Parties. [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date ICT Date: [Attachment 1: Background included] According to the Grant Agreement (Article 24) Background is defined as “data, know-how or information (…) that is needed to implement the action or exploit the results”. Because of this need, Access Rights have to be granted in principle, but parties must identify and agree amongst them on the Background for the project. This is the purpose of this attachment. !! Beware – Attachment 1 is a vital document – check what your project partners are listing and (more importantly) not listing!! Earlier framework programmes required the parties to define Background and to make any exclusions "specific". This was translated into the Consortium Agreements by having Background exclusion lists, mostly in addition to the list of Background Included. The new MGA for H2020 obliges the parties to “identify and agree” upon the Background for the Project. Therefore, DESCA2020 proposes to work with actively listed Background. It is the responsibility of the parties to make this ‘agreement on Background’. It seems reasonable to expect that if parties know of a specific need for access rights to specific Background, they will be able to identify this up front (potentially with limitations). In any case, such a duty to inform is explicitly mentioned in Article 25.2 and 25.3 of the MGA) and this information needs to be shared before accession to the GA. The counterpart of working with a positive list is that the parties fully accept that anything not listed simply IS no Background, and that therefore, there is no reason to “exclude” it. That is the reason why there is no need any more to explicitly exclude background in Attachment 1 such as the background of research units not involved in the Project as was usual in FP7 Consortium Agreements. PARTY 1 As to [NAME OF THE PARTY]CSC-TIETEEN TIETOTEKNIIKAN OY (“CSC”), it is agreed between the parties that, to the best of their knowledge knowledge, The following background is hereby identified and agreed upon for the Project. Specific limitations and/or conditions, shall be as mentioned hereunder: Describe Background Specific limitations and/or conditions for implementation Specific limitations and/or conditions for exploitation Scientific and technical information, data and knowhow, infrastructure and assets belonging to CSC and its units and teams directly involved in CompLeap Project, necessary for achieving the goals of the Description of Action, as specified in the Annex I (please choosetechnical annex),. Access Right to Background is only granted to the extent that it is needed for implementation of the action. Access Right to Background is only granted to the extent that said Background is not subject to terms and conditions in other agreements that may prohibit the desired Access Right. This represents the status at the time of signature of this Consortium Agreement.

AS WITNESS. The Parties have caused this Consortium Agreement to be duly signed by the undersigned authorised representatives in separate signature pages the day and year first above written. It is too impractical This agreement exists in five original copies, two for all Parties to sign the same document at the same timeBUT and one for USTUTT, NGU and TK each. The procedure proposed for the signatures is widely used: Each Party signs a separate signature page as many times as there are Parties (it is also possible to sign only 1 or 2 originals as only one fully signed copy is necessary according to Belgian Law). The Coordinator gathers all originals and then delivers the whole package consisting of the text and all signatures (original or copies) to all Parties. [INSERT NAME OF PARTY] VYSOKE UCENI TECHNICKE V BRNE Signature(s) Name(s) Title(s) Date [INSERT NAME OF PARTY] UNIVERSITAET STUTTGART Signature(s) Xx. Xxxxxxx Xxxxxxxx Registrar and Member of the Xxxxxx´s Board Date CIC NANOGUNE Signature(s) Name(s) Title(s) Date [INSERT NAME OF PARTY] XXXXXX XXXXXXX LTD Signature(s) Name(s) Title(s) Date [Attachment ATTACHMENT 1: Background included] BACKGROUND INCLUDED According to the Grant Agreement (Article 24) Background is defined as “data, know-how or information (…) that is needed to implement the action or exploit the results”. Because of this need, Access Rights have to be granted in principle, but parties Parties must identify and agree amongst them on the Background for the project. This is the purpose of this attachment. !! Beware – Attachment 1 is a vital document – check what your project partners are listing and (more importantly) not listing!! Earlier framework programmes required the parties to define Background and to make any exclusions "specific". This was translated into the Consortium Agreements by having Background exclusion lists, mostly in addition to the list of Background Included. The new MGA for H2020 obliges the parties to “identify and agree” upon the Background for the Project. Therefore, DESCA2020 proposes to work with actively listed Background. It is the responsibility of the parties to make this ‘agreement on Background’. It seems reasonable to expect that if parties know of a specific need for access rights to specific Background, they will be able to identify this up front (potentially with limitations). In any case, such a duty to inform is explicitly mentioned in Article 25.2 and 25.3 of the MGA) and this information needs to be shared before accession to the GA. The counterpart of working with a positive list is that the parties fully accept that anything not listed simply IS no Background, and that therefore, there is no reason to “exclude” it. That is the reason why there is no need any more to explicitly exclude background in Attachment 1 such as the background of research units not involved in the Project as was usual in FP7 Consortium Agreements. PARTY 1 As to [NAME OF THE PARTY]VYSOKE UCENI TECHNICKE V BRNE, it is agreed between the parties Parties that, to the best of their knowledge knowledge, the following background is hereby identified and agreed upon for the Project. Specific limitations and/or conditions, shall be as mentioned hereunder: Describe Background Specific limitations and/or conditions for implementation (please choose),Article 25.2 Grant Agreement) Specific limitations and/or conditions for Exploitation (Article 25.3 Grant Agreement) Design, development, and application of atomic force microscopes including control electronics and software. Fabrication and characterisation of plasmonic antennas for various applications. Simulation and design of antennas with specific parameters. Application, design and development of high frequency magnetic resonance spectroscopy, covering  frequency domain methodology.  Rapid scan methodology This represents the status at the time of signature of this Consortium Agreement.

AS WITNESS. The Parties have caused this Consortium Agreement to be duly signed by the undersigned authorised representatives in separate signature pages the day and year first above written. [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [It is too impractical recommended to insert a new page for all Parties to sign the same document at the same time. The procedure proposed for the signatures is widely used: Each Party signs a separate signature page as many times as there are Parties (it is also possible to sign only 1 or 2 originals as only one fully signed copy is necessary according to Belgian Law). The Coordinator gathers all originals and then delivers the whole package consisting of the text and all signatures (original or copies) to all Parties. each signature.] [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [Attachment 1: Background included] included According to the Grant Agreement (Article 2416.1) Background is defined as “data, know-how or information (…) that is (…) needed to implement the action Action or exploit the results”. Because of this need, Access Rights have to be granted in principle, but parties Parties must identify and agree amongst them on the Background for the projectProject. This is the purpose of this attachment. !! Beware – Attachment 1 is a vital document – check what your project partners are listing and (more importantly) not listing!! Earlier framework programmes required the parties to define Background and to make any exclusions "specific". This was translated into the Consortium Agreements by having Background exclusion lists, mostly in addition to the list of Background Included. The new MGA for H2020 obliges the parties to “identify and agree” upon the Background for the Project. Therefore, DESCA2020 proposes to work with actively listed Background. It is the responsibility of the parties to make this ‘agreement on Background’. It seems reasonable to expect that if parties know of a specific need for access rights to specific Background, they will be able to identify this up front (potentially with limitations). In any case, such a duty to inform is explicitly mentioned in Article 25.2 and 25.3 of the MGA) and this information needs to be shared before accession to the GA. The counterpart of working with a positive list is that the parties fully accept that anything not listed simply IS no Background, and that therefore, there is no reason to “exclude” it. That is the reason why there is no need any more to explicitly exclude background in Attachment 1 such as the background of research units not involved in the Project as was usual in FP7 Consortium Agreements. PARTY 1 As to [NAME OF THE PARTY], it is agreed between the parties Parties that, to the best of their knowledge knowledge, [insert the relevant option here]. [Option 1 start] the following Background is xxxxxx identified and agreed upon for the Project. Specific limitations and/or conditions, shall be as mentioned hereunder: Describe Background Specific restrictions and/or conditions for implementation (please chooseArticle 16.4 Grant Agreement and its Annex 5, Section “Access rights to results and background”, sub-section “Access rights to background and results for implementing the Action”) Specific restrictions and/or conditions for Exploitation (Article 16.4 Grant Agreement and its Annex 5, Section “Access rights to results and background”, sub-section “Access rights for exploiting the results”) [Option 1 end] [Option 2 start] Option 2: No data, know-how or information of [NAME OF THE PARTY] is Needed by another Party for implementation of the Project (Article 16.1 and its Annex 5 Grant Agreement, Section “Access rights to results and background”, sub-section “Access rights to background and results for implementing the action”) or Exploitation of that other Party’s Results (Article 16.1 and its Annex 5 Grant Agreement, Section “Access rights to results and background”, sub-section “Access rights for exploiting the results”),. [Option 2 end] This represents the status at the time of signature of this Consortium Agreement. [Same for PARTY 2, PARTY 3, etc] Attachment 2: Accession document ACCESSION of a new Party to [Acronym of the Project] Consortium Agreement, version […, YYYY-MM-DD] [OFFICIAL NAME OF THE NEW PARTY AS IDENTIFIED IN THE Grant Agreement] hereby consents to become a Party to the Consortium Agreement identified above and accepts all the rights and obligations of a Party starting [date]. [OFFICIAL NAME OF THE COORDINATOR AS IDENTIFIED IN THE Grant Agreement] hereby certifies that the consortium has accepted in the meeting held on [date] the accession of [the name of the new Party] to the consortium starting [date]. This Accession document has been done in 2 originals to be duly signed by the undersigned authorised representatives. [Date and Place] [INSERT NAME OF THE NEW PARTY] Signature(s) Name(s) Title(s) [Date and Place] [INSERT NAME OF THE COORDINATOR] Signature(s) Name(s) Title(s) Attachment 3: List of third parties for simplified transfer according to Section 8.3.2. [Option: Attachment 4: Identified entities under the same control according to Section 9.5] [Option: Attachment 5: NDA for External Expert Advisory Board agreed under Section 6] [Option: Module GOV LP] Governance structure for Medium and Large Projects

AS WITNESS. The Parties Beneficiaries have caused this Consortium Agreement to be duly signed by the undersigned authorised representatives in separate signature pages the day and year first above written. It is too impractical for all Parties Linked Thrid Party to sign the same document at the same time. The procedure proposed for the signatures is widely usedCO2GeoNet (CO2GeoNet) : Each Party signs a separate signature page as many times as there are Parties UNIZG-RGNF (it is also possible to sign only 1 or 2 originals as only one fully signed copy is necessary according to Belgian Law). The Coordinator gathers all originals and then delivers the whole package consisting of the text and all signatures (original or copiesUNIZG-RGNF) to all Parties. [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [Attachment 1: Background included] included According to the Grant Agreement (Article 24) Background is defined as “data, know-how or information (…) that is needed to implement the action or exploit the results”. Because of this need, Access Rights have to be granted in principle, but parties Participants must identify and agree amongst them on the Background for the project. This is the purpose of this attachment. !! Beware – Attachment 1 is a vital document – check what your project partners are listing and (more importantly) not listing!! Earlier framework programmes required the parties to define Background and to make any exclusions "specific". This was translated into the Consortium Agreements by having Background exclusion lists, mostly in addition to the list of Background Included. The new MGA for H2020 obliges the parties to “identify and agree” upon the Background for the Project. Therefore, DESCA2020 proposes to work with actively listed Background. It is the responsibility of the parties to make this ‘agreement on Background’. It seems reasonable to expect that if parties know of a specific need for access rights to specific Background, they will be able to identify this up front (potentially with limitations). In any case, such a duty to inform is explicitly mentioned in Article 25.2 and 25.3 of the MGA) and this information needs to be shared before accession to the GA. The counterpart of working with a positive list is that the parties fully accept that anything not listed simply IS no Background, and that therefore, there is no reason to “exclude” it. That is the reason why there is no need any more to explicitly exclude background in Attachment 1 such as the background of research units not involved in the Project as was usual in FP7 Consortium Agreements. PARTY 1 BENEFICIARY BRGM As to [NAME OF THE PARTY]BRGM, it is agreed between the parties Participants that, to the best of their knowledge knowledge,the following background is hereby identified and agreed upon for the Project. Specific limitations and/or conditions, shall be as mentioned hereunder: Describe Background Specific limitations and/or conditions for implementation (please choose),Article 25.2 Grant Agreement) Specific limitations and/or conditions for Exploitation (Article 25.3 Grant Agreement) Patents, rights to inventions, copyright and related rights, rights to goodwill, rights in designs, rights in computer software, database rights, rights in confidential information, including knowhow and trade secrets, that has been generated by BRGM researchers prior to XXXX project in particular for: Groundwater monitoring tools and CO2 detection tools in boreholes Uncertainty assessment (GERICO software) No part of the Background data may be published or made available to any third party outside of the Project, without the prior written consent of BRGM, which may be granted subject to any legal restrictions or limits, including those imposed by third parties. Data and background knowledge/knowhow not generated using funding from XXXX remains the property of BRGM or the consortium under which the data were generated Publication of Results using BRGM Background to any third party shall be possible only after receiving written consent from BRGM. Raw measurements will not be made available to the Consortium. Exploitation of Results using BRGM Background shall be agreed on a case by case basis with the concerned Participant. This represents the status at the time of signature of this Consortium Agreement. BENEFICIARY BGR

AS WITNESS. The Parties have caused this the Consortium Agreement to be duly signed by the undersigned authorised representatives in separate signature pages the day and year first above written. It is too impractical European Organization for all Parties to sign the same document at the same timeNuclear Research (CERN) Name: Xx. The procedure proposed Xxxxxxx Xxxxxxxx Title: Director-General Signature: Date: 3D Plus SA Name: Xxxxxx Xxxxxxx Title: President Signature: Date: Airbus Group SAS Name: Xx. Xxxxxx Guédra-Degeorges Title: Vice-President, France Sites Coordinator for the signatures is widely usedAirbus Group Innovations Signature: Each Party signs a separate signature page as many times as there are Parties (it is also possible to sign only 1 or 2 originals as only one fully signed copy is necessary according to Belgian Law)Date: Jyaskylan Yliopisto Name: TBD Title: TBD Signature: Date: Katholieke Universiteit Leuven Name: Dr. Elke Lammertyn Xxxx Van Dun Title: Head of European Projects General Manager KU Leuven Research & Development Signature: Date: Name: Xxxx. The Coordinator gathers all originals and then delivers the whole package consisting Xxxx Xxxxxx Title: Senior Academic Staff Scientist-in-charge Signature: Date: Rijksuniversiteit Groningen Name: Prof. Dr. Sibrandes Xxxxxxx Title: President Signature: Date: Université de Montpellier Name: TBD Title: TBD Signature: Date: Xxxxxxxxx-Xxxxxxxxx Universität Erlangen-Nürnberg Name: Xxxxxx Xxxxxxxx Title: Head of the text and all signatures (original or copies) to all Parties. [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [EU office Signature: Date: Attachment 1: Background included] included According to the Grant Agreement (Article 24) Background is defined as “data, know-how or information (…) that is needed to implement the action or exploit the results”. Because of this need, Access Rights have to be granted in principle, but parties the Parties must identify and agree amongst them on the Background for the projectProject. This is the purpose of this attachment. !! Beware – Attachment 1 CERN The following Background is a vital document – check what your project partners are listing hereby identified and (more importantly) not listing!! Earlier framework programmes required the parties to define Background and to make any exclusions "specific". This was translated into the Consortium Agreements by having Background exclusion lists, mostly in addition to the list of Background Included. The new MGA for H2020 obliges the parties to “identify and agree” agreed upon the Background for the Project. ThereforeSpecific limitations and/or conditions, DESCA2020 proposes to work with actively listed Background. It is the responsibility of the parties to make this ‘agreement on Background’. It seems reasonable to expect that if parties know of a specific need shall be as mentioned hereunder: Describe Background Specific limitations and/or conditions for access rights to specific Background, they will be able to identify this up front implementation (potentially with limitations). In any case, such a duty to inform is explicitly mentioned in Article 25.2 and Grant Agreement) Specific limitations and/or conditions for exploitation (Article 25.3 of the MGAGrant Agreement) and this information needs to be shared before accession to the GA. The counterpart of working with a positive list is that the parties fully accept that anything not listed simply IS no Background, and that therefore, there is no reason to “exclude” it. That is the reason why there is no need any more to explicitly exclude background in Attachment 1 such as the background of research units not involved - Know-how for special qualification procedures in the Project as was usual CHARM/CC60 test facilities none none - Know-how in FP7 the design and deployment of XxxXxx none none This represents the status at the time of signature of this Consortium Agreements. PARTY 1 As to [NAME OF THE PARTY], it is agreed between the parties that, to the best of their knowledge (please choose),Agreement.

AS WITNESS. The Parties have caused this Consortium Agreement to be duly signed by the undersigned authorised representatives in separate signature pages the day and year first above written. It is too impractical for all Parties to sign the same document at the same time. The procedure proposed for the signatures is widely used: Each Party signs a separate signature page as many times as there are Parties (it is also possible to sign only 1 or 2 originals as only one fully signed copy is necessary according to Belgian Law). The Coordinator gathers all originals and then delivers the whole package consisting of the text and all signatures (original or copies) to all Parties. [INSERT NAME OF PARTY] ASTON UNIVERSITY Signature(s) Name(s) Title(s) Date [INSERT NAME OF PARTY] DAUGAVPILS UNIVERSITATE Signature(s) Name(s) Title(s) Date [INSERT NAME OF PARTY] INSTITUT DRUSTVENIH ZNANOSTI XXX XXXXX Signature(s) Name(s) Title(s) Date [CRRC GEORGIA NON ENTREPRENEURIAL Signature(s) Name(s) Title(s) Date XXXXX XXXXX FINE ARTS UNIVERSITY Signature(s) Name(s) Title(s) Date UNIVERSIDAD XXXXXX XXXXX Signature(s) Name(s) Title(s) Date CULTURE COVENTRY Signature(s) Name(s) Title(s) Date UNIVERZITA KOMENSKEHO V BRATISALVE Signature(s) Name(s) Title(s) Date THE XXXXXXXXXX XXXXX PUNE UNIVERSITY Signature(s) Name(s) Title(s) Date HOCHSCHULE FUER ANGEWANDTE WISSENSCHAFTEN Signature(s) Name(s) Title(s) Date Attachment 1: Background included] included According to the Grant Agreement (Article 24) Background is defined as “data, know-how or information (…) that is needed to implement the action or exploit the results”. Because of this need, Access Rights have to be granted in principle, but parties Parties must identify and agree amongst them on the Background for the project. This is the purpose of this attachment. !! Beware – Attachment 1 is a vital document – check what your project partners are listing and (more importantly) not listing!! Earlier framework programmes required the parties to define Background and to make any exclusions "specific". This was translated into the Consortium Agreements by having Background exclusion lists, mostly in addition to the list of Background Included. The new MGA for H2020 obliges the parties to “identify and agree” upon the Background for the Project. Therefore, DESCA2020 proposes to work with actively listed Background. It is the responsibility of the parties to make this ‘agreement on Background’. It seems reasonable to expect that if parties know of a specific need for access rights to specific Background, they will be able to identify this up front (potentially with limitations). In any case, such a duty to inform is explicitly mentioned in Article 25.2 and 25.3 of the MGA) and this information needs to be shared before accession to the GA. The counterpart of working with a positive list is that the parties fully accept that anything not listed simply IS no Background, and that therefore, there is no reason to “exclude” it. That is the reason why there is no need any more to explicitly exclude background in Attachment 1 such as the background of research units not involved in the Project as was usual in FP7 Consortium Agreements. PARTY 1 ASTON UNIVERSITY As to [NAME OF THE PARTY]Aston University, it is agreed between the parties Parties that, to the best of their knowledge (please choose),, Option 1: The following background is hereby identified and agreed upon for the Project. Specific limitations and/or conditions, shall be as mentioned hereunder: Describe Background Specific limitations and/or conditions for implementation (Article 25.2 Grant Agreement) Specific limitations and/or conditions for Exploitation (Article 25.3 Grant Agreement) Option 2: No data, know-how or information of [NAME OF THE PARTY] shall be Needed by another Party for implementation of the Project (Article 25.2 Grant Agreement) or Exploitation

AS WITNESS. The Parties have caused this Consortium Agreement to be duly signed by the undersigned authorised representatives in separate signature pages the day and year first above written. It is too impractical Lead Partner: xx a solely non-profit independent foundation with the official place of operations at xx Signature(s): Name(s): xx Title(s): xx As Witness: The Parties have caused this Consortium Agreement to be duly signed by the undersigned authorised representatives in separate signature pages the day and year first above written. Partner: {please insert you details here, and signatory’s details below} Signature(s): Name(s): Title(s): Annex 1 PROJECT DESCRIPTION Annex 2 Template of accession document for adding members to the existing Collaboration Agreement ACCESSION of a new Partner to Collaboration Agreement for the “xx” project (Annex 1), version […, DD-MM-YYYY] [OFFICIAL NAME OF THE NEW PARTNER] hereby consents to become a Partner to the Collaboration Agreement identified above and accepts all Parties the rights and obligations of a Partner starting [date]. xx (“xx”) hereby certifies that the consortium has accepted in the meeting held on [date] the accession of [the name of the new Partner] to sign the same document at the same timeconsortium starting [date]. The procedure proposed for Project Description has been updated to include the signatures is widely used: Each Party signs a separate signature page as many times as there are Parties (it is also possible contribution of the new partner, and the consortium has given its agreement to sign only 1 or this amendment. This Accession document has been done in 2 originals as only one fully to be duly signed copy is necessary according to Belgian Law)by the undersigned authorised representatives. The Coordinator gathers all originals [Date and then delivers the whole package consisting of the text and all signatures (original or copies) to all Parties. Place] [INSERT NAME OF PARTYTHE NEW PARTNER] Signature(s) Name(s) Title(s) [Date and Place] [INSERT NAME OF PARTYTHE SUPERVISION COMMITTEE REPRESENTATIVE] Signature(s) Name(s) Title(s) Date [INSERT NAME OF PARTY] Signature(sAnnex 3 - DATA PROCESSING AGREEMENT This data processing agreement, including any appendices hereto, (together the "Data Processing Agreement") Name(s) Title(s) Date [Attachment 1: Background included] According to the Grant Agreement (Article 24) Background is defined as “data, know-how or information (…) that is needed to implement the action or exploit the results”. Because of this need, Access Rights have to be granted in principle, but parties must identify and agree amongst them on the Background for the project. This is the purpose of this attachment. !! Beware – Attachment 1 is a vital document – check what your project partners are listing and (more importantly) not listing!! Earlier framework programmes required the parties to define Background and to make any exclusions "specific". This was translated into the Consortium Agreements by having Background exclusion lists, mostly in addition to the list of Background Included. The new MGA for H2020 obliges the parties to “identify and agree” upon the Background for the Project. Therefore, DESCA2020 proposes to work with actively listed Background. It is the responsibility an integrated part of the parties to make Agreement. All defined terms within the Agreement shall have the same meaning when used in this ‘agreement on Background’. It seems reasonable to expect that if parties know of a specific need for access rights to specific BackgroundData Processing Agreement, they will be able to identify unless explicitly defined otherwise in this up front (potentially with limitations). In any case, such a duty to inform is explicitly mentioned in Article 25.2 and 25.3 of the MGA) and this information needs to be shared before accession to the GA. The counterpart of working with a positive list is that the parties fully accept that anything not listed simply IS no Background, and that therefore, there is no reason to “exclude” it. That is the reason why there is no need any more to explicitly exclude background in Attachment 1 such as the background of research units not involved in the Project as was usual in FP7 Consortium Agreements. PARTY 1 As to [NAME OF THE PARTY], it is agreed between the parties that, to the best of their knowledge (please choose),Data Processing Agreement.

AS WITNESS. The Parties have caused this Consortium Agreement to be duly signed by the undersigned authorised representatives in separate signature pages the day and year first above written. This Collaboration Agreement may be executed by electronic signature or transmission, or in Adobe Portable Document Format (PDF) sent by electronic mail to each other. Signature in the PDF copy or in the electronic copy of this Agreement will be as enforceable as an original. [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [It is too impractical recommended to insert a new page for all Parties to sign the same document at the same time. The procedure proposed for the signatures is widely used: Each Party signs a separate signature page as many times as there are Parties (it is also possible to sign only 1 or 2 originals as only one fully signed copy is necessary according to Belgian Law). The Coordinator gathers all originals and then delivers the whole package consisting of the text and all signatures (original or copies) to all Parties. each signature.] [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [Attachment 1: Background included] included According to the Grant Agreement (Article 2416.1) Background is defined as “data, know-how or information (…) that is (…) needed to implement the action Action or exploit the results”. Because of this need, Access Rights have to be granted in principle, but parties Parties must identify and agree amongst them on the Background for the projectProject. This is the purpose of this attachment. !! Beware – Attachment 1 is a vital document – check what your project partners are listing and (more importantly) not listing!! Earlier framework programmes required the parties to define Background and to make any exclusions "specific". This was translated into the Consortium Agreements by having Background exclusion lists, mostly in addition to the list of Background Included. The new MGA for H2020 obliges the parties to “identify and agree” upon the Background for the Project. Therefore, DESCA2020 proposes to work with actively listed Background. It is the responsibility of the parties to make this ‘agreement on Background’. It seems reasonable to expect that if parties know of a specific need for access rights to specific Background, they will be able to identify this up front (potentially with limitations). In any case, such a duty to inform is explicitly mentioned in Article 25.2 and 25.3 of the MGA) and this information needs to be shared before accession to the GA. The counterpart of working with a positive list is that the parties fully accept that anything not listed simply IS no Background, and that therefore, there is no reason to “exclude” it. That is the reason why there is no need any more to explicitly exclude background in Attachment 1 such as the background of research units not involved in the Project as was usual in FP7 Consortium Agreements. PARTY 1 As to [NAME OF THE PARTY], it is agreed between the parties Parties that, to the best of their knowledge knowledge, [insert the relevant option here]. [Option 1 start] the following Background is xxxxxx identified and agreed upon for the Project. Specific limitations and/or conditions, shall be as mentioned hereunder: Describe Background Specific restrictions and/or conditions for implementation (please chooseArticle 16.4 Grant Agreement and its Annex 5, Section “Access rights to results and background”, sub-section “Access rights to background and results for implementing the Action”) Specific restrictions and/or conditions for Exploitation (Article 16.4 Grant Agreement and its Annex 5, Section “Access rights to results and background”, sub-section “Access rights for exploiting the results”) [Option 1 end] [Option 2 start] Option 2: No data, know-how or information of [NAME OF THE PARTY] is Needed by another Party for implementation of the Project (Article 16.1 and its Annex 5 Grant Agreement, Section “Access rights to results and background”, sub-section “Access rights to background and results for implementing the action”) or Exploitation of that other Party’s Results (Article 16.1 and its Annex 5 Grant Agreement, Section “Access rights to results and background”, sub-section “Access rights for exploiting the results”),. [Option 2 end] This represents the status at the time of signature of this Consortium Agreement. [Same for PARTY 2, PARTY 3, etc] Attachment 2: Accession document ACCESSION of a new Party to [Acronym of the Project] Consortium Agreement, version […, YYYY-MM-DD] [OFFICIAL NAME OF THE NEW PARTY AS IDENTIFIED IN THE Grant Agreement] hereby consents to become a Party to the Consortium Agreement identified above and accepts all the rights and obligations of a Party starting [date]. [OFFICIAL NAME OF THE COORDINATOR AS IDENTIFIED IN THE Grant Agreement] hereby certifies that the consortium has accepted in the meeting held on [date] the accession of [the name of the new Party] to the consortium starting [date]. This Accession document has been done in 2 originals to be duly signed by the undersigned authorised representatives. [Date and Place] [INSERT NAME OF THE NEW PARTY] Signature(s) Name(s) Title(s) [Date and Place] [INSERT NAME OF THE COORDINATOR] Signature(s) Name(s) Title(s) Attachment 3: List of third parties for simplified transfer according to Section 8.3.2. [Option: Attachment 4: Identified entities under the same control according to Section 9.5] [Option: Attachment 5: NDA for External Expert Advisory Board agreed under Section 6] [Option: Module GOV LP] Governance structure for Medium and Large Projects [To use the following paragraphs it is recommended to do as follows:

AS WITNESS. The Parties have caused this Consortium Agreement to be duly signed by the undersigned authorised representatives in separate signature pages the day and year first above written. It is too impractical for all Parties to sign the same document at the same time. The procedure proposed for the signatures is widely used: Each Party signs a separate signature page as many times as there are Parties (it is also possible to sign only 1 or 2 originals as only one fully signed copy is necessary according to Belgian Law). The Coordinator gathers all originals and then delivers the whole package consisting of the text and all signatures (original or copies) to all Parties. [INSERT NAME OF PARTY] AGENCIA ESTATAL CONSEJO SUPERIOR DE INVESTIGACIONES CIENTÍFICAS Signature(s) Name(s) Title(s) Date [INSERT NAME OF PARTY] THE OPEN UNIVERSITY Signature(s) Name(s) Title(s) Date [INSERT NAME OF PARTY] INSTITUT D´AERONOMIE SPATIALE DE BELGIQUE Signature(s) Name(s) Title(s) Date [CENTRE NATIONAL DE LA RECHERCHE CIENTIFIQUE Signature(s) Name(s) Title(s) Date ISTITUTO NAZIONALE DI ASTROFISICA Signature(s) Name(s) Title(s) Date KONINKLIJKE STERRENWATCH VAN BELGIE Signature(s) Name(s) Title(s) Date UNIVERSIDAD COMPLUTENSE DE MADRID Signature(s) Name(s) Title(s) Date Attachment 1: Background included] included According to the Grant Agreement (Article 24) Background is defined as “data, know-how or information (…) that is needed to implement the action or exploit the results”. Because of this need, Access Rights have to be granted in principle, but parties must identify and agree amongst them on the Background for the project. This is the purpose of this attachment. !! Beware – Attachment 1 is a vital document – check what your project partners are listing and (more importantly) not listing!! Earlier framework programmes required the parties to define Background and to make any exclusions "specific". This was translated into the Consortium Agreements by having Background exclusion lists, mostly in addition to the list of Background Included. The new MGA for H2020 obliges the parties to “identify and agree” upon the Background for the Project. Therefore, DESCA2020 proposes to work with actively listed Background. It is the responsibility of the parties to make this ‘agreement on Background’. It seems reasonable to expect that if parties know of a specific need for access rights to specific Background, they will be able to identify this up front (potentially with limitations). In any case, such a duty to inform is explicitly mentioned in Article 25.2 and 25.3 of the MGA) and this information needs to be shared before accession to the GA. The counterpart of working with a positive list is that the parties fully accept that anything not listed simply IS no Background, and that therefore, there is no reason to “exclude” it. That is the reason why there is no need any more to explicitly exclude background in Attachment 1 such as the background of research units not involved in the Project as was usual in FP7 Consortium Agreements. PARTY 1 As to [NAME OF THE PARTY], Agencia Estatal Consejo Superior de Investigaciones Científicas it is agreed between the parties that, to the best of their knowledge knowledge, The following background is hereby identified and agreed upon for the Project. Specific limitations and/or conditions, shall be as mentioned hereunder: Describe Background Specific limitations and/or conditions for implementation (please chooseArticle 25.2 Grant Agreement) Specific limitations and/or conditions for exploitation (Article 25.3 Grant Agreement),

AS WITNESS. The Parties have caused this Consortium Agreement to be duly signed by the undersigned authorised representatives in separate signature pages the day and year first above written. It is too impractical for all Parties to sign the same document at the same time. The procedure proposed for the signatures is widely used: Each Party signs a separate signature page as many times as there are Parties (it is also possible to sign only 1 or 2 originals as only one fully signed copy is necessary according to Belgian Law). The Coordinator gathers all originals and then delivers the whole package consisting of the text and all signatures (original or copies) to all Parties. [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [INSERT NAME OF PARTY] Signature(s) Name(s) Title(s) Date [Attachment 1: Background included] According to the Grant Agreement (Article 24) Background is defined as “data, know-how or information (…) that is needed to implement the action or exploit the results”. Because of this need, Access Rights have to be granted in principle, but parties partiesParties must identify and agree amongst them on the Background for the project. This is the purpose of this attachment. PARTY 1 As to [NAME OF THE PARTY], it is agreed between the partiesParties that, to the best of their knowledge (please choose), !! Beware BewareBe aware – Attachment 1 is a vital document – check what your project partners are listing and (more importantly) not listing!!! Earlier framework programmes required the parties to define Background and to make any exclusions "specific". This was translated into the Consortium Agreements by having Background exclusion lists, mostly in addition to the list of Background Included. The new MGA for H2020 obliges the parties to “identify and agree” upon the Background for the Project. Therefore, DESCA2020 proposes to work with actively listed Background. It is the responsibility of the parties to make this ‘agreement on Background’. It seems reasonable to expect that if parties know of a specific need for access rights to specific Background, they will be able to identify this up front (potentially with limitations). In any case, such a duty to inform is explicitly mentioned in Article 25.2 and 25.3 of the MGA) and this information needs to be shared before accession to the GA. The counterpart of working with a positive list is that the parties fully accept that anything not listed simply IS no Background, and that therefore, there is no reason to “exclude” it. That is the reason why there is no need any more to explicitly exclude background in Attachment 1 such as the background of research units not involved in the Project as was usual in FP7 Consortium Agreements. PARTY 1 As The annotated MGA also allows for negative list. You may wish to [NAME OF THE PARTY], it is agreed between the parties that, refer to the best of their knowledge (please choose),FP7 DESCA if you prefer this approach.