IT FAQs

---

 

Usually software is created with the intention of being "sold" many times - otherwise it would be uneconomic to produce. Even if it is mainly "bespoke" - created for one customer - there will usually be elements which the developer will want to reuse. Therefore the developer gives a licence for use, allowing licences to be sold to other customers as well. Licences may be exclusive, but will usually be non-exclusive and subject to limitations on how the product may be used. The type of limitations will depend on the nature of the product.

---

 

The basic rule is that if your employee creates the software in the course of his or her employment, then you own it. However if you pay someone else to do it, then he or she will own the rights to it. It is therefore important that this type of development is covered by an agreement setting out who owns what rights, particularly assigning to the customer the right which the customer needs.

---

 

Usually the developer will continue to own the intellectual property rights in the product in spite of your input. For this reason it is important to set out, in a formal agreement, the input which each party will be contributing to the project, and who, finally, will own and be at liberty to do business with what.

---

 

The licence will usually set out how many users can use the product - exceeding this will contravene the conditions under which you are allowed to use the product. If you could buy a single use licence, and then reuse the products for many users, the seller would be deprived of its legitimate revenue - you would then in effect be pirating the software. This would not only be a breach of your contract with the software vendor, but also potentially a criminal offence.

---

 

There are a number of reasons for this, and these relate principally to the nature of the medium. Software almost always has bugs in it, because it is not possible to try out every possible use of a product - otherwise it would never get released. Software is also frequently used in conjunction with other programs which have a different author, and it would be impossible to know how every function of another product might interact. Often the developers can only react to problems which present themselves. Without limiting liability to a reasonably high degree, releasing software may be too risky for a business. The reasonableness of the limitations is often a question of negotiation, particularly where the product is "mission critical" or of high cost.

---

 

Except where software is open-source, the crown jewels of a product lie in its source code - which is hidden from and inaccessible to the outside word. This prevents unauthorised copying and tinkering with the guts of the software, and preserves its integrity and commercial value. However if the developer went bust, or key personnel were no longer available, the maintenance and use of the product could become impossible. Developers therefore make arrangements for the source code of their product to be placed in escrow. This means that the code and key materials are deposited with a trusted third party, under an arrangement by which registered users can have access in the event of disaster striking the developer. The best organisations to perform this role are specialists, with facilities for both holding and releasing - rather than banks or usual deposit holders. Formal agreements are necessary to allow a user to have the benefit of escrow arrangements.

---

 

Not necessarily - it depends partly on which country's laws are intended to cover the contract. In some states of the USA

licences of this sort, where a label on the packaging states that opening the seal is deemed to be an acceptance of the licence terms, is binding under local law. In the UK there is no binding law on this. The principles which should apply are those of offer and acceptance, and one view is that if a user has already bought the box containing the disc, then having the licence terms set out one the shrink wrapping would be too late. In each case, the method of purchase and the precise mechanics of it will matter.

---

 

Click wrap is where licence terms are accepted on screen - generally with a "click to accept" procedure. This may happen either in the case of software loaded from disc, or downloaded. Its effectiveness is governed by some of the same considerations as those for shrink wrap - discussed above.

---

 

You may well need access to the source code of the software, unless someone else has bought the rights to the product. Whether you can gain access to the code will depend on whether it has been deposited with a third party under an escrow arrangement - as discussed elsewhere in these FAQs - and whether you are entitled to the benefit of that arrangement.

---

 

Generally, no - the intellectual property right which covers software is copyright, which arises automatically and cannot be registered in the same way as a patent. This is the situation in the UK and Europe, but not in the USA. This inconsistency is a matter of international concern, and it is likely that software developments will become patentable in the future. Patents have been granted in Europe for processes which amount to programs, and so the situation is uncertain and fluid.

---

 

We may never know, but it was considered to be a real enough problem for many professionals - and not by any means just those who stood to make a buck from it - to be very alarmed. Corporations which would not normally spend freely without very good cause spent enormous sums on proofing themselves. There were also problems, many of which were quietly dealt with - since it would help no-one's business to trumpet its own lack of readiness.

---

 

IT projects are notoriously liable to problems for a number of reasons. Some products are oversold by suppliers, whose salespeople are happy to answer "Yes" to every query about abilities. Frequently also the buyer has an imperfect understanding of what it wants at the outset, and fails to specify its needs correctly or in sufficient detail. This leads to misunderstandings, or "project creep" where the buyer changes what it wants as time goes by, without understanding the technical and cost implications. If the parties do not address issues promptly and maturely, and at the right level, projects can become disasters, with hugely expensive litigation and no winners. Any project of substance should have consultation and dispute resolution procedures built in.