Go to Database Directory || Go to Bibliography

Reproduced with permission of Journal of Business Law (March 2007) 161-181. Copyright © Sweet & Maxwell Limited and Contributors.

Software as Goods

Sarah Green & Djakhongir Saidov [*]


Software is a term used to describe the collections of instructions and data (also referred to as programs), that allow computers to operate. Without software, computers are redundant vessels, unable to perform any dynamic functions. From a legal point of view, software is remarkable for two principal reasons. First, its unique characteristics mean that it is not truly analogous to any conventional chattel with which the law is familiar. Secondly, despite the fact that it is one of the most ubiquitous commodities of our commercial age, it has no readily discernible legal identity. It is surprising, for instance, that even the most venerable legal texts currently devote only a few paragraphs to this commonplace product and its place within the law relating to the sale of goods.[1] This, combined with the relative paucity of judicial authority on the matter, means that it is not clear what manner of legal treatment should apply to disputes involving software. This uncertainty manifests itself in the question of whether software should count as goods for the purposes of the Sale of Goods Act 1979 (SGA) or the 1980 United Nations Convention on the International Sale of Goods (CISG). It is the purpose of this article to make the case for software to be classed as goods, under both the SGA and the CISG, where the circumstances are appropriate.


The lack of clarity surrounding the legal approach to software is both conceptually arbitrary and commercially inconvenient. Currently, parties to transactions concerned primarily with the transfer of software [2] are denied predictability in [page 161] terms of the legal response to any problem they may encounter, whereas such predictability is taken for granted by those contracting for conventional products. Add to this the fact that there is no convincing reason why software should be excluded from the statutory protection afforded to other items subject to sales, and it becomes increasingly apparent that the law's failure properly to tackle this issue is unsatisfactory and needs to be addressed: "Liability under a sale of goods is associated primarily with compensating a purchaser in respect of unfulfilled expectations..."[3]

Purchasers of software have, in general, the same expectations of fulfilment as those individuals purchasing items with which the law is more comfortable. A refusal to classify software as "goods" has the effect of failing to recognise the need for these expectations to be protected. The SGA [4] and the Sale and Supply of Goods Act 1994 (SSGA) function so as to provide legal assurances to those contracting to buy "chattels personal other than things in action and money".[5] Whether software is covered by this definition depends upon its classification as a chattel personal, as distinct from a thing in action. Such an interpretive question is one for the common law, but the common law provides no easy answer. The situation is somewhat similar in the context of the CISG. Although the question of whether software is goods within the CISG has arisen on a greater number of occasions than it has in English common law, it remains unresolved. One reason for this is that neither of these regimes was developed with a view to governing transactions in software. Another reason is that the rapid growth in the commercial and social significance of software has outpaced comparable developments in the legal understanding of the relevant technologies. It cannot (and should not) be denied that software is a unique phenomenon, so attempts to understand its nature through analogy with existing concepts are not always helpful. In order for software to receive an appropriate legal treatment, therefore, either our legal taxonomy, or the criteria we use in relation to it, needs to be revised. The discussion that follows demonstrates how important it is to recognise that, in determining the most appropriate classification of a product, the context in which it is being considered, and its capacity within that context are often more relevant considerations than are the intrinsic characteristics of that product.

"The word [goods] is of very general and quite indefinite import, and primarily derives its meaning from the context in which it is used."[6]

To fail to recognise this is to fail to distinguish between the (potentially) several nature of interests in goods, each one requiring separate legal treatment. Money, [page 162] for instance, in its most common and recognisable form, is a medium of exchange and so is unable to constitute the subject-matter of a sale. It is, however, only excluded from the ambit of "goods" once it has passed into currency.[7] As a physical note or coin, money can behave like goods when it is kept and exchanged for its own intrinsic value. This simple example shows just how dependent legal classification is (or should be) upon contextual considerations.


We examine both the SGA and the CISG for several reasons. First, these are both influential in the international legal environment [8] and, considering the importance of software for today's economy, it is important that there is clarity regarding its treatment under these regimes. Secondly, despite the fact that the United Kingdom has not ratified the CISG, it is beneficial for the English commercial community to be aware of developments in relation to it, since UK merchants may find themselves bound by it [9] and UK courts may sometimes be obliged to apply it.[10] Thirdly, the relationship between domestic and international developments has been aptly described as "symbiotic" [11] and there may be, therefore, some valuable lessons for the two systems to learn from each other.

In attempting to identify what it is about the legal concept of a sale of goods that has caused such confusion to arise in relation to software, we begin by examining two characteristics of the products themselves, namely "tangibility" and "movability" (variously identified as being necessary for products to have in order for them to count as "goods"). Next we look at the contracts to which software is subject, a context in which the question posed so often seems to take the form of asking whether "software transactions" are contracts for goods or for services, or whether they are licensing agreements or sales. Such an approach, we suggest, is not helpful; there is no reason to suppose that all software contracts should be of a common type. Rather, the law should look to the context of each individual agreement, just as it does with other products, in order to identify the precise nature of the contract at issue, and to deal with it appropriately. Our principal contention throughout this article is simply that it is possible to classify software as goods, and that, in the appropriate context, this is what should happen. [page 163]


Under some legal regimes, the criterion of tangibility is crucial for determining whether the object in question is goods.[12] Tangibility is usually defined as having a physical form or being capable of being perceived by the senses.[13] This notion has played a significant role in the current debate and it has even been stated that tangibility is the "stumbling block" to the classification of software as goods.[14] Furthermore, in St Albans DC v International Computers,[15] Sir Iain Glidewell distinguished between software per se and software contained on a computer disc. In his opinion, instances of the former would not be " 'goods' within the statutory definition", whereas a:

"computer disc onto which a program designed and intended to instruct or enable a computer to achieve particular functions has been encoded"

would be. A clear implication of this decision is that, to be treated as goods, software must be contained on a tangible medium.

By contrast, the way the CISG has been interpreted by courts and commentators is much less categorical. There is no apparent uniformity as to whether the tangibility/intangibility dichotomy is a relevant consideration. In one case,[16] the court ruled that custom-made software was not tangible and, on that basis, implied that it was not goods within the meaning of the CISG.[17] Another court, however, took a much more liberal approach by stating that the notion of "goods" under the CISG includes all tangibles and intangibles that might be the subject of an international sales contract.[18] There is also academic disagreement on the matter; some argue that goods do not have to be tangible under the CISG,[19] while others maintain that it governs only tangible goods.[20] Finally, some commentators take a somewhat ambiguous position by stating that the CISG generally governs tangible [page 164] objects, but also suggesting that the term "goods" should be interpreted broadly so as to include all kinds of software.[21]

Relevance of the distinction to the question whether software is goods

In establishing whether this distinction is relevant for the purposes of classifying software, it is necessary to determine why tangibility is ever required of a good. It is probably because of the requirement that property must pass under a sale. Most legal systems define a sales contract as an agreement for the transfer of property in goods for money, usually called the price,[22] and such a transfer generally requires a transfer of possession. In the case of pure intangibles, however, it is often argued in both common and civil law systems that either an alienation [23] or a possession of an intangible is impossible or that intangibles are not capable of being owned because they cannot physically be possessed.[24] It would seem, therefore, that some form of tangibility requirement is indeed necessary. Our primary contention on this point, however, is that legal notions of tangibility be updated in order to accommodate the digital age. A fundamental mistake, commonly made when classifying software, is the drawing of a qualitative distinction between hardware and software. In actual fact, there is no legally relevant distinction to be made between them. As will be demonstrated below, components of hardware differ physically from components of software only in terms of their size. They both have a corporeal form, but whilst hardware can be perceived by the unaided senses, software cannot.

This does not alter the fact that software is a tangible product, as the Supreme Court of Louisiana recognised when it agreed that:

"[i]n defining tangible, 'seen' is not limited to the unaided eye, 'weighed' is not limited to the butcher or bathroom scale, and 'measured' is not limited to a yardstick."

Hall J. then asserted:

"The software itself, i.e. the physical copy, is not merely a right or an idea to be comprehended by the understanding. The purchaser of computer software neither desires nor receives mere knowledge, but rather receives a certain arrangement of matter that will make his or her computer perform a desired [page 165] function. This arrangement of matter, physically recorded on some tangible medium, constitutes a corporeal body."[25]

This corporeal body takes the form of massive strings of "bits".[26] If a program is stored permanently on a CD ROM,[27] each "bit" is represented by either the presence or absence of a pit on the disc's surface. When a program is stored in a less permanent form, such as on a computer hard disc, it takes the form of a series of magnetic switches, positioned at either "I" or "O". Even in the case of an electronic transfer or "download",[28] when a program is in its most transient state, it still has a corporeal form because it exists as a series of electrical pulses. As electronic communication is merely a form of linking up hardware, any software that is received on a computer has not been plucked out of the ether, but has come from another machine located elsewhere.

Since software has this tangible form, it is capable of being alienated and possessed. In proving this assertion, it is important to note that the notions of property and possession are inextricably linked. As Bridge explains:

"[i]n the law of personal property, possession is the relationship between a person and a chattel based upon both the fact and intention of excluding all others from effective control of the chattel."[29]

If something cannot be possessed, then an aspiring owner cannot exclude others from it. In order to be possessed, software must exhibit two particular features. First, the notion of exclusivity requires that software be capable of being controlled. Since software exists as a physical attribute on hardware, it can be controlled,[30] and exclusive access to it can be maintained.[31] Secondly, software must be movable, because if it is not, it cannot be transferred without losing the capacity to be exclusively possessed.[32]

A failure to recognise the true nature of software is likely to lead to the unfortunate situation in which the law applicable to a particular transaction will depend on whether software has been delivered on a disc or downloaded online,[33] even though the purpose of such transactions will often be the same. No doubt parties to these transactions, and particularly those who contract as consumers,[34] would be surprised to learn that their chosen medium of delivery could have [page 166] significant consequences for their legal rights.[35] Under English law, the rights and obligations of the parties to a transaction not classed as a sales transaction, would be governed by common law rather than the SGA.[36] A contract found not to be a sales contract under the CISG would require judges and arbitrators to determine the law applicable to the dispute.[37] Either way, such a result could be regarded as unfair and contrary to the reasonable expectations of software buyers.[38]


Something that is not movable cannot be transferred without losing its capacity to be exclusively possessed. Unless it can be so possessed, its aspiring owner cannot exclude others from it. Bridge illustrates the point by comparing a diamond ring with information: the transferor of information "retains the information that was transmitted which denies one of the features of a property right, namely its exclusivity", whereas "a diamond ring cannot support two wearers at the same time".[39] Thus, the movability of a product would seem to be a good indicator of its ability to be classed as goods for sales purposes.

Software is movable.[40] Choses in action are not. A chose in action, such as a copyright, cannot be moved. If the holder of that copyright has it infringed, he or she has not had that right removed and transferred to the infringer. On the contrary, the right crystallises and enables him or her to take legal action. Another sort of chose in action, such as the "know how" to create a program, is not physically movable either because, although it might be communicated from one mind to another, it does not thereby leave its origin; a copy is made, but the original remains where it is. Such things necessarily travel with those who have ever shared in them, and remain with them; they are copied and distributed, but not moved. It is entirely possible to remove, however, a piece of software from one piece of hardware to another. Of course, such a thing can be copied and distributed, (and often is), but the same can be said of almost any conventional chattel. The essential [page 167] distinction between those things that are movable and those that are not is the possibility of deleting them from their source.[41] Movability is directly relevant to the requirement of delivery. According to the SGA, "'delivery' means voluntary transfer of possession from one person to another"[42] and it is clear that "delivery" under the CISG is also intended to include acts which would enable the buyer to have possession over the goods.[43] This is something that can occur in relation to software, distinguishing it once more from choses in action, which cannot be delivered. Since the performance of a sales contract is epitomised by the delivery of those goods,[44] it is clear that deliverability is an essential characteristic for any goods purporting to be the subject of a sale.

A further indicium of software's movability is that, regardless of the medium on which it is supplied, it is usually "intended to be furnished as a distinct chattel".[45] In other words, when it is incorporated into another object (such as a computer hard disc), it is not an accession to that other object in the true sense of the term. This is because it can be added to and taken away from its medium without causing any material damage to that host object.[46]

It is perhaps significant that Art. 2 of the US Uniform Commercial Code has explicitly moved away from a definition of "goods" which employs the term "chattels personal" and adopted one that reads "all things (including specifically manufactured goods) which are movable at the time of identification to the contract for sale".[47] This explicit reference to the criteria of movability and identification effectively pinpoints the characteristics of products most relevant to the question of whether they can be goods.

As far as the CISG is concerned, although it does not expressly require that in order to be "goods" an object must be movable, its various provisions reflect that such a requirement does in fact exist.[48] The corresponding section of the SGA,[49] which has adhered to the use of the term "personal chattels", could be regarded as being less specific and, consequently, less immediately helpful; after all, whilst some personal chattels will be capable of constituting the subject-matter of a sale, others will not. It would perhaps be more effective to identify from the outset [page 168] those things to which the statute will attach, rather than to refer to a genus from which exceptions must then be made. This is particularly true where, as here,[50] such a genus is beset by conceptual baggage.

Goods/services distinction

It has been argued that software transactions are contracts for the supply of services, rather than sales of goods, thus relying on a distinction recognised by many legal systems.[51] In such systems, different legal regimes apply, depending on how a particular contract is classified.

A number of attempts to explain the difference between goods and services have been made. For instance, it has been pointed out that service contracts, unlike sales transactions, are based on a continuing relationship and call for close co-operation and interaction between parties.[52] These two phenomena, however, can also be applicable to sales transactions, some of which are themselves performed over a long period and may also require mutual co-operation.[53]

It has also been argued that services are not capable of being stored,[54] and this point perhaps reflects the main difference between goods and services, namely the intangible nature of the latter.[55] It is possible that the law treats goods and services differently on pragmatic grounds because of the different ways in which they are traded. Thus, as far as tangible products are concerned, the emphasis is placed on the product itself "because it is possible to track its physical transfer from the producer to the consumer".[56] By contrast, the intangible nature of a service might explain why an emphasis is placed on the way a service is provided rather than on the product resulting from it.

Another possible reason for the distinction is the fact that the passage of property rights constitutes the central element of a sales contract. Service transactions, therefore, cannot be regarded as sales because, as a service in itself cannot be owned and possessed, there can be no transfer of property rights over it.[57] Whilst [page 169] it can be argued that a party has a legal right to claim performance of a service under the contract, such a right would be contractual rather than proprietary in nature.

The effects of the distinction

One feature of this distinction is that, in general, the duties and liabilities of the seller and a service supplier are different.[58] In the context of sales, the seller's liability is strict, making the seller liable for defects in the goods even in the absence of negligence.[59] With services, by contrast, the supplier's duties are usually those of exercising a specified standard of care.[60] Whilst this difference might be due to the intangible nature of services, leading the law to focus on its performance rather than on its outcome, the performance of every service has an outcome (such as a material product or information), on which the law could focus instead.[61] It would seem, therefore, that the distinction is not a logical necessity.[62]

Different types of software transactions

Because the goods/services distinction is established in English law and under the CISG, however, the question of how to classify a software transaction in relation to it will often be pertinent. Such transactions are diverse and when precisely a transaction amounts to a service is often a matter of judgment. Contracts involving software are just another example of how "trade in goods is increasingly taking on the characteristics of trade in services and vice versa",[63] so it is not surprising that there is no agreement as to how they should be characterised. Although some authors state that any transaction involving software is a service,[64] it is suggested that a better approach would be to refrain from such generalisations and to attempt to distinguish among various ways in which software can be traded.[65] [page 170]

First, a distinction is often made between contracts involving standard software [66] and contracts for software specifically developed [67] for the needs of a particular customer.[68] This distinction has been emphasised in the context of the CISG where some courts have held that contracts for the development of individual software are contracts for services, whereas contracts involving standard software are sales.[69] Although these decisions have received some support in academic writings,[70] the more recent and, it is submitted, better, view is that this distinction in itself is irrelevant for the question of whether a particular transaction is a sale within the meaning of the CISG.[71] The CISG contains specific rules designed to deal with the question of whether contracts involving manufacture/production [72] and services [73] fall within its scope and, therefore, these provisions, rather than an assumed distinction between standard and custom-made software, should be relied upon.

What may appear to be a difficult question is whether designing software for a particular customer falls within the scope of Art. 3(1) or (2). Those supporting the above-mentioned decisions do so relying on an assumption that custom-made software transactions fall within Art. 3(2).[74] It is our contention, however, that as long as software can be regarded as products "manufactured or produced",[75] [page 171] Art. 3(1) should be applied.[76] The essence of this provision is that unless those who order the goods supply "a substantial part of the materials necessary for such manufacture and production", the contract is a sales contract.[77] Nonetheless, the suggestion that, in some rare cases, there may be some reciprocal influence between Art. 3(1) and (2) seems correct.[78] For example, where materials supplied by the buyer do not in themselves constitute, under Art. 3(1), a substantial part of the materials necessary for the production of the goods and where services, other than those relating to the manufacture/production, do not constitute, under Art. 3(2), "a preponderant part" of the seller's obligations,[79] in exceptional circumstances, the combination of both contributions may change the character of the transaction as a whole to the extent that it falls outside the CISG.[80]

Therefore, whether a transaction involving software developed for the needs of a customer is a sales contract under the CISG is dependent on the facts of a particular case.[81] Although the position of the English common law is not entirely straightforward [82] (and the importance of characterising a contract is not as significant as it is under the CISG),[83] it nevertheless seems that whether a transaction involving custom-made software would be treated as a sale is also contingent upon the circumstances of a given case. For example, it is now broadly accepted that the question of whether a contract is one for work and materials or one for sale of goods is decided with reference to what the "substance of the contract" is and this determination may be made on the basis of a comparative assessment of the value or relative importance of work and materials.[84] It would seem, then, that the division of software into discrete categories on the basis of that which is mass-produced being distinguished from that which is bespoke, does not necessarily follow from the "substance of the contract" test and would, if relied upon, unjustifiably restrict this test.

Secondly, it is often the case that the delivery of software is accompanied by various support services, such as installation support,[85] system support, program [page 172] support services [86] and training.[87] According to the CISG, such contracts are sales as long as they do not involve the manufacture/production of software, and provided that services or labour do not constitute "the preponderant part of the obligations of the party who furnishes the goods".[88] The common law's answer will, once again, depend on the outcome of the "substance of the contract" test. It has also been suggested, however, that if services and goods are capable of being separated, different regimes may govern the "service" and "goods" parts of the contract.[89]

Thirdly, some contracts may consist of providing the right to use database content online, such as those made with Westlaw or Lexis-Nexis.[90] While some commentators allude to the possibility that such transactions can be treated as sales,[91] others argue that, assuming that no licensing arrangement is involved, such agreements are more likely to be treated as services.[92] In our view, however, the situation is more complicated because such transactions may involve both goods and services.[93] We have argued that one reason underlying these distinctions is that intangibles are distinguished from (tangible) goods because they cannot be possessed, owned and are not therefore amenable to control. If this explanation underlies the goods/services and tangible/intangible distinctions, then contracts providing access to online databases involve both goods and services. The use of online search engines, for example, constitutes a service because the software that enables these search engines to function is not possessed and controlled by a user in any meaningful sense.[94] If, however, a piece of software is downloaded onto a computer in the course of using an online database, that software can be regarded as goods because once software is downloaded onto a computer, possession and [page 173] control can be exercised over it.[95] Therefore, we may conclude once more that the appropriate classification of software transactions cannot be determined solely on the basis of the nature of their subject-matter: whether an agreement is really a service or a sales contract is something that can only be determined by the context of a particular transaction.

Licence/sales distinction

It is remarkable that the distinction between licensing and sales transactions is so often confused where software is concerned, particularly as this rarely appears to be a problem in the case of other products. Whilst the characteristics of software have led to uncertainty about its classification as "goods", the nature of the transactions to which it is subject has created further confusion. It is a common argument that many transactions involving the transfer of software are not sales, but licences and, as such, should not attract the statutory machinery of either the SGA or the CISG.[96] With respect, such an argument is misconceived. In the majority of software contracts, for example, it is necessary to distinguish between two phenomena; the intellectual property transaction and the goods transaction. These often take the form of a licensing agreement and a sale respectively.[97]

Take, for example, the typical case of an individual who buys, say, a database package.[98] Such a buyer purchases the program copy: possession of, and title to, that copy are transferred to him or her. In relation to that copy, the buyer has the superior possessory and proprietary right. He or she can exclude all others (including the seller) from that copy. Of course, he or she cannot reproduce, copy [page 174] or distribute that program without permission from the seller; nor can he or she otherwise exploit its originality or individuality for his or her own commercial gain.[99] This latter limitation, however, does not affect the sales transaction that has nevertheless occurred in relation to the physical copy of the program. A similar argument could, after all, be applied to the purchaser of a book; under the sales contract, the buyer has the ultimate proprietary and possessory rights over that copy of the book, against both the seller of the copy and the owner of the copyright in it (should they be separate parties). The fact that he or she does not also acquire (under a normal sales contract) the IP rights in the content is not taken to suggest that the book has thereby not been sold to him or her.[100]

Plurality of interests

Where software is concerned, two distinct forms of value exist. The first of these vests in the corporeal product itself. Generally, an individual who buys, for example, a software package, will do so in order to acquire it for its use value. The fact, therefore, that the corresponding IP rights over it are restricted will make no difference to the utility he or she derives from the transaction. In fact, the issue is unlikely even to occur to the majority of such purchasers. This interest [page 175] in the use value relates to the tangible and operational state of the product and, consequently, requires that the purchaser's expectations in terms of quality, fitness for purpose and functionality of the product be protected. In this context, where a consumer buys software in order to benefit from its use value, the transaction is indistinguishable from those in which conventional goods are bought for a similar purpose. There is no reason, therefore, to differentiate between the types of legal protection afforded in each context.

The second form of value that can exist in relation to software is the exchange value of the IP rights associated with it. A wish to acquire such IP rights does not necessarily coincide with a wish to exploit the use value of the product itself. (In fact, the two often do not coincide in practice.)[101] It is only these incorporeal IP rights with which a licensing transaction is usually concerned, but such rights are not transferred in the way that the product itself is under a sale. The licensee does not acquire the ultimate proprietary interest [102] in the intangible exchange value of the program; such rights are not, therefore, sold. All that the licensee does acquire under a licence agreement is the right to use the physical product to which the intangible property relates, subject to the rights of the copyright holder. The practical difference between this transaction and the sale of the product is obvious. Under the licensing agreement, the licensor, as holder of the IP rights, is legally entitled to exploit the uniqueness of the product. Under the separate sales transaction, however, the licensee of the IP has the proprietary and possessory interest in the one copy of the software that is transferred to him or her. This "use" right is good against the whole world, including the party who is licensor of the IP corresponding to that product: but because the licensing agreement relates to a legally independent phenomenon, it has no bearing on the effects of the sale of the digitised goods.

Therefore, the existence of IP rights over a computer program does not necessarily preclude the delivery of software from being treated as sales. Nevertheless, it seems that, in some cases, the nature of a licensing agreement may have an effect on how the delivery of software is characterised. Because of the existence of various restrictions and conditions flowing from the existence of IP rights, the delivery of software may not always be regarded as a sales contract. For instance, a licensing agreement may require the return of software in case a software user violates this agreement; or periodic fees, instead of a one-off fee, may be required and the duration of using software may be limited and that software may be subject to return. It is suggested that, in such cases, the terms of the IP transaction prevent the use value of software from being enjoyed and the delivery of software should not be regarded as a sale since it has few incidents of a sales contract.[103] [page 176]

This will not always be the case, however; even a licensed transaction can still be very similar to a sales contract in that the licence may be granted perpetually for a one-off fee. In such a case, it has been suggested that the transaction would become an "economic equivalent" of sales [104] where the title holder has no realistic expectation of software being returned.[105] The important point is that whether or not the existence of IP rights has an effect on the characterisation of the software transaction as sales is a matter of a particular case. A non-exhaustive list of relevant considerations includes such factors as whether the duration of using software is indefinite, whether payment is to be made once or periodically, and whether the licence can be revoked.


The final question that needs to be addressed in this section is whether treating software contracts as sales, despite the existence of IP rights, is compatible with the CISG and the SGA. In the context of the CISG, it may be argued that it is inappropriate to regard them as sales, because, although the CISG does not govern the transfer of property,[106] it provides that one of the main obligations of the seller is to transfer property in the goods.[107] Nevertheless, there are other provisions which allow such contracts to fall within the CISG. First, Art. 42,[108] which requires that the seller deliver the goods "free from any right or claim of a third party based on industrial property or other intellectual property",[109] provides that this obligation does not extend to cases where "at the time of the conclusion of the contract the buyer knew or could not have been unaware of the right or claim".[110] It seems that the latter requirement concerning the buyer's knowledge would often be met because either the contract would contain provisions relating to IP rights or the packaging would display a notice to that effect.[111] Secondly, since the CISG allows the parties to derogate from its provisions,[112] they can deviate from the seller's obligations to transfer the property in the goods.[113] Thus, despite the requirements of Art. 30, it would seem that, even in the absence of the parties' [page 177] intention to derogate from this provision, the existence of IP rights would often not prevent a software transaction from falling within the CISG.[114]

In terms of the SGA, the corresponding stipulation, allowing for the parties to agree to pass limited title, can be found at s. 12(3).Under this section, a vendor may contract to sell to the buyer only such title as he or she (or a third party) may have, as long as the buyer is made aware of all such encumbrances to title before he or she agrees to the sale.[115] Whilst the case law in which this section has featured to date bears no examples of s. 12(3) being used in this context, there is nothing in the wording of the section, or indeed in the Act, to preclude such an application. Thus, it would seem that, under both the CISG and the SGA, the transfer of property rights in a piece of software is capable of being classified as sales, even when it is unaccompanied by a corresponding transfer of the IP rights to that product.


A fundamental question, which is likely to influence the debate about whether software can be goods, is whether the existing sales regimes are really adequate or suitable to deal with peculiarities of software transactions. It is clear that, like other sales laws, neither the development of English sales law nor the drafting of the CISG contemplated their application to software transactions. It is not surprising, therefore, that there have been numerous assertions to the effect that conventional sales laws are inadequate to deal with such transactions.[116] The central charge is that the intellectual equipment that we use to deal with software transactions is not suited to the realities and expectations surrounding them, or that the rules underlying the existing regimes are based on factors which have no real relevance.[117] The question of whether existing sales regimes are adequate to deal with software transactions is immensely complex and cannot be answered without an extensive examination of the adequacy of different parts of these regimes. Whilst such an examination would be outside the scope of this paper, we will try to make some tentative observations based on our analysis thus far.

Strict liability

Under both English law and the CISG, liability for the lack of conformity of goods is strict, so a seller will be liable for failing to provide goods in accordance with legal requirements [118] and not for failing to exercise a particular standard of care. It has been argued that it is not appropriate to treat software as goods [page 178] because strict liability is not a suitable standard to apply to the software industry where suppliers (and purchasers) of software packages generally do not expect the product to function perfectly as soon as it is delivered because the fixing of "bugs" in software is a normal (and sometimes integral) part of such transactions.[119] A further objection to rules based on strict liability is that such rules are likely to inhibit innovation in the software industry.[120]

It is submitted that both English law and the CISG are sufficiently flexible to take account of these arguments and, if properly interpreted, will substantially alleviate the concerns raised. As far as English law is concerned, a seller is indeed strictly liable for any breach of s. 14 of the SGA. Such a breach will occur, however, only when the goods sold fail to meet a standard that a reasonable person would regard as satisfactory. More specifically, s. 14(2A) of the SGA explicitly states that any such judgment should be made "taking account of any description of the goods, the price (if relevant) and all the other relevant circumstances." This does not mean that goods have to be perfect when they are first delivered. "Fitness for purpose" and "satisfactory quality" are both fluid concepts that derive the exact terms of their applicability from the facts of any given situation. In setting out a suggested list of aspects of quality, against which goods are to be judged, s. 14(2B) states that all points are "in appropriate cases aspects of the quality of the goods". If and when applied, therefore, to the software market, these concepts will reflect what is "satisfactory" and "reasonable" within the realities of that specific commercial context. So, for example, a software program might be considered to be of satisfactory quality and reasonably fit for its purpose as long as it is free of significant bugs after an eight-month period of "on site" fixes.[121]

A similar argument can be made in the context of the CISG. With respect to the standard of fitness for "ordinary purpose" in Art. 35(2)(a), the prevailing view is that this provision does not require that goods be flawless.[122] Although there is no agreement as to the precise minimum standard required by this provision, there is little doubt that ultimately such a minimum standard should be determined on the basis of the parties' reasonable expectations in particular circumstances.[123] If this suggestion is correct, it would seem that the CISG supports the parties' expectation that software is rarely free from "bugs". A similar outcome will result from applying the standard of fitness for any particular purpose expressly or impliedly made known to the seller in Art. 35(2)(b). If a contract expressly provides that software must be perfect, the objection that strict liability is not [page 179] appropriate is irrelevant, because the CISG simply upholds agreements, so parties are free to raise objections to such a provision. If, however, a court is in search of the implied purpose of the goods, it will almost always have to interpret the contract on the basis of an understanding of a reasonable person in the light of all relevant circumstances.[124]

Thus, the fact that the interpretation of the particular circumstances on the basis of English law and the CISG will almost always involve reliance on fluid and flexible notions is likely to address substantially the concern that strict liability may not be in line with expectations prevalent in the software industry.

The existing rules on conformity

Perhaps because governing software transactions has not previously been an explicit concern of either the SGA or the CISG, both regimes have created uncertainty as to whether their implied terms relating to quality and fitness for purpose apply only to a storage/transmission medium or to both a medium and a program itself.[125] Whilst certainty is needed on this issue in order to promote commercial viability and legal coherence,[126] the lack of a specific provision does not necessarily render these regimes inadequate to govern software transactions: a commonly adopted set of classification criteria, to complement them, might solve the problem.

Such criteria should perhaps state that it is a copy of software in its entirety to which the rules on conformity apply. As was suggested in St Albans,[127] if there is a defect in either the medium or the program, there "would prime facie be a breach of the terms as to quality and fitness for purpose implied by the Sale of Goods Act".[128] First, this has to be the only sensible conclusion, not least in terms of the buyer's expectations. A purchaser of a computer program, if asked, is likely to reveal that he or she regards a functional piece of software as being the thing with which he or she identifies her sales contract. He or she is unlikely to be satisfied, therefore, if his or her vendor (in cases in which the vendor is not also the program creator) claims that he or she is only responsible for the disc on which his or her software is supplied, or (where the software was bought online), for the effectiveness of the program's download. Secondly, software is a peculiar product in that it consists of a computer program and a medium on which it is contained. As we have demonstrated, software can be regarded as a good and, if this is correct, the product as a whole and not only its storage/transmission medium will have to be considered goods. Since the rules on conformity apply to goods, these rules should, in our view, apply to everything that constitutes software which includes both a program and a medium. [page 180]


Some of the main challenges that have been raised with respect to provisions relating to the contractual conformity of goods seem to be (or at least are not incapable of being) adequately addressed by the SGA and the CISG. The calls for a specialised instrument dealing specifically with the peculiarities of software transactions, however, cannot be ignored. Indeed, one of our conclusions is that, although the SGA and the CISG are not incapable of governing software transactions, a specialised set of rules may indeed be something to be seriously considered, particularly if such rules were to exist at the international level. One reason for this is that electronic commercial practices, as well as the software market are, by and large, truly global or transnational in nature,[129] and it is often argued that a uniform, stable and secure international legal environment is necessary to support electronic commercial practices,[130] of which the software sector is said to be a "cornerstone".[131] The question of whether the time is ripe for international unification or harmonisation in this area remains open. In attempting to answer this question, it will be impossible to avoid the enduring debate surrounding the international unification and harmonisation movement.[132] Leaving aside the traditional viewpoints, some have argued that uniform law-making is ill suited for the dynamically developing sector of software commerce,[133] and that what is needed instead is a gradual evolution of law, flowing from commercial practices.[134] This argument, like many others, deserves serious consideration. Some important initial attempts have already been made in relation to some aspects of e-commerce,[135] but there is still a long way to go before a substantial international agreement on the appropriate legal treatment of software can emerge. [page 181]


* The authors are grateful to Professors John Miller and Albert Kritzer for their invaluable comments on an earlier draft of this article. Any errors are our own.

1. See, e.g. A. G. Guest (ed.), Benjamin's Sale of Goods (6th edn, Sweet & Maxwell, London, 2002), para. 1-086; and M. G. Bridge, The Sale of Goods (Oxford University Press, Oxford, 1997), p. 31. p. S. Atiyah, J. Adams and H.McQueen, The Sale of Goods (11th edn, Longman, London, 2005) is something of an exception to this, devoting pp. 77-82 to the issue.

2. To be distinguished, therefore, from transactions in which the transfer of software is incidental to the main purpose of the contract, e.g. the sale of a computer system onto which software has been pre-loaded. Such transactions as these cause few legal problems, as they are treated as sales of conventional products. See Advent Systems Ltd v Unisys Corp, 925 F. 2d 670 at II; and St Albans DC v International Computers [1997] F.S.R. 251 at 265 per Sir Iain Glidewell.

3. C. J. Miller and R. S. Goldberg, Product Liability (Oxford University Press, Oxford, 2004), para.1.04.

4. As amended by the Sale of Goods (Amendment) Act 1995, the Sale and Supply of Goods Act 1994 and the Sale and Supply of Goods to Consumers Regulations 2002 (SI 2002/3045).

5. SGA 1979, s. 61(1) and SSGA, s. 18(1).

6. The Noordam (No. 2) [1920] A.C. 904 at 908-909.

7. SGA 1979, s. 61(1). CISG does not provide a definition of "goods". Art. 2 of the CISG contains a list of transactions which are not governed by the CISG.

8. See M. G. Bridge, "Uniformity and Diversity in the Law of International Sale" (2003) 15 Pace Int'l L. Rev. 55 at p. 57. There have also been numerous statements to this effect in the context of the CISG (see p. Schlechtriem, "Basic Structures and General Concepts of CISG as Models for a Harmonisation of the Law of Obligations" (2005) 10 Juridica International 27).

9. M. G. Bridge, The International Sale of Goods: Law and Practice (Oxford University Press, Oxford, 1999), p. 39.

10. J. J. Fawcett, J. M. Harris and M. G. Bridge, International Sale of Goods in the Conflict of Laws (Oxford University Press, Oxford, 2005), pp. 680-682.

11. A. H. Boss, "Electronic Commerce and the Symbiotic Relationship between International and Domestic Law Reform" (1998) 72 Tulane L. Rev. 1931.

12. See the following discussion of the position of the English common law. A similar position has been taken in respect of the definition of "goods" in cases decided by the European Court of Justice (see F. Smith and L. Woods, "A Distinction without a Difference: Exploring the Boundary between Goods and Services in the World Trade Organization and the European Union" (2005-2006) 12 Columbia J European L 1 at p. 31.

13. See Black's Law Dictionary (6th edn, 1991), p. 1456.

14. L. Longdin, "Liability for Defects in Bespoke Software" (2000) 8 Int'l J L Information Technology 11.

15. St Albans, above fn.2, 265.

16. Appellate Court Köln, August 26, 1994 (Germany) at <http://cisgw3.law.pace.edu/cases/940826g1.html>.

17. ibid.

18. Appellate Court Koblenz, September 17, 1993 (Germany) at <http://cisgw3.law.pace.edu/cases/930917g1.html>.

19. H. Bernstein and J. Lookofsky, Understanding CISG in Europe (2nd edn, Kluwer Law International, 2003), pp. 19-22; J. Lookofsky, "In Dubio Pro Conventione?" (2003) 13 Duke J Comp Int'l L 263.

20. See F. Ferrari, "Cross-Reference and Editorial Analysis -- Article 1" at <http://www.cisg.law.pace.edu/cisg/text/cross/cross-1.html>; F. Ferrari, "How to Create One Uniform Contract Law" (2001) 5 Vindobona J Int'l Commercial L Arbitration 3 at pp. 18-19.

21. Schlechtriem in p. Schlechtriem and I. Schwenzer, Commentary on the UN Convention on the International Sale of Goods (CISG) (2nd (English) edn, Oxford University Press, Oxford, 2005), pp. 28-30; Herber in p. Schlechtriem, Commentary on the UN Convention on the International Sale of Goods (CISG) (2nd edn (in translation), Clarendon, Oxford, 1998), p. 23.

22. See J. S. Ziegel and C. Samson, Report to the Uniform Law Conference of Canada on CISG (1981) at <http://www.cisg.law.pace.edu/cisg/wais/db/articles/english2.html>; see also SGA 1979, s. 2(1).

23. See A. p. Sergeyev and Y. K. Tolstoy, Civil Law (Vol.2, Prospekt, Moscow, 1997), p. 13.

24. See Benjamin's Sale of Goods, above fn.1, pp. 61-62; M. G. Bridge, Personal Property Law (3rd edn, Oxford University Press, Oxford, 2003), pp. 5, 15 & 144.

25. South Central Bell Telephone Co v Sidney J Barthelemy, 643 So. 2d 1240 at 1246.

26. The argument is presented in detail in S. C. Green, "Can a Digitized Product be the Subject of Conversion?" ([2006] 4 L.M.C.L.Q 568).

27. Compact Disc Read Only Memory.

28. When software is "downloaded" onto a computer, it means that a copy of it is taken from the remote computer (also known as a server) and stored onto the (relatively) permanent memory of the user's computer (also known as a client).

29. Bridge, above fn.1, p. 202.

30. For a detailed explanation, see Green, above fn.26.

31. For instance, by protecting access to a program through the use of a password.

32. There is no doubt that software is movable -- see section on "Movability" below.

33. Above fn.28.

34. CISG does not govern sales of:

"goods bought for personal, family or household use, unless the seller, at any time before or at the conclusion of the contract, neither knew nor ought to have known that the goods were bought for any such use" (Art. 2(a)).

35. This implication of the dichotomy suggested by Glidewell has been recognised in both judicial and academic contexts -- see Atiyah, Adams and McQueen, above fn.1, p. 79; and Beta Computers (Europe) Ltd v Adobe Systems (Europe) Ltd 1996 SLT 604 at pp. 608-609 per Lord Penrose.

36. See St Albans, above fn.2, at 265.

37. See Art. 7(2) of the CISG.

38. Atiyah, Adams and McQueen, above fn.1, pp. 77-82. See also B. L. Horovitz, "Computer Software as a Good under the Uniform Commercial Code: Taking a Byte out of the Intangibility Myth" (1985) 65 Boston U.L. Rev. 129 at p. 133.

39. See Bridge, above fn.24, p. 6.

40. This word is used here in the literal sense of the term, i.e. capable of being taken from one place and transported to another. It is, therefore, not synonymous with the Roman Law classification used in continental legal systems.

41. Similarly, under Art. 2 of UCC, the "determination of whether or not a particular res is a good is based upon its movability at the time of identification to the contract" (Horovitz, above fn.38, p. 6).

42. SGA 1979, s. 61(1).

43. Huber and Widmer in Schlechtriem and Schwenzer, above fn.21, pp. 337-339; J. S. Ziegel and C. Samson, Report to the Uniform Law Conference of Canada on Convention on Contracts for the International Sale of Goods (1981), stating that Art. 30 CISG is analogous to its common law counterparts, at <http://www.cisg.law.pace.edu>.

44. SGA 1979, s. 27 and CISG, Art. 30.

45. R. M. Goode, Commercial Law (3rd edn, Penguin, London, 2004), p. 197.

46. ibid.

47. UCC, Art. 2-105, and see UCC Official Text and Comments (West Group, 2003), p. 84.

48. See Arts 30, 31, 35, 46, 67-69 & 85-88. See also J. Honnold, Uniform Law for International Sales under the 1980 United Nations Convention (3rd edn, Kluwer Law International, 1999), p. 51.

49. s. 61(1) of the SGA 1979.

50. See the discussion above at fn.5 and accompanying text.

51. See Smith and Woods, above fn.12, pp. 1-3; Atiyah, Adams and McQueen, above fn.1, p.21.

52. J. N. Bhagwati, "Economic Perspectives on Trade in Professional Services" (1986) 45 The University Chicago Legal Forum 45 at pp. 45-48; W. J. Ethier and H. Horn, "Services in International Trade" in International Trade and Trade Policy (E. Helpman and A. Razin eds, The MIT Press, Boston, 1994).

53. See Hamburg Arbitration proceeding March 21, 1996 (Germany) at <http://cisgw3.law.pace.edu/cases/960321g1.html>; and Zürich Arbitration proceeding May 31, 1996 (Switzerland) at <http://cisgw3.law.pace.edu/cases/960531s1.html>. It is generally accepted, both by those supplying and purchasing software on a medium to large scale, that the provision and implementation of such a product often necessitates an accompanying period of maintenance and bug-fixing. It is not unusual for such an ongoing relationship to last for eight months or so. See "Computer Programs as Goods Under the U.C.C." (1979) 77 Mich. L. Rev. 1149 at p. 1158.

54. See Bhagwati, above fn.52, p. 45.

55. See above fn.12, pp. 44-45.

56. Above fn.12, p. 44.

57. Above fn.12, pp. 44-46, making a similar point.

58. Although the result in practice may often be the same. See also N. Kawawa, "Contract Law Relating to Liability for Injury Caused by Information in Electronic Form" (2000) 1 J Information L Technology at <http://www.warwick.ac.uk>.

59. See Benjamin's Sale of Goods, above fn.1, para.11-055.

60. See section on "Strict liability" and Kawawa, above fn.58. Contrast, for example, ss.13, 14(2) & 14(3) of the SGA with s. 13 of the Supply of Goods and Services Act 1982.

61. Currently the obligation to provide a particular outcome can be strict if this is what the service provider has undertaken to do. See, e.g. Greaves & Co (Contractors) Ltd v Baynham Meikle & Partners [1975] 1 W.L.R. 1095; Supply of Goods and Services Act 1982, s. 16(3); and Benjamin's Sale of Goods, above fn.1, para.14-049.

62. It can be argued that the origins of the distinction are merely intuitive (above fn.12, p. 47).

63. A. D. Mitchell, "Towards Compatibility: The Future of Electronic Commerce Within the Global Trading System" (2001) 4 J Int'l Economic Law 683.

64. A. Scott, "Software as Goods: Nullum Simile Est Idem" (1987) 3 Computer L Practice 133 at p. 136.

65. See, e.g. above fn.10, p. 518.

66. Standard software "is not developed for a particular user and includes 'mass market' software that consumers can purchase 'off-the-shelf"': A. S. Zohur, "Acknowledging Information Technology under the Civil Code: Why Software Transactions Should Not Be Treated as Sales" (2004) 50 Loyola L. Rev. 461 at p. 465.

67. For different meanings of the term "develop", see L. M. Hutcheson, "The Exclusion of Embedded Software and Merely Incidental Information from the Scope of Article 2B" (1998) 13 Berkeley Technology L J 977 at pp. 995-999.

68. "'Custom software' is software that is either specifically developed for a particular user or modified to fit a particular user's needs" (ibid.). For the description of programming services, see "Computer Programs as Goods Under the U.C.C.", above fn.53, pp. 1161-1162.

69. Appellate Court Köln, August 26, 1994 (Germany) at <http://cisgw3.law.pace.edu/cases/940826g1.html>; District Court of München February 8, 1995 (Germany) at <http://cisgw3.law.pace.edu/cases/950208g4.html>.

70. See J. Mowbray, "The Application of the United Nations Convention on Contracts for the International Sale of Goods to E-Commerce Transactions: The Implications for Asia" (2003) 7 Vindobona J Int'l Commercial L Arbitration 121 at pp. 128-129.

71. CISG Advisory Council Opinion No. 4, "Contracts for the Sale of Goods to Be Manufactured or Produced and Mixed Contracts" at <http://www.cisg.law.pace.edu/cisg/CISG-AC-op4.html>; Schlechtriem in Schlechtriem and Schwenzer, above fn.21, pp. 54-55; F. Diedrich, "CISG and Computer Software Revisited" (2002) 6 Vindobona J Int'l Commercial L Arbitration 55 at pp. 64-65.

72. "Contracts for the supply of goods to be manufactured or produced are to be considered sales unless the party who orders the goods undertakes to supply a substantial part of the materials necessary for such manufacture or production" (Art. 3(1)).

73. "This Convention does not apply to contracts in which the preponderant part of the obligations of the party who furnishes the goods consists in the supply of labour or other services" (Art. 3(2)).

74. Above fn.70, p. 128.

75. See CISG, Art. 3(1).

76. See Commercial Court Zürich February 17, 2000 (Switzerland) at <http://cisgw3.law.pace.edu/cases/000217s1.html>; and Supreme Court December 4, 1996 (Germany) at <http://cisgw3.law.pace.edu/cases/961204g1.html>.

77. Another difficult question relates to the interpretation of the term "materials" in Art. 3(1). See CISG Advisory Council Opinion No. 4, above fn.71.

78. CISG Advisory Council Opinion No. 4, above fn.71, para.1.2.

79. See Art. 3(2) as well as the paragraph below.

80. CISG Advisory Council Opinion No. 4, above fn.71, para.1.2.

81. A number of policy reasons have been put forward to argue that liability of suppliers of custom-made software should be less strict than that of suppliers of standard software (Atiyah, Adams and McQueen, above fn.1, pp. 80- 81).

82. See Bridge, above fn.1, pp. 46-49, for a more detailed discussion of the approach taken in English law and concluding that its position on the subject is opaque.

83. Bridge, above fn.1, p. 47.

84. Robinson v Graves [1935] 1 K.B. 579; see also Benjamin's Sale of Goods, above fn.1, pp.33-34 & 37.

85. Supreme Court December 4, 1996 (Germany), above fn.76; American Mint LLC v GOSoftware, Inc, Federal District Court (Pennsylvania) (United States) at <http://cisgw3.law.pace.edu/cases/050816u1.html>; and District Court München, above fn.69.

86. For the description of these services, see "Computer Programs as Goods Under the U.C.C.", above fn.53, pp. 1158-1161.

87. Commercial Court Zürich, above fn.76.

88. Art. 3(2) of the CISG. For the discussion of the "preponderance" standard, see CISG Advisory Council OpinionNo.4, above fn.71; and Schlechtriem in Schlechtriem and Schwenzer, above fn.21, pp. 60-61.

89. Bridge, above fn.1, p. 47.

90. See A. Rodau, "Computer Software: Does Article 2 of the Uniform Commercial Code Apply?" (1986) 35 Emory L. J. 853 at p. 917; M. G. Larson, "Applying Uniform Sales Law to International Software Transactions" (1997) 5 Tulane J Int'l & Comparative L 445 at p. 468.

91. Larson, above fn.91, p. 470 (in the context of CISG).

92. Above fn.10, p. 516.

93. For the discussion of a possibility of such transaction being treated as sales in the context of the US law, see Rodau, above fn.90, pp. 916-917.

94. This is more complicated than it might first appear, since some digitised material must be downloaded to the local memory of a computer for it to be able to interact with that machine. Therefore, when a user is merely "browsing" an online database, he or she will have at least temporary possession of some software. Possession is, however, a relative concept, and it would be reasonable to suggest that, in contractual terms, the downloading of software to a more permanent store on a computer (such as a hard drive or CD ROM), would signify the point at which property in that software would be intended to pass, as this cannot usually be done unless the user puts in a password to identify him or herself as a paying subscriber.

95. Above fn.28.

96. See, inter alia, Horovitz, above fn.38, p. 130; above fn.10, paras 10.45- 10:51; Benjamin's Sale of Goods, above fn.1, para.1-077.

97. Perhaps the confusion between the two in this context stems from the fact that sales of physical software copies are rarely unaccompanied by licences restricting the corresponding IP rights over them. There are two main reasons why this is so; both attributable to the unique nature of software. First, there is the ease with which software can be copied and disseminated, and second is the value of software relative to the media on which it is distributed. Therefore, the software licence, along with technical barriers to its distribution (such as the well-known registration process employed by high profile software producers), are of paramount importance for the effective protection of IP rights in such goods. It is far more difficult, for example, to reproduce someone else's book and distribute it as your own work than it is to do the same with software. Not only would it be very expensive to do the former, but it would also be a far more visible exercise, making it easier for the rightful holder of the IP rights to monitor and impugn such activity. Nonetheless, despite the almost omnipresent licensing restrictions on copying software, the conceptual position is unaffected; software is capable of being the subject matter of a sale. Whilst licences are, in most cases, commercially sensible elements of dealings in software, they are neither a legal nor a logical necessity.

98. The argument that follows applies regardless of the means by which such a purchase is made; it includes software supplied on a CD, downloaded from a website or supplied pre-loaded on a computer.

99. The most common type of software licence is the one that restricts the use of a software program to a particular piece of hardware; such a tool is backed up by a technical device within the program, requiring that particular software copy to be registered. Once this has been done, that particular copy can only be re-sold if it forms part of the sale of the hardware on which it is registered. This restriction is, however, an effect of the licence in question. In the absence of such a licence, and unless the registration requirement has been inserted into the software, it would be possible to move (and so re-sell) software to a third party. In other words, there is nothing inherent in the nature of software as a physical entity that prevents it from being re-sold.

100. The analogy with books is by no means perfect (as software is not analogous to any other product), but neither is it as imperfect as it might first appear. For instance, it might be argued that the content of a book is often less important than that of software, resulting in greater liability for defective software content, and that, whereas the defective content of a book does not automatically cause damage, a computer will simply follow incorrect instructions, almost always causing damage. Consider, however, the example used by Sir Iain Glidewell in St Albans, above fn.2, of an instruction manual for a car:

"Suppose ... [t]he instructions are wrong in an important respect. Anybody who follows them is likely to cause serious damage to the engine of his car. In my view the instructions are an integral part of the manual. The manual including the instructions, whether in a book or a video cassette, would in my opinion be 'goods' within the meaning of the SGA, and the defective instructions would result in a breach of the implied terms in s. 14."

There also exists an argument that, whereas a book can be read and resold, software cannot be downloaded, used and the sold on to a third party. This restriction, however, is not a consequence of the nature of software, but of a certain type of licence often issued in relation to it.

101. For example, the average purchaser of a software package has no desire to acquire the IP rights; nor does he or she care how many copies are sold to other people: the only interest he or she has in a software package lies in its functionality.

102. There can, of course, be no possessory rights in relation to an intangible thing, so proprietary rights are all that an "owner" can hold.

103. Rodau, above fn.90, p. 908; and Schlechtriem, above fn.21, p. 29.

104. Horovitz, above fn.38, p. 156.

105. L. S. Primak, "Computer Software: Should the U.N. Convention on Contracts for the International Sale of Goods Apply?" (1991) 11 Computer L J 197 at p. 221.

106. Art. 4(b) of the CISG.

107. Art. 30 of the CISG.

108. Art. 41 of the CISG, which requires that goods be delivered "free from any right or claim of a third party", can, perhaps, also be relevant. However, because it does not deal with claims/rights emanating from IP and because restrictions in licenses usually emanate from IP rights, it will be Art. 42 which will usually be relevant.

109. Art. 42(1) of the CISG.

110. Art. 42(2)(a) of the CISG.

111. Larson, above fn.90, p. 463; and Diedrich, above fn.71, p. 70.

112. See Art. 6 of the CISG.

113. See Diedrich, above fn.71, p. 70.

114. See Commercial Court Zürich, above fn.76.

115. See Atiyah, Adams and McQueen, above fn.1, p. 118; Bridge, above fn.1, pp. 398-399; and Benjamin's Sale of Goods, above fn.1, para.4-032.

116. See, e.g. Larson, above fn.90, p. 486 (referring to the CISG as "obsolete").

117. See R. T. Nimmer, "Images and Contract Law -- What Law Applies to Transactions in Information" (1999) 36 Houston L. Rev. 1 at pp. 5 & 16.

118. Under the SGA, s. 14, a seller is liable for any failure of the goods sold to match up to the implied terms of satisfactory quality and reasonable fitness for purpose. Under the CISG, Art. 35(2)(a) & (b), a seller will be liable if the goods are not fit for any particular purpose expressly or impliedly made known to the seller at the time of the conclusion of the contract or if they are not fit for the purposes for which goods of the same description would ordinarily be used.

119. See "Computer Programs as Goods Under the U.C.C.", above fn.53, p. 1149, n.29.

120. See Nimmer, above fn.117, pp. 53-55.

121. In consumer contexts, such fixes would be compatible with the new SGA, Pt 5A (ss.48A-F), which implements Art. 3 of Dir 1999/44. Above fn.3, para.5.21.

122. See The UNCITRAL Digest of Case Law on CISG at <http://www.cisg.law.pace.edu/cisg/text/digest-toc.html>.

123. See Schlechtriem in Schlechtriem and Schwenzer, above fn.21, pp. 417-418; and Art. 8(2) & (3) of the CISG.

124. See Art. 8(2) & (3) of the CISG.

125. See Mowbray, above fn.70, pp. 145-146.

126. Compare the provisions of the SGA and the CISG with ss.401-405 of the Uniform Computer Information Transactions Act 1999.

127. Above fn.36.

128. Above fn.36, 265 per Sir Iain Glidewell.

129. Above fn.11, generally.

130. Above fn.11; M. L. Rustad, "The Uniform Commercial Code Proposed Article 2B Symposium: Commercial Law Infrastructure for the Age of Information" (1997) 16 John Marshall J Computer & Information L 255 at p. 270. On the value of legal certainty, see p. Van Alstine, "The Costs of Legal Change" (2002) 49 U.C.L.A. L. Rev. 789.

131. Diedrich, above fn.71, p. 56.

132. See, inter alia, L. Mistelis, "Is Harmonisation a Necessary Evil? The Future Harmonisation and New Sources of International Trade Law" in Foundations and Perspectives of International Trade Law (I. Fletcher, L. Mistelis and M. Cremona eds, Sweet & Maxwell, London, 2001), pp.20-23.

133. B. H. Kobayashi and L. E. Ribstein, "Uniformity, Choice of Law and Software Sales" (1999) 8 George Mason L. Rev. 261 at p. 275.

134. ibid.

135. See 1996 UNCITRAL Model Law on Electronic Commerce; 2001 UNCITRAL Model Law on Electronic Signatures; and 2005 Convention on the Use of Electronic Communications in International Contracts.

Pace Law School Institute of International Commercial Law - Last updated January 7, 2008
Go to Database Directory || Go to Bibliography