Intellectual Property – a Crash Course for Developers

Being on vacation, I wasn’t able to write my usual article for Overload myself, so I have asked my friend Samuel ‘Lawyer’ Bunny, Professor of Law at Efrafa University, to write a brief description of intellectual property law aimed at software developers. If some of you consider it as lacking in controversy, don’t worry – I will be back from my vacation in time to write the next one.
‘No Bugs’ Bunny

Disclaimer: opinions within this article are those of Samuel Bunny, and do not necessarily coincide with the opinions of the translator and Overload editors; please also keep in mind that translation difficulties from Lapine (like those described in [ LoganBerry2004 ]) might have prevented an exact translation. In addition, both the translator and Overload expressly disclaim all responsibility from any action or inaction resulting from reading this article.

In addition, as always with legal matters, it should be mentioned that neither the author nor translator are practising lawyers and that nothing in this article should be interpreted as legal advice. If you are in need of legal advice, you should ask your attorney.

There is nothing more powerful than an idea whose time has come.
~Victor Hugo (one of the authors behind the ‘Berne Convention’ on copyright)

Yet Another Disclaimer: in this article I will not address questions about the usefulness or morality of the existing laws (I’ll leave that to ‘No Bugs’ when he’s back). My goal here is to explain the basic concepts as they stand now, and not to discuss whether they should or should not be changed. Also it should be noted that intellectual property laws differ from one jurisdiction to another, and while an effort has been made to write only about issues which are widely acceptable, there is no guarantee that any statement will be valid where you are.

Basically, all Intellectual Property rights can be divided into three distinct categories: copyright, patents and trademarks (there are also other related rights, like industrial design rights, which we won’t discuss here). These three categories of rights, as a rule of thumb, provide separate and independent protection. It means, in particular, that the very same software program can be protected by copyright, by patent(s), and by trademark(s).

Copyright

Out of the three protection mechanisms I’ll look at, copyright seems to be the simplest concept. If you have written a poem you are entitled to a certain set of rights concerning your work, including the right to prevent others from using it, the right to prevent others from modifying it, and so on. In most places you are not required to register your copyright, and are not even required to put copyright notice (like ‘Copyright 2011 Samuel Bunny’) for your rights to be enforceable.

So far so simple. The complications begin when we start to consider situations when the copyrighted work is allowed to be used without the permission of the copyright holder. This concept is known as ‘fair dealing’ in the UK, and ‘fair use’ in the US. It allows some limited use of copyrighted works. For example, you can usually use some quotes from the original book, even when you’re writing a negative review about it and don't have permission from the author. It is an effective defence in many practical scenarios, for example, Wikipedia claims ‘fair use’ for certain types of images in limited circumstances.

It should be noted that there is a rather common misconception that copying for non-commercial purposes automatically provides a ‘fair use’ defence. This is dead wrong: while non-commercial can be one of the factors when ‘fair use’ is considered, courts in various jurisdictions have held that copying for non-commercial purposes can constitute copyright infringement, including criminal copyright infringement. You need to keep in mind that non-commercial purposes does not guarantee ‘fair use’ to be a valid defence. In general, the determination of ‘fair use’ tends to be very complicated, and the safest thing is not to rely on it until you’ve got advice from your attorney who specializes in IP law (unfortunately I’m already retired, so I won’t be able to help you – sorry).

Impact of copyright on software developers

For software developers, the basics of copyright can be summarized in a very simple way: don’t copy-and-paste third-party code into your own code. While this is not an exact definition (for example, replacing copy-and-paste with re-typing the source code won’t help to avoid liability), it is a good starting point.

Furthermore, we need to mention that even if you’re using third-party code in a modified form, you can still be found liable for copyright infringement. The safest thing (and the most detrimental for solicitor salaries) is to avoid any kind of copying of source code which is not yours.

One other thing to remember (to be discussed in more detail below) is that even copying open-source code can be dangerous and detrimental for your company, so check with your legal department (or with the project steering committee) what you are allowed to use in your project, and what you are not. And while we are on the subject: the absence of a copyright notice does not mean that the material is not copyrighted – most text, including source code, is copyrighted by default without any notice – so it is better not to copy anything before clarifying it.

Patents

As we have seen, normally copyright arises at the very moment that an author has written something, and no registration is necessary. In contrast, a patent arises only when the inventor goes to a competent patent office and says ‘I have a new invention to patent’ and submits a patent application which describes the invention in detail. From this point on inventors are allowed to use the words ‘patent pending’ when they describe their product. Still, this is merely the start of a lengthy process known as ‘patent prosecution’, when the task of the inventors – usually via patent attorneys representing the inventor – is to persuade the patent office that their invention is patentable.

In general, there are three main criteria for being patentable: the invention should be novel (so no ‘prior art’ can be found which describes the same invention), useful (known as ‘utility’ in US and ‘industrial applicability’ in EU), and non-obvious .

Software patents

Software patents are an extremely controversial subject and legislation on them is still in a state of flux. As of 2011, in the US software patents are generally not prohibited. In the EU the situation is much more complicated: while the ‘Proposal for a Directive of the European Parliament and of the Council on the patentability of computer-implemented inventions’ (which caused much debate at the time) was rejected in 2005, this doesn’t mean that software inventions are not patentable in the EU. Currently, the way the European Patent Office interprets existing law is that (very roughly) software inventions are only patentable as long they have a ‘technical character’ (see, for example, [ EPO2007 ]). It considers ‘pure’ software algorithms to be similar to mathematical formulae, and the patenting of mathematical formulae is prohibited in most countries, and in practice means that software patents are possible in the EU though they are subject to substantially more scrutiny than in the US.

Impact of patents on softwaredevelopers

For software developers doing everyday development, the impact of patents is usually not large. Generally, you are not under any obligation to make a patent search to check that your code is not infringing a third-party patent, though if you do know about a patent, wilfully infringing it might have unfortunate implications. On the other hand, if you yourself have made something which you’re sure that nobody else has done before it might be a good idea to approach your management asking if they’re interested in patenting your invention (as a rule of thumb, any invention made during working hours belongs to the company). Assuming that your invention is viable, going ahead with a patent will certainly improve your status in the company, might result in a bonus, plus the line ‘co-authored such and such patent’ will look very nice on your resume. Some companies (most notably IBM) even have special programmes to encourage employees to submit inventions to a dedicated IP legal department (and this programme is one of the reasons why IBM has been a world leader in new patents for many years).

Trademarks

The first de-facto trademarks appeared when a blacksmith in a small town decided to put a special sign on his swords, to make sure that whenever somebody is impressed with the sword quality, he can identify the smith and come to him to buy another sword. The very same idea is now known as ‘trademark’.

Trademarks can be either ‘registered’ or ‘unregistered’. For registered trademarks, usually the symbol ® is used, for unregistered trademarks the symbol ™. There are further differences between the two, but they’re of no interest to software developers, so we’ll leave them aside.

Impact of trademarks on software developers

For software developers, the only thing to remember about trademarks is not to use third-party trademarks without consulting management and/or the legal department. While it might seem a good idea to add a huge Apple logo onto your home page to promote your Mac programs, it’s much safer to ask before doing it to avoid nasty potential problems.

Licences

We have discussed the three main forms of intellectual property, but many software developers will ask: how do licences fit into this picture?

Technically, licences do not belong to intellectual property law – instead they’re usually considered as a part of contract law. For example, when you’re buying a software product you’re buying not only the physical CD containing the binary executable, you’re also entering into a contract which allows you to use the product (within certain limitations specified in the licence).

With open-source licences the situation is usually the following: when you get the source code you are not automatically allowed to use it (because it is copyrighted). The only reason that you are able to use it is because you have also entered into a contract with the copyright holder; this contract will allow you to use copyrighted code in exchange for agreeing to observe some limitations stipulated in the licence. In case of common open-source licences, acceptance of licence terms is implicit when you start to use the code (this means that if you’re using the code you must agree to licence terms).

Impact of licences on software developers

For software developers, the impact of licences is very similar to the impact of copyright, as described above: basically, you should not copy-and-paste third-party code into your own code unless you’ve got clearance from the management (legal department, project steering committee, etc.). In addition, don’t use third-party libraries without such clearance.

It should be noted that even if the library is open-source, clearance from management should still be obtained. Otherwise, it can lead to nasty legal problems.

An example: you’re working for a big company. One day you find a good library which you’re craving to use in your project. You’ve checked that it is an open-source licence so you’ve decided to go ahead without letting anybody know. Two years down the road, an auditor has found this code which appears to be licensed under the GNU General Public License [ GPL ]. Now you’re in serious trouble because of the ‘viral’ nature of the GPL: it requires that all the code compiled together with a single piece of GPL code must itself be licensed under the GPL. Your company now faces a dilemma: either to licence the whole application under the GPL, which is an unlikely choice for the company, or to scrap your code (and probably yourself). If the third-party code is not GPL, but the GNU Lesser General Public License [ LGPL ] it might be more acceptable for your company though clearance is still required. In particular because figuring out who really owns the code might be tricky, and because certain paperwork might be necessary to ensure compliance with the LGPL.

A similar situation can easily arise even within open-source projects: for example, using GPL’d code in Apache products is prohibited [ Apache ], so if you use GPL’d code within an Apache project it will be a waste of time not only for you putting it there but also for somebody else to remove it later. And BTW, despite it seeming counter-intuitive – while LGPL has a chance of being allowed for commercial projects, it is still prohibited for an Apache project.

As you can see all this licensing business is extremely convoluted, so I will summarize the bottom line: don’t rely on your own judgement: don’t use anything from third-parties unless you have very clear permission from management (legal department, project steering committee, etc.). Asking in advance can save you and your company/project lots and lots of time.

References

[ Adams] http://en.wikipedia.org/wiki/Lapine_language

[Apache] http://www.apache.org/legal/resolved.html

[EPO2007] EPO Board of Appeal Case Law Special edition 6 l Official Journal 2007

[GPL] http://www.gnu.org/copyleft/gpl.html

[LGPL] http://www.gnu.org/licenses/lgpl.html

[Loganberry2004] David ‘Loganberry’, Frithaes! - an Introduction to Colloquial Lapine!, http://bitsnbobstones.watershipdown.org/lapine/overview.html