Hytale Asset Licensing: Slikey on How Hypixel Studios Handles Infringement, and the One Thing He Cautions Against

Do not rehost or relicense Hytale assets where crawlers can reach them. That is the one concrete caution Hytale Tech Director Slikey gave on 29 September 2026, and the example he chose is specific enough to be useful: using Hytale textures for your project in a GitHub repo and licensing everything as MIT. Around it he described how Hypixel Studios actually handles infringement, which is a nice message first and a conversation before lawyers. Read this next part before anything else. This is a post on X by a developer. It is not a policy page, not documentation and not a contract. Slikey says in the post itself that the studio are not lawyers and can not provide legal advice, and he explicitly declines to say whether what any individual is doing is legal. Nothing in this article is legal advice either. We are a server list writing up what a developer said. If you need to know where your own project stands, read the actual shared source licence agreement yourself and talk to a lawyer about your specific situation. What Slikey Actually Said The post is a reply to the modder Kaayky RPG, who had asked about a modding toolkit UI design. Slikey's reply, in full and as written, including his "can not" as two words and his use of "action" as a verb: We generally do not comment whether what you are doing is legal. We are not lawyers and can not provide legal advice. All I can say is that the way we action infringement is by sending a nice message before taking any serious action. We want our community to read the policy, interpret it to their best ability and if we see something seriously wrong we will first seek a conversation rather than sending lawyers after someone. What I do want to caution against is directly hosting / relicensing our assets available for crawlers. (e.g. you use our textures for your project in a Github repo and license everything as MIT). The limitations are laid out in the shared source license agreement. Slikey, Tech Director, 29 September 2026, 14:52 UTC. The question he was answering, from Kaayky RPG on 29 September 2026 at 12:28 UTC: Here's the Hyblend Toolkit UI, but like I said before, I don't know if I'll keep this design, since I don't know if it goes against Hypixel's guidelines/policies... Not sure if tagging someone can help, but it doesn't hurt to try, right? :T@Simon_Hypixel #Hytale #HytaleModding Worth noting what the exchange is not. A modder asked for a ruling on his own project's UI design and did not get one. What he got instead was a general statement of posture plus a warning about a different problem entirely, which is the asset relicensing pattern. The Risk Pattern He Names: Hytale Assets in a Public Repo Under a Permissive Licence Stripped to its parts, the thing Slikey cautions against has two components that have to be present together: Directly hosting or relicensing Hytale assets. Not referencing them, not reading them from an installed copy of the game, but putting the asset files themselves somewhere you control and then stating licence terms over them. Somewhere crawlers can reach. His phrase is "available for crawlers", and the example is a GitHub repo. The example he gives joins both: Hytale textures committed into a GitHub repo, with the whole repo licensed as MIT. MIT is a blanket permissive licence. Applied repo-wide, it tells every reader that everything inside can be used, modified and redistributed by anyone for any purpose, which is a claim about the Hytale assets sitting in that repo as much as about your own code. This site's reading, not his words: the relicensing half is probably the sharper of the two problems. Committing a texture is one act. Publishing a LICENSE file that purports to grant everyone else rights over that texture is a second, louder one, and it is the one a crawler indexes alongside the file. Why "Available for Crawlers" Is the Phrase That Matters He could have said "public" and did not. Our reading is that crawler reachability is a practical test rather than a legal one: it describes assets that get indexed, mirrored, scraped into datasets, copied into other projects and surfaced in search results. An asset in that position stops being a thing one person did and becomes a thing that propagates, with your licence statement travelling attached to it. That also makes it the version of the problem a studio can see. A publicly crawlable repo is discoverable by Hypixel Studios in exactly the way a private working directory is not, which connects directly to the enforcement posture below: they first have to notice. We want to be careful here. Slikey does not say that non-crawlable hosting is fine, and we are not saying it either. He named the crawler case as the one he wants to caution against. What falls outside it is not addressed. Where This Shows Up in Practice for Hytale Server Owners and Modders Slikey named exactly one concrete example, the GitHub repo licensed as MIT. Everything in the list below is our extrapolation from that example to the shapes the same pattern takes in a normal Hytale project, and none of it is something he mentioned: Resource packs and texture overrides in a public repo. A pack that ships modified or unmodified Hytale textures, versioned in a public repo, with a permissive LICENSE file at the root, is the closest match to his example that a server owner is likely to create by accident. Plugin and mod repositories with assets committed for convenience. Models, textures, sounds or UI art dropped into src/main/resources so a build works, in a repo whose licence covers the whole tree. Asset pipelines and converters that commit their test fixtures. Tooling often carries sample input to make tests reproducible, and sample input for a Hytale asset converter is a Hytale asset. Model repositories and shared asset libraries. A community collection of models derived from game assets, published for others to pull from, is relicensing by design rather than by accident. Docker images and CI artefacts. A published image layer or a build artefact attached to a release can contain game assets even when the repository tree looks clean, and both are routinely public and routinely indexed. Documentation sites built from a repo. Screenshots are a different question, but a docs build that copies asset files into a published static site puts them exactly where crawlers are. The practical move, again our suggestion and not studio guidance, is to separate your own work from their assets. Keep your code in the repo and have the build or the installer fetch assets from the user's own installed copy of the game, so that your licence only ever covers things you wrote. Where that is impossible, at least make sure your licence file does not silently claim to cover files you did not create. For the adjacent technical problems, our guide to mod conflicts and asset patching frameworks covers patching assets at runtime rather than shipping copies of them, and the asset editor and Blockbench guide covers making your own models instead. If you would rather avoid the question entirely, original assets are the answer, and model making and custom assets is where to start. What He Said About Enforcement Three things, all of them in his own words rather than ours: They generally do not comment on legality. Not for any individual project, including the one he was asked about. He gives the reason: they are not lawyers and can not provide legal advice. The first step is a message. "The way we action infringement is by sending a nice message before taking any serious action." Conversation precedes lawyers. "If we see something seriously wrong we will first seek a conversation rather than sending lawyers after someone." The expectation he states alongside it is that the community reads the policy and interprets it to the best of its ability. Two honest qualifications, because this is the part people will want to over-read. First, "we will first seek a conversation" describes their usual practice as the Tech Director characterises it on X. It is not a guarantee, not a published commitment, and not something anyone should rely on as protection. Second, read the preposition: the nice message comes "before taking any serious action", which means serious action remains available. The posture is that they would rather talk first, not that talking is all they do. The genuinely reassuring part is the one that is easy to miss: the studio expects people to read the policy and interpret it as best they can, which is a tolerant standard. It is not an invitation to skip reading it. What We Are Not Going to Tell You: The Licence Itself Slikey says the limitations are laid out in the shared source license agreement. That is the whole of what we know about that document from this post, and we are not going to characterise what it permits, restricts or defines. We have not read it as part of writing this, and a server list paraphrasing a licence agreement is exactly how people end up with a confident wrong answer. So: the shared source licence agreement is the document to go and read if any of this touches your project. Read it in full, and get advice on it if the stakes are real for you. What This Does Not Settle Whether any particular project is infringing. He explicitly declines to say, for the project he was asked about and by extension for yours. What the licence actually permits. Not addressed in the post, and not addressed here. Whether a restrictive licence changes anything. His example is MIT. Whether a copyleft or custom licence over the same assets lands differently is not stated, and we do not know. Whether a private repository changes anything. He flags assets "available for crawlers". A private repo is not crawlable, but nothing in the post says private hosting is therefore acceptable. Whether third-party asset conversion tools are affected. Tools that read installed game files and produce something else are not mentioned at all. Where modification stops mattering. Heavily edited textures, assets used as references, and assets used to train or generate something are all outside what the post covers. Whether this is a change. Nothing suggests new policy. It reads as a developer describing existing practice, but we cannot confirm it matches anything published. How This Differs From Our Existing Coverage Two earlier pieces sit next to this one and neither covers it: Hytale shared source server code on GitHub covers what shared source is, how the access gate works and what the contribution workflow looks like. It is about getting at the code. It says nothing about enforcement or about relicensing assets, which is what is new here. The Hytale server monetization policy covers what servers may and may not charge for, and how that is enforced. It is a different policy on a different subject. Asset licensing and monetisation rules are separate things and conflating them is a common mistake. For scale, the modding scene passed 5,000 mods and 20 million downloads in April 2026, which is a good reason this question keeps coming up: there are now a great many public repositories with Hytale-shaped files in them. The Bottom Line If you take one thing from this: keep their assets out of your public repositories, and keep your licence file from claiming rights over files you did not make. That is the pattern the Tech Director picked out by name, and it is also the easiest one to avoid. If you take two: the studio's stated posture is a message and a conversation before anything serious, which is humane and should not be mistaken for immunity. They expect you to have read the policy, and the document Slikey points at is the shared source licence agreement. Go and read it, and ask a lawyer rather than a server list if the answer actually matters to you. Building something for Hytale servers? List your server on HytaleCharts so players can find it.