Read this before you sign that legal agreement

A recent post on e27 highlighted a hackathon known as Hackit that required winning participants (who were only informed after they have won) to give up their IP rights for the works that they have created in the course of the hackathon in exchange for the prize money.

An excerpt of the agreement posted by e27 is as follows:

“I acknowledge that exclusively license the subject matter referred to as a AMTD HackIT App or FOX TWO HackIT App (all of the above collectively referred to as “Intellectual Property” for short) with fees free and royalty free to AMTD. In particular, I acknowledge that I do not have, have never had, and shall not claim to have, any royalties or other equitable or legal rights in any AMTD HackIT App Patent Application(s) worldwide and any subsequent patent applications and patents related to these patent applications.”

Intellectual property law is extremely complex and byzantine, given that it comprises many different subject matter (copyright, trade marks, patents, etc) all of which are conceptually different and governed by different rules, which can also vary substantially in different countries. This incident prompted me to share some thoughts with my friends in the startup community which I hope they will find useful.

1. Read before “signing”

While this sounds obvious, I cannot emphasize enough that you must always read the terms and conditions of such events before you “sign”. If you detect terms which make you feel uneasy or raises alarm bells, you would be better off walking away or seeking legal advice before you agree.

Note that I use the word “sign” in quotes because your “signature” need not be on paper. Electronic transactions can be considered just as valid and binding as a paper document, and your tick in a box with a click on “I Agree” could very well be enough to bind you to that agreement.

2. Poorly written code rings alarm bells

If you can tell the difference between elegant code and shoddy cut-and-paste jobs, then you should also easily be able to tell when legal “code” sounds dodgy. Without going into details, a careful reading of the clause excerpted above will tell you that the first sentence is logically inconsistent with the second sentence. If you never had any legal rights to the code that you write, how can you exclusively license it to anyone?

Such poor drafting should ring alarm bells and signal that the agreement should not be signed without some extra thought. Or you should simply walk away.

3. Check with your peers

Whether you are an organizer or participant in an event where there is collaborative creation of intellectual property, you should definitely reach out to your peers in the startup community to find out what the common practices are or, in the case of specific industries, what the industry best practices are before drafting the terms and conditions (in the case of the organizer) or before signing the terms (in the case of the participant).

This may involve, where applicable, seeking answers from industry associations or referring to industry codes of practice, or just asking those who have many years of experience in that specific area. Most definitely, I recommend consulting lawyers who have experience in this industry to avoid pitfalls such as poor drafting and/or acting in a way that is negatively perceived by other members of the community.

4. Please seek advice

Most developers would simply choose to walk away if they do not agree with the terms of the agreement. This option works if the time and effort spent and/or the amount of money involved is minor. However if a developer has spent a substantial amount of time and effort in building their product, and/or the money that is due to them is significant, then walking away might be much more difficult. In such instances, the developer should seriously consider seeking legal advice.

I understand that bootstrapped startups are very unlikely to have funds allocated for legal advice. In very early stages prior to the incorporation of a company, that may still be fine. The moment that the founders incorporate a company as a vehicle to grow their business, having good legal advice right from the beginning will definitely save all the parties from unnecessary pain at a later stage.

It is always easier to fix bugs before writing new code.

About the author

Xu Si Han is a lawyer admitted to practice in the Supreme Court of Victoria, Australia. He currently works in a local law firm in Singapore assisting in outreach to the tech community. While he does not possess any programming-fu beyond rudimentary Python, he has always maintained lawyers are like software engineers: lawyers draft agreements (code) which are interpreted and enforced by the courts (compiler/interpreter).

Comments