JHS 166 Terms and Conditions of Public IT Procurement

Annex 4. Special Terms and Conditions for Projects Implemented Using Agile Methods (JIT 2015 – Agile Methods)

  • Version: 2.2
  • Published: 25 June 2018
  • Valid until: until further notice

INSTRUCTIONS FOR USE

Special terms and conditions for the procurement of client's applications include the Special Terms and Conditions for the Procurement of Client’s Application under Open Source Software Terms (JIT 2015 – Client’s Applications Open Source), the Special Terms and Conditions for the Procurement of Client’s Application under Software Terms Other than Open Source (JIT 2015 – Client’s Applications Non-Open), and the Special Terms and Conditions for Projects Implemented Using Agile Methods (JIT 2015 – Agile Methods). Before any application procurement, the client must always select the most suitable special terms and conditions. In some cases, it may be appropriate to enable, in the invitation to tender, the submission of tenders based on different special terms and conditions.

In the Special Terms and Conditions for Projects Implemented Using Agile Methods (JIT 2015 – Agile Methods), “client's application” refers to a program or its part produced specifically for the client, and any expansions, modifications, additions (such as interfaces), configurations and parameterisations of standard software which are made by the supplier for the client and delivered by applying agile delivery methods. These terms and conditions are intended to be used in projects that are implemented e.g. by using the Scrum or XP method or by other such agile project models where the supplier bears the delivery responsibility for the client's application to be delivered as the end result of the project. The suitability of the definitions used in the terms and conditions should always be checked against the project model used.

The delivery of the client's application may also include standard software if so expressly agreed in the agreement.

Under these terms and conditions, the client procures the application under an open source software licence. The use of an open source licence offers advantages, particularly in the following situations:

  • When procuring the client's application for activities that are carried out in a similar or corresponding manner by several procurement units.
  • When procuring an application subject to special publicity or transparency requirements.
  • When procuring an application which is to be integrated with other systems, requiring cooperation between several parties. In such case, it should also be considered whether the supplier should be required to develop the application in public in the manner enabled by Section 18 of these terms and conditions in order to facilitate cooperation with other partners of the client.
  • In using these Special Terms and Conditions, it may be necessary to consider in some situations whether the client's application or parts thereof should be procured under a licence other than an open source code licence. In such cases, the invitation to tender and agreement should include the following changes to these terms and conditions and specify the extent to which the changes concern the object of the invitation to tender:

    Sections 17–19 of these Special Terms and Conditions shall be removed. Subsections 4–12 of Section 12 of these Special Terms and Conditions shall be replaced by the following section:

    12 Rights

    (4) The client shall have the unrestricted right, without any extra charge, independently or assisted by an external service provider, and without being limited by the copyright, intellectual property rights or business or professional secrets of the supplier or a third party, to:

        1. use the client's application in its own activities,
        2. modify and develop the client's application further for its own use,
        3. make copies of the client's application for its own use,
        4. use the material and know-how generated in conjunction with the production of the client's application in connection with other applications,
        5. transfer the client's application to another hardware platform or operating system environment or geographic location; however, taking into account any export restrictions,
        6. transfer rights to use the client's application to third parties, if this is required for the performance or reorganisation of the client's tasks,
        7. receive the right of use and possession to the machine and source code versions of the client's application.

    When exercising these rights, the client shall ensure that the supplier's business secrets remain confidential in accordance with the Act on the Openness of Government Activities.

    distribute the copies, either in modified or unmodified form, to third parties, and transfer this right, or any part thereof, to third parties.

    (6) The client's afore-mentioned rights do not alter or expand the warranty or any other liabilities of the supplier from the provisions of warranty or acceptance or other obligations or requirements which applied to the client’s application in its original application environment.

    These terms and conditions are not suited to application procurement implemented following the so-called waterfall model. In projects that follow the waterfall model, work proceeds in clear stages so that the acceptance of the preceding stage is a precondition for the next stage (e.g. specification – design – implementation – testing). Special terms and conditions for the procurement of client's applications (Annexes 2 and 3) are intended to be used for projects following the waterfall model. Furthermore, these terms and conditions should not be used for projects where the supplier only places experts available for the client and is not responsible for the actual delivery of the client's application. It is recommended that Special Terms and Conditions for Consulting Services be used in these cases.

    The object of delivery must fulfil the absolute requirements agreed upon in the agreement, together with the optional requirements, the implementation of which has been agreed upon during the project. On the basis of these requirements, more detailed specifications concerning the implementation and a project plan are usually prepared. During the project, both the project plan and the delivery schedule of different items and of functionalities on the task list are flexible. What is essential is that the absolute requirements and the functionalities accordant with the specifications that concern these requirements are implemented during the project. The implementation schedule and order of even absolute requirements may be changed during the project in accordance with the agreed procedure.

    Agile methods require substantial participation by the client and that the client is prepared for quick decision-making. According to the manifesto for agile software development, i.e. the Agile Manifesto, agile software development values the individual and interaction over methods and tools, working software over comprehensive documentation, customer collaboration over contract negotiations, and responding to change over following a plan. (Source: http://agilemanifesto.org/iso/fi/). What is essential in agile methods is feedback during the delivery project, continuous evaluation and flexible modification of different versions and functionalities, as well as the re-evaluation and modification of the scope and delivery method. Special attention must be paid to the sufficient documentation of the code of the application. The client must have sufficient and competent resources in order to make these evaluations and decisions during the project in accordance with the project schedule. It is often useful to obtain feedback from the end users of the application. If there are any delays in evaluations and solutions or if it becomes evident only at a later project stage that the end result is not in accordance with the objectives, there may be additional costs, the distribution and pricing of which should be agreed in the agreement, if necessary.

    As specified in JIT 2015 – General Terms and Conditions, the contracting parties should pay attention to ensuring that all specifications fulfil the requirements. If it becomes apparent in the specification phase that a requirement will not be fulfilled or that it will not be e.g. expedient to implement it, the supplier must notify the client of this and the matter must be handled through the change management procedure.

    If it becomes apparent during the project that fulfilling the client's requirements or the performance of additional work requires modifications to the client's operating environment, the supplier must notify the client of these modifications without any undue delay. Correspondingly, the client must notify whether it intends to carry out these modifications or whether the functionalities will be implemented so that no modifications will be made.

    The definition of "complete" must be agreed upon in the agreement. According to Section 8.2, the results of an iteration may be accepted if the client confirms that they fulfil the agreed criteria for acceptance. These criteria may differ from one work stage to the next.

    With regard to specification iterations, for instance the following may be agreed: “The definition of "complete" is initially the following: "Complete" is a result or version which is to be completed at each time. Unless otherwise agreed, the objective of an iteration is to produce a "complete" result or version which fulfils the requirements set for it, has been tested and is functional. The definition of "complete" is adjusted to refer to an ever higher quality as the project proceeds. "Complete" is defined by the client and the supplier at the beginning of each iteration, and the definition is entered in a memorandum. Ultimately, the client has the right to decide on the definition of "complete."”

    With regard to implementation iterations, for instance the following may be agreed:

    • All tasks assigned to the iteration have been performed and marked as completed.
    • The result of the iteration fulfils the requirements set for the iteration.
    • The source code related to the iteration is complete and has been commented appropriately.
    • Unit and regression tests are completed successfully without identifying any defects.
    • The products and interfaces of the iteration have been documented in detail.
    • The result of the iteration has been installed in the required environments.

    The client often procures the application so that it is built upon standard software which is parameterised or supplemented to meet the client's requirements. The agreement must specify the object of delivery, its absolute and other requirements, as well as any standard software included in it. Attention should also be paid to the following:

    • The supplier is responsible for ensuring the technical functionality of the solution within the scope agreed upon in the agreement, and for the fulfilment of absolute and other agreed requirements.
    • Work will often be carried out in the client's premises in full or in part.
    • The testing and acceptance procedures apply to the entire object of delivery, including any related standard software.
    • Provisions on testing and approval procedures have been added to these Special Terms and Conditions for agile methods. However, it is usually necessary to agree in more detail in the agreement on both the testing and evaluation to be conducted during the project and on the acceptance testing and acceptance process. Documentation forms an essential part of the product or service. Documentation concerning the object of delivery should be reviewed in conjunction with testing.
    • During agile projects, up-to-date, clear and appropriate documentation should be produced of decisions made during the project and the grounds for them, and of any changes to schedules, the scope of the project, requirements and specifications as well as the approvals related to the foregoing. It should be noted that, from the viewpoint of procurement legislation, the absolute requirements set forth already in the invitation to tender can be altered only to a limited extent.
    • If the delivery includes standard software programs, they must be itemised in the agreement. Unless otherwise agreed, operating systems and database management programs may be standard software licenced under terms and conditions other than those of open source software; however, standard software must otherwise be licenced under the terms and conditions of open source software. Rights of use to standard software are primarily determined according to their own licence terms and conditions. The scope of the rights of use to standard software must correspond with the requirements presented by the client in its invitation to tender.
    • It should be noted that the source code of closed third-party standard software cannot usually be obtained or stored even by escrow agents. In these situations, the source code can principally be stored only for that part of the solution the source code of which is held by the supplier and the source code of which it is entitled to transfer.
    • Agile deliveries may be priced in various ways. Pricing models may be linked to time or results or to combinations of these. Possible pricing models include a purely time-based pricing, a target price, a pricing model based on a function point analysis or a corresponding scheme, a ceiling price for a specific period, etc. It should be noted that a pricing model based purely on a fixed price should be avoided because, as such, it does not enable an agile delivery model which is significantly associated with flexibility and the possibility to make changes.
    • The agreement must also include a pricing model for the implementation of any optional requirements and for any additional work.
    • These Special Terms and Conditions for Projects Implemented Using Agile Methods can be used together with the terms and conditions of open source code.

    Software is developed in source code form and, for the purposes of code management, the source code is maintained in a version control system. The starting point of the terms and conditions is that the source code is released in a public version control system after development, but no later than within thirty (30) days of the acceptance of the delivery. The terms and conditions also provide for the use of a public version control system already at the beginning of the development work so that anyone can monitor the development process. This is advantageous if the project requires, e.g., cooperation between several suppliers, the customer or other parties.

    There are a number of open source software licences. The definition of open source software and a list of associated licences are available at http://www.opensource.org/. The EUPL 1.1 licence is available at http://joinup.ec.europa.eu/software/page/eupl/licence-eupl. See also JHS 169 Use of open source software in public administration.

    Primarily, there should be no restrictions for licences used so that as many different technologies as possible can be offered (or suitable components can be selected during the project). If the procurement unit has a justifiable reason to require a specific open source software licence from the supplier, the licence should be defined in the invitation to tender and a corresponding stipulation should be added to the agreement. Such a reason could, in certain situations, be the use of specific open source code software by the procurement unit, for example. Usually, compatible licences should also be permitted. In some cases, the client may want to use several licences in its relicensing, i.e. a dual licence.

    In the application procurement phase, special attention must be paid to the prevention of vendor lock-in by preparing to withdraw from the use of the system during or at the end of the system life cycle and for the costs resulting from it. According to these terms and conditions, the supplier has the obligation to design the object of delivery so that data can be detached in a reasonable manner. Any costs arising from the withdrawal from the application should be taken into account in the offer comparison phase already when procuring the specific application.

    For the procurement of a client's application, a procurement agreement must always be entered into. These standard and conditions are attached to the procurement agreement, together with JIT 2015 General Terms and Conditions. With regard to the order of interpretation, these Special Terms and Conditions take precedence over the General Terms and Conditions. Where deviations with respect to the special and general terms and conditions are necessary, provisions on such deviations should be included in the procurement agreement.

    On the date of publication of this recommendation, the portal referred to in Section 17 (7) is avoindata.fi.

    Requirements concerning the use of open interfaces should preferably be defined in the invitation to tender. Annex 10 of the recommendation JHS 166 offers supporting material for the use of open interfaces.

    These use instructions do not form part of the agreement.

    Agreement date and no.: _____________________________Annex no.: _____________

    JIT 2015: Special Terms and Conditions for Projects Implemented Using Agile Methods

      1 Scope of application

    (1) These Special Terms and Conditions shall be applied to projects implemented using agile methods upon assignment by a public procurement unit and carried out to meet the client's specific needs and according to the client's requirements, if these Special Terms and Conditions have been referred to in the agreement and to the extent it has not been otherwise agreed in in writing.

    (2) These Special Terms and Conditions are used together with the General Terms and Conditions of Public IT Procurement. In case of any conflict, these Special Terms and Conditions take precedence over the aforementioned General Terms and Conditions of Government IT Procurement with regard to their corresponding provisions.

      2 Definitions

    In addition to the following definitions of these Special Terms and Conditions, the definitions of JIT 2015 General Terms and Conditions shall be applied. In these Special Terms and Conditions, a change has been defined differently from the General Terms and Conditions due to the object of these terms and conditions.

    platform software

    fialustaohjelmisto

    generally available operating systems and database management software

    absolute requirement

    fiehdoton vaatimus

    a requirement referred to in the agreement or its appendices, according to which the properties or functionalities defined therein must be included in the object of delivery, or a quality requirement which the object of delivery must fulfil

    iteration

    fiiteraatio

    a part of the project with a limited duration, such as a Scrum method sprint, where a specific limited number of functionalities defined in the task list is implemented, and which may end in an interim acceptance

    application to be published

    fijulkaistava sovellus

    the software code included in the material to be delivered, and its documentation; however, not including client-specific software installation and definition data, nor platform software or its software code or documentation

    publication plan

    fijulkaisusuunnitelma

    a description of the content of iterations, the combination of iteration results into partial wholes, and their publication schedule

    public version control system

    fijulkinen versionhallintajärjestelmä

    a service open to the public where the software source code, together with other material associated with software development, can be maintained in an expedient manner for software development purposes

    development environment

    fikehitysympäristö

    the technical platform required for the development of the client's application agreed in the agreement, such as hardware, software and data links, and the required licences and their maintenance

    operating environment

    fikäyttöympäristö

    the technical platform (servers, system software, data links, etc.) on which the object of delivery is installed for testing or production use

    additional work

    filisätyö

    separately agreed work performed in addition to the fulfilment of the original absolute and optional requirements

    handover

    filuovuttaminen

    the handover of the object of delivery to the client for acceptance testing.

    A part of delivery can also be handed over for approval testing.

    change

    fimuutos

    an agreed addition, specification or removal concerning the agreed delivery scope or content of the object of delivery

    Change does not refer to, for example, a change made to the implementation order of agreed functionalities, changes to schedule within the total project schedule or changes in resources that do not have a larger than minor impact. A change may increase or reduce the scope of delivery.

    specifications

    fimääritykset

    the technical and functional properties defined by the contracting parties for the object of delivery on the basis of the requirements of which the contracting parties have agreed or will agree in writing

    project plan

    fiprojektisuunnitelma

    a general-level plan which describes the project concerning the object of delivery, the number and essential content of iterations, resources and schedule, and the responsibilities and tasks of different roles

    defect

    fipuute

    such deviation from the requirements which can be implemented as part of another iteration before the handover of the object of delivery and which is entered in the task list

    solution description

    firatkaisukuvaus

    a description of the object of delivery on a detailed level and of how the solution fulfils the requirements and specifications

    client's application

    fitilaajan sovellus

    software or a part thereof created for the client, expansions and additions (such as interfaces) to standard software made by the supplier for the client, configuration, parameterisation and any other possible software delivered by the supplier as part of rollout, apart from standard software

    The client's application also includes its documentation.

    function point analysis

    fitoimintopistelaskenta

    a method with which the size of the software project can be defined before implementation and verified after implementation.

    material to be delivered

    fitoimitettava aineisto

    material to be delivered refers to the material, such as software code, documentation, configuration information, instructions and other material, which the supplier delivers to the client in order to fulfil the agreement.

    With regard to software code, material to be delivered includes both the source code and the executable form of the code.

    part of delivery

    fitoimituksen osa

    part of the delivery refers to a part of the object of delivery, for which a separate delivery schedule has been agreed and which is delivered separately to the client for acceptance

    optional requirement

    fivalinnainen vaatimus

    a requirement other than an absolute requirement set for the object of delivery

    standard software

    fivalmisohjelmisto

    software or a part thereof developed and marketed by the supplier or a third party and defined as standard software in the agreement, together with its documentation

    Standard software may also be licensed with an open source code licence. Standard software or its documentation is not the client's application.

    error

    fivirhe

    the object of delivery handed over for acceptance testing does not fulfil the absolute requirements, the optional requirements agreed for the object of delivery or agreed specifications, or it does not function according to them or does not comply with the delivery documentation or with what has been otherwise agreed in the agreement

    compatible licence

    fiyhteensopiva lisenssi

    a licence, the terms and conditions of which are not in conflict with another open source software licence in a situation where the same entity is licensed at the same time under both another licence and the compatible licence or, if the method of combining different parts of the entity enables separate licensing terms for different parts, compatible licence refers to any open source software licence

      3 Delivery

    (1) These terms and conditions apply to an IT development project implemented by using agile methods where the supplier is responsible for the delivery of the client's application. The supplier shall be responsible for the management of the project, unless otherwise agreed.

    (2) The client's application has been specified in the agreement. If the object of delivery includes standard software programs, such programs and the special terms and conditions governing them, if any, must be stated in the agreement.

    (3) The supplier is responsible for ensuring that the client's application and its descriptions are in conformance with the agreement and that the work is carried out with the professional expertise required by the task and following good technical and project practices and a high quality level. The supplier is responsible, for its own part, for ensuring that the object of delivery is defined and designed so that the client is able, utilising automated systems as specified by the supplier, to convert all of the client's material stored by the application into a format conforming with the data material openness requirement. The supplier is responsible, for its own part, for ensuring that the object of delivery is defined and designed so that the processing of personal data with the application complies with the requirements set by data protection legislation.

    (4) The object of delivery covers the client's application implemented in accordance with the absolute requirements, any optional requirements agreed to be implemented during the project and the specifications agreed upon mutually on the basis of the aforementioned requirements, together with other agreed products, services, functionalities and items, including additional work and functionalities, if any. The documentation of the object of delivery includes a data description. The supplier shall not be entitled to charge separately for the delivery of the data description, unless otherwise agreed. 

    (5) The supplier shall provide an open interface to the object of delivery if a requirement for an open interface has been agreed upon in the agreement.

    (6) Unless otherwise agreed, the delivery includes the design, specification, implementation, testing and rollout of the client's application. In addition, the delivery may include other tasks, such as those associated with data conversion and personnel training, if they have been agreed upon in the agreement.

    (7) The stages, iterations, schedule and required resources of the delivery shall be agreed upon in the agreement and specified in the project documentation.

    (8) The support, maintenance and further development of the object of delivery shall be agreed upon separately.

      4 Delivery project

    (1) At the beginning of the delivery project, the supplier and the client specify and supplement the project plan and solution description and, together, prepare the preliminary specifications, tasks lists and a schedule for project results in accordance with the requirements.

    (2) The delivery project consists of several iterations, in each of which one or more functionalities stated in the task list are implemented and for each of which an iteration objective has been set. The supplier shall test the iteration results independently before handing them over to the client. Unless otherwise agreed, the supplier shall hand over the iteration results to the client for evaluation and acceptance at the end of each iteration. If the client does not accept the iteration results, the defective functionality will be returned to the task list to be implemented during an agreed later iteration.

    (3) The supplier shall regularly report to the client in the manner agreed in the project documentation on the progress of iterations and the implementation of functionalities on the task list. During and after each iteration, the task list, project documentation and schedule, as well as the resource situation and needs of the client and the supplier, shall be evaluated. The task list shall be kept up to date.

    (4) Unless otherwise agreed and specified in the project documentation, the work to be performed together by the client and the supplier shall be carried out at the client's premises, and the client's project personnel shall take part in daily or otherwise recurring project meetings with the supplier's personnel.

    (5) During the project, the supplier shall provide the client with expert assistance concerning the evaluation and selection of different implementation methods and technology alternatives.

      5 Organisation and implementation of the delivery

    (1) The contracting parties shall set up a project and a steering group for it for the fulfilment of the agreement and cooperation between the parties. Both contracting parties shall appoint their representatives to the steering group which supervises the implementation of the project as a cooperation organisation of the contracting parties. The tasks and authority of the steering group shall be defined in the agreement, and the group shall meet upon the request of the contracting parties as necessary and at a minimum after each partial delivery and other delivery phase. Minutes shall be maintained of the meetings of the steering group. The steering group may not amend the agreement.

    (2) The supplier shall appoint a project manager whose task is to report on the state and progress of the project to the project's steering group. The project manager is responsible for the planning and supervision of iterations and project work. Other tasks shall be specified in the agreement.

    (3) Both contracting parties shall appoint a contact person whose task is to monitor and supervise the fulfilment of the agreement and to communicate matters related to the fulfilment of the agreement within their organisation and to the other contracting party. Unless otherwise agreed, the supplier's project manager shall be the supplier's contact person. Each contracting party shall notify the other contracting party in good time of the replacement of its contact person, taking into account what has been agreed upon concerning the replacement of key persons below in Sections 6 and 7.

    (4) The supplier shall appoint a person responsible for the implementation of iterations who will be responsible for the task list, daily status meetings and work supervision and monitoring.

    (5) The contracting parties shall appoint the personnel resources required for the project and provide them with the authorisations agreed in the agreement in order to make decisions related to daily project work. Appointed key persons may be agreed upon in the agreement.

    (6) The contracting parties shall each on their part reserve the necessary work premises and equipment for the project.

    (7) A contracting party shall contribute to the implementation of the project in situations and contexts that are under the control of the said party. Both contracting parties shall make the decisions required to implement the project without delay.

    (8) The supplier shall cooperate and negotiate with any other suppliers and consultants used by the client, if the client so requests. Unless otherwise agreed, the supplier shall be entitled to charge for such additional work. However, the supplier must give an advance notification of any additional work thus resulting.

    (9) Unless otherwise agreed, the supplier shall produce the client's application and perform other tasks belonging to the project using the supplier's working methods.

    (10) The contracting party responsible for the development environment shall be, during the project, responsible for taking the backup copies that are part of the object of the agreement and pertain to the object of delivery and for verifying that they are functional.

    (11) The delivery project shall end once the object of delivery has been accepted in full and taken into use.

      6 The supplier's resources

    (1) The supplier shall ensure that the project has a sufficient number of personnel who have sufficient expertise and knowledge to take part in the implementation of the project and who fulfil the agreed requirements.

    (2) The supplier shall not replace the key persons named in the agreement without the client's permission for reasons other than those independent of the supplier. The client may not refuse from issuing its permission for such replacements without reasonable cause. The supplier shall always notify the client in advance in writing of replaced key persons and shall without delay name a new person in place of the person to be replaced.

    (3) Upon the justified request of the client, the supplier shall replace an individual it has appointed for the project without any undue delay.

    (4) In terms of competence, the new person must fulfil the agreed requirements.

      7 The client's resources and obligation to cooperate

    (1) The client shall ensure that there is a sufficient number of personnel for tasks related to the delivery, project meetings, the acceptance of iteration results and other tasks who have sufficient expertise and knowledge to properly contribute to the implementation of the project. Those taking part in the project must have sufficient authorisations to accept iteration results and perform other tasks required by the project.

    (2) The client shall strive not to replace the key persons named in the agreement. The client shall always notify the supplier in advance in writing of the replacement of key employees and without delay name a new person in place of the person to be replaced.

    (3) In addition to the client's tasks agreed upon in the agreement, the client shall provide the supplier with the information in the possession of the client which the supplier has requested in order to carry out its task. The client shall be responsible for the information, instructions and regulations it has issued to the supplier.

    (4) The client shall be responsible for carrying out the tasks agreed upon in the agreement within the agreed schedule.

      8 Inspecting and accepting iteration results

    (1) The purpose of the acceptance of iteration results is to ensure the progress of the project. The client shall inspect and accept or reject the iteration results within the agreed schedule so that the following iterations may begin according to the planned schedule.

    (2) The iteration results are considered accepted if the client finds that they fulfil the criteria set for their acceptance. The criteria for the acceptance of iteration results are agreed upon in the agreement, and there may be different criteria for different types of iterations or iterations performed at different stages.

    (3) The non-performance or non-acceptance of a task agreed to be performed within an iteration shall be processed as a defect, and the task will be assigned to be performed during a later iteration or it will be agreed to be changed. Any impact of this on the project price and payment points shall be agreed at the same time.

      9 Testing and accepting parts of the delivery

    (1) Unless otherwise agreed, the client shall test a part of the delivery within seven (7) weekdays after the supplier has notified in writing that testing may be started. As an exception to the foregoing, if a part of the delivery is taken into production use independently, the acceptance testing procedure agreed upon below in Section 10 shall be applied instead.

    (2) The acceptance of the part of the delivery is a precondition for the start of the first iteration of the next part of the delivery, unless otherwise agreed. Any identified defects and errors shall be entered into the task list.

    (3) The acceptance of a part of the delivery does not release the supplier from its liability for any errors that are identified during the testing of later stages and that cannot have reasonably been identified during the testing of the part of the delivery.

      10 Acceptance testing and the acceptance of the delivery

    (1) The supplier shall perform the supplier's tests specified in the agreement for the object of delivery before the supplier hands over the object of delivery to the client for acceptance testing. Unless otherwise agreed, the supplier shall perform the tests in accordance with its practices using the material supplied by the client in advance. The accepted completion of the supplier's testing is an absolute requirement for the supplier having the right to hand over the object of delivery to the client for acceptance testing. The supplier's testing is considered accepted if no errors are identified that would prevent the delivery from being accepted in accordance with Section 10(5). The supplier shall notify the client of the time when the object of delivery is ready for the client's acceptance testing and shall provide the client with an account of the testing performed and its results.

    (2) The client shall, at its own expense, bring the operating environment required in testing into compliance with the agreement, unless otherwise agreed. The supplier shall hand over the object of delivery for acceptance testing so that it is installed in the operating environment in accordance with the agreement according to the delivery schedule. The supplier shall provide the client with operating instructions for the client's acceptance testing as well as the documentation concerning the object of delivery. The supplier shall also provide the client's representatives with agreed training for the performance of the tasks in question.

    (3) The client shall perform the acceptance testing. The client shall provide an acceptance testing plan for the supplier in advance for commenting. However, the acceptance testing plan shall not be binding. Without being limited by it, the client has the right to perform any tests it deems necessary. Unless otherwise agreed, the client shall have thirty (30) days to perform the client's acceptance testing, starting from the date on which the supplier has notified in writing that the object of delivery is ready for acceptance testing, and the supplier has handed over the object of delivery for testing in accordance with Section 10(1). The supplier may not hand over the object of delivery to the client for acceptance testing before the mutually agreed date without the client’s express written consent. The contracting parties may agree that the supplier assists the client during acceptance testing.

    (4) The client shall without delay notify the supplier in writing of any errors it has identified in the application; however, no later than within three (3) weekdays after the time reserved for the client's acceptance testing has ended.

    (5) Acceptance will not be prevented by minor errors that do not prevent the object of delivery from being used in the agreed purpose of use or prevent its operation.

    (6) The object of delivery shall be deemed to have been accepted if the client has not notified of any errors within the time set out in Section 10(4) or if the client takes the application into production use.

    (7) The supplier shall immediately correct any errors discovered during acceptance testing. The supplier shall correct free of charge any errors that are due to the supplier's negligence. The time reserved for acceptance testing shall be extended by the time the supplier needs to correct the error and the client reasonably needs for the testing and acceptance of the corrected errors. If an error is caused by standard software, the supplier shall correct the error or have the error corrected at its own expense and according to its possibilities. If this is not reasonably possible, the supplier shall work around the error at its own expense. If creating a workaround is not reasonably possible through generally available means, the parties may agree upon additional work to work around the error, or the client shall be entitled to a price reduction. If the error is so significant that, due to the error, the purpose of the agreement remains essentially unfulfilled, the client shall have the right to cancel the agreement, unless the error concerns the standard software required by the client.

    (8) With regard to fixed-price deliveries, both contracting parties shall be responsible for their own costs associated with the performance of acceptance testing. In deliveries priced on the basis of working hours or amount of work, the client shall, however, compensate the supplier for its work performed in relation to acceptance testing so that the supplier is responsible for its own costs associated with any re-testing performed due to the correction of errors, if any.

    (9) Unless otherwise agreed, the delivery shall be deemed to have taken place when the object of delivery has been accepted and the supplier has fulfilled all of its contractual obligations related to the rollout of the object of delivery.

      11 Warranty

    (1) During the warranty period, the supplier shall, free of charge and without any undue delay, correct any errors detected in the object of delivery. Corrections also include amending the documentation with changes corresponding to the corrections.

    (2) The warranty does not cover errors which the client could have reasonably identified during or before acceptance testing.

    (3) The warranty period is six (6) months starting from the acceptance of the application by the client, unless otherwise agreed. If the client's application is accepted in stages, the warranty period for previously accepted stages will not expire until six (6) months have passed from the acceptance of the entire client's application.

    (4) The client has the right to demand that, before the payment of the final instalment, the supplier lodges for the client a security accepted by the client regarding the fulfilment of the warranty obligations. The security shall be fifteen (15) per cent of the total price of the agreement inclusive of value added tax, and it must remain valid for at least three (3) months after the term of the warranty period under the agreement. In case of a delay in the fulfilment of the warranty obligations, the supplier shall extend the term of the warranty period. The supplier shall be responsible for all security-related costs.

    (5) With regard to standard software, the warranty terms of the standard software in question shall be applied to the warranty.

    (6) If an error detected in the object of delivery during the warranty period is caused by standard software, the supplier shall correct the error or have the error corrected at its own expense and according to its possibilities. If this is not reasonably possible, the supplier shall work around the error at its own expense. If creating a workaround is not reasonably possible through generally available means, the parties may agree upon additional work to work around the error, or the client shall be entitled to a price reduction. If the error is so significant that, due to the error, the purpose of the agreement remains essentially unfulfilled, the client shall have the right to cancel the agreement, unless the error concerns the standard software required by the client.

    (7) The warranty shall expire to the extent the client modifies the client's application or the specified application environment without agreeing on it in writing with the supplier, or the client's application is used for purposes other than its intended purpose of use or in violation of instructions concerning its use, or the error is caused by some other reason attributable to the client.

      12 Rights

    (1) The right of ownership to data media containing the applications that are the object of the agreement shall be transferred to the client once the data media have been delivered.

    (2) The right of ownership and intellectual property rights to the client's material belong to the client or a third party, and they are not assigned to the supplier. The supplier shall have the right to process the client's material only for purposes pertaining to the fulfilment of the agreement.

    (3) Unless otherwise agreed, copyright and other intellectual property rights to the client's application and the associated documentation, the client's material excluded, is held by the supplier or a third party. The client's copyright or other intellectual property rights shall not be transferred to the supplier, unless otherwise separately agreed upon.

    (4) The supplier shall grant the right to use the material delivered to the client without additional charges under the terms and conditions of open source code software. If the client and the supplier have not agreed upon the open source licence to be used, the supplier shall specify the open source licence to be applied. If several open source licences are applied to the material delivered, all licences must be mutually compatible.

    (5) The supplier shall notify the client of the open source licence to be applied no later than before the delivery of the application or, if the client requests the supplier to specify the licence earlier, within thirty (30) days of the client's written request. If the supplier does not specify any licence, the supplier shall grant the client, without any additional charge, a royalty-free, permanent, irrevocable and non-exclusive right to, independently or with the assistance of an external service provider and without being limited by copyrights and intellectual property rights of the supplier or any third party:

        1. use the client's application for any purpose,
        2. modify and further develop the client's application,
        3. make copies of the client's application,
        4. distribute the copies, either in modified or unmodified form, to third parties, and
        5. transfer this right, or any part thereof, to third parties.

    (6) The supplier assures that the client may utilise the aforementioned rights without being limited by any business or professional secrets of the supplier or a third party.

    (7) The supplier and the client are entitled, without hearing the other party, to utilise the client's application and any material and know-how they have generated in conjunction with the agreement. This agreement does not remove the client's obligation to take any export limitations into account.

    (8) The supplier must hand over the material to be delivered to the client.

    (9) The supplier shall ensure that each and every licence in the material to be delivered is compatible with other licences in the material to be delivered and with the licence requirement specified by the client in the agreement, if any. The client commits to complying with the open source licence terms applicable to the material it has received.

    (10) The supplier's liability for errors towards the client is determined based on the agreed purpose and extent of use, and nothing agreed regarding the client's rights in this Section 12 of these Special Terms and Conditions shall increase the supplier's liability for errors.

    (11) Regardless of the open source code licence selected by the supplier, the supplier shall be responsible towards the client for any part of delivery it has made itself or contracted to its subcontractor as set out in Sections 6 (2) – 6 (7) of JIT 2015 – General Terms and Conditions.

    (12) The delivery may include platform software if such software and the terms and conditions governing it have been specified in the agreement or if the client has later approved them. The provisions of Section 12 (4) do not apply to platform software which is governed by the applicable terms and conditions of standard software. The supplier shall not be liable towards the client for breaches of intellectual property rights associated with third-party platform software, except to the extent the third party in question has committed to the same towards the supplier under the standard terms and conditions of the platform software.

      13 Maintenance

    (1) The supplier shall provide the client's application, together with agreed standard software, with separately agreed support and maintenance services. The supplier commits to offering these support and maintenance services for the duration of at least one (1) year, starting from the acceptance of the client's application.

      14 Storing the source code of standard software

    (1) If the client so demands, the supplier shall contribute to ensuring that the source code of the standard software included in the object of delivery, together with any modifications and additions made thereto for the client, is stored in the possession of an impartial provider of a source code storing service (an escrow agent) so that the client obtains the source code and the rights to use it in case:

        1. the holder of the rights to the standard software is declared bankrupt or placed into liquidation, or
        2. maintenance is not available for the object of delivery from the supplier, the right holder of the standard software in question, or from any third party, under terms and conditions substantially similar to those agreed upon by the supplier and client.

      15 Change management

    (1) When applying these terms and conditions, a change is considered not to include changes in the order of implementation of agreed functionalities, changes in schedule within the total project schedule, resource changes with only a minor impact, or any other similar minor changes.

    (2) All changes and their impact on the delivery schedule or price shall be agreed upon in writing following a mutually agreed procedure. A change may increase or reduce the scope of delivery.

    (3) The client shall compensate for the changes if they result in additional work and costs for the supplier. This requires that compensation for changes has been agreed upon in writing in advance.

      16 Delays

    (1) If the object of delivery fulfilling the absolute requirements, or a part thereof, is not delivered within the agreed schedule, this shall be regarded as a delay. The non-performance or non-acceptance of a task agreed to be performed within an iteration shall not be regarded as a delay; instead, it will be processed in accordance with Section 8(3).

    (2) If a contracting party finds that it will be delayed in its delivery or in its performance of an obligation or considers such delay probable, the contracting party must, without delay and in writing, notify the other contracting party of the delay and its impact on the fulfilment of the agreement. The contracting parties shall agree upon a new delivery time, if required.

    (3) If the delivery, or a part of the delivery which is meant to be taken into production use independently, is delayed due to a reason under the responsibility of the supplier, the supplier shall pay a contractual penalty to the client for every commencing seven (7) day period of time by which the supplier exceeds the due date agreed for the delivery or its part under the agreement. The penalty for each above-mentioned period shall be 0.5 per cent of the purchase price of the delayed object of delivery. However, the maximum penalty is 7.5 per cent of the afore-mentioned price. The amount of damage caused by the delay does not affect the amount of the penalty. A delay in the delivery of documents and information, which prevents the use of the object of delivery, shall be considered comparable to a delay in the delivery.

    (4) The supplier shall not be entitled to receive a contractual penalty due to the client's delay.

      17 Open publication of the application

    (1) The supplier shall publish the application within thirty (30) days of the acceptance of the object of delivery in a manner deemed appropriate by the supplier, unless otherwise separately agreed. The publication shall take place in a manner which supports version control so that the application to be published is publically available under the open source licence determined in accordance with Section 12 (4).

    (2) If no licence has been determined in accordance with Section 12 (4), the supplier shall use the following licensing statement when publishing the application: "This program and its documentation are licensed under the EUPL 1.1 licence or, at the licensee’s option, any later version thereof." If the licensing of the parts used in the application to be published is not compatible with the EUPL 1.1 licence, the supplier shall use the following licensing statement with respect to these parts: "This program and its documentation are licensed under the MIT licence."

    (3) The supplier shall copy and add the text of the applicable licences in connection with the application to be published.

    (4) Insofar as the application to be published includes modifications of or expansions to parts of other open source code projects, such modifications and expansions shall primarily be published so that they are offered as contributions to the open source code project in question. In this respect, the supplier shall license the modifications and expansions in accordance with the practices of the open source code project in question. If publication is not reasonably possible in this manner, it shall, in any case, be carried out in accordance with Section 17 (1).

    (5) Upon publishing the application, the supplier may announce extensive limitations of liability for the benefit of the supplier, but they shall not affect the supplier's liability towards the client under this agreement. Furthermore, this agreement shall not prevent the supplier, if it so desires, from being committed to a maintenance responsibility for the application to be published towards a third party.

    (6) Prior to the publication and also during the maintenance of the application to be published, the supplier shall ensure that the application to be published does not include any of the client's confidential information or any other client-specific information, such as specifications, addresses, credentials or passwords related to the use of the information system. If required, the client shall contribute to specifying the information that is to be kept confidential.

    (7) The supplier is obligated to publish information about the publication of the application to be published in the portal for compatibility descriptions and specifications maintained by the Finnish Government within thirty (30) days of the publication. The information shall, at minimum, include the publication date, a description and a location.

      18 Development model

    (1) If so agreed in the agreement, the client may demand the supplier to develop the application to be published in a public version control system.

      19 Maintenance of the application to be published

    (1) The supplier shall maintain the application to be published for a period of at least twelve (12) months starting from the acceptance of the object of delivery. Unless otherwise agreed, the maintenance shall include ensuring the availability of the application in accordance with Sections 17 (1) and 17 (2), and the entry of corrections to errors and of other modifications under the agreement into a public version control system at minimum at intervals of six (6) months as well as updates of information published in the portal in accordance with Section 17 (7) when necessary.

    (2) The client and the supplier may agree upon extending the maintenance of the application to be published beyond the afore-mentioned scope. In such case, if the content of the extended maintenance of the application to be published is not agreed upon in more detail, the following terms and conditions shall be applied to the extended maintenance:

        1. In addition to the tasks set out in Section (1) above, the maintenance activities shall include general provision of information to third parties about the state and the development roadmap of the application. The supplier's obligation and the client's commitment shall be limited to the amount of work agreed upon.
        2. The supplier shall report to the client at agreed intervals and in the agreed manner or, unless otherwise agreed, at intervals of six (6) months, on any communications and actions taken and, at the same time, shall hear the client's opinions on further actions. The supplier's shall take the client's opinions, together with the opinions of any other user organisations, into account as it deems best. However, the supplier shall not have, unless otherwise agreed, the obligation to take concrete action on the basis of the client's opinions.
        3. The supplier shall have the right to invoice the extended maintenance of the application to be published from the client based on time spent and at agreed prices. If extended maintenance for the same application to be published is acquired by several parties, any single maintenance tasks shall be charged only once.
        4. Either contracting party may terminate the extended maintenance of the application upon three (3) months’ notice.