10 Legal Principles for IT

These principles are deliberately broad, and will be applied very differently depending upon your business structure and strategy.

1. Prevent Issues Before You Have To Fix Them

Disputes are expensive and only make lawyers money. While you cannot always prevent a dispute, clearly specifying the rights and obligations of each party goes a long way towards limiting the areas of dispute and promoting an early settlement.

2. Document And Agree On Scope

The majority of IT disputes arise from poorly defined or undocumented scope. If your client agrees to pay $Y for X (eg a Chair), it is vital that both parties actually agree on what X means. Disputes arise when the client expects a lounge, and is presented a rocking chair (translate to code how you will).

Signatures are useful to demonstrate agreement, and are legally necessary for some documents, but are of limited use if the document doesn’t clearly demonstrate agreement between the parties.

3. Document And Agree On Changes To Scope

The next greatest cause of IT disputes is poor change management of scope. Yes, this is the same as (2), and the same principles apply.

Your scope document should be living, changing and flexible. Too often, IT companies have a great formal agreement, then a string of undocumented discussions and maybe a few emails explaining why the contract is not being followed. Formalise your scope changes, and scope change process.

4. Clearly Define Who Owns Intellectual Property

The value in most IT and Tech companies is their Intellectual Property (IP), which includes copyright (code / design), trade marks (branding), and patents (inventions).

IP falls into four broad categories:

  1. What I bring to the table, now and in future;
  2. What you bring to the table, now and in future;
  3. What we develop together; and
  4. IP owned externally by a third party.

It is vital to define what is included in each category (code module X; client list Y etc), and who owns it. For contractors, don’t assign ownership until you get paid.

5. Check FOSS Module And Code Snippet Licences Before Including

Many Free / Open Source Software (FOSS) modules have licences that restrict commercial use, or require you to release your derivative source code. Check the licence first.

6. Structuring – Separate IP Ownership From Risk

In principle, the entity that bears most of the risk (the trading entity) should license rather than own the IP.

There are many legal structures to do this – including incorporation, holding companies or trusts. The preferable structure usually depends on tax implications.

7. The One Who Drafts The Contract Controls The Negotiation

Put this another way: Would you prefer to draft your own code, or modify someone else’s. While it looks like less work/cost to start with someone else’s contract, you fight an uphill battle for each change.

Entering negotiations with your own standard set of terms instantly puts an otherwise small player in a stronger position. It also adds a level of professionalism to your pitch. We recognise this is not always possible, especially when contracting with government departments under the GITC, but it is advised in most circumstances.

8. Maintain Supplier SLAs ≥ Customer SLAs

If your supplier offers 90% uptime, and you promise 99% to your customers, you bear the risk. Make sure you price and insure accordingly, or rethink what you will promise.

Also, check the penalties in each SLA – if your supplier doesn’t deliver, does their penalty cover your loss reimbursing your customers?

9. Protect Your Brand With Trade Marks

Trade marks are relatively cheap, and add value to your business. Selling or licensing a trade mark is much easier to quantify than attempting to sell or license goodwill.

Trade marks also assist in domain name disputes, and help protect your online presence from typo-squatters.

10. Give Your Lawyer All The Details, And Early

A solution to the wrong problem won’t help you. Unless your lawyer has all the relevant details, we can’t accurately advise you.

Contracts are like code – complete with dependencies and variables. Give your lawyer the whole contract, including associated documents.

Giving your lawyer a quick check over any proposed agreement is good risk mitigation strategy. Usually everything is fine. When it isn’t, it can be expensive and inconvenient to attempt to fix later.

The above principles have been adapted from a talk by Matt Phipps at Barcamp Gold Coast V.