You own and operate a young but fast growing technology company. You make and sell software, hardware, semi-conductor chips or Internet-based services. You have a solid, and ever expanding, base of loyal customers. You have identified a problem they have and through clever technology — implemented through your even smarter staff — you are able to solve their problems. To show their appreciation, your customers pay your princely sums for your products and services.

Eventually (in the life of a Canadian tech company, that usually means in the next three to five years), you will likely take your company public (by selling shares of it to public investors on a stock exchange) or, even more likely, you will sell your company to a bigger technology company (that will integrate your products and services into their broader suite of customer solutions).

In either case, upon such a so-called "liquidity event", someone is proposing to pay you a lot of money for your tech business. But they will not hand over the money until you have assured them, through a series of legal promises called representations and warranties, that all is well with the company and its key assets (namely, its intellectual property, its people and its balance sheet). If these promises prove to be untrue, then after the liquidity event you will find yourself giving back to them a good chunk of the money they paid to you when they bought your company.

Given this process, it is worth understanding now, well before you are contemplating a sale of the company, what problems typically come to light on a sale of a tech company that can diminish its value. Remember when our parents taught us to learn from our own mistakes. While that is an effective pedagogical method, it is quite painful; it is so much better to learn from the mistakes of others. Therefore, what follows (in this and the next couple of columns) are 10 common mistakes of young tech companies that can diminish their value in the eyes of a buyer. Thus, you would do well to avoid these missteps. And the good news is, with some attention to the management of these risks, they can indeed by stickhandled successfully, so that you and your fellow shareholders can maximize the economic return on your hard work when it comes time to selling your company or taking it public.

Owning your Intellectual Property

A buyer prepared to give you millions of dollars for your intellectual property (IP), be that software code, trade secrets, patents and the like, will want absolute comfort that your company actually owns all the IP you say it does. And sadly, many tech companies make silly mistakes early on in their lives with the result that they in fact end up not owning all their IP.

Consultants and independent contractors (essentially, any type of creative/development staff who are not employees) constitute a major risk because legally they can end up owning the IP they worked on for you (and you merely are given a license to use it), unless they have expressly signed over to your company ownership of it in a written document. I cannot tell you how sad — and frustrating — it is, to be sitting in one of our boardrooms with all the parties’ papers laid out ready to sell a tech company, and we are waiting for the owner to finish pleading with a key contractor to have him confirm the company’s ownership of a critical item of IP (which he developed for the company’s flagship software product), because the purchaser will not close the deal until this happens. What makes it a difficult moment, of course, is that the contractor — at the eleventh hour — decides he is only willing to sign the transfer document if he receives some percentage of the sale price of the company.

The way to avoid this invidious scene, is to make sure you have the consultant/contractor sign a piece of paper at the beginning of their engagement that clearly gives you all the IP rights in whatever they work on for you (they should also waive all moral rights in copyright works). It’s also a good idea to get this paper signed by all your regular employees as well, but it’s not fatal if you do not have this paper signed by your Canadian employees, because Canadian copyright law gives the employer the ownership of the materials they created in the course of their employment (but even employees must agree explicitly to waive moral rights). Nevertheless, it’s a good practice to have everyone who touches your IP crown jewels to sign an agreement that confirms your ownership of their work product and that waives moral rights.

Offshore Nuances

Additional considerations arise if you have IP developers (whether employees or contractors) resident outside of Canada. You might have, for example, a software development group in Romania, or India, or you might contract with a third party supplier in one of these countries. Canadian tech companies are tapping into such foreign talent pools with increasing frequency, typically because of a shortage of suitable skills in Canada. Incidentally, non-tech companies with large information technology (IT) needs are doing the same thing. Senior management of many of corporate Canada’s largest players are tapping into IT resources offshore to ensure a steady supply of IT skill sets. Again, to the extent software applications development and maintenance services are being so performed in faraway places, the Canadian company wants to ensure it owns all the resulting software code and other materials.

As with domestic staff, you’ll want to have the foreign developers sign tight proprietary rights agreements to ensure you own all IP in their work product. But here’s the additional risk: local law wherever they might be based may well have additional rules that you need to comply with in order to end up owning the relevant IP. For example, in India there is a specific rule in that country’s copyright act that, in certain circumstances, actually allows the ownership of the copyright in the created work (say, your company’s software) to revert to the individual developer, unless this rule is expressly overridden in the written contract with the developer. Thus, your standard form IP transfer clause needs to be importantly modified for use in India.

In today’s intensely global talent market, it’s easy to forget about such legal nuances. The result can be a material loss of IP ownership as there is much IP development taking place outside of Canada for Canadian tech companies and IT departments. Don’t let this mistake erode the value of your IP, especially when the solution is as simple as a short piece of paper signed by the relevant people at the appropriate time.

The Perils of Open Source Software

Another way to jeopardize the proprietary nature of the software your company develops is to use open source software (OSS) in a careless or cavalier way. There is certainly a role for OSS in your company, including in the development environment for your home-grown software. There is lots of really useful and inexpensive OSS out there (especially on the Internet), and your programmers will likely be very keen to use a bunch of it (continuing the long-standing practice and behaviour when they were in university or college, where they would regularly embed chunks of OSS into their projects, and sensibly so given that they are efficient and cheap software building blocks).

OSS is perfect for use by students in school projects because typically the licenses for OSS provide that it can be used for free so long as the source code resulting from it is disclosed to the public and the developer does not charge any fees for the use of the resulting software. Now, while this is a perfectly sensible licensing model for the academic world, it can wreak havoc on the proprietary nature of your own IP when applied to your software products. In essence, it is very easy to transform your own proprietary software (that you wish to charge your customers good money for), into OSS that you cannot exploit on a revenue producing basis.

The result can be the following real life situation. A Canadian software company is being sold. The American purchaser (assisted by a phalanx of tech law savvy M&A lawyers) performs an audit on the selling company’s software code to check for OSS. In fact, there exists an audit product for exactly this purpose — the audit program scans the subject software to detect all instances of OSS embedded within it. The audit uncovered more than 100 instances of OSS, and put in doubt the seller’s assertion that its software product was truly proprietary.

This deal ultimately closed, but at a lower valuation. The selling shareholders were particularly displeased because they had no idea the company’s software engineers were making such extensive use of OSS. This ignorance proved to be very expensive.

The result could have been avoided easily with some pro-active oversight and management of the software development process. You have to educate your staff about the risks of using OSS, and you have to teach them how to use it in a way that does not make your own code OSS. This can be done fairly easily, assuming it is done early in the design of the product. It is a much more difficult task to retrofit after the fact, after the OSS is carelessly misused.

As well, management should double check compliance with these safe OSS programming practices, by running the OSS audit software against early alpha and beta versions of the product. This way, if any problems are detected, they can be dealt with easily and cheaply, thus helping to preserve the IP value of your company.