If your startup or video game studio’s business involves IP licensing (it likely does), it’s important to understand common IP license terms.  Proceeding with an IP license without fully understanding key license terms can have a disastrous impact on your company’s future.

Let’s start with the obvious:

A.  Licensor.  The person/company granting the license.  If you own the IP and are licensing it to another, you are the licensor.

B.  Licensee.  The person purchasing the license.

Now onto an overview of (some) important terms:

1.  Perpetual.  This is the most important term in any license.  A perpetual license is one that continues in perpetuity and will only end if the licensee breaches the license terms (rare).  If you see the word perpetual, assume that the license lasts “forever”.  This works in some cases but if you actually intended to license the IP for a fixed term, perpetual is the wrong word to use.
2. Term.  If the license is not perpetual it has a fixed term (typically a number of years), which you must specify.  Once the term ends, the license ends .
3. Exclusive vs Non-Exclusive.  An exclusive license is one that only the licensee may use.  For example, if you exclusively license your video game to a publisher, you cannot publish it yourself.  Conversely, non-exclusive licenses permit additional licenses.  You can limit exclusive licenses by, for example, imposing platform or geographic restrictions:  exclusive license for distribution only on the Apple iOS store in Germany.  If you still plan on using the software yourself, internally, be sure to retain rights to your own software when granting an exclusive license!
4. Worldwide/territory/other scope.  Specify the scope of the license, such as whether it applies only to a particular geographic region, technology platform or type of end user.
5. Sublicensable.  A sublicensable license means that the licensee can grant licenses to others.
6. Assignable.  An assignable license can be transferred to another, removing the original licensee from the license.  Typically, licenses are assignable only upon mutual agreement, an acquisition or bankruptcy.
7. Derivative works.  By permitting the creation of derivative works you permit the licensee to modify and create new versions of the licensed IP.  The license to make derivative works can be limited (for example, to ensure compatibility with changes in operating system versions) or broad.  It is usually the case that the license prohibits the creation of derivative works.

When reviewing an IP license agreement, I often recommend starting with a review of the license terms and to watch for the above terminology.  Each term can alter the scope of the license and you need to ensure that the license terms are consistent with the terms you previously agreed to.

I’m against the NDA.  This is common sentiment in the technology sector as well.  Before I dive into my issues with the NDA, let’s distinguish between types of NDA.

A Non-Disclosure Agreement is an agreement that requires a receiving party to not disclose or use certain information that the disclosing party wants to provide. Typically they are provided as a start to business negotiations or as part of a broader agreement.

I don’t take issue with NDAs that protect business information, such as financials, business plans or product launch plans or NDAs that are part of a broader agreement.

I do take issue with stand-alone NDAs that serve only to protect the “next great idea”. An idea (excluding patentable ideas) has no value; execution of an idea has value. Indeed, the same idea can be executed multiple ways with only a single approach achieving success.

Signing an NDA protecting an idea has the potential to limit your company’s own product development in the future as you will be restricted from “directly or indirectly” using the idea. Who is to say that you would not have arrived at the idea yourself, which is especially common in industries where most ideas are slight derivatives of what’s already out there, or what “indirect” use of an idea means. Further, imagine the challenge of creating a company-wide “ideas bank” where you place all ideas presented in NDAs and that you can never use.

A smart company will not use an NDA and, instead, will intelligently disclose the bare minimum level of information necessary for discussions to continue. These smart companies recognize that NDAs are hard to enforce as you face the burden of discovering an alleged breach and establishing that the breach actually involves information protected by the NDA. They also realize that NDAs tend to slow business negotiations.

Instead of the NDA, control what you say.  It’s far is far easier than trying to control what other people have already been told.

All too frequently, Terms of Service, Terms of Use and End User License Agreements (see our post on the differences between each) are found unenforceable when challenged in court because the agreements are not properly implemented.

To simply describe the implementation process (see our post on the technical aspects):

1.  Present the agreement to the user; then
2.  Require the user to affirmatively agree, usually through a click, to the agreement.

In the web context, implementation typically looks like this:

[Check box] I agree to the Startup Company Terms and Conditions (linked to the terms and Conditions)

[Continue] (or similar language, such as “Purchase” etc.)

In the above implementation approach, the user cannot proceed unless they check the box and click the button at the bottom of the page.

In the mobile context, implementation is more challenging given the need to balance legal implementation and user experience.  While the above approach can work, it may not be ideal from a UI/UX perspective.

One mobile approach is to present the agreement to the user, require that they scroll through the agreement and, once scrolled through, the user is presented with the following button at the bottom of the page:

[I agree] to the Terms and Conditions.

Given the differences between each mobile application, agreement implementation on mobile takes many forms and the above approach may not work for you.

Spending the time to determine the most effective way to implement your electronic agreements is vital as the agreements are worthless if found to be unenforceable.

Canadian startups are frequently influenced by U.S.-centric blog posts concerning startup company structure.  Relying on these posts ignores some fundamental differences in how Federal and British Columbia corporations can be incorporated compared to a Delaware corporation.  Indeed, Canadian startups should not ignore such differences as they permit a more lenient corporate structure from which to grow a company.

To start, here is an overview of the Delaware corporate structure typically recommended to startups:

1.  Authorize 10,000,000 shares.  Delaware corporations must authorize a fixed number of shares at the time of incorporation.  This number can be altered in the future but will require shareholder approval.  The large number is used as: (a) it avoids fractional shares; and (b) looks expensive.
2. Issue around 5,000,000 shares.  Shares are issued to founders but at least a 1/3 of authorized shares remain unissued for option pool grants and investment rounds.
3. Allocated shares to option pool.  A certain number of shares are allocated to the option pool.  The art of structuring the option pool, especially in regard to finance rounds, will be discussed in a future post.

Once complete, assuming a 10% pool, 6,000,000 shares (5m founder shares and 1m pool) have been issued or allocated.  The remaining 4 million shares, or 40% of the company, will be reserved for future investment rounds and expansion of the option pool (if needed).

Conversely, Federal and British Columbia corporations are NOT required to authorize, and thereby set a cap on the number of, shares.  Instead, shares can be unlimited, thereby granting the Canadian startup great leeway in granting shares in the future without having to worry about running into the authorized share limit that Delaware corporations face.

Here is what the same startup, incorporated Federally or in British Columbia, would look like structurally:

1. Authorize an unlimited number of shares.
2. Issue about 5,000,000 shares.
3. Allocate the option pool, fixed or rolling.  Given that shares are unlimited, you are not forced to set a fixed number of shares to constitute the option pool, although you could.  Instead, you can set the option pool size as a rolling % of issued shares creating an automatically adjusting pool size regardless of the number of shares issued in the future.

Ultimately, the Federal/BC startup is not faced by the same rigid share structure, governed by the authorized share requirement, that a Delaware startup is, thereby taking away a few of the corporate structure challenges that U.S. startups often face.  With unlimited shares, the Canadian startup’s future share grants are only restricted by the corporation’s constituting documents, agreements with shareholders or third parties and BC corporate law.  Conversely, the Delaware corporation needs to review how a share grant will reconcile with the number of authorized shares and, if needed, increase that number and seek shareholder approval to do so.

Of course, if you want to structure the company exactly like a U.S. startup, you certainly can authorize a fixed number of shares in your Canadian startup!