“There are people out there who don’t see value in intellectual property, and so they’re always going to have a problem if there are lawsuits involving intellectual property.”
Paul Allen
A large number of different agreements are being concluded within the IT sector, such as software licensing agreements, software development agreements, professional service agreements, SaaS/PaaS/IaaS agreements, etc. Although quite different, the common point of all these agreements is intellectual property, as one of the most important and indispensable issues when we talk about software. This is not surprising, since the software is a work of authorship, that is, the copyright protection of the software is generally accepted both in Serbia and in the world. However, for many years, the question of whether software can be patented creates a variety of controversies around the world, as we wrote in more detail in our blog about the legal protection of software.
This text focuses on software development agreements concluded between a developer (natural person or entrepreneur) and an IT company. Among other specifics, this type of agreement is characterized by a special emphasis on the issue of the moral rights of an author. Specifically, moral rights (the right to be recognized as the author of the work, to have the name indicated on each copy of the work, to publish the work, to oppose changes to the work by unauthorized persons, etc.) can have only a natural person as an author of the work (e.g., software), not legal entities. Legal entities, on the other hand, can have or acquire only economic rights of copyrights (the right to reproduce a work, to put copies of a work on the market, to broadcast, to lease, etc.).
Not just that; moral rights are additionally specific because they do not always share the fate of economic rights. For example, according to the law of the Republic of Serbia, the author cannot transfer his moral rights to other persons by an agreement, while some or all economic rights regarding his work of authorship can be assigned to another person. However, this is not the case in all countries, and that is an additional reason why caution is necessary, especially when concluding an agreement with foreign persons, and the applicable law is not the law of the Republic of Serbia. Let’s take the USA as an example: in the US law, there is a well-known legal institute “work made for hire”, according to which the entire transfer (of moral and property rights) is possible, provided that all the legal conditions are met. However, domestic law does not recognize this type of transfer, which may lead to difficulties in the practical execution of the US-governed agreements in Serbia.
Precisely due to these and other specifics of moral rights, as well as the importance of the first transfer of rights in the chain, in this text, we do not deal with software development agreements between two companies. Namely, the first transfer, from a natural person – the author of the software to a legal entity, is the most frequent and most important in practice, because if it is not conducted properly, and in the event the company does not secure the broadest range of rights for themself, the company may suffer serious, million-dollar lawsuits from clients from abroad, to whom the company previously incorrectly transferred the rights to which the company itself was not entitled to.
Think of it like a virus that could spread to any future contracts with clients if you haven’t addressed it properly with the software developer beforehand.
1. Who is the Owner of the Intellectual Property?
It is in the interest of an IT company to own the entire intellectual property right on a software (which is transferable) so that it can continue to uninterruptedly exploit the software economically, but also to modify it, upgrade, etc. For that reason, the IT company should pay special attention to how it will regulate the issue of who owns the intellectual property created by a developer. This is especially supported by the fact that companies are often not even aware of how much just one word can change the whole meaning of the transfer of rights. Hence, a fatal error may occur in not making a clear distinction between the transfer (sale) of software and its licensing. Also, it is not uncommon to incorrectly describe the subject of the transfer, i.e., the software, and thus, to misdefine the intellectual property, as well as to erroneously determine the moment of transfer of ownership on the software, etc.
These are just a handful of the critical issues, but certainly not the sole ones, that are frequently mishandled in agreements, potentially leading to severe consequences.
For example, if you as a company have not correctly transferred all transferable economic rights from the developer, and you deliver the created product to your foreign client further in the chain, who then wants to file a patent application, precisely due to that erroneous transfer, your client may be subject to multi-million lawsuits, which may easily overturn on you in the end. And all that is only because the transfer of rights, most often unintentionally, has not been properly conducted.
Another reason why the first transfer of copyright might be of great significance for you is the fact that, if you wish to deposit your copyright before the Intellectual Property Office, you need to have an adequate legal ground for obtaining the copyright on that work of authorship (among other things). Taking into account the growing interest for the tax benefits introduced in the domestic tax system in the recent few years, for instance, companies which decide to use IP Box benefit must not forget to examine on time whether the copyright on the work of authorship that should be deposited has actually been adequately transferred to them.
In the event that the applicable law is the law of the Republic of Serbia, a provision of the Law on Copyright and Related Rights of the Republic of Serbia should be kept in mind, which prescribes that if a computer program (software) was developed based on the software development agreement, the party who ordered such development – client (in our cases, an IT company) shall acquire all rights to the exploitation of that computer program unless otherwise provided by the agreement. Therefore, the client who has “ordered” the software obtains all the transferable rights by default, but the law allows the software development agreements to provide a different solution. For that reason, it is additionally important to precisely regulate this issue in the agreement and avoid any doubts.
Somewhat different rules apply to a computer program which is a work of authorship created under employment, which we discussed in more detail in the blog regarding this topic.
2. Previously Developed Technologies
In practice, it is not uncommon for a developer to incorporate previously written pieces of code or even pieces of third-party code into software that the developer has written for the IT company with which he is in a contractual relationship at the moment. If such intellectual property is not properly regulated (first by identification), the third parties’ rights may be violated, as well as the liability for high damages due to such violation.
In practice, we call them background technologies – they include all the technologies developed by your developer before entering into an agreement with you, and which are being used while providing the services to you pursuant to that agreement. For example, if the developer is using its self-developed application to provide you with a service, one obvious question may arise: who owns the results of such work?
To preempt this query and the potentially unfavorable response, ensure you contemplate this well in advance and ensure it’s addressed in the agreement.
3. Open-Source Software
The issue is getting more complicated if the developer incorporates open-source software (hereinafter: OSS) into a product developed for that IT company. The use of OSS must be precisely regulated in both the agreement and the internal rulebooks of the IT company. Otherwise, the IT company risks that a certain OSS license may prevent the company in the future from charging a fee to third parties for using the developed software, or, if the software is delivered to an end customer, risks being the subject of a lawsuit for intellectual property infringement.
Although it might seem as a triviality, if your company develops software for further commercialization, it is crucial for your agreement to acknowledge whether your contractor can use open source code while developing software for you.
4. Violation of Third-Party Rights
A common problem that can occur in practice is the question of what happens, and who is responsible, in case the developed software violates the rights of third parties. This particular issue needs to be dealt with preventively in the software development agreement. Specifically, it is necessary to clearly distinguish to what extent is the developer responsible for the said violation, and consequently obliged to compensate the company, in which cases and to what extent can his liability be limited, and above all, whether the said liability can be limited.
What happens if your contractor has been providing services by using the software in the ownership of the company in which he or she has previously been employed? Can the previous employer demand any actions from you? Which kind? What can you do in that case? A variety of questions can cause you a major headache if the agreement itself does not provide answers to them.
On top of that, it should be noted that the legal regulations in most countries do not provide for liability waiver in cases when a person intentionally commits a violation, or for example, if a person was aware that their actions were a violation of others’ rights. The reason behind that is not to protect reckless and dishonest persons.
Finally, there are situations when the software created by the developer is combined with the software of the IT company to which it is delivered, or when, besides the developer, third parties participate in the creation of the software (through services or materials). Practically, this case involves several copyright holders, so such situations require a proper redistribution of responsibilities among the parties.
The violation of third-party rights leads to serious disputes and extremely high damage compensations. Taking into consideration how much value a software may have nowadays, and how much damage can occur in the event of a violation of rights, such compensations and penalties are often in the millions. On top of all this, the situations in which software development agreements are international are much more common, and certainly, the nature of the software is such that it is easy to use and distribute around the world. That is exactly what most commonly leads to international disputes, which involve far higher costs compared to domestic proceedings.
5. License
Even when it is not the primary focus of the agreement (it is not a software licensing agreement), a license for different parts of the delivery may still appear in the software development agreements. For that reason, we are witnessing that the most frequent mistakes related to the license are the incorrect definition of the subject of the license, and even more often inadequate determination of the scope of the license.
Aspects such as whether the software will be fully developed in the future or if certain parts already exist, and whether the so-called accompanying products and the like will be created as well, directly affect how the definition will be made. Therefore, it is important to take care that the definition is not too narrow and thus restrictive, but not too broad and thus potentially unenforceable.
Finally, the license should reflect the redistribution of rights (and obligations) between the licensor and the licensee; hence, it is important to precisely define what is allowed and what is forbidden, and which rights do (not) belong to whom. Some of the typical rights granted by a license are the right to make a copy of the software, the right to modify the software, the right to distribute, and so on. It is also very important to precisely regulate whether the license is exclusive or not, whether there are time-period or territorial restrictions, etc.
6. Residual Memory
A particularly sensitive matter when it comes to signing NDA with contractors may also arise with the software development agreement, is, whether the developer has the right to freely use ideas, techniques, and know-how related to the delivered software, which the developer (or members of his team) kept in his residual memory.
This issue is, in practice, governed by a particular clause that may, depending on the wording, easily lead to significant consequences if they happen to be applied.
Although these clauses are not found too often in software development agreements, when present, they cause negotiation efforts, as a rule. There are several reasons for that, and one of the key ones is the intention of the IT company to be the sole owner of everything created during the contractual relationship, especially if the software is a highly competitive product. However, can someone’s memory actually be limited? That question calls for a discussion. Therefore, this clause requires caution when regulating.
7. Further Transfer of Intellectual Property Rights to Third Parties
It has been previously said that the transfer of intellectual property rights from the developer to the IT company that contracted the developer for the software, should be seen as the first transfer of rights in a chain.
Namely, most often, the IT company which is the acquirer of the rights in the first transfer (and the developer is the first transferor) will further transfer the rights on the software (either through software licensing or through a full transfer of ownership rights on the software). For that reason, if the first transfer of rights from the developer to the IT company, i.e., the party commissioning the software (the first link in the chain) is not done correctly, the problem will exist in all subsequent transfers, or it may even disable further transfer.
What happens in practice?
For example, when negotiating the transfer of intellectual property rights from a developer to a large parent IT company, that is a founder of a number of smaller companies, it is essential to correctly define to whom the rights will be transferred. To the parent company or to all the related companies? Correctly defining this situation means the adequate resolution of the ownership relations not only regarding the parent company but also, if necessary, in relation to the subsidiaries of the company or generally related persons. The definition of the affiliated parties is in this case of great importance for both parties involved, in order to avoid any party to obtain the rights that have not been dedicated to them.
This should be especially considered if the parent IT company plans to sell (any) daughter company in the future. The fact that a daughter company holds a license or other right to the software may significantly increase the value of that company when sold to a third party. It is expected that the buyer of the daughter company will perform due diligence during the purchase, and if these issues are not (properly) regulated in the software development agreement, it may happen that it will turn off the potential buyer, i.e., the investor. This is especially important if related parties disagree, and the common interest in using the software remains.
A common example from practice is to request from the seller in a status change (in our example it would be the parent company that sells the daughter company) to guarantee and confirm that he is the sole owner and holder of all intellectual property rights and that its intellectual property is not subject to any restrictions which would prevent their transfer to third parties. If that guarantee was not correct due to improper transfer, the parent company could be exposed to serious damages for guaranteeing something that is not true.
8. Trade Secrets
Although at first glance it does not appear that they belong here, trade secrets are another important aspect of intellectual property that makes an integral part of any software development agreement. Any disclosure of a company’s trade secret carries the risk of the potential damage that could be made if the trade secret gets into the wrong hands. On the other hand, sharing business confidential information with the other party is inevitable in any business relationship; thus, it is necessary to find the perfect balance – to discover as much as it is necessary for successful cooperation, but to protect yourself from eventual risks.
This is where the confidentiality clause in the software development agreement becomes significant, clearly delineating confidential information, the contracting parties’ obligations for safeguarding it, and the potential penalties for breaching these obligations. Although it is undoubtful that a separate confidentiality agreement is the best way to regulate this matter, if the parties do not agree on signing a separate NDA for some reason, it is recommended that the software development agreement contains at least a comprehensive confidentiality clause that will save the owner of confidential information from later difficulties in case of a dispute regarding the disclosure.
Practice shows that, unfortunately, insufficient attention to the matter of intellectual property happens to be a very present and most often fatal mistake when drawing up software development agreements. Intellectual property issues might seem less important at the beginning of business cooperation, but one step in the wrong direction may lead to the dead-end from which it is very difficult to return to the right path. Therefore, it is crucial to approach each agreement with a great deal of caution, to avoid potentially catastrophic consequences.
