Legal Transformation of the SIGame Ecosystem

Over the years of working on the game, I’ve interacted with content creators, players, designers, composers, and programmers. Now, it seems, it’s time to engage with lawyers.

Previously, I didn’t give much thought to how the project operates within a legal framework or the risks it faces. But with age comes experience, and I’ve started to understand the legal intricacies of working in IT and with user-generated content.

I had dealt with similar issues once before — when I implemented whitelabeling in the game by removing all terms and names from the original show, as well as photos and names of famous players. Now it’s time to complete what I started.

Let me state upfront: 100% legal compliance is only possible with an empty project. No project— no risks. ?? Thus, the goal is to minimize risks as much as possible.

Secondly, even the lawyers didn’t give me clear-cut answers (though they did provide valuable information), so many of my decisions are guided by common sense.

Current Ecosystem Overview

We have user-generated content. Authors create multimedia and text-based packages; players create nicknames; and when creating rooms, players choose arbitrary names visible to all participants. Until recently, there was also a global chat for all players, moderated only by auto-replacement of swear words with asterisks (the chat has now been removed).

Since I don’t create the content by myself, it can sometimes be problematic. Problematic content can be categorized as:

• Copyright violations (e.g., melodies, screenshots, quotes without attribution or disallowed to be copied at all).
• Legal violations in any country (e.g., calls to action, prohibited imagery). This raises the question: which country’s laws apply to a global application? Likely, all of them simultaneously.

All other content is legal.

The forms of content are: packages, avatars, and text messages. Content accessibility: it is potentially visible to an unlimited audience (e.g., a chat within a private room is only visible to room members and is less critical).

The goal is to protect the project from accusations of hosting problematic content by shifting responsibility to its creators and promptly responding to external complaints.

Key Objectives

1. Avoid significant costs (no full-time moderators or lawyers).
2. Preserve the core appeal of the game — the ability to play with friends using custom packages. Without this, the project loses its essence.

Proposed Solutions

1.Emphasize the non-commercial nature of the project:

Reduces risks significantly by relying on fair use for educational, illustrative, or citation purposes.

Steps:

• Remove ads from the app.
• Keep donation links but highlight that:

a) Donations are optional.

b) They only cover server and domain costs.

c) They don’t provide any in-game advantages (e.g., cosmetic changes).

2. Content storage:

The game and associated VK group should not store content permanently without moderation.

Actions:

• Remove potentially problematic content from the built-in “Verified Content” Library.
• Transfer the large VK group’s content to a third-party group managed by enthusiasts (in progress).

3. Content transmission:

Emphasize the authors’ responsibility for the content they create/upload.

Actions:

• Explicitly state in the user agreement that participants are responsible for their content.
• Enable the use of external libraries in the game, shifting responsibility to their authors and owners.
• Players uploading packages not from the library must acknowledge their responsibility. Include a notification in the game and ensure that such packages are automatically deleted after the game ends.

4. Authorization:

Require authorization for actions visible to a wide audience, such as:

• Naming a game room. (Anonymous users will use automatically generated names.)
• Using external packages.

External libraries will reduce the need for authorization, allowing most players to remain anonymous.

5. Content complaints:

Implement a process to respond to complaints, allowing for the blocking of problematic content and providing feedback to the complainant.

6. Decentralization:

Support multiple small content libraries instead of one central repository. This ensures the game can continue functioning even if issues arise with one library.

7. Attribution:

Include the author and source for every content item. Optionally, include licensing information. Display this data in the game.

8. User education:

Educate users on what content is permissible, where to source it, how to provide attribution, and their responsibilities.

Conclusion

This may seem somewhat scattered, but these combined measures should help mitigate risks. It doesn’t have to be implemented all at once (nor is that feasible), but we should move gradually and confidently in this direction.