--- title: "Designing Around Data You Don't Own" description: "The day I started structuring my tool's database, one question stopped me cold: who owns what I'm modeling? My project is…" date: "2026-06-30T09:00:00.000Z" updated: "2026-08-24T15:05:22.384Z" locale: "en" canonical: "https://ninhache.fr/en/blog/concevoir-autour-donnees-quon-ne-possede-pas" author: "Néo Almeida" tags: "design, data, reflexion" categories: "notes" --- # Designing Around Data You Don't Own The day I started structuring my tool's database, one question stopped me cold: who owns what I'm modeling? My project is a companion for an existing MMO, not an original game. The classes, spells, items, zones: all that content comes from a publisher who granted me nothing. I can write all the code I want, that code belongs to me, but the data it manipulates isn't mine. That simple sentence ended up governing half of my architecture decisions. ## Code and data are not the same thing This is a confusion I see often, including in myself early on: you open a repo under an open-source license and assume everything in it is covered by the same freedom. That's not true. **The code** A license like the AGPLv3 covers the code, the software architecture, the way I've organized my services and components. It gives anyone the right to reuse my engineering work, modify it, redeploy it, provided they share their changes. It's a license designed for software you wrote yourself. **The data** My repo also contains files that describe the game's content: skill names, stats, descriptive text, sometimes graphic asset identifiers. None of that is my creative work. I didn't invent it, I didn't draw it, I only organized it so a website could display it. Putting them in the same repo as my code doesn't move them under my license. These are two distinct legal regimes sharing the same storage space, and nothing more. Treating this coexistence as a merger is the kind of mistake that looks harmless until the day it isn't. What actually helped me was making this boundary concrete in the project's structure itself, rather than keeping it as a vague intention. A folder for the code, clearly documented as open source. A separate space, with its own access rules, for everything that comes from the publisher. Physical separation forces mental separation, and it makes visible to anyone contributing to the project what they're allowed to redistribute and what they're not allowed to touch. ## Clearly stating what you are not A fan project that works well starts by publicly admitting what it is not. This isn't a formality tacked on at the bottom of the page to cover yourself, it's an honest stance toward the players who use the tool. A non-affiliation notice, a visible disclaimer, a legal notice page explaining the nature of the project: all of this serves to avoid confusion between the game's publisher and an independent community tool. I'd rather a player understand from their very first visit that they're using a fan project, built with no official ties to the studio that made the game, than let ambiguity linger that would benefit my perceived credibility in the short term. **Why transparency protects you** This transparency also has a practical effect: it makes clear, in case of a disagreement with the publisher, that I never claimed to speak on their behalf or pass myself off as them. A project that plays it transparent from the start negotiates from a healthier position than a project that let people believe in a closeness it never had. --- ## Two layers of data, not one The question that naturally follows is distribution. Everything I store internally isn't meant to be republished publicly in full. I ended up designing two distinct data layers. **Internal layer** Complete, it's what powers the tool's calculations and recommendations. **Public layer** Filtered, it only shows what's necessary for the site's actual use, without exposing raw datasets that could be scraped and redistributed elsewhere in another form. This isn't a complicated architecture to set up if you think about it from the start. It is, however, hard to fix after the fact, once a public API is already exposing everything out of habit. **My rule** By default, nothing goes out until I've consciously decided it should. **The version that leaks** Expose everything, then lock it down case by case: the version that always ends up letting something slip that you regret. ## User accounts, hence obligations There's one last point that's easy to forget because it doesn't concern the game's publisher but the users themselves. As soon as a fan project offers accounts, saved preferences, a history of builds or characters, it's processing personal data. Non-commercial or amateur project status exempts you from nothing under GDPR. **Export** The user's right to retrieve their own data. **Deletion** The right to have it erased. **Minimization** Only collect what's actually necessary. **Legal basis** A clear justification for each type of processing. These obligations apply whether the project is run by a company or by a single person in their spare time. I've made a habit of treating this question as an integral part of the design, not as a legal checkbox added later. An account section that lets users view and delete their own data costs little to build from the start, and costs a lot to add after the fact on an already-established user base. ## What this changes in how I think **Leçon** Building on data you don't own shouldn't be treated as a legal detail to sort out after coding. It's a design constraint just like performance or security. Separating what's mine from what's borrowed, displaying that publicly, only distributing what should be distributed, and respecting users' data as much as the publisher's: these are guardrails you put in place before writing the first line of schema, not fixes you add when someone complains. A fan project that lasts is a project that knows, at every moment, what belongs to it and what doesn't.