Germany has strict rules governing video game content that large studios and indies need to comply with before publishing or advertising a game in Germany.  Breaching these rules is costly as fines may total $550,000 USD in addition to (in some cases) constituting a criminal offence.  Often, the laws result in modified video game content just for the German market (see: Half-Life, Wolfenstein).

By factoring these rules into development you can facilitate a smooth release in Germany.

1. What Content is Unlawful in German Video Games?

It is unlawful to display violations of human dignity, propaganda material of unconstitutional organizations (especially Nazi symbols), glorify violence and war as well as certain pornographic content.  See Article 4 for the full list.

In addition, it is unlawful to provide content that has the potential to impair the social and emotional development of children if you don’t take precautions to shield children from the content. Depending on style and presentation, games that cover violence, sex or drug use can fall under this category.

2. Does my Video Game Violate German Law?

If you’re unsure whether your game violates German law, there are two ways for your game’s content to be reviewed:

A.  You can have it pre-assessed by the German certified self-regulation organization USK.  The organisation offers basic initial assessments at a flat rate equivalent to $330 USD. You can also apply for an official rating which will prevent your game from being put on the “index list” of restricted content allowing for legal certainty before launching. This assessment entails a test run of the game and costs up to an equivalent of $1,320 USD. For a yearly fee equivalent to $3,300 USD, you can also become a USK member, which includes customized child protection solutions and a certain degree of protection from fines and other administrative measures.

B.  If your game is sold through certain marketplaces (Google Play, Nintendo eShop and Windows Store), you can obtain classification via the International Age Rating Coalition. This system is free to developers and allows you to rate a game using a complex questionnaire.  As of October 2016, IARC will be recognized as an official age classification system by German authorities.

3.  Wont Somebody Please Think of the Children!

As mentioned above, for some games, child protection measures have to be taken.  Examples of such measures include:

A.  tagging your website with an age restriction label; and

B.  restricting game distribution to adults, for example by using an age verification system.

Content that is deemed specifically harmful to children may only be made available to adults in closed user groups.  In addition, if you act as a website provider, it might be necessary to appoint a “Youth Protection Representative” to ensure compliance.

While these requirements are not minimal, it’s important to take them into account if you plan on Germany constituting a portion of your game’s market.

Thanks to guest writer Dominika Wiesner, a German trainee lawyer  working in our office this summer, for her work on this blog post.

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.