Brendan Scott, July 2008
Acquisition Costs
Acquisition – Internal Requirements
Because of the Tragic Closure of closed source software, a purchaser is typically required to make a decision to buy one of a range of products, each with overlapping feature sets and other characteristics (rather than, for example, buying one at random and supplementing the software with third party or custom built components to cover any feature gap involved). In such an acquisition therefore, a wrong decision can end up being very expensive. As a result the decision process becomes invested with much more weight than it really ought to.
How do you know what you’re buying?
When drafting any contract, the drafter is faced with something of a philosophical problem – how do I describe the obligations on the parties. In particular, if acting for a purchaser, how do I describe the thing being bought? In many cases this is done by establishing a some form of enumeration (for example, you might use the serial numbers on equipment to describe them). Sometimes it is simply a general description of the purchased item (eg a slotted screwdriver). This is important because if the vendor supplies something you weren’t expecting, then it will only be a breach of the contract if the item has been correctly described there.
In the world of physical items making sure the description is correct is comparatively easy to do because a visual inspection of the device will quickly determine the issue. For physical items this is primarily because, while it may be a complex marvel of engineering, it usually only has a limited number of characteristics which are relevant. Moreover, often a vendor will provide a sample of the thing, so the contract can reference the sample provided (for example, a certain make and model of car). Compliance with these contracts are comparatively easily verified by the purchaser. For example, you will know if the wrong make or model of car has been delivered to you.
The same is not true of software. Software is often “sold” (a misleading term, since it isn’t typically sold) by signing a licence agreement with the person acquiring the software. The licence agreement needs to first identify what is licensed, then it needs to decribe the scope of the licence. While the second part is comparatively easy, the first entails some difficulties. For example how would a purchaser verify that they have received the right software? If the licence refers to a different thing to what has been loaded the software is unlicensed. If you sign a licence agreement for (eg) Software version X when you buy a computer how do you know that that is the copy of the software which is actually installed? If it says “version X” on the splash screen, is that enough? Logically it isn’t. In fact, what constitutes version X is determined arbitrarily by the maker of the software (well, not entirely arbitrarily, its determined by what will likely maximise sales). You don’t even have access to the gold masters to verify that what you have is the same (even if you did your supplier has probably customised some things for you, so it would be unlikely to be exactly the same).
Writing Specs
For a small purchaser this is typically a leap of faith. They simply assume that the licence corresponds to what has been installed. Its functionality is typically too complex to verify for themselves (and for new software, they are unlikely to even know what it is they are looking to verify). Larger purchasers address this problem not by identifying the software, but by identifying its characteristics. That is, the contract says (in effect), I don’t care what you give me, as long as it complies with the description at the back called the Specifications. What comprises the specifications varies depending on the circumstances. In theory, the specifications are a detailed description of what the software does and how it does it. Specifications can also be used earlier in an acquisition process to cull inappropriate software or determine the vendor who will supply the software. The trade off involved when drafting specifications is of detail against certainty.
If you are a company of any size, then management will require that the contract be reasonably specific about what it is that is being acquired and the terms of use. This means that a precondition to securing a licence is having an adequate specification for the software. This, in turn means not only money spent on developing a specification (assuming it’s not “complies with the documentation”, which, by the way, has some substantial risks) but also time.
The creation of a specifications document means extra work for the acquiring organisation. If it is not identified early enough, this work can start happening at the time the acqusition is being negotiated. This means that the specifications are drawn up in parallel with the contract. This is not necessarily a bad thing (apart from the fact that it is a key document defining what it is that is being acquired), but it means that the contract shouldn’t be executed until the specifications are completed (sometimes this is fudged at the acquirer’s risk).
These issues do not arise in the open source case because there is no risk that the software will not be delivered, or that the software which is delivered will be different from what has been reviewed (since they are one and the same thing). A company may want to create specifications for their own internal purposes, but such specifications will not need to be at the level of detail required for an effective contract.
Look-ahead Costs
If your vendor has different licensing terms and/or, (more likely) different licensing fees depending on some aspect of your implementation (eg is it virtualised, run on a certain sort of hardware, distributed or updated in a certain way etc) this raises additional costs. These are costs of attempting to anticipate your organisation’s actual needs and making sure either that the scope of the licence is broad enough to cover those needs or that there is some ability to upgrade the licence in the future to do so. In each case this is likely to involve additional licensing costs – costs which may not be utilised in the future (eg if, as it turns out, you don’t need the features covered by the licence extension). If a licence extension is not sought it is likely to also involve additional soft costs. You may, for example, need to restructure a deployment because you have chosen to forego certain features to save on licence fees. This involves at least an opportunity cost because you can’t use those features in your organisation, and it may involve additional internal costs of having to re-engineer the solution (eg to accommodate the missing functionality).
Over time, many of these cases turn out to involve additional costs simply because it is very difficult to foretell the future. While at the time of acquisition the organisation may well have thought it had no need for feature x, in three years time the world will have moved on and feature x may now be extremely important (and perhaps more expensive to licence, and, of course, with an increased opportunity cost until the feature is acquired). In the worst case scenarios a decision to forego functionality can result in a solution design which forecloses that functionality, or requires substantial reworking to implement.
Acquisition Delay
An contract negotiation typically takes a long time, much longer than either of the parties anticipates (although their lawyers will probably have a pretty good idea). Where there is proper will on each side a contract negotiation can go very quickly, but this is usually not the case. If you’re dealing with a large organisation then the chances are you will be presented with a contract and you get the choice to take it or leave it. This makes the contract negotiation process speedy indeed! Just as with feature sets, the contract terms are designed on an 80-20 rule and, moreover, are designed to inherently favour the vendor (exactly just how biased they are varies from vendor to vendor). If you’re one of The Many for the contractual terms, then no problem (I note here that there is not necessarily any correlation between The Many for features and The Many for contractual terms). If you are one of The Few, this may cause major problems because the consequences for copyright infringement are now completely disproportionate to the loss which such infringement occasions. Indeed, infringement in a commercial context can carry with it criminal liability.
For example, licensing of software often assumes specific business models and matches the licence to the vendor’s expectations of the model. If you have a different business model the licence terms will prohibit it. In the past many people would have signed the terms and ignored them, making the pragmatic assumption that if the vendor is paid, they don’t much care about whether or not you’re complying with the licence. With the introduction of criminal sanctions for infringement this option changes becomes extremely high risk (because a vendor has a discretion to pursue a civil infringement, but no discretion in respect of a criminal one and these actions will typically be initiated by a disgruntled employee).
Going through a licence negotiation then involves educating the vendor about your business model and convincing them that they should be willing to change the terms of the licence to accommodate it. Because these things are typically outside the scope of authority of the people typically tasked with negotiating the terms, these aspects need to be passed back up the chain within the vendor – causing delays. The overall process can be both lengthy and time consuming. Note: industry sectors which are highly regulated face similar challenges when negotiating with their vendors.
While the ideal situation is for organisations to get all their licensing ducks in a row before commencing on a project, it would not be unusual for this to be left until the proverbial last minute. This often puts undue pressure on the contractual negotiations (ie to not press sufficiently on specific issues). Where the licence terms are inconsistent with your business model giving up on some contractual terms is not an option (because to do so would invalidate your model). The only options are to push your way through negotiations or give up on the model/product. However, this means that whatever dependencies there are on the product (eg your product release) will likely be blown out and you still face the prospect of last minute re-engineering to back the relevant component out and either replace it with something else or live without the functionality (if the licence negotiations are not successful, or are not quick enough).
If the software is for inclusion in a consumer device this sort of delay can be fatal.
Brendan Scott's Weblog 