The Invisible Closed Source Overhead – 3

The Invisible Closed Source Overhead – 3
Brendan Scott January 2009

More on Acquisition –
and About the Day After

Earlier Articles in this Series

The Invisible Closed Source Overhead – 1

The Invisible Closed Source Overhead – 2

How Do You Know What You’re Buying II

Another issue that the acquirer of closed source software may have to contend with is the complexity of the licensing options.  In the previous post we discussed how defining the software which is being acquired can present a problem.  There is an additional, related, difficulty being that the software itself is not necessarily the most important part of an acquisition.  A well defined concept of software in an agreement does not settle the issue because what is being acquired is defined not only by what the software is, but also what can be done with the software as a consequence of the acquisition.   It will be hardly relevant if, even though what constitutes the software has been spelled out in exquisite detail, the licence does not permit the acquirer to (eg) run the software.

Therefore understanding the licensing terms is crucially important to actually defining the acquisition.  Larger vendors can provide a highly differentiated smorgasbord of licensing options, with different things being allowed for different price points and/or configurations.   In some cases whole jobs can be dedicated to simply understanding and explaining the licensing of a single vendor’s suite of products (one example – but job ads tend to be pulled once they expire so google might be a better bet).   As the licence terms effectively define what is being acquired, this means that acquirers can either invest a lot of time and money understanding the range of licensing options – or they can buy blind.  In too many cases it is the latter.

Short Aside

Incidentally, the fact that the same thing is licensed under different conditions depending on its use means that the vendor is effectively charging the customer for the customer’s innovative uses of the vendor’s product.  Imagine if the cost of a pencil differed depending on whether it was being used to write a Nobel-Prize-Winning novel or for a student’s homework – and if you were breaking the law for using the pencil you bought to use at school to later write a Nobel-Prize-Winning novel.

Post Acquisition

Having acquired the software you are now likely to discover that you have a number of additional problems facing you.

Re-engineering Your Processes

Regardless of the process and outcomes of a licence negotiation the vendor will have a pricing model against which you will be charged. In order to support this pricing model you will, at a minimum, need to re-engineer your processes to record any relevant data. Clearly this is not much of an issue for organisation wide one-off up front fee licences. It becomes increasingly complex as the pricing model becomes more fine grained. In addition to pricing requirements some vendors also have copy control requirements as a means of cross checking that the licensing has occurred correctly. This means that manufacturing processes may need to be changed to include, for example, the application of a sticker or other verification to a chassis, as well as processes to order, acquire and store the stock of these indicia.  A vendor may include auditing or accounting requirements, so record keeping practices may also need to be added.  Moreover, there is likely to be wastage of these indicia (lost, damaged etc) so in practice the licence fees for such software will be slightly higher.

Straight Jacketed

Software licence terms are rarely general (eg: “you may install and use the software as is reasonably appropriate”). Rather, they are specific. They will describe in some detail the circumstances in which you can (and can’t) install and use the software. Where you are a manufacturer installing the software on a device you may find the licence includes arbitrary restrictions on the characteristics of the device.

For example  Microsoft recently announced a drop dead date for the shipment of Windows XP.  It then extended that shipment date for devices meeting certain (maximum) specifications.   It subsequently modified that date further, relaxing the limitations on what devices the software could be loaded on [article with overview also here]. So, if you had acted on the earlier indications you would have arbitrarily limited yourself.  The subsequent later easing of the restrictions could end up being to the benefit of competitors (in that you may have committed yourself to a specific platform from which it  takes time to extract yourself).  Indeed (after this paragraph was first drafted) the Vista litigation has shown that exactly this happened.  According to a number of articles (examples: 1, 2, 3, 4)  HP upgraded their stock to match Vista’s requirements, only to find themselves expensive and uncompetitive when the Vista requirements were weakened (at Intel’s insistance).

Negotiation

The negotiation of a closed source licence can be straight forward, or it can be very involved.  The extent to which your business is unusual has an impact on this, with variations from a standard form of operation (as envisaged by the Vendor, albeit based on its other customers) meaning greater difficulty in negotiating a suitable licence.  Ironically, this means that the more innovative your business is, the harder it will be to become licensed.  Equally, if you are in a sector with which the vendor does not normally deal, the licensing terms can be similarly challenging.  Mitch Kapor and Pamela Samuelson, in their lectures at UC Berkeley refer to the case of the university sector.  This sector has very specific requirements for their accounting and calendaring systems.  However, no vendors are prepare to meet those requirements, despite it being a market of substance.  Universities are therefore looking to create open source solutions.

In most cases negotiations lead inexorably to a position which is suitable to each of the parties, although this may take some time.  In some cases though negotiations may break down.  If you have committed time and resources into a product on the assumption that the negotiations will turn out ok, then these will be sunk.  Moreover, you may now be caught with insufficient time to find a replacement and ship your product.  In any case you will end up either curtailing certain aspects of your proposed implementation or paying increased licensing fees or both.

Open source licensors will likely be less flexible on certain points than will closed soruce licensors (who can usually be swayed by the liberal application of licensing fees).  However, it is always clear ahead of time exactly what an open source licensor will be inflexible on, whereas, with a closed source vendor, it may not be until the very end of negotiations that you find out that the vendor really is serious about such-and-such a point.  Moreover, open source licensors will permit broad rights of internal use, so innovative applications of the software are unlikely to cause any licensing issues.  Examples of such problems in the closed source space include multiplexing terminals, embedding on devices and use in virtual machines.

In certain cases (particularly relating to data formats and standards) closed source vendors have an incentive to de-emphasise the licensing terms until after you have become committed to development using the relevant product.  Go have a look at vendor’s websites for their software development kits.  Do these pages emphasise how much fun and productive it is to use the SDK and are covered in eye candy, or do they emphasise the licensing restrictions you’ll be under if you ever want to ship a product using that SDK and are sombre and sober?

What can often happen is that the developers will download and start using an SDK because it solves a problem and legal only gets wind of it when the relevant products are mostly complete and nearing shipment.  This puts the acquirer in a weak negotiating position for the licence terms – or may even tie their hands.

Lack of a Crystal Ball

In many cases the licence you have struck with your vendor will expire after a certain time.  Customers typically enter into such agreements with a poor understanding of how their use of the product will develop over time.  They may believe it is something in the nature of a trial or a stopgap measure.  However, it is not at all unusual for stopgap measures to balloon in scope over time.  At the end of the initial licence period you are then in a position of weakness when renegotiating the licence.  There are a variety of marketing tricks used by Vendors (eg discontinuing old versions or discontinuing support for old versions) to make you pay a new round of licence fees, despite not really needing the difference in functionality.

Further, while this is certainly a problem where software is acquired by way of stopgap, it is also an inherently difficult problem even for those customers with a well developed understanding of their requirements going forward.

Long Term Uncertainty

Open source cannot assure you that you will always have a vendor to turn to when you need to solve a problem.   That’s because a vendor will only exist where there is a community which is sufficiently strong to support that vendor.  What open source does assure you though is that, all else being equal, if there is enough interest then there will be a vendor.   That is, a vendor does not have the option of shutting down a product because they want to focus on a new product.  It can shut down its own support, but it can’t stop others from supporting it – and others will support it if there is a market to do so.

This can happen in a variety of different ways.   A vendor can realise that an existing product effectively cannibalises the market for a new product, so they can stop shipments of the old product.  While you might think that if you stay with your existing copies you’d be fine – which is true to a point.  If you want to exchange data with others, you may be in trouble.  Vendors often introduce file formats in new versions of their products which are incompatible with the formats used in older versions.  If enough people (or enough people in a specific category – government departments are a prime example of this) can be convinced to move to the new format, then, by needing to exchange documents with that category, they can drag existing users forward onto the new format.

The vendor might be acquired by another player who has a different strategic outlook (and therefore cans your product).  The vendor might just lack business acumen and go under.