Charles A. Tyrrell, C.P.M., A.P.P.
Charles A. Tyrrell, C.P.M., A.P.P., Procurement Specialist, AT&T Systems Leasing Corporation, www.attcapital.com, Bloomfield Hills, MI, 48303, 248/339-1566, Chuck_Tyrrell@attcapital.com
Abstract. Acquiring software can be unlike any other product or service acquisition. Software is licensed, not purchased. The fact that the purchaser does not gain ownership of the software creates unique obligations and liabilities. Small missteps in software acquisition can have devastating consequences. The Uniform Commercial Code is being amended to include software and other transactions in information. The Year 2000 issue is now recognized for its size and scope in terms of available resources to address the issue and the money that it will cost to become compliant. Purchasing has the opportunity to add value and reduce costs through a thorough understanding of the nuances of acquiring software.
Overview. Software is becoming a major component of many products. Unlike other procurements software is licensed, not purchased. For those who think that software is none of their concern because they only deal in hardware, there is "hidden" software in more and more products and there are consequences of not properly licensing the "hidden" software.
Software is an expression of ideas in a form that a machine can interpret and then perform a function. As such software is the intellectual property of its originator. For those who have had little exposure to software procurement, the concepts of intellectual property can seem daunting.
Software had traditionally been protected by copyrights. This gave the software the same protections as books and music. Unlike books and music much software has a limited lifetime. In the mid- to late-1980's more and more software was being patented. While patents gave more protection to the software many infringement lawsuits were filed covering the "look and feel" of how the humans interacted with the software. When Article 2B of the Uniform Commercial Code is completed and adopted by the States there will be clear guidelines for transactions involving software.
Software is delivered on many different types of media; diskettes, tapes, compact disks, and even embedded into integrated circuits. Independent of the media the rights, duties, and obligations of the purchaser and supplier must be addressed. When the software is embedded into hardware it is often referred to as firmware. This method of delivery is somewhat different, but terms and conditions of the transaction should be no different than for other methods of delivery.
A method of delivery now receiving widespread coverage in the trade press is the delivery of software electronically over the Internet or another type of network. Again the basic underlying product is still someone's expression of ideas and must be licensed in an appropriate manner.
Software exists, and can be delivered, in two states; object code and source code. Source code is a set of instructions written in a programming language that must be converted to machine language to be executed on a computer. Source code can typically be understood by humans. Object code is the source code after conversion to machine readable language. Object code generally can not be easily understood by humans. For the most part software is delivered in object code format. This makes the delivered product less vulnerable to unauthorized copying and tampering.
In acquiring software the purchaser does not gain any ownership rights to the product being acquired. Instead the intellectual property is licensed. The terms and conditions of the license (contract) between licensee and licensor determine the rights conveyed to the licensee. With hardware the purchaser has all rights to the product except those rights specifically excluded. With software the licensee has only the specific rights that are granted.
When someone goes to see a movie and pays for a seat in the theater, that person does not get an ownership interest in the movie. Instead they are allowed to use the movie for its intended purpose. This transaction is an example of licensing.
Many products are sold as if they are a hardware only product, yet they contain a considerable amount of software. Without the protections of a license to use the software the hardware may be unusable in the event of a dispute. An example would be a manufacturing machine that has embedded software for control and monitoring of its operations. If a third party claims an infringement of the software, then the manufacturing company could be enjoined from using the machine until the claim of infringement is settled. In the absence of any protection from such infringement claims, the manufacturing business will be impacted possibly to the point of ceasing operations.
Quality. In the software marketplace the concept of quality has a very limited meaning. Quality does not refer to the ability of the software to perform to its applicable specifications nor being free from errors. Instead quality is limited to the physical media that contains the software. The thinking in the industry is that no software can be made error free, so the suppliers of software will deny any warranty.
Some software quality issues that are important to the licensee and that many licensors will warranty are those associated with destructive code embedded within the software. These go by many names including Trojan horse, back doors, worms, and viruses to name a few. All of them leave a licensee exposed to possible security breaches and possible data loss.
Liabilities. When using licensed software many liabilities are created. How those liabilities can be mitigated is up to the purchasing professional in conducting negotiations with the supplier of the software. It is imperative that the purchaser understand exactly how the software will be used by their organization. The organization's policies and operating procedures must be understood and the license crafted to adhere to those policies and procedures.
Indemnifications. The supplier of the software must be contractually bound to a level of accountability in regards to their ability to license the software. They must also be bound to protect the licensee from loss.
The first portion of the indemnification that must be in any software license is that the supplier has all rights, title, ownership, or marketing rights necessary to provide the software to the licensee. This must also include that the rights granted do not violate any copyright, patent, trade secret or other intellectual property rights. The supplier must also represent that at the time of delivery of the software that it not be subject to litigation.
The second portion of the indemnification is that the supplier must indemnify and hold harmless the licensee from any and all actions, claims, losses, damages, liabilities, awards, costs, and expenses resulting from any breach or claimed breach. Both parties to the agreement also must have a positive obligation to inform the other of any notification of action from any third party.
The final portion of the indemnification reefers to action to be taken in the case of claimed or actual infringement. The supplier shall at their option and expense either procure the right for the licensee to continue to use the infringing software, or replace or modify the infringing product or make its use noninfringing.
Obligations. Beside the standard obligations of timely payment and fair dealings with the supplier, there are some obligations that are unique to software.
The most obvious of these is to only use the software in the manner proscribed in the license. Incorrect use can result in the revocation of the license. Unauthorized copying of the software and documentation can not only result in license revocation, but may also result in criminal and/or civil prosecution.
The licensee also has the obligation to protect the software and documentation with the same level of care that the licensee uses for their own proprietary information.
Escrow Of Source Code. Some software will be of much more strategic importance than others. One provision that can be negotiated is the escrowing of source code. This can be a very contentious issue with the licensor. It would then put their intellectual property in the hands of a third party. It can also be very costly. Therefore software should only be escrowed in very specific circumstances. For example if the licensor leaves that line of business, they discontinue maintenance or support of the particular product, or in the case of bankruptcy or business closure.
To further protect the intellectual property there must be specific provisions that the licensee needs to prove to the escrow agent to access the source code and limitations to what the licensee may do with the intellectual property. This can be as simple as fixing a recently uncovered problem to as complicated as making the product work with another operating system. These use of the changes to the original source code are generally limited to that of the licensee who made the changes.
Uniform Commercial Code Rewrite. The current Uniform Commercial Code (UCC) affects practice and law throughout the economy on transactions in goods. At the time of the adoption of the UCC there was a clear distinction between goods, services, and intangibles in the marketplace. Over time that distinction has become blurred. The services sector of the economy now dominates the goods sector. The driver of this fundamental change in the economy is computerization.
In July of 1995 the Executive Committee of the National Conference of Commissioners on Uniform State Laws concluded that the appropriate approach to codify guidelines for information transactions was to develop an Article of the UCC dealing with licensing and other information transactions. This Article is designated as Article 2B. The current draft is nearly 200 pages long and covers forms of intellectual property other than just software.
More than 30 organizations have had input to the drafts that have so far been completed. Many of these organizations directly represent the interests of the large software publishers. Info World magazine editor Ed Foster has been following this issue with editorial columns from time to time in the magazine. He has also hosted town hall style meetings around the country to solicit input to the Committee directly from software users.
With the ubiquity of software in all manner of products it is important for professional purchasers to keep up to date on the Article 2B writing and adoption process. If your organization has significant resources in software, either developed or licensed, it may be prudent to become involved with the development of Article 2B.
Year 2000 Compliance. The largest issue facing the world of software, users and developers alike, is that of Year 2000 (Y2K) Compliance, also referred to as the Millennium Bug. At midnight December 31, 1999 all software that is not compliant will cease to operate correctly when performing date calculations.
For many years programmers used two character fields to represent the year in dates. For example the year 1997 would appear as 97 in the program. This worked well for most applications for a long time. But as the year 2000 approaches we can see errors occurring. With a two character year the year 2000 will be represented as 00, yet the program will read it as 1900. Therefore all date calculations will be in error.
For example interest calculations on a mortgage could be up to 100 years too high. The program that tracks the mortgage payments could show the payments to be up to 100 years late. Many of these programs have imbedded within them delinquency reporting to credit agencies. So then the credit agencies will get incorrect information based entirely upon an error in an unrelated program. The mortgage holder would not find out about this until the next time that they applied for credit and it would be denied based upon the late payment history from the mortgage company.
In the early days of computers the hardware was very expensive, memory cost dollars per byte. Programming was comparatively inexpensive. Programmers were instructed to write their software in ways that preserved the expensive hardware resources. One easy way was to represent the year with only the last two characters. The logic of the program would understand the implied first two characters, and in printing the "19" would be inserted. Some forward thinkers saw the need to someday use four characters but of course the currently developed program would be replaced and no longer in use by the time that the 2000 would effect anything.
Now things are different. Memory costs dollars per megabyte. Some programmers are being paid six figure annual salaries. Many legacy programs written in the 1970's and 1980's are still in use, and are critical to the functioning of their businesses.
Some businesses are unaware as to the impact that Y2K problems will have upon their operations. The only way to assess the impact is to examine all software for Y2K compliance. In many instances this will require a line by line examination of the source code. Many programs contain little or no documentation form their original development nor form subsequent maintenance of the code.
After a complete evaluation of all applications a determination needs to be made as to how best to address the problems that have been identified. Some applications can be fixed fairly easily, others will take extensive re-writing, while others will need to be completely replaced.
Whatever decision will finally be made, get started now. December 31, 1999 seems like it is a long time in the future. As of May 1, 1998 you only have 609 days left to get all of this work done. A typical application development and implementation plan of nearly two years would mean that the new application will not be fully functioning by December 31, 1999.
What is widely believed to be the first lawsuit involving a firm supplying software that is not Y2K compliant has been filed. It involves Produce Palace International, an upscale grocery in Warren, MI against Tec-America Group. Produce Palace upgraded its point of sale system including ten cash registers to be Y2K compliant. Visa and other credit card companies have made their systems compliant and have begun issuing cards with expiration dates in the year 2000 and beyond. The problem came up with the credit verification system provided by Tec-America. When a credit card was scanned into the system with a date beyond December 31, 1999 the Tec-America system would cause the Produce Palace point of sale system to crash halting sales until the store's system could be brought back on line. Customers were denied the use of their credit cards for that purchase and many have not returned. In the lawsuit Produce Palace is asking for $100,000 in damages for the cost of the system and tens of thousands of dollars for lost business.
This lawsuit illustrates the point that the Y2K problem in not limited to Fortune 500 firms running mainframe, COBOL based legacy applications. Large businesses, small businesses, nonprofit organizations, and governmental units will all be effected. Mainframe, personal computer, client/server, and even point-of-sale application will be effected. Some newer applications will need to be updated while older applications may already be in compliance.
There is a lot of hype and fearmongering in the trade and popular press. Stories have been told that if the Y2K work is not completed that planes will be falling from the sky and that trains will be stopped on the tracks at the stroke of midnight December 31, 1999. That just will not happen. Shipments on the trains may not be accurately tracked. All of the passengers on the planes will be 100 years late in their arrival.
Given the hype surrounding the Y2K issues be careful not to under represent the impact within your organization. Left unaddressed there will be business impacts. What those impacts are must be determined by each organization.
The total cost to businesses, governments, and non-profit organizations to become compliant is estimated in the trillions of dollars to hundreds of trillions of dollars in the United States alone.
Conclusion. Purchasing has the opportunity to add value and reduce costs through a thorough understanding of the nuances of acquiring software. Correctly understanding the unique obligations and liabilities of software acquisition as well as keeping current with the issues in the marketplace are essential to making a value-added contribution.
Info World, 1996, 1997
National Conference of Commissioners on Uniform State Laws, 1997 http://www.law.upenn.edu/bll/ulc/ulc.htm
Wong, Wylie, "Grocer Registers Year 2000 Suit",
Computerworld, August 18, 1997