11. Sam Silva: Technology Agreements

• Software licensing agreements are central, focusing on key provisions, considerations, and potential challenges.
• Defining the scope of the license and considering end-user experience during specification are critical.

Software License Agreements and Exclusivity

• It's important to understand the license scope, limitations, exclusions of liability, and the interplay between schedules.
• Exclusivity is not a binary decision, tailoring to specific needs like jurisdiction or sector is also important.
• Software suppliers are experts in their agreements, which are likely to favor them.
• Scenario: A company, "InnovateRetail," develops a cutting-edge inventory management software. Another retail firm, "StoreFrontCo," seeks to license the software to obtain first-mover advantage in their region. To balance InnovateRetail's desire to maintain broad market reach, and StoreFrontCo's need for exclusive advantage, a tailored agreement is struck. The license grants StoreFrontCo exclusive usage within their state for two years, alongside first access to new features within their specific retail segment of e-commerce during the first year. This approach allows StoreFrontCo to obtain a competitive edge to innovate while also ensures InnovateRetail can engage with other sectors or regions of e-commerce without limitations.

Managing Software Restrictions and Audits

• Managing restrictions (number of users, hardware, geography) when licensing software is crucial.
• Precision in defining audit rights for suppliers and internal monitoring/compliance is a must.
• The SAP versus Diageo case shows consequences of exceeding restrictions and importance of license scope.
• Scenario: "HealthTech Corp" licenses remote patient monitoring software. Initially, HealthTech licenses for 500 users, but HealthTech acquires a competitor, adding 300 new employees. Anticipating growth, the licensing agreement includes a scalable clause that allows for user number increases at a predefined cost per additional user pack in 50s and this avoids unexpected breach of contract.

Navigating Contract Limitations and Liability

• Understanding limitations, exclusions, and liability clauses is critical.
• Best practice framework: defining losses that cannot be legally excluded, financial caps for phases, and liability phases.
• Unlimited liability is needed for confidentiality and IP breaches.
• Commercial dialogue with service provider to determine maximum liability is beneficial.

Direct and Indirect Losses in Contracts

• Defining direct and indirect losses clearly impacts liability.
• Centrica versus Accenture case: losses one step removed from the breach, such as acquiring a new system, are significant.
• Be cautious of exclusion clauses, they may be unenforceable (Unfair Contract Terms Act).
• Scenario: EduCorp contracts EdTech Inc for a student management system. The system is faulty, which causes delay for student enrollment. EdTech is responsible for direct losses such as system replacement. An example of direct loss in this case would be paying for the faulty software. Indirect losses are compensation to affected students i.e. financial aid.

Acceptance Testing in Software Development

• Acceptance testing ensures software meets customer requirements.
• Types: development, user acceptance, and volume stress testing.
• Acceptance certificate triggers payment milestone.
• Disagreements may arise; resolve conflicts.
• 'Deemed acceptance' allows software use under conditions even if it hasn't passed testing.

Intellectual Property Ownership and Indemnities

• IP is typically owned by the software developer, unless there is written assignment.
• Categories of IP include background IP, new IP, third-party IP; modifications and developments must also be taken into account.
• IP indemnity should be separate from the operational clause.

Source Code Escrow Agreements and Support

• Source code escrow agreements grant customers access in case of insolvency or breach of support.
• Define source code materials broadly (documentation, license scope for modification).
• Clear Terminology and pricing for software updates and customers should have the right to refuse new versions.
• Link new version releases to support agreements and specify support periods.
• Use 'active' language, and define terms to avoid ambiguity or "agreements to agree."
• Align support start with warranty periods.

Warranties, Support Agreements, and Service Levels

• Warranties offer limited support but do not necessarily provide free service.
• Separate agreements for licenses and support reduce customer's ability to recover from software supply.
• Key service metrics: availability, response times, resolution, and fixed time.
• Availability formulas must be attainable, measurable, understandable, controllable, and affordable.
• Specify narrower service windows for better protection.
• Implications of service levels not being met must be addressed; contractual service levels & interplay between service credits/liability cap are the considerations.

Supplier Contracts and Force Majeure Clauses

• Review exceptions and exclusions, notably force majeure clauses in supplier contracts.
• Clause should cover events beyond supplier's control and not include third-party acts/omissions.
• Suppliers must provide business continuity and disaster recovery obligations; these prevail over force majeure.
• Straightforward process for claiming service credits and terminating agreements in material breaches is crucial.

Agile Contract Strategies and Challenges

• Distinguish traditional SDLC contracts from RAD or agile methodologies.
• Agile Approach challenges: comprehensively listing requirements, determining cost/delivery, changing requirements.
• Include a long stop delivery date, a cap budget, and a process for adjusting dates/budget if necessary.
• Identify product owners and scrum masters for decisions sans senior-level approval. Be on the lookout for a good bail-out provision.
• Prioritize technical documentation over legal documents in agile contracts.

Technical Specifications and Business Requirements

• Technical specifications/business requirements must be understood.
• Customer develops these in-house or with consultant to align to intended outcomes.
• Clear IP ownership is important, especially regarding open-source licenses.

Change Control in Contracts and Software Development

• Change control in contracts is very important, particularly in software development.
• Clear pricing and impact assessments for proposed changes, as well as flexibility for minor changes must be in place.
• Impact from changes in law and the potential for continuous improvement in services need to be thought about and addressed.
• Rationalization and reinstatement of new baselines and liquidated damages as a delay remedy must be considered.

Licenses - Scope of the license

• Clear definition of what is being licensed in terms of the software and make sure that the definition of software captures new versions and new releases
• Provide certainty to ensure that procured and trust part of the license is actually procured
• Licensee rights regarding using, copying software for backup, modifying; scope wide enough to allow that activity
• Sometimes, need enhanced rights, so exclusivity; not binary as different ways to slice and dice exclusivity
• Need to ask why they want exclusivity, the way of structuring to match the reasons/requirements

Licenses - Other Restrictions on Use

• Software suppliers experts in area of software licensing
• The licensing restrictions be on number of users, hardware infrastructure, and geography. If is on some sort of schedule i.e. technical schedule
• Customer understand those restrictions on use; what happens if exceeded e.g. license fee payable
• Supply perspective: audit rights to suppliers
• Customer perspective: audit rights clause have to be precise and make sure have the appropriate monitoring and compliance in place
• SNP versus Agent case: a warning tale on licenses scopes
  • Aigio contracted with SAP for an ASAP system - The scope of the license was based on the number of users
  • After Aigio procured SAP system, they procured at another salesforce system
  • Court held that Aigio was in breach of license agreement and said that effectively SAP's argument was one.

Limitations and Exclusions from Liability

• Ask "what categories of loss can be recovered under each head, and then how much can be recovered."
• Firstly set out "which loses which can't be excluded by law". In particular Misrepresentation and implied conditions of sale of goods act.
• Get the general financial cap and different financial caps to losses types for example damage to properties
  • Breaches of confidentiality - "Unlimited liability that's fairly market practice."

Examples of Clauses

• Express losses as direct losses in the agreement itself. E.g. Waste of management time and cost of new system
• There are two examples about total values - Look at two scenarios, more preferable as a customer prospective to be able to recover loss of profit e.g. 2 due to wider definition scope
• Need to deal with the supplier doesn't know the lot or there trying to circumvent the law, not know which scenarios is better
• Do not rely on acter unless you really have to - Try get best position possible - Reliance on judge and day is very risky - Liability's clause is very broad
• Contract always try to negotiate their executions of liability is very broad

Source Code Escrow

• Object Code VS source code. The ability to modify software requires the source code - Manage this risk, introduce source-code agreements
• The circumstances the agent that the escrow agent will lease; Triggers include "In solvency and ceasing to trade" - Key definition definition source source code much tour
• In definition - Get more manuals documentation otherwise, the the IT program is very hard to implement

New Versions New Releases - Definitions VERY Important

• Understand what new functionality is e.g. Bug Fixes defect connections
• Frequency set out
• Pricing - The number 2 concept - For older copies are are no longer supported
• The supplies will need the time period e.g. Months
• The test schedule needs to be on the same schedule on Legal
  • Who performs? "Who does the OBLIGATION?"
  • When must they perform?
  • Often should they perform it and withstanding it?

Support Agreements

• Structure, Exceptions and Exclusions
• Drafting Problems
• Structure either stand alone agreement. OR agreement is part of license agreement
• If software licenses is part of software agreements, that's that software support. After software expect - Warranty. You should have warranty support for part free free free to change during particular agreement
• "The limits are so large to really affect" - Check that cap isn't too hard so you can get correct support during the contract
• The third metric to look at - Main service. Matrix are resolution fixed time and availability
• Principle of service that meets - Not possible a 200% guarantee - Practical/mesmerising understandable all together in
• Make sure not all controlled by external third parties
• See 99 and the IT range - Examples can be down per down time per month
• You just divide it in the smaller you know diluted.

Force Majeure - The End of an Agreement

• Force majeure - Try to make reasonable and see what's correct
• Another thing: A software supplier always have an act of omission from third parties - It's normally too wide
  • It's very small to see the events e.g. Civil commotions/what makes them important