Category Archives: Intellectual Property

Real World Items in Games

When creating realistic video games, developers often desire to render real-world items digitally but neglect considering rights held in these items.  A failure to investigate rights held in real-world items is not limited to smaller studios as major developers (ex. Activision) have been sued for using real-world items in their games, such as AM General’s Hummer and certain firearms.   To assist in avoiding these issues, consider the following steps when inserting real-world items into your game:

  1.  Check to see if the item you are adding to the game is based on a real-world item.  For example, modes of transportation, firearms and luxury goods in games could all be based off a real-world item.
  2. When purchasing assets from marketplaces be sure to ensure that the asset creator has not  infringed the rights of third parties.  This has been an issue on the UE marketplace leading to an audit of most firearm asset packages.
  3. If your item is based on a real-world item, determine the rights held in that item.  For example, the design could be covered by a design patent while the name or logo could be trademarked.
  4. If there are rights held in the item be sure to secure a license from the rights holder before proceeding, otherwise you risk litigation and will be running afoul of most representations and warranties contained in publishing and platform agreements you sign.

In many cases, it’s cheaper to design your own items rather than seeking a license for real-world items, which may not be granted.  Take the GTA series and its use of cars of its own design – it’s doubtful that an automaker would license their rights to a game in which the same car is used to commit (digital) criminal offences, including murder.

If you are in doubt whether the particular item or its name is protected, be sure to contact your legal counsel before spending time integrating it into your game.

NDA Pitfalls

Non-Disclosure Agreements (NDAs) are a critical part of a technology company’s legal arsenal but are often relegated to a standard template without much thought.  Too often, I’ve seen NDAs sent by sophisticated companies that contain a number of pitfalls that often negate some of the protections that NDAs are relied upon for.  While there are numerous pitfalls to be watched for when drafting and reviewing NDAs, I wanted to highlight a few pitfalls that I frequently encounter that are often missed by both disclosing and receiving parties:

1.  Duration

While it may seem obvious it bears repeating: the duration of a NDA matters.  Often the NDAs I receive specify a relatively brief duration: usually between 2 and 5 years.  Problematically, after the time-period expires the protections provided by the NDA lapse and the previously confidential information can be disclosed at will.  While you may not believe that confidential information would be valuable 5 years into the future, this could be a costly assumption – image if the Coca-Cola recipe was treated the same?

NDAs should specify a perpetual duration unless you have a specific reason for limiting the duration.  Regardless, if the NDA duration has a limit you should be very careful to disclose only information that you’re comfortable becoming public information in the future.

2.  Who Can be Disclosed to

I often encounter NDAs that classify the NDA itself as confidential information that can only be disclosed with permission from the other party.  While seemingly innocuous, this treatment of the NDA can become a massive headache when it comes time to sell your company or its technology.  For example, you could be prohibited from disclosing the mere existence of the NDA to the purchaser or its legal counsel.

NDAs should permit disclosure of the NDA itself to your professional service providers, third parties proposing to engage in transactions with your company and their professional service providers.

3.  Scope of Protection

Do not neglect the scope of the NDA’s protection.  Obviously the NDA should protect information physically disclosed or spoken to the other party but there may be certain things disclosed to the other party that don’t fall within the typical scope of “information”.  For example, you may want the NDA to protect things that are visually perceived by the other party when on-site or sounds heard by the other party (this could matter if the sound of a machine could be used to determine a key design feature).

Always consider what you are disclosing under the NDA and be sure that the scope of the NDA’s protection matches the scope of disclosure as well as inadvertent, passive, disclosures that may take place.

Ultimately, the pitfalls with a NDA, as with any legal document, originate from the treatment of the NDA as a standard templated agreement.  The NDA is a powerful document that should be carefully crafted to reflect your particular business needs and to avoid the above pitfalls.

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!