To print: Click here or Select File and then Print from your browser's menu

This story was printed from silicon.com, located at http://www.silicon.com/

Story URL: http://comment.silicon.com/0,39024711,11012533,00.htm

Ask the lawyer @ Silicon.com

By Alastair Breward

Published: Monday 06 September 1999

On the first Monday of every month, Silicon.com brings you answers to your IT law questions. Just send your queries to askthelawyer@silicon.com. This month, Alastair Breward of London law firm, Taylor Joynson Garrett, responds to your questions.

Q. Do software contractors own the code they write for client's systems if no contract has been signed saying they do not? What does the client own if they have not stipulated code ownership in the contract?

A. Generally speaking, yes, the contractor owns the code if there's no contract to say the client owns it.

The main thing to be 'owned' in software is the copyright. Where an employee generates a copyright- by creating software, graphics, or a manual, for example- in the course of doing his or her job, the employer owns it. Where a contractor (either a company or an individual hired from an agency) generates a copyright, the contractor owns it - unless the agreement says otherwise.

For the most part, in English law, contracts do not need to be in writing. Oral contracts are enforceable (if you can prove what the terms were, when the other side denies it!) However, there is an exception for transfers of ownership of copyright - these must be in writing signed by the transferring party. An oral contract for software can never suffice to transfer the copyright to the paying party, even where this was clearly intended.

It would be a pretty absurd if the paying party received nothing for its money, so what the courts will usually do, under their rules on making sense of contracts, is to find an implied term in the contract that the paying party was to at least have the use of the software, i.e. a licence. This licence will only be implied where (a) this must be done to make commercial sense of the contract, and where (b) it is completely clear that the term was intended to be there.

So the bottom line is that a paying party who does not get a written, signed contract assigning copyright will get, at best, a limited licence to use the outputs. Often, this will be non-exclusive, allowing the contractor to license the same basic product to competitors. However, a contract can assign copyright in work product not yet in existence, so there is usually no need for a separate second legal document.

Finally, special care should be taken when drawing up the legal documents used by contract staff to contract with the entity which will start out owning the copyright - this could be the programmer, the company used by the programmer for tax purposes, or the agency from which the programmer was hired.

Q. We currently do not have a company email or web access policy, and I am keen to put one in place. We have looked into packages like WebSense and Mime Sweeper, however we also need something we can add to staff contracts to both cover the company against the acts of our staff and to restrict potential time-wasting behaviour. What are the legal implications of email and web access?

A. This is such a big field, and the corporate philosophies of different companies (eg as to the freedoms given to employees) vary so much, that I think the best thing is to mention all the things you should consider when preparing a policy. Think about each as it applies to you, when drafting your own policy. Incidentally, most major law firms, including my own, have templates which you can start from, but there's no substitute for management input.

1. Emails are inherently non-confidential, especially internally. To give you clear powers to read emails without breach of anyone's rights, state that all emails using office equipment are open to management scrutiny.
2. Emails leave a record - they are like letters not voice calls, despite often being casually worded.
3. These records multiply - inboxes, outboxes, blind copies, and back-up copies.
4. Emails can be abusive, sexist, or racist as easily as spoken words, but with the aggravating factor that they leave a trail.
5. Likewise for defamatory content. Note too, that defamation can be inadvertent.
6. Despite 1 above, proper confidentiality notices help
7. Likewise, disclaimers of liability can help a little, though the broad rule is that the employer is liable for the acts of its employees in the course of employment. But one aim of an email policy is to support the argument that the employee was acting 'on a frolic' of his/her own.
8. Emails or web downloads can contain malicious code so get a suitable filter on your server - don't rely on policy.
9. Emails are admissible in court and other official proceedings - just like letters - but without the careful thought and double checking that usually goes into business letters. So don't let employees discuss litigious matters by email.
10. Junk mail ('Spam') isn't illegal, but it makes for awful PR
11. 'Company wide' emails about missing coffee mugs waste minutes of every recipient's concentration - perhaps several hours for a £3 item!
12. Auto-delete facilities can get rid of unread copies of broadcast messages whose relevance is past.
13. Hard copies of important emails will often be useful later.
14. Likewise, confirmations of receipt can be worth their weight in gold later - never assume it arrived.
15. Downloads can infringe intellectual property rights. Whether a download does or doesn't infringe depends on the integrity of the Web site operator and the license terms displayed. Consider simplifying this by banning some downloads outright, e.g. music of any kind.
16. Contracts can be formed quite easily by email. But don't allow it except by those who understand the relevant law of contract formation - it isn't too hard.
17. There is plenty of offensive material out there which can be viewed or downloaded. Consider a blanket ban on this, especially downloading, though even viewing will put permanent copies of the material into company cache storage. Bear in mind how hard it is to define what is offensive!
18. Most issues can arise both within the company (between two employees), and externally with the outside world. Check though your policy to see that both aspects are covered where relevant.
19. Breaking a policy is one thing, but it will help you if staff are clear about the consequences of breaking it. A sweeping statement that any breach will be treated very seriously is probably inadequate.
20. Finally, technical and legal developments in this field are rapid at present, so the policy will need keeping up to date, with input from your HR, IT and legal functions. Consider instituting a small committee to meet six-monthly.

**Network Multimedia Television Ltd./Silicon.com give no warranties as to the accuracy of the information and advice contained herein and can take no responsibility for any acts or omissions resulting from reliance upon the information provided. Commentary is intended only as general guidance on legal issues arising from the circumstances described, and specific legal advice based on all relevant facts should always be sought.**