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.

The US DMCA (Digital Millennium Copyright Act) contains very useful provisions that provide a company with a safe harbour (in the U.S.) from copyright infringement committed by users of the company’s website or other online service.  For technology companies, especially those that permit users to contribute content, this safe harbour is invaluable as, without, liability for copyright infringement committed by users could be a financial disaster – imagine the liability a video upload site could incur.

To be granted the safe harbour, your company must comply with a number of legal requirements, including:

  1.  The posting of certain information concerning a notice-and-take-down process for alleged copyright infringing content, counter-notice to challenge an allegation and compliance with this process; and
  2. Registering your online service with the US copyright office and registering a DMCA agent, who acts as the point of contact for DMCA/copyright infringement claims.

Previously, DMCA agent registration did not expire.  Due to changes in the regulations governing DMCA agent registration, all current DMCA registrations expire on December 31, 2017.  Going forward, companies may register DMCA agent information electronically, each registration being valid for 3 years.  A failure to re-register a DMCA agent will result in the loss of the DMCA safe harbour, even if you previously registered and no change occurred with respect to that agent.

The benefits to the DMCA safe harbour greatly outweigh the minor costs involved in registering a DMCA agent.  Accordingly, we recommend registration to our Canadian clients, even if they do not have a presence in the U.S.  If your company has already registered, be sure to contact your legal counsel to timely begin re-registering your DMCA agent.

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!

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.