Summary

• General Comments
• When Mediation / Arbitration will be used
• Mediation
• Arbitration
• How to Request Mediation / Arbitration
• General Notes on the Arbitration
• The Arbitration Procedure
• Arbitration Scenarios
• Harassment, Unsolicited Contact & Foul Play
• Exclusion of Liability
• Waiver of Deformation
• The Agreements

General Comments

The aim of mediation and arbitration is to settle fairly any disputes that arise between a Purchaser and a Developer. Examples of disputes include, but are not limited to, disagreements over the quality or completion of work, the allocation of funds or the cancellation of a project. By agreeing to this Agreement, Developer, Purchaser and CodeCogs agree to enter into mediation and/or arbitration at the request of either party and further agree to abide by the terms, conditions and rules set out below. These rules shall govern any mediation and arbitration, except that, where any of these rules are in conflict with a provision of United Kingdom law. In such circumstances, that provision shall prevail. In any dispute Developer and Purchaser will allow CodeCogs to mediate and CodeCogs agrees to do so. CodeCogs shall be impartial and independent and will operate in line with the rules detailed below.

When Mediation / Arbitration will be used

Mediation / Arbitration will be used in the following circumstances:

• Developer and Purchaser cannot reach an agreement on whether the submitted Software & Documentation is in compliance with the initial request.
• Developer and Purchaser cannot reach agreement on an acceptable part payment for work that both sides recognise only to be in partial compliance with the accepted bid.
• One party cancels this Agreement and an amicable pay settlement has not been reached.
• Any other dispute on the website between a Developer and a Purchaser that cannot be resolved.

Mediation

Mediation is the first step in trying to resolve a dispute. It is a less complicated procedure than arbitration and it involves CodeCogs diplomatically trying to negotiate a mutually acceptable solution. The majority of disputes can be settled this way. It is usually a fairly quick and straightforward way for both parties to come to an agreement. CodeCogs will suggest various solutions to the disagreement with the aim of encouraging both parties to settle on one of the options. It should be noted that at this stage neither party is obliged to accept one of the proposed solutions and their decision to do so, or not, will not affect the following arbitrary procedure.

If an agreement cannot be reached at this point, or a mediated solution is not possible, then at CodeCogs sole discretion, the mediation stage will close and arbitration will begin.

Arbitration

If a solution cannot be negotiated through mediation then the dispute will pass onto arbitration. Arbitration is a method of resolving a dispute in which the disputants present their case to an impartial third party ("Arbiter"), who then makes a decision for them, in order to resolve the conflict. This decision is final and binding. Arbitration differs from mediation. In mediation, the third party simply helps the disputants develop a solution on their own and does not force a solution.

How to Request Mediation / Arbitration

To request mediation / arbitration you need to go to the "My Cogs" section and select the bid or request that you are having trouble with. Then, click on the "Request mediation / arbitration" button and fill out the details of why you are requesting mediation / arbitration. After you have submitted the information a CodeCogs mediator / arbiter will contact you by email with further details of what will happen next.

General Notes on the Arbitration

CodeCogs shall act as the Arbiter in all cases.

Developer and Purchaser agree that any decision the Arbiter makes is final and binding and hereby waive any other further legal challenges or remedies including, but not limited to, civil or criminal litigation against the other party or CodeCogs.

The Arbiter shall ensure that both parties are treated with equality and that each party is given a fair opportunity to present its case. Unless otherwise agreed by all parties, including CodeCogs, the language of the arbitration shall be English.

The Arbiter shall ensure that the arbitral procedure takes place with due expedition. It may, at the request of a party, or at its own discretion, extend the time period over which the arbitration occurs.

Developer and Purchaser both agree to be prompt in any correspondence with the Arbiter. Failure of either party to respond to any of Arbiter’s correspondance within five (5) business days, or the deemed attempt of either party to stall the proceedings will, at the discretion of arbiter, lead to that party forfeiting the arbitration. A forfeit of arbitration will lead to a ruling in favour of the other party.

If either party wishes or is required to submit to arbitration any confidential information, the Arbiter assures that they will not sell, copy, or disclose any confidential information (including source code, trade secrets or any other information) to any other parties. The sole purpose will be to determine if the developed software functions as requested, and thus resolve the dispute.

All correspondence between parties shall be via email. All email shall be copied (CC’d) to cc2008@codecogs.com Telephone or other contact shall only be allowed at the request of the Arbiter. All phone calls will be initiated by the Arbiter and shall be clearly documented. It is not permitted for either party to contact the other directly during the arbitration process.

The Arbitration Procedure

The aim of the arbitration is to settle one of the disputes listed above. The decision will solely be based on whether the Software & Documentation submitted by the Developer fulfils the requirements specified in the "complete bid request" accepted by the Purchaser on the Web Site. If the bid has been clarified, modified and/or changed after the initial bid has been accepted then any party wishing to benefit from this should provide proof. This will ideally be in the form of emails that have been copied (CC'd) to CodeCogs throughout the development process (via the address: cc2008@codecogs.com). These emails will be viewed as true and factual evidence that cannot be disputed. As emails are incredibly easy to alter, emails submitted that have not been CC'd to CodeCogs will only be admissible at the discretion of the Arbiter and will be viewed with scepticism.

If the Arbiter comes to the conclusion that either or both parties have been withholding information or supplying unclear information at any point, deliberately or otherwise, essential to the request, bidding, development, or arbitration process, it will take this information into account and rule on the arbitration accordingly. Unclear information can include, but is not limited to, (a) contradictory information given in the “complete bid request” (b) unclear, inconsistent or easily misinterpretable information either in the “complete bid request” or subsequent emails, or (c) poor attention to detail at any stage.

Arbitration Scenarios

Below is a list of various possible disputes that could arise. With each one there are guidelines as to how the dispute would be arbitrated should such a situation arise. As no two disputes are the same these guidelines are not absolute and final and the Arbiter reserves the right not to rule in line with any particular one. In attempting to making a fair and just decision the Arbiter will take all facts that are deemed relevant into account. This will be done in an impartial manner.

In all instances, the Arbiter will judge whether any submitted material is fair, accurate, reasonable, and reliable. If either party is judged to have provided inaccurate information this will be taken into account in making a decision.

1. Project Cancellation

   If a Purchaser decides to cancel an accepted bid, after funds have been escrowed, and a Developer has already started work on the project, then the Developer will be fairly compensated for their time spent and proportion of work.

   The Developer will be asked to submit proof of all work that they have done (including designs, code, prototypes, and support documents), along with details of time they have spent working, researching, and any other costs they may have incurred. Any other relevant information may also be submitted. From the material that is judged to be correct the Arbiter will calculate the percentage of the total “complete bid request” that has been completed.

   The Purchaser is allowed to receive the work that has been completed to date, and will receive it in line with the original "complete bid request" (i.e. If they have requested complete ownership they will receive ownership of the completed work to date). Purchaser will also be subject to a cancellation fee as outlined in section 2.9.

   If Developer cancels a project without providing sufficient justification / reasons they may, at the discretion of the Arbiter, have their account terminated and be expelled from the Web Site. They will not be paid for any work completed. If Developer is found to have multiple accounts, or tries to open new accounts in the future they will be subject to the same closing procedure.

2. Project Reduction / Shortening of Request

   If a Purchaser decides to reduce the scale of, or only want part of the "complete bid request" a dispute may arise. If the Developer has already started work on the portion that is no longer required the Developer will be fairly compensated for their time spent and proportion of work.

   The Developer will be asked to submit proof of all work that they have done on the required and un-required portion of the “complete bid request” (including designs, code, prototypes, and support documents); along with details of time they have spent working, researching, and any other costs they may have incurred. Any other relevant information may also be submitted. From this information the Arbiter will calculate the percentage of the un-required portion has been completed, as well as the percentage of the “complete bid request” that is no longer required.

   Once this decision has been made it is up to the Developer to decide if they wish to continue working on the required portion of the project. If they do not wish to continue the same procedure will be followed, as described above, as to the settlement they are entitled to for the amount of work they have completed of the required portion.

   The Purchaser is allowed to receive the work that has been completed to date, including required and un-required portions, and will receive it in line with the original "complete bid request" (i.e. If they have requested complete ownership they will receive ownership of the completed work to date).

3. Work Is Submitted Late / Not Submitted

   If the deadline for submitting Software and Documentation to CodeCogs for a project is breached by the Developer then the Developer will loose 20% of his fee for every day that the Software & Documentation is late. That is to say that if the Developer is five (5) or more days late they will not be paid for the project. This rule also applies if the Software & Documentation is incomplete (i.e. there is Software but no Documentation).

   To avoid unfairly penalising the Developer, this rule will, at the discretion of the Arbiter, not necessarily be enforced if one of the following has occurred:

   • The "complete bid request" has been changed since the commencement of the project. If for example the Purchaser has increased or changed the scope of the project it may be deemed fair that the Developer receives an extension in time to complete the project. Supporting emails will be essential in proving this.
   • The original deadline has been changed and was not be clearly redefined.
   • After the deadline has passed the Purchaser has continued to work with the Developer on the project. In doing so the Purchaser has implied by their actions that they agree to an extension in time.

   For the purposes of submitting work it should be noted that GMT is the time zone that is recognised, used, and logged by CodeCogs. All deadlines correspond to this time zone.

4. The Developer does not have the required skills or is working slowly

   Purchaser asserts that the Developer is either working too slowly, or does not have the required ability to complete the work as specified in the "complete bid request". The Developer will be asked to submit proof of all work they have done to date (including designs, code, prototypes, and support documents), along with details of the time they have spent working on the project. The Purchaser will also be asked to submit a report on their expected timelines for the project, detailing the key phases where the project was deemed to be falling behind schedule. Having studied the evidence the Arbiter will decide if the Purchaser’s accusation is valid.

   If it is decided that the Purchaser’s accusations are NOT valid the arbitration will be ruled in favour of the Developer. The Purchaser will then have the option of either allowing the work to continue, or agree to the Developer being paid in FULL and the project cancelled.

   If it is decided that the Purchaser’s accusations are valid the arbitration will be ruled in favour of the Purchaser. CodeCogs will then cancel the project and return all escrowed funds to the Purchaser. In such cases the Purchaser is not allowed to receive delivery of the code and holds no rights over it. All rights remain with the Developer.

5. The Purchaser claims the Software does not function as requested and / or the quality is poor

   This type of dispute is the most common and occurs when a Developer delivers Software and Documentation to the Purchaser and claims it to be fully (or partially) in line with the request. After testing, the Purchaser disputes this claim and/or claims that the software is of such a poor quality that it is rendered useless. The best way for disputes of this kind to be resolved is for the Software and Documentation to be tested. The testing procedure will be conducted as follow:

   • The Purchaser produces a list of "faults" or functions they feel the software does not perform correctly or at all. Subjective items are not allowed to be on this list as all criteria must be able to be tested. Exceptions to this (i.e. the allowance of subjective items) will only be allowed if expressly stated in the "complete bid request" and/or at the discretion of the Arbiter.
   • The Purchaser may only issue one list containing all faults. This will be submitted upon request by CodeCogs at the beginning of the arbitration procedure. Once submitted this list cannot be added to by the Purchaser. The Arbiter reserves the right to add a fault to the list if it is discovered during testing.
   • Having received the list of faults CodeCogs will then conduct testing on the Software. The sole aim of this testing is to determine if the faults detailed on the list are correct.
   • Once testing is complete the Arbiter will make a decision. The decision will depend on the number and severity of the faults found. If the software contains a large fault, or several smaller ones, then the arbitration may be ruled entirely in the favour of the Purchaser. In such cases the Purchaser will receive a full refund of the escrowed funds.

   If possible testing will always be conducted on CodeCogs premises. In certain circumstances this may not be possible. If such a case arises CodeCogs reserves the right to request that testing be done "on site" at the Purchaser's or Developer's location, or any other location it deems appropriate. This will be conducted at the expense of the Purchaser. If either party refuses to facilitate this testing, they forfeit the arbitration.

Harassment, Unsolicited Contact & Foul Play

CodeCogs takes it's responsibility as an Arbiter seriously and aims to reach judgement in a fair and just manner. Harassment, abuse, threats, attempts to manipulate data or influence the arbitration process in any way will not be tolerated. Any such occurrences will usually result in a ruling in favour of the other party. Harassment may include telephone calls or large numbers of unsolicited emails.

Exclusion of Liability

Except in respect of deliberate wrongdoing, the arbiter shall not be liable to a party for any act or omission in connection with the arbitration.

Waiver of Deformation

The parties and the Arbiter agree that any statements or comments, whether written or oral, made or used by them or their representatives in preparation for or in the course of the arbitration shall not be relied upon to found or maintain any action for defamation, libel, slander or any related complaint. This Agreement may be pleaded as a bar to any such action.

The Agreements

The full version of each user agreement can be viewed by clinking on the correct link below:

1. Purchaser User Agreement
2. Developer User Agreement