How to protect your software legally

Software can be protected in several ways, through contracts and through formal legal protection.
You put contractual protection in place yourself through agreements with employees and developers. Formal protection is provided by Slovak and EU law. The best approach combines both.

Let us look at the individual steps in setting up legal protection for software.

I. Agreement with developers and employees

Technology companies often forget about it. Do not make the same mistake. When drafting every agreement, pay attention to the following:

1. Sign a proper NDA
   Before you start dealing with a specific quote, project or customer, sign an NDA (non-disclosure agreement). Follow the rule that an NDA should be signed always, with everyone and in advance.
   An agreement like this prevents a whole range of potential problems. It is not rocket science, just a simple document of a few pages.
   Do not forget to agree on contractual penalty clauses that apply on top of damages.
   
2. Know the subject matter
   Define the subject matter in every agreement, in other words, what your cooperation covers. Remember that besides defining it positively (what the cooperation covers), you should also define it negatively (what the cooperation does not cover). You may want your supplier to work on the design, but not on its implementation. Think along those lines.
   
3. Source code
   Are you handing over the source code? When? Will it be updated? What will the recipient be allowed to do with it: only keep it, or continue working with it? How will liability for it be handled? All of these questions need to be answered and covered in your agreement with the developer or employee.
   If the source code is not part of the subject matter, go back to point 2 and see what needs to be done. You are right if you think the subject matter needs to be defined negatively.
   
4. Everything in writing
   Not every agreement has to be in writing by law. However, it saves a lot of time and energy, and not only for the lawyers who would deal with any disputes. Above all, for you.
   
   Besides a written agreement, you can also conclude framework agreements. These are not universal, though. So always ask yourself: what is the purpose of the agreement? A framework agreement pays off in two cases:
   1. recurring performance, where relationships are so complex that agreements with the same content keep repeating. In these situations there is no need to tailor each agreement. One core agreement is put in place and used repeatedly, and you can spend the resources you save on your business;
   2. when you have not yet decided what the agreement should cover. This is a situation where the parties do not yet know whether they want to cover every stage of the software life cycle, or how detailed the arrangements need to be. In that case, a general framework agreement is put in place for all stages, and it is then tailored stage by stage as you go.

5. Preamble
   The preamble is the ideal place for the parties to describe in plain language what they expect from the agreement. You can do this in three steps, guided by three basic questions: What is the current state? What is the desired state? How do we get there?
   
6. Definitions, terms and annexes
   Define what you think the individual terms in the agreement mean, and do it right at the start. That way you will not have to look for definitions in individual provisions; you can simply use the term defined at the beginning of the agreement. All parties will then be on the same page about what each word means. This mainly concerns legal terms such as work, documentation and remuneration.
   Annexes, on the other hand, are usually technical. They cover the definition of the work, its functionality, pre-sale analyses or the acceptance procedure.
   A tip from everyday life: do not forget to attach the annexes to the agreement when signing!
   
7. Relationship with the developer
   Always settle this relationship before you start selling the software. Unfortunately, companies often forget exactly this part. Your company may then be unable to sell the software legally, simply because the relationship with the developer was not properly finalised.
   At this point, also pay attention to the developer's status. The agreement will differ depending on whether they are an employee, a contractor or working under an agreement for work performed outside employment. Also make sure you sign the NDA with them that we described above.
   
8. Authors
   The author will always be a natural person, so never list a legal entity (a company) as the author.
   By law, the author holds moral rights and economic rights. It is the economic rights that matter to you in agreements, because every author's basic right is to use their work and to consent to someone else using it. This means the author must give consent to a specific person: a “licence”.
   Your relationship with the author of the software can be governed by different regimes:
   - Contractual use: your company uses the software under a licence agreement or under an assignment of rights to an employee work,
   - Employment contract, employee work regime: the software is created by your employee under an employment contract. In practice, these are cases where the employee creates the software in performing their job duties. Unlike contractual use, the author's consent is not needed here, because it was given to you by virtue of their employment. For technology companies as employers, this means they automatically hold the rights to the work. You can modify it in any way, label it with your name and distribute it. Conversely, the employee, even though they created the software, may not dispose of the work themselves and is not even legally entitled to additional remuneration for it.
   
   Note that the employee work regime does not apply to people working under agreements for work performed outside employment. For a technology company, this means that if it wants to hire a university student to create software, it will have to use a different form of protection. The employee work regime will not apply.

II. Agreement with the customer

This agreement builds on what you have already defined in your agreements with suppliers.

1. Do not exceed the scope of the developer's economic rights
   If you set up the agreement with the developer correctly, this part will not be a problem. However, you must always make sure that you never sell, license or provide the software to customers and the public to a greater extent than you have from the developer.
   That is why it is important to know how the legal relationships concerning the subject matter are governed throughout the software life cycle, what the subject matter is, whether it includes the accompanying documentation and even its language. Another question is whether you are dealing with off-the-shelf or customised software.
   
2. Licence
   A licence is consent between the IT company and the end customer to use its software. To be valid, it must contain several mandatory elements. Always include in the licence:
   - Who grants consent to use the software to whom,
   - What the consent is granted for,
   - What the consent is not granted for,
   - How the software is to be used,
   - How the software must not be used,
   - Where the software may be used,
   - Who may use the software and for what purpose,
   - How long the software may be used,
   - What your remuneration is,
   - What happens if the licence passes to another user,
   - When the software licence ends,
   - Whether the right to use the licence can be divided (a sublicence),
   - Whether the right to use the licence can be assigned and whether this excludes further use of the licence by the original party,
   - That the author may not further use or license the software (an exclusive licence) or that the author may use the software and license it further (a non-exclusive licence)
   
3. When does the licence start?
   Set the day on which the licence starts. It can start when the software is handed over, when the remuneration is paid or on a specific date.
   
4. What environment is the software in?
   Define how the software will be delivered. It can be in the cloud or on a physical medium.
   
5. Cooperation
   Define the customer's response times so that you can develop, deploy and service the software. If cooperation is not defined, the software probably cannot be provided to the extent the parties expect.
   
6. Trial period
   Set a period after which the customer will no longer be trialling the software but will be its regular owner.
   
7. What defects and incidents are, and the resulting contractual penalties
   Things are not always ideal. That is why it is important to set out solutions for situations when things do not go to plan. Include provisions in the agreement on what to do if things do not go to plan, what the response times are and how servicing works.
   Always remember that servicing can also create a new work, new software, so cover licences for these newly created elements as well.
   Also focus on the NDA we mentioned at the start of this blog. It can be signed with the customer too, and this is even recommended. A similar regime applies as with an NDA with employees.
   Finally, do not forget sanctions for breaching the agreed obligations.
   
8. Procedure when the agreement ends
   The subject matter of the agreement is the software. We have already made that clear. But what happens if the agreement ends or terminates? Will the customer be entitled to keep using the software? Will they also receive the source code? What about the data in the software? And what will happen to the licence?
   Ask yourself these questions for a simple reason: the life of the software does not end with the agreement. The customer must work out with you what happens after the cooperation ends. The agreement is exactly the right place to do that.

III. Formal legal protection of software

In Slovakia, this protection is minimal. There is really only one instrument: a trade mark. However, it only protects the software's name and branding, that is, its logo and name (what is visible on the outside). It never protects the inside of the software, its features and how it works (what the ordinary eye cannot see).

If you need advice on an IT agreement with a customer or developer, or on a trade mark, write to us at eva.schin.webinar@mathisonlegal.sk.

We have helped 200+ IT companies and startups, and we will be happy to advise you too.