0% found this document useful (0 votes)
45 views

Exercises On Operative & Boilerplate Clauses of Technology Contracts - Part 2

The document requests a review of several clauses commonly used in technology agreements by Axis Tech. Regarding a limitation of liability clause, the summary identifies issues with having no dollar cap on liability and excluding liability for direct damages without definition. Points are provided that could be added, such as indemnification, force majeure, and dispute resolution. For a warranty clause, issues around ambiguity and lack of limitations are noted. Regarding a schedules and milestones clause, weaknesses around missing dates, lack of specificity, and payment terms are identified. Redrafted versions of the clauses are provided addressing the identified issues.

Uploaded by

exmeronly
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
45 views

Exercises On Operative & Boilerplate Clauses of Technology Contracts - Part 2

The document requests a review of several clauses commonly used in technology agreements by Axis Tech. Regarding a limitation of liability clause, the summary identifies issues with having no dollar cap on liability and excluding liability for direct damages without definition. Points are provided that could be added, such as indemnification, force majeure, and dispute resolution. For a warranty clause, issues around ambiguity and lack of limitations are noted. Regarding a schedules and milestones clause, weaknesses around missing dates, lack of specificity, and payment terms are identified. Redrafted versions of the clauses are provided addressing the identified issues.

Uploaded by

exmeronly
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 8

Axis Tech. Pvt. Ltd.

, an early SaaS Startup, have approached you, to review some of


their operative clauses which they tend to put in their technology agreements and
identify what can be added into these clauses. Review and explain the points that are
missing or can be added into these clauses. Once you have identified these, re-draft
the clauses.

Original Clause:

“Axis has to enter into a lot of Software Subscription Agreements with various
companies for their project management software. They generally put in this
clause to limit their liability.

“10. LIMITATION OF LIABILITY.


10.1. Dollar Cap. PROVIDER’S CUMULATIVE LIABILITY FOR ALL CLAIMS
ARISING OUT OF OR RELATED TO THIS AGREEMENT WILL HAVE NO
DOLLAR CAP.

10.2. Excluded Damages. Except with regard to breaches of Clause 7


(Confidential Information), IN NO EVENT WILL THE PROVIDER BE LIABLE
FOR LOST PROFITS OR LOSS OF BUSINESS OR FOR ANY DIRECT
DAMAGES ARISING OUT OF OR RELATED TO THIS AGREEMENT.””

Review of Existing Clauses:

10.1. Dollar Cap:

● It is unclear why there is no dollar cap set for provider liability. This can be a
significant risk for Axis, as they could potentially be held responsible for a large
amount of money in the event of a claim.

● Having no dollar cap might make Axis less attractive to potential customers, as they
would be taking on a significant financial risk by entering into a contract with them.

10.2. Excluded Damages:

● Excluding liability for lost profits or loss of business is a common practice in


technology agreements. However, it is important to note that this will not protect Axis
from all potential claims.

● The clause specifically mentions that it does not apply to breaches of Clause 7
(Confidential Information). This means that Axis could still be held liable for damages
related to the disclosure of confidential information.

Points Missing or To Be Added:

Direct Damages: The clause excludes liability for direct damages, but it is unclear what this
definition includes. It would be helpful to provide a more specific definition of direct damages
to avoid any ambiguity.
Indirect Damages: The clause does not mention indirect damages. It is important to
explicitly state whether Axis is liable for indirect damages, such as consequential losses or
reputational harm.

Indemnification: The clause does not include an indemnification provision. This provision
would require the provider to compensate Axis for any losses or damages incurred as a
result of the provider's breach of the agreement.

Force Majeure: The clause does not address force majeure events. This provision would
excuse Axis from performing its obligations under the agreement if it is prevented from doing
so by an event beyond its control, such as a natural disaster or war.

Dispute Resolution: The clause does not specify how disputes arising under the agreement
will be resolved. It would be helpful to include a provision for arbitration or mediation to avoid
costly litigation.

Redrafted Clauses:

10. LIMITATION OF LIABILITY

10.1. Dollar Cap: The Provider's cumulative liability for all claims arising out of or related to
this Agreement shall not exceed [insert dollar amount] per claim.

10.2. Excluded Damages: Except with regard to breaches of Clause 7 (Confidential


Information), the Provider will not be liable for:

I. Direct Damages: Losses that are a direct consequence of the Provider's breach of
this Agreement, such as lost revenue or data recovery costs.
II. Indirect Damages: Losses that are not a direct consequence of the Provider's
breach of this Agreement, such as lost profits or business opportunities.

10.3. Indemnification: The Provider shall indemnify and hold harmless Axis, its officers,
directors, employees, and agents from and against any and all losses, damages, costs, and
expenses (including reasonable attorneys' fees) arising out of or related to any breach of this
Agreement by the Provider.

10.4. Force Majeure: Neither party shall be liable for any delay or failure to perform its
obligations under this Agreement due to any cause beyond its reasonable control, including,
but not limited to, acts of God, natural disasters, war, terrorism, strikes, labor disputes, and
government regulations.

10.5. Dispute Resolution: Any dispute arising out of or relating to this Agreement shall be
settled by binding arbitration in accordance with the rules of the International Chamber of
Commerce (ICC). The arbitration shall be conducted in English and shall be held in
Bengaluru, India. The decision of the arbitrator shall be final and binding on the parties.
When it comes to warranty, they tend to put these clauses in their agreements.
Review and advise on how to improve them.

“Vendor represents and warrants that, after installation, each New Module will perform
materially for its lifetime in the client system without any defects, according to its
documentation issued by Vendor under the heading “Official Product Documentation.”

Issues with the Existing Clause:

● Ambiguity of "materially": The term "materially" is subjective and open to


interpretation. It is unclear what level of performance constitutes "material"
performance. This ambiguity could lead to disputes between Axis and its clients.

● Lifetime warranty: Offering a lifetime warranty without any limitations can be


financially risky for Axis. It is important to define the duration of the warranty or
include some limitations.

● Lack of definition for "defects": The clause does not define what constitutes a
"defect." This lack of clarity could lead to disagreements between Axis and its clients
about whether a particular issue is covered by the warranty.

● Documentation reliance: Relying solely on official product documentation for


warranty coverage can be problematic. The documentation may not be
comprehensive or may be updated after the client has purchased the module.

Redrafted Clause:

11.1 Client Protection - Warranty of New Modules

I. Vendor warrants that, after installation, each New Module will perform
substantially in accordance with its Official Product Documentation for a
period of [warranty duration] from the date of purchase.

II. A 'defect' for the purposes of this warranty is defined as any nonconformity
with the Official Product Documentation that materially impairs the
functionality of the New Module.

III. In the event of a breach of this warranty, the Client shall be entitled to, at its
option, repair, replacement, or a full refund of the purchase price of the New
Module.

Review the Schedules and Milestones clause they typically use for their
Application/ Software Development Agreements. Here is the clause:

“Vendor will complete the Services on or before ______________.

Milestones: Vendor will complete the Service by the following deadlines


(“Milestones”):
A. Alpha Version functioning according to Specifications (“Operational”):
_________ [days] after Effective Date;
B. Beta Version Operational: ________ [days] after Alpha Version
Operational;
C. Full System Operational and submitted for Acceptance Testing:
_______ [days] after Beta Version Operational.
Payment: Customer will pay Vendor the full amount once they submit the
software as per Milestone C, as defined above.”

Review of Schedules and Milestones Clause:

Strengths:

● Clearly defines the overall completion deadline for the application/software


development services.

● Identifies specific milestones with deadlines for alpha, beta, and full system versions.

● Links payment to the completion of Milestone C (Full System Operational).

Weaknesses:

● Dates: The clause uses placeholders for dates instead of specific deadlines.

● Specificity: The clause lacks specifics regarding the content and functionalities
expected at each milestone. This can lead to ambiguity and disagreements.
● Flexibility: The clause lacks provisions for potential changes or delays.

● Testing: The clause mentions "Acceptance Testing" but doesn't specify details like
duration or responsibilities.

● Payment terms: Linking full payment to Milestone C might incentivize rushing


completion over quality.

Re-draft of the clause:

11.2 Schedule and Milestones

I. Vendor agrees to complete the Application/Software Development Services (the


"Services") on or before [insert date].

II. The Services will be delivered in accordance with the following milestones:

1) Milestone A: Alpha Version

Completion date: [insert date] ([number of days] days after the Effective Date).
Deliverables:

a) Functioning alpha version of the application/software according to the


agreed-upon specifications.

b) Documentation outlining known issues and limitations.

2) Milestone B: Beta Version

Completion date: [insert date] ([number of days] days after alpha version
completion).

Deliverables:

a) Functioning beta version of the application/software with additional


features and functionality.

b) Updated documentation addressing known issues from the alpha


version.

3) Milestone C: Full System

Completion date: [insert date] ([number of days] days after beta version
completion).

Deliverables:

a) Fully functional application/software meeting all agreed-upon


specifications.

b) Comprehensive documentation including user guides and technical


specifications.

c) Successful completion of acceptance testing.

11.3 Payment Schedule

Customer shall pay Vendor the total fee for the Services in accordance with the following
schedule:

I. [percentage]% upon completion of Milestone A.

II. [percentage]% upon completion of Milestone B.

III. [remaining percentage]% upon successful completion of Milestone C and


acceptance testing.

11.4 Change Management


Any changes to the scope, requirements, or deadlines of the Services must be agreed upon
in writing by both parties. Such changes may necessitate adjustments to the schedule and
milestones.

Exercise 2: Further Review the Major Operative Clauses for Technology Contracts

Further review the following Operative Clauses for Axis Tech. Pvt. Ltd. which they
will use for their SaaS based Project Management Tool, “Surf Work”.

“1. Delivery, Acceptance and Rejection:

“Vendor shall deliver each Deliverable to Customer’s systems, on the


following time frame: ____________ (“Delivery”).

Each Deliverable will be considered accepted as soon as Surf Work is


delivered and installed in the client’s main system (“Acceptance”):

Customer may reject a Deliverable only in the event that it materially deviates
from its Technical Specifications and only via written notice setting forth the
nature of such deviation. In the event of such rejection, Vendor shall correct
the deviation and redeliver the Deliverable within _____ days.””

Strengths:

● Clearly defines the timing and method of delivery for each Deliverable.

● Establishes a straightforward acceptance process based on delivery and installation.

● Provides a mechanism for rejection based on material deviations from specifications.

● Outlines a timeframe for Vendor to address any rejections.

Weaknesses:

● Dates: The clause uses placeholders for dates instead of specific deadlines.

● Materiality: The clause relies on the vague term "materially" to define the threshold
for rejection.

● Acceptance criteria: The clause lacks detail on what constitutes successful delivery
and installation.

● Rejection process: The clause lacks specificity regarding the timeframe and format
for rejection notices.
● Redelivery deadline: The clause uses a placeholder for the redelivery deadline,
which could be insufficient depending on the complexity of the issue.

Revised clause:

11.5 Delivery, Acceptance, and Rejection

Delivery: Vendor shall deliver each Deliverable to Customer's systems on or before [insert
date] in accordance with the agreed-upon specifications.

Acceptance: A Deliverable will be considered accepted upon:

I. Delivery and installation on Customer's main system.

II. Successful completion of all acceptance criteria, including functional testing


and performance verification.

III. Customer's written confirmation of acceptance.

Rejection:

I. Customer may reject a Deliverable only in the event that it deviates from the
Technical Specifications by more than [percentage]% or fails to meet any
critical functionalities.

II. Any rejection must be submitted in writing within [number of days] after
delivery and clearly outline the nature of the deviation.

Redelivery:

In the event of a valid rejection, Vendor shall correct the deviation and redeliver the
Deliverable within [negotiate a timeframe based on complexity] days.

Since it is a Software sold as a service with an option of automatic renewal of


services, which “Term” Clause does not suit the client’s needs out of the following,
state with reasons:

a. This Agreement will terminate on Customer’s acceptance of the Final


Deliverable (as defined in Section __, Deliverables)

b. This Agreement will continue until terminated by either party as


specifically authorised herein. Vendor will provide Maintenance for a
period of _______, starting on the Effective Date. Thereafter,
Maintenance will renew every _____, unless Customer notifies Vendor
of its intent not to renew 30 or more days before any renewal date.
After Maintenance has renewed ______ times, Vendor may refuse any
subsequent renewal by written notice 30 days before the next renewal
date.
c. This Agreement will remain in effect for _____ years from the date of
execution by both parties. Thereafter, it will renew for successive
1-year periods, unless either party refuses such renewal by written
notice 30 or more days before the end of the current term.

Out of the three "Term" clauses, the one that does not suit the client's needs is option
(a):

This Agreement will terminate on Customer’s acceptance of the Final Deliverable (as defined
in Section __, Deliverables).

Reasoning:

● This clause implies that the agreement will terminate as soon as the final deliverable
is accepted, regardless of the client's desire to continue using the service.

● This is problematic for a SaaS model with automatic renewal, as the client might still
want to access the service and its features beyond the completion of the final
deliverable.

● Option (b) and (c) are more suitable for a SaaS model because they allow for
automatic renewal:
I. Option (b) offers a specific maintenance period with automatic renewals
unless the client opts out.

II. Option (c) offers a fixed initial term with automatic one-year renewals unless
either party cancels.

● Both options allow the client to continue using the service after the final deliverable is
completed, which is essential for a subscription-based model.

● Therefore, the client should choose either option (b) or (c) depending on their specific
needs and preferences for the automatic renewal terms.

You might also like