Continued from CYA: Using Contracts to Protect Your Company. Escrow: When purchasing software (especially from small vendors), make sure the source code is placed into escrow with a third party. This means that if the vendor goes bankrupt or out of business, you have the source code of the software to help support the application. Perpetual Licenses: Your software licenses should be perpetual. This allows you to use the software forever even if you drop support and maintenance (can’t get updated versions). While you might save some money with term licenses, when they expire you are forced to purchase all new licenses. Exclusivity: A non-exclusive software licenses means the vendor can sell the product to many customers. An exclusive contract dictates that the vendor will not sell the product to anyone but your company. If a vendor is developing software only for you it should be exclusive. If they are using you as the first customer to fund the development to sell to other companies you should get a large discount. Transferable and assignable: Consider negotiating for a license that is transferable or assignable. If your company ever splits off units into other operating entities, you can assign the license to the new entity. You should allow the vendor to specify that you can’t sell the license to someone else however. Termination: Always, always make sure you have a termination clause such as 30 days written notice to terminate the agreement. If the project you are working on is cancelled a month in, you don’t want to keep paying support or maintenance for a year. Smart vendors might want to make you pay extra for a termination clause as they depend on the contract duration for their income streams. Force Majeure: Make sure this clause is specific. An act of god could mean anything. In some cases, these circumstances are part of the reason why you want to purchase support and maintenance. Confidentiality / Publicity: Make sure this clause cuts both ways. Typically they state your company can’t issue statements about them. Make sure the vendor can’t issue statements about your company without approval as well. Location: Shoot for worldwide. While your company might only operate in the United States, you might someday decide to open a branch in Europe or Mexico. Payment: Make sure this matches your company’s payment methods. If your company pays net 45, don’t let the contract state net 30 or you might be faced with penalties. Also, if the contract references a service to be provided, don’t pay 100% upfront. You never know when you won’t like the end result. Limitation of Liability: Make sure your interests are covered here and not just the vendor’s. Indemnity: Make sure your interests are covered here and not just the vendor’s. Service Levels: Define specific service levels, escalation procedures, fix timeframes, etc. If the vendor is not living up to their promises, you want to be compensated. Response Times: Determines the response time of the vendor for various situations. If the vendor is not living up to their promises, you want to be compensated. Also, make sure your technical support people know the response times so they can plan accordingly and are not surprised. Remedies: Remedies are used to provide financial (or other) compensation for a party not living up to the terms in the contract. Make sure your interests are covered here and not just the vendor’s. Governing Law: Ensure your legal team agrees to the governing body. Your corporate legal and procurement teams are valuable resources in reviewing and negotiating software and hardware contracts. Always work with them to make sure you are using all of your company resources to get the best terms and contract conditions. Related Articles: Software | Hardware Licensing: Key Contract Terms

CYA: Using Contracts to Protect Your Company Software licensing and hardware contracts are a primary tool in protecting your company from vendors that you have purchased product from and do business with. In an ideal world, vendors work well with your companies representatives and when issues arise they are handled to meet both parties’ needs. Unfortunately, we don’t always exist in this perfect world. When conflict arises, sometimes the best interests of both parties cannot be met. This is why it is essential to protect your company by negotiating, redlining, and modifying contracts to ensure your best interests are met. A good contract will meet your company’s present needs and ensure the vendor provides you with an acceptable product, service, updates, and support. A good contract will also protect your company’s financial interests. A great contract will meet your company’s present and future needs and protect you from unforeseen changes in your company structure or the vendor’s company structure. You may think the difference between a good and great contract deals only with timeframes on the terms and conditions, but have you considered what happens when: 1. Your favorite vendor is purchased by worst vendor 2. Your company is acquired by someone else 3. Your company restructures or spins off operational units and your assets must be split between the new units 4. Your company goes through bankruptcy 5. Your company changes priorities and no longer needs software, hardware, or services that you have under contract for years to come These are just a few examples of unforeseen circumstances that you might not have considered when negotiating contracts with vendors. A great contract allows you minimize the financial impact when your business changes or the vendors business changes. There are many good ideas on how to protect your company’s interest and provide flexibility in contracts. Below are some ideas on structuring contract terms and conditions to provide you with flexibility to handle unforeseen changes and protect yourself. If you haven’t read the article Software | Hardware Licensing: Key Contract Terms, now might be a good time. Some of the following suggestions are largely based on terms presented and defined in that article. Ownership of Data: If you are outsourcing an application or service, make sure your company owns the data. Also, make sure you have a clause that makes the vendor give you your data when requested no matter what. You don’t want an outsourcing vendor to withhold your valuable corporate data if you missed a payment. Consider negotiating a poison pill clause into software contracts. Such clauses would give customers money if the vendor is purchased. You probably will have a difficult time collecting the money but you can use it for leverage with the new vendor owner. Continue article - CYA: Using Contracts to Protect Your Company: Part 2

This article is aimed at relating my experience in trying to reduce Oracle licensing costs, how they view contracts, and how to put yourself in the best position in relation to your licensing arrangement. I plan to explain more about the Oracle licensing model in future articles. In this article I will use the Oracle Enterprise Database product as an example. First of all, in my opinion, Oracle seems to like having large contracts with customers. By this I mean that they would prefer to have one license contract covering many instances of their software products. The article How Oracle Licensing Differs also includes information on how Oracle builds large contracts with customers. An example would be having contract id AB123 that includes 100 CPU licenses of the database product. In this example the 100 cpu licenses are distributed across 10 servers - each with 10 cpu’s. When you purchased these 100 cpu licenses you paid the upfront license cost for the 100 cpu’s and each year after you pay a yearly maintenance fee that covers support and software upgrades for these 100 licenses. Let’s say in this example you paid 75% of list price. List price for the Database Enterprise Edition is $40k per cpu, so you paid $4,000,000 x 75% = $3,000,000 for the upfront licenses and pay 22% (15% support + 7% software upgrades) of list for at yearly maintenance for a total of $660,000. Now for the part they don’t want you to know – they will try to maintain this yearly revenue stream at $660,000 no matter if you are actively using all 100 licenses or not. Hypothetical situation - Somewhere down the line, you are a good IT manager and find a way to cut costs by consolidating platforms. After your consolidation you can decommission two of your 10 cpu servers. So you go to Oracle and inform them you are no longer using 20 of your 100 cpu licenses and would like to only pay maintenance for 80 licenses. First thing your sales rep might say is - Why don’t you keep the 20 licenses (i.e. keep paying maintenance) and put them on the shelf. That way when you need them, you have them and don’t have to pay for upfront licensing again. You inform them that you really would like to give these licenses up and not pay for them anymore because you have no future need. This could go around and around a couple of times. Finally Oracle might tell you – OK, I’ll let you stop paying for the 20 licenses you are not using if you sign a software decommission letter and promise you are no longer using them (they have the right to do a software audit). However, your original 25% discount was based on a volume of 100 cpu licenses. If you want to change your contract to 80 licenses, we cannot give you the 25% discount because your volume has decreased. The best we can do is give you a 95% discount. This means that your yearly maintenance will be list price x quantity x 95% x 22% or $40,000 x 80 x .95 x .22 = $668800. So your maintenance costs will actually go up. Are you sure you want to do this? What this tactic buys Oracle is the fact that their yearly maintenance revenue does not decline, and that their install base does not decline either, even though not all software is in use. How do you protect yourself from this situation? The best answer seems to be making sure you have many small license contracts instead of few large ones. While Oracle has you cuffed if you try to reduce the quantity of a contract, they can do nothing if you wish to cancel an entire contract to reduce costs. Back when you needed the original 100 cpu licenses, if you arranged 10 contracts with 10 cpu licenses each, you have more flexibility in the long run. The downside is that you have to manage 10 contracts instead of one, but if you make sure they are all coterminous (all have the same end date), it is not that much more difficult to manage. Related Articles: How Oracle Licensing Differs CYA: Using Contracts to Protect Your Company