There isn’t a business around today that doesn’t use software in form or another on a daily basis, and many companies commission or create their own software for use in the workplace. However, with the increasing popularity of Bring Your Own Technology schemes and the prevalence of mobile devices and open source software, it is also increasingly difficult to keep a handle on exactly what software is being used in your workplace, by whom and in what way. However, the pitfalls of losing track of software usage could lead to legal infringements and expensive litigation.
By and large, it is copyright which governs what you can and can't do with software. As a key area that is becoming ever more fraught with new complications, it’s crucial to understand what software copyright actually covers, how to get these rights and what can and can't be copied.
Someone who creates a piece of work will not necessarily own any rights in it, far less any absolute right against the work being copied. First off, copyright only protects specified works. This is, however, a very long list, ranging from music to paintings. As far as software is concerned, the list can include:
- what the user sees on screen (the "GUI") (and this might, in turn, cover static images, frames and movement)
- the functional specification (the written record of what the software is meant to do)
- preparatory design materials (for example, diagrams showing how the software will hang together)
- algorithms (the logical steps that will be taken by aspects of the software, perhaps written out algebraically)
- source code (the instructions to the computer written out in a way that a person can understand, and written in one or other of the "languages" understood by computers)
- object code (the computer's translation ("compilation") of source code into long lines of binary numbers)
- means to prevent software from being copied (as the law says, "circumventing" this is a no-no)
- computer generated works (again, from music to paintings!)
Copyright only protects "original" works. However, the threshold is modest. The work must merely have involved a degree of skill, labour and judgment, and not have been copied from another work. Finally, copyright arises automatically when a relevant work is recorded, and this is without the need to register, pay or do anything more.
The most important thing to understand is who owns software copyright. The starting point is that the person who puts fingers to keyboard will own the copyright in the software they write. However, unless this person is writing software speculatively on his own account, things are seldom that straightforward.
If the software writer is an employee, then (unless the contract of employment says otherwise), the copyright will belong to the employer if the software was written in the normal course of the employee's duties. There might be issues here about, for example, the extent to which the employee had already written the software before his employment, whether software written "out of hours" also belongs to the employer, and whether an employee's duties extend to software writing. Marking software with the “©” symbol stating the owner and year it was written helps to prove ownership and establishes rights in some countries.
Unless there's a written transfer of the rights, a consultant (e.g. an external software designer or software house) will be the first owner of the copyright in any functional specification, source code or other works that he writes. If there is something in writing about the uses to which the commissioner may put the software, for how long, etc, then that will normally apply. However, if he is paid for the work, the consultant will be deemed to have granted an "implied licence" to the commissioner to use the work for the purposes for which it was commissioned. It goes without saying that the latter approach leaves room for serious dispute: e.g. whether the commissioner is allowed to use the same software for other projects.
Another area to watch out for is where software is developed by two or more people. If the respective contributions can be easily separated then each will own the copyright in his own input. However, where the contributions can't be separated out in this way, the works will be jointly owned. If there is no agreement on how things will pan out, then each of the authors can use the software and sue if it is found to be being misused. However, each author will need the consent of the other/s if he wants to allow third parties to use the software or if he wants to sell his copyright. If one of the joint authors dies, then his share of the copyright passes not to the other author/s, but to his heirs.
Finally, whilst software writers generally keep hold of their ownership of their software and give others permission to use it to a limited extent, software copyright itself can be sold either outright or in part (e.g. for a particular period of time).
Once ownership is established, the key thing to understand is what constitutes software copyright infringement?
An owner can sue someone who copies his software. Copying covers a multitude of sins ranging from photocopying manuals to rekeying code. Even "transitory" copying is caught, e.g. running or storing the software. Translating source code from one computer language to another infringes, as does (apart from one exception that we'll come back to) decompiling object into source code. Other types of prohibited copying includes getting round code designed to prevent the software from being copied!
One key area is the difference between literal and non-literal software copying. In another field of endeavour, there's quite a difference between "copying" a chef's recipe by photocopying it or by watching the chef carry out the recipe and making notes of your own.
There is also another type of activity that infringes software copyright, and this is where someone knows that they are holding an infringing copy of the software (say on a CD-ROM), and distributes that copy without the owner's permission. In fact that, and also knowingly copying software can also amount to a criminal offence.
What doesn't infringe software copyright?
A copyright owner can give one or more people the right to use his software under the terms of a licence. There may be rules on the period of use, number of users, place where the use can take place, payments, and so on. Under such an arrangement, a licensee may study the way his software works. He may make a back-up of his copy of the software and, unless his licence forbids this, he may correct errors in the software. Whatever his licence says, he may also "decompile" the software (translate the computer-readable object code into human-readable source code), but only to the extent that this is required for him to link this software with some other software. The more senior an employee, the more likely that a job specification which does not expressly mention software writing will be read to include writing software. It is possible to sell software copyright even before it is written so long as this is done in writing.
How "free" is open source software?
Some open source software can be used as you like with little significant obligation to its publisher beyond, perhaps, only redistributing it on the same basis as you received it (maybe acknowledging its author and offering royalty-free use maybe linked with a request for a donation to its author).
More normally, however, open source software is subject to a bundle of serious can and can't do's. As we have seen, software is subject to copyright, and any use of another's software (however "free" it is expressed to be) will be subject to some limited form of licence. Some open source software can be used for developing other software. This might be fine if you are only using that open source software to develop applications for your own use. However, if you want to on-sell or license the developed software, there could be issues that need tackling. Some open source software is made available on the basis that if you use it to develop other software, then you must make that developed software available for the world to use on the same terms as the original software.
In other cases you are allowed to charge for the use of the developed software, but only if you make it possible for the user to separate out the open source software and give him the same permissions to use that open source element as you had when you used it.
Whether or not that happens in practice, a software writer will likely be making actual (or implied) promises to his licensees that they have the right to use his software without complaints from others (including complaints from the writers of embedded open source software). Any company thinking of investing or perhaps buying the software writer's business will be concerned to see it is not picking up responsibility for promises that could not be kept. A possible investor will also think twice if the writers' software portfolio is based upon the use of open source software the subject of inappropriate open source licences.
If you are writing software for use by others, it would be helpful if you could always identify any open source element in your software. If needs be, for example if you want to change your licensing strategy, it will be invaluable if you can easily pinpoint the open source coding in issue and rewrite that aspect yourself (or use some less restrictive open source software).