Law in general may be a slow moving beast but not law in this area - it is fast changing, applying established principles to new circumstances. This fact sheet is a guide to some of the issues in this area but legal advice should always be sought where agreements and licences are involved.

Ownership

Besides you yourself being the creator of the software 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.

If you work with a developer, but put in a lot of your experience and knowledge, then 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

Licences

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 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.

Software licences have so many limitations on liability for a number of reasons relating 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.

"Shrink-wrap" licences

These do not necessarily work. 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

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

Software Patents

Generally speaking you cannot patent software. 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.

Escrow

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.