Category Archives: Intellectual Property

UI/UX Invalidated your Contract

Online contracts are only effective if implemented correctly.   I’ve written on different processes for implementing online contracts, which is often easier to accomplish in the web context.  In the mobile context, implementation is challenging given the need to balance user experience with contract formation.

How you structure contract formation in your mobile application involves negotiation between the UI/UX team and legal counsel and a balancing of user experience against the risks of the contract unenforceability.  With millions of DAU, the risks are enormous.

A recent case illustrates this risk and shows that even sophisticated startups can run the risk of a weaker contract formation process and be burned.  Lyft presented users with this acceptance screen:

LI Image

It includes the typical web approach to contract acceptance, with a check box stating: [I agree] to the Terms of Service (link).  Recently, a NY court determined that this process did not clearly indicate to users that a contract was being agreed to.  The combination of a series of “Next” screens, the small size of the contract formation text (relative to the large, pink “Next” button) and that the contract was presented in the context of an unrelated phone number request all contributed to the court’s conclusion that users were not sufficiently notified of what they were agreeing to and, as a result, did not accept the Lyft Terms of Service.

Luckily for lyft, prior to the lawsuit, a new contract formation process was implemented, one I’ve advocated for myself:

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.

Take away:

  1.  At a minimum, mobile applications should have prominent language indicating that a contract is being presented to users (ideally as a separate screen labeled “Terms of Service” or similar).
  2. Contract language should be noticeable and not blend into the background as a user registers for the application.  Try to alter the flow of the registration process so the user recognizes that something new is occurring.
  3. Any button on the contract page should state “I agree” or “I accept”, rather than “Next” and this button should not overwhelm the contract link.

In my opinion, the scrolling process described above is one of the better approaches for implementing a contract into a mobile application.  Other approaches are available but your UI/UX team needs to work with legal counsel to ensure that design considerations do not overwhelm contract enforceability.

Top 5 Video Game Studio Legal Mistakes

We represent quite a few video game studios, many of which are indie.  Regardless of studio size, we are often called to fix legal mistakes that could easily have been avoided.  These legal mistakes frequently fall into one (or all) of the following five categories:

  1.  Don’t forget to incorporate or incorporate too close to the date of launch.  Often incorporation is left to the last minute and only happens when Steam or Apple asks for a company name.  This is a problem as game intellectual property (IP) must be transferred to the new company at its fair market value, which may be more than nominal (given that it is about to be sold) and could involve complex tax solutions.  By incorporating earlier in the development cycle, you can put in place proper agreements so that the company owns game IP from day one.
  2.  Don’t create complex corporate structures with no purpose.  If you don’t know why your company has a particular corporate structure, you likely don’t need it.  The more complexity, the more likely mistakes will be made in the future when you use a certain structure for a different purpose than originally intended.
  3. Don’t  forget to assign IP to the studio.  The company needs to own game IP as, without, it cannot sell the game since it does not own the game in the first place.  This can be remedied through employment, contractor or IP assignment agreements.
  4. Don’t use oral agreements with independent contractors.  Use independent contractor agreements to document the studio’s relationship with contractors and to ensure the company owns the contractor’s work.
  5. Don’t sign publishing agreements without review.  Have a lawyer review your publishing agreements as there is often a disconnect between the terms you negotiated and the publishing agreement terms (often unintentionally, given publisher reliance on agreement templates).

By keeping the above in mind, you should be able to structure your studio correctly and save the legal fees otherwise incurred to clean these sorts of mistakes up.  For our indie clients, we certainly understand that they would rather put money into development than into legal fees!

IP Licensing Terms to Watch for

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.

My Problem with the NDA

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.