Software: copyright or patentable invention? Software is considered to be a ‘work of authorship’ and is therefore protected under copyright. This means that it is prohibited to copy, publish or otherwise reproduce software unless there is permission of the owner. The same applies to creating derivative works.
Occasionally, the creation of a software module could be considered an invention. If the invention meets all the requirements for patent protection, the owner is entitled to apply for patent registration. This principle applies to all inventions, and thus also software.
What is Software #
Source code vs. object code. Software is a somewhat imprecise word for ‘source code’ or ‘object code’. Typically, software is distributed in the form of ‘object code’, also called ‘binary code’: machine-readable algorithmic instructions in the form of bits and bytes. For example, object code could look like this:
€ù?w„ÉtX¶ÉD;Ærê¸ X €Ë €ûdt€útujŠP €Ê €úcu
Source code is a set of computer instructions written by software programmers in a particular programming language, with statements such as:
PrintDocument (file name, number of copies, which pages, colour, page resizing)
if X=50, then do Y, else go to Zx and do Zy
For your computer to understand these algorithmic instructions, the source code must first be compiled (i.e. converted) into object code. Whilst a computer cannot execute mere statements such as “if…, then…, else…”, human beings cannot understand object code.
Open source. Whilst software is subject to copyright and the source code is a trade secret, the software programmer could make it available to others under a so-called ‘open source licence’. This means that everyone would have access to and be entitled to use, change and redistribute the software. The rationale is that other developers are more willing to improve the open source software and that improvements are realised much quicker than the owner of proprietary software would be able to achieve. The initial software developer will benefit from being the most informed and best suited party to realise the wishes from the software users (and such development work is often paid).
Open source software is typically distributed under the terms and conditions of a defined standard. Some widely used standards include: (a) the GNU General Public License (GPL) or Lesser GPL (LGPL), (b) the Artistic License (e.g. Perl), (c) the Mozilla Public License, (d) the Common Public License, (e) the Sun Community Source License (SCSL), (f) the Sun Industry Standards Source License (SISSL), (g) the Sun Industry Standards License (SISL), and (h) the Open Software License.
These open source licence terms require, as a condition for use, modification or distribution of the software or other software incorporated into, derived from or distributed with such software (a Work): (i) the making available of source code or design information regarding the Work; (ii) the grant of permission for creating derivative works of the Work; or (iii) the grant of a royalty-free licence to any party under intellectual property rights regarding the Work.
Software licence models, SaaS #
There are two common licence models: a perpetual licence and ‘software as a service’ (SaaS), with the related question where the application (and inserted data) are hosted.
Perpetual licences. A perpetual licence grants the user, subject to the licence restrictions, a right to use the software permanently without paying additional fees (with the exception of software upgrades). In addition to the perpetual licence, the licensee might optionally enter into a maintenance and support agreement for receiving bug fixes, incremental software improvements and minor new functionalities.
When software is purchased in a box or as a package to be installed on a computer, this is typically a perpetual licence: after payment of the licence fee, the user may use it without restrictions in time. Any ‘updates’ or ‘patches’ are delivered under a maintenance and support agreement, which may be fully paid in advance in order to prevent the high costs associated with the maintenance of countless versions being developed (see section (iv) below).
Software as a service (SaaS). The second and increasingly popular model is SaaS (‘software as a service’): the licensee pays a subscription fee and hosting of the software is provided by the licensor. The software functionalities are provided by way of ‘service’ through the internet rather than by way of a user licence. Likewise, the SaaS agreement takes the form of a service agreement instead of a licence (granting a right), and the terminology changes from licensor and licensee into service provider and customer.
Hosting. Increasingly, software applications become web-based. This means that the software operates somewhere on a server or website and the functionalities are used through an internet browser. A major advantage of web-based accessibility is that it considerably reduces error-sensitivity and installation issues. This means that web-based software is installed on the servers of the licensee’s organisation or on the servers of the licensor, and accessed through the intranet of the licensee or through the internet via a secure connection.
Hosting by the licensor (or service provider) triggers questions related to data security (possibility to access and protection of the software against third parties seeking access to the data managed through the software) and personal data protection (access and use of personal data, including the names of companies and individuals). The right to store and access depends from country to country, and the law governing such data is determined by the physical location where such data are collected and stored in a data centre. This is why it is crucial for many organisations to control where their data are stored (or where the data centre is located).
Subscription licences. If the licensee cannot finance a perpetual licence or wishes to remain free to step over to alternative solutions, a subscription licence could be attractive: the licensee pays a periodical fee and receives all bug fixes and support in exchange for the service fee. In many cases, the breakeven compared to a perpetual licence is at five years, the term for amortisation of software (and after which the perpetual licence would have been more beneficial). In a pure subscription scenario, the software would be ‘hosted’ on the servers of the licensee itself.
Software licences #
In order to be authorised to use software (in object code form), a user must obtain a licence. In software licences, there are several points of attention:
- The scope of the licence must permit the licensee to use the software in accordance with its requirements (and match its needs and expected use).
- The licence can be limited to named users, a number of concurrently active users, an enterprise, a type or method of use (e.g. light users or for a specific subtask within a greater package of functionalities), the frequency of use, an installation on one device, or to any other licence criteria.
- If parts of the software depend on third-party software, such third-party software must be licensed as well (or at least, an adequate licence can be obtained on reasonable conditions). For example, certain business applications may not only require the installation of a certain server operating system but also the (licensed) availability of applications for data processing or spreadsheets.
- The software is likely to be accompanied by manuals, documentation and other materials explaining the functionalities. At least formally, a copyright licence to use the manuals, documentation and materials should be granted as well.
Common software licence restrictions. To modify the software, software programmers must have access to the source code. To obtain source code, the object code could be ‘decompiled’ or ‘reverse-engineered’. If the software has a complex structure, reverse engineering is often impossible or at least rather burdensome and does not result in the original source code. Despite its complications or impossibilities, software licence agreements typically prohibit copying and reverse engineering. An example of a ‘licence restriction’ is:
Except as expressly permitted in Article [2], Licensee shall not, and shall not permit any third party to:
(a) copy, publish or disseminate the Licensed Software;
(b) modify, translate or otherwise create Derivative Works of any part of the Licensed Software;
(c) create its own version of the Licensed Software;
(d) assign, sub-licence, lease, rent, loan, transfer, disclose or otherwise make available the Licensed Software; or
(e) reverse assemble, decompile, disassemble or otherwise attempt to circumvent any protection of the Licensed Software.
Implementation and consultation. Often, software requires more than just a licence for use. It is important to identify the additional services necessary to launch the software or to make the software effectively operational. If the software is not very user-friendly, making it work might require impactful change-management projects (changing an organisation’s traditional way of working and adopting the software). The services accompanying software are often called ‘consultancy’ and these may include software programming work. Embedding the software in the existing software environment of the licensee is commonly referred to as ‘integration’ or ‘implementation’. Finally, a software application might require monitoring by a system administrator, who will most likely need specific training.
The impact of consultation, implementation and training services is often underestimated. At the same time, whilst the software industry matures, the impact of introducing new software solutions should not be overestimated either. These services are often a hidden cost element, the effect of which can remain unidentified in a licence agreement.
Maintenance & support (M&S) #
Typically, software requires continuous development and:
- contains a fault or flaw, or causes a failure (or ‘bug’ in) or otherwise ill-functioning components;
- may be susceptible to security issues;
- can be improved, if only to a limited extent;
- probably needs to be tailored to the particular technical and use requirements of the licensee’s organisation;
- is dependent on compatibility with hardware;
- is dependent on the performance of other software (e.g. supported office applications are often upgraded every three or four years and internet browser versions may be incompatible with previous versions); and
- is typically provided with a warranty period of no more than 90 days.
After the initial warranty period, there is almost invariably a need to continue receiving bug-fixes, software improvements, improved compatibility with internet browsers and solutions for changes in the environment in which the software operates. For such purpose, the licensee should enter into a maintenance and support (M&S) agreement with the software provider. The M&S agreement defines which software updates a licensee will receive, which service level a licensee can expect and specify the period of time in which bugs must be fixed.
‘Updates’ and ‘upgrades’. Bug-fixes, security solutions, minor software improvements and other changes delivered during the warranty period or in the framework of a maintenance and support agreement are provided in the form of a software ‘update’. Usually, they are numbered (e.g. versions 3.2.1, 3.2.2 and 3.2.3; or versions 2.0, 2.1 and 2.2).
Many software licences distinguish updates from ‘upgrades’: an upgrade would contain significant additional functionalities or features compared to the previous version (and are often numbered by whole number increments: 1.0, 2.0 etc.). These upgrades of software normally justify a renewed licence (and licence fee). An update, on the other hand, would be covered by the maintenance and support.
Error and support levels. Depending on the seriousness or ‘severity’ of any failure of the software, the parties would agree on an error-support level: the licensor’s or service provider’s obligation to fix errors that occur during the licensee’s or customer’s use of the software. Common severity error classifications are:
- Critical errors cause the software or even the computer to stop working. These errors require both immediate action and an immediate solution or implementation of a fall-back scenario;
- Major errors have a significant impact on the software functionalities but do not block its key functions. These require immediate action and a solution must be available as soon as reasonably possible;
- Normal errors do not disturb the normal operation of the software but require appropriate action;
- Minor errors do not disturb the normal operation of the software and a solution should become available when the software provider’s course of updating allows.
The severity of a software error determines the priority a licensor or service provider must give to reproduce, describe and confirm such error (response time), as well as the time it is permitted to fix it. Depending on the importance of the software for the licensee or customer, these severity levels, priorities and required efforts are agreed in a service level agreement (SLA).
Note: this chapter is also included in the e-book Cross-border contracting – How to draft and negotiate international commercial contracts, written by Weagree-founder Willem Wiggers and published by the ITC (the joint agency of the U.N. and WTO) and downloadable free of charge.
