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. 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
Appears in 6 contracts
Samples: Consortium Agreement, Consortium Agreement, Consortium Agreement
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 … … … … … … … … … … … … … … … … DECLARATION OF ACCESSION of a new Party to [Attachment 1: Background includedAcronym of the Action] According 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 PCA identified above and accepts all the rights and obligations of a Party starting [date], “the Accession Date”. [OFFICIAL NAME OF THE COORDINATOR AS IDENTIFIED IN THE Grant Agreement 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) This NON-DISCLOSURE AGREEMENT (Article 24“NDA”) Background is defined 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 “data, know-how Party” or information together as “Parties” respectively [Acronym of the Action] Members have elected to institute a special External Expert Advisory Board (…) that is needed to implement the action or exploit the results”EEAB). 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 For the purpose of this attachment. !! Beware – Attachment 1 is a vital document – check what your project partners are listing and participation of the EEAB Member in the [Acronym of the Action] External Advisory Group (more importantlyhereinafter "Purpose"), [Acronym of the Action] Member(s) not listing!! Earlier framework programmes required may, in conjunction with 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 Purpose disclose to the list of Background Included. The new MGA for H2020 obliges EEAB Member Confidential Information which 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 [Acronym of the parties Action] Member regards as confidential and the EEAB Member is willing to make this ‘agreement on Background’. It seems reasonable undertake to expect that if parties know restrict the use and further disclosure 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. 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.3Confidential Information.
Appears in 4 contracts
Samples: Project Consortium Agreement, Project Consortium Agreement, Project 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] 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 PARTY 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. As to [NAME OF THE PARTY], it is agreed between the parties Parties that, to the best of their knowledge (please choose),
knowledge, [insert the relevant option here]. [Option 1: The 1 start] the following background Background is hereby xxxxxx identified and agreed upon for the Project. Specific limitations and/or conditions, shall be as mentioned hereunder: Describe Background Specific limitations and/or conditions [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 25.2 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”) Specific limitations and/or conditions for exploitation or Exploitation of that other Party’s Results (Article 25.316.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] ACCESSION [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: Goals: What further research activity or other training is needed to attain these goals? 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 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.
Appears in 3 contracts
Samples: Consortium Agreement, Consortium Agreement, 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] 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 PARTY 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. As to [NAME OF THE PARTY], it is agreed between the parties Parties that, to the best of their knowledge (please choose),
knowledge, [insert the relevant option here]. [Option 1: The 1 start] the following background Background is hereby xxxxxx identified and agreed upon for the Project. Specific limitations and/or conditions, shall be as mentioned hereunder: Describe Background Specific limitations and/or conditions [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 25.2 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”) Specific limitations and/or conditions for exploitation or Exploitation of that other Party’s Results (Article 25.316.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] ACCESSION [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) Governance structure for Medium and Large Projects [To use the following paragraphs it is recommended to do as follows:
Appears in 2 contracts
Samples: Consortium Agreement, 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. 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] 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 PARTY 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. As to [NAME OF THE PARTY], it is agreed between the parties Parties that, to the best of their knowledge (please choose),
knowledge, [insert the relevant option here]. [Option 1: The 1 start] the following background Background is hereby xxxxxx identified and agreed upon for the Project. Specific limitations and/or conditions, shall be as mentioned hereunder: Describe Background Specific limitations and/or conditions [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 25.2 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”) Specific limitations and/or conditions for exploitation or Exploitation of that other Party’s Results (Article 25.316.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] ACCESSION [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) Governance structure for Medium and Large Projects [To use the following paragraphs it is recommended to do as follows:
Appears in 2 contracts
Samples: Consortium Agreement, 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 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. As to [NAME OF THE PARTY], 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
Appears in 2 contracts
Samples: Consortium Agreement, 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 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 PARTY 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. 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.325.3 Grant Agreement) … … ..
Appears in 2 contracts
Samples: Consortium Agreement, 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 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. 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),
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.3FP7 DESCA if you prefer this approach.
Appears in 1 contract
Samples: Consortium Agreement
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. BENEFICIARY BRGM As to [NAME OF THE PARTY]BRGM, it is agreed between the parties Participants that, to the best of their knowledge (please choose)knowledge,
Option 1: The 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 Exploitation (Article 25.325.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
Appears in 1 contract
Samples: 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 The Parties agree that this Consortium Agreement may be executed by electronic signatures in separate counterparts, which shall be considered as equivalent to an original signature for all Parties to sign purposes and shall have the same document at the same timeforce and effect as an original signature. 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 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 PARTY 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. As to [NAME OF THE PARTY], Erasmus Universitair Medisch Centrum Rotterdam it is agreed between the parties Parties that, to the best of their knowledge (please choose),
Option 1: The knowledge, the following background Background is hereby identified and agreed upon for the Project. Specific limitations and/or conditions, shall be as mentioned hereunder: Describe Background Specific limitations restrictions and/or conditions for implementation (Article 25.2 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”) Prostate cancer risk calculator The risk calculator is freely available on the internet and will be used in the pilot studies Exploitation is not allowed This represents the status at the time of signature of this Consortium Agreement. As to Stichting Europese Studie Prostaatkanker Screening (ERSPCF) it is agreed between the Parties that, to the best of their 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 restrictions and/or conditions for exploitation implementation (Article 25.316.4 Grant Agreement and its Annex 5, Section “Access rights to results and background”, sub-section “Access rights to background 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”) and results for implementing the Action”) ERSPC/ERSPC Foundation No specific restrictions - as this No specific restrictions - as this will bring in knowledge and input is based on knowledge and input is based on knowledge knowhow on screening for knowhow on screening for and knowhow on screening for prostate cancer. prostate cancer. prostate cancer. This represents the status at the time of signature of this Consortium Agreement. PARTY 4 PARTY 5 PARTY 6 PARTY 7 PARTY 8 PARTY 9 PARTY 10 PARTY 11 PARTY 12 PARTY 13 As to Universiteit Gent (UG) it is agreed between the Parties that, to the best of their 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 restrictions and/or conditions for implementation (Article 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”) Expertise in health economic evaluation of screening programmes No specific restrictions No specific restrictions Expertise in systematic literature review of cost- effectiveness studies (soft IP); not to be kept confidential No specific restrictions No specific restrictions This represents the status at the time of signature of this Consortium Agreement. PARTY 15 PARTY 16 PARTY 17 PARTY 18 PARTY 19 PARTY 20 As to International Agency for Research on Cancer (IARC) it is agreed between the Parties that, to the best of their 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 restrictions and/or conditions for implementation (Article 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”) Any data, materials, know- Access Rights will be granted to Any other use or exploitation of how, expertise, techniques the extent IARC’s Background is IARC’s Background will be and methods, and any other Needed for implementation of the subject to a separate intellectual property rights of Project, and to the extent that agreement to be negotiated in IARC that are necessary for such Background is not subject to good faith with IARC. the implementation of the specific terms and conditions Project through existing agreements that may hinder or prohibit the envisaged Access Rights. IARC’s Background will be made available for the duration of, and for the purpose of research/ academic activities within the Project. This represents the status at the time of signature of this Consortium Agreement. PARTY 21 PARTY 22 PARTY 23 PARTY 24 As to EPSRC it is agreed between the Parties that, to the best of their 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 restrictions and/or conditions for implementation (Article 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”) ERSPC/ERSPC Foundation No specific restrictions - as this No specific restrictions - as this will bring in knowledge and input is based on knowledge and input is based on knowledge knowhow on screening for knowhow on screening for and knowhow on screening for prostate cancer. prostate cancer. prostate cancer. This represents the status at the time of signature of this Consortium Agreement. ACCESSION [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 made 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) [to be completed if relevant/required] [to be completed if relevant/required] THIS NON DISCLOSURE AGREEMENT (this “Agreement”) is made and entered into as of the [insert date] (the “Effective Date”), by and between: [X] Consortium Members, as defined below and listed in Exhibit 1; and [insert Recipient’s name and Recipient’s address] (“Recipient”)
Appears in 1 contract
Samples: 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] 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 PARTY 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. As to [NAME OF THE PARTY], it is agreed between the parties Parties that, to the best of their knowledge (please choose),
knowledge, [insert the relevant option here]. [Option 1: The 1 start] the following background Background is hereby xxxxxx identified and agreed upon for the Project. Specific limitations and/or conditions, shall be as mentioned hereunder: Describe Background Specific limitations restrictions and/or conditions for implementation (Article 25.2 16.4 Grant AgreementAgreement and its Annex 5, Section “Access rights to results and background”, sub-section “Access rights to background and results for implementing the Action”) Specific limitations restrictions and/or conditions for exploitation Exploitation (Article 25.316.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] ACCESSION [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) Governance structure for Medium and Large Projects [To use the following paragraphs it is recommended to do as follows:
Appears in 1 contract
Samples: 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] 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 PARTY 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. As to [NAME OF THE PARTY], it is agreed between the parties Parties that, to the best of their knowledge (please choose),
knowledge, [insert the relevant option here]. [Option 1: The 1 start] the following background 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 [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 25.2 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”) Specific limitations and/or conditions for exploitation or Exploitation of that other Party’s Results (Article 25.316.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] ACCESSION [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) Governance structure for Medium and Large Projects
Appears in 1 contract
Samples: 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 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 Access Rights to Background made available to the Parties: a. b. ... This represents the status at the time of signature of this Consortium Agreement. Background excluded from Access Rights: a. b. ... This represents the status at the time of signature of this Consortium Agreement. [Attachment 13: Background includedAccession document] According ACCESSION of a new Party 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 [Acronym 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] 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. 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 their knowledge (please choose),
Option 1a 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: The following background is hereby identified and agreed upon for the ProjectListed Affiliated Entities] If you have used option 1 in Art. Specific limitations and/or conditions9.5, Attachment 4 shall be as mentioned hereunderdeleted [Attachment 5: Describe Background Specific limitations and/or conditions List of Third Parties] List of Third Parties to which transfer of Foreground is possible with prior notice to the other Parties and for implementation which the other Parties have waived their right to object. Governance structure for Small Collaborative Projects Choose [Module GOV SP] for Small Projects with a simple governance structure: only one governance board (Article 25.2 Grant Agreement) Specific limitations and/or conditions for exploitation General Assembly). Main difference: [Module GOV LP] has two governance boards (Article 25.3General Assembly and Executive Board)
Appears in 1 contract
Samples: 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] 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 PARTY 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. As to [NAME OF THE PARTY], it is agreed between the parties Parties that, to the best of their knowledge (please choose),
knowledge, [insert the relevant option here]. [Option 1: The 1 start] the following background Background is hereby xxxxxx identified and agreed upon for the Project. Specific limitations and/or conditions, shall be as mentioned hereunder: Describe Background Specific limitations and/or conditions [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 25.2 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”) Specific limitations and/or conditions for exploitation or Exploitation of that other Party’s Results (Article 25.316.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] ACCESSION [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) Governance structure for Medium and Large Projects
Appears in 1 contract
Samples: 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. 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 (please choose),
Option 1: The 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 (Article 25.2 Grant Agreement) Specific limitations and/or conditions for exploitation Exploitation (Article 25.325.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.
Appears in 1 contract
Samples: 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 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 copiesSignature(s) to all Parties. [INSERT NAME OF PARTY] Name(s) Title(s) Date Signature(s) Name(s) Title(s) Date 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 Annex 1: Background included] According to the Grant Framework Partnership Agreement (Article 2430.1) Background is defined as “data, know-how or information (…) that is needed to implement the action Project 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 annex.
PARTY 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. As to [NAME OF THE PARTY], 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 Agreement31.2 FPA) Specific limitations and/or conditions for exploitation 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.331.2 FPA) or exploitation of that other Party’s Results. This represents the status at the time of signature of this Consortium Agreement.
PARTY 2 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 31.2 FPA) Specific limitations and/or conditions for exploitation ( Option 2: No data, know-how or information of [NAME OF THE PARTY] shall be Needed by another Party’s for implementation of the Project (Article 31.2 FPA) or exploitation of that other Party’s Results. This represents the status at the time of signature of this Consortium Agreement. Etc. [Annex 2: Accession document] ACCESSION [Acronym of the Project] Consortium Agreement, version […, YYYY-MM-DD] [OFFICIAL NAME OF THE NEW PARTY hereby consents to become a Party to the Consortium Agreement identified above and accepts all the rights and obligations of a Party 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] Project Leader Signature(s) Name(s) Title(s) [Annex 3: List of Third Parties for simplified transfer according to Article 8.2.2.] [Option: Annex 4: Identified Affiliated Entities according to Article 8.5] Simple Letter Agreement for the Transfer of Materials concluded under and subject to the terms and conditions of the [insert acronym] Consortium Agreement, which is based upon Regulation (EU) No 1290/2013 of the European Parliament and of the Council of 11 December 2013 laying down the rules for the participation and dissemination in “Horizon 2020 – the Framework Programme for Research and Innovation (2014-2020)”, the Framework Partnership Agreement with the European Institute of Technology with the effective date of DD/MM/YYYY and the Specific Agreement entered into by the KIC LE. In response to the RECIPIENT’s request for [insert description] (the MATERIAL). The PROVIDER asks that the RECIPIENT and the RECIPIENT SCIENTIST agree to the following before the RECIPIENT receives the MATERIAL:
1. The above MATERIAL is the property of the PROVIDER and is made available solely within the frame of the project entitled “[insert full project title]”, acronym “[insert acronym]” (hereinafter the “[acronym] Project”).
2. If and to the extent that the MATERIAL constitutes a genetic resource and any associated Confidential Information constitutes traditional knowledge associated with such genetic resource, PROVIDER declares that to the best of its knowledge:
(i) the MATERIAL and any associated Confidential Information has been obtained, exported and imported in accordance with all applicable statutory legislation and regulations, with special consideration to the Convention on Biological Diversity, the Nagoya Protocol and any applicable access and benefit-sharing legislation or regulatory requirements;
(ii) it is not aware of any third party rights in the MATERIAL and any associated Confidential Information that would preclude it from supplying the MATERIAL and such associated Confidential Information to the RECIPIENT in accordance with this Material Transfer Agreement; and
(iii) the information contained in the Genetic Resource and/or Traditional Knowledge Form attached hereto is correct, up to date, complete and accurate. The PROVIDER undertakes to provide the RECIPIENT with any and all information required for the RECIPIENT to fulfil its own obligations towards the country of origin, the provider country, and indigenous and local communities pursuant to the Convention on Biological Diversity, the Nagoya Protocol and any applicable access and benefit-sharing legislation or regulatory requirements.
3. THIS MATERIAL IS NOT FOR USE IN HUMAN SUBJECTS.
4. The RECIPIENT agrees not to analyze the MATERIAL beyond the purpose of the implementation of its action tasks under the Project, including analyses determining the composition, chemical properties or method of production of the MATERIAL.
5. The MATERIAL will be exclusively and restrictedly be used in the RECIPIENT’s laboratory for [specify] for not-for-profit research purposes related to the [insert acronym] Project only. The MATERIAL will not be further distributed to others, either within or outside the RECIPIENT’s organisation, without the PROVIDER’s prior written consent.
6. The RECIPIENT agrees to acknowledge or properly refer to the source of the MATERIAL in any publications reporting use of it, unless the PROVIDER expressly indicated otherwise. In the latter case, the RECIPIENT’s publications should not refer to or be linked in any way with the PROVIDER’s name, or any variation, adaption or abbreviation thereof, or any trademark owned by the PROVIDER or any of its Affiliated Entities.
7. Any MATERIAL delivered pursuant to this Agreement is understood to be experimental in nature and may have hazardous properties. THE PROVIDER MAKES NO REPRESENTATIONS AND EXTENDS NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED. THERE ARE NO EXPRESS OR IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, OR THAT THE USE OF THE MATERIAL WILL NOT INFRINGE ANY PATENT, COPYRIGHT, TRADEMARK, OR OTHER PROPRIETARY RIGHTS. Unless prohibited by law, RECIPIENT assumes all liability for claims for damage against it by third parties which may arise from the use, storage or disposal of the MATERIAL except that, to the extent permitted by law, the PROVIDER shall be liable to the RECIPIENT when the damage is caused by the gross negligence or willful misconduct of the PROVIDER.
8. The RECIPIENT agrees to use the MATERIAL in compliance with all applicable statutes and regulations.
9. [Optional: The MATERIAL is provided at no cost.]
10. Upon completion of the Project, the RECIPIENT shall immediately cease (i) the use of the MATERIAL and (ii) return any remaining MATERIAL to PROVIDER. At the PROVIDER’s request, the RECIPIENT shall destroy all materials which contain or are based on or derived from the MATERIAL or any part thereof in accordance with all applicable laws and regulations. The PROVIDER, RECIPIENT and RECIPIENT SCIENTIST must sign both copies of this letter and return one signed copy to the PROVIDER. The PROVIDER hereby expressly waives any right it may have to litigate against the RECIPIENT SCIENTIST. The PROVIDER will then send the MATERIAL. PROVIDER INFORMATION and AUTHORISED SIGNATURE Provider Scientist: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Provider Organisation: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Address: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Name of Authorised Official: . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Appears in 1 contract
Samples: Consortium Agreement
