Jump to content

Forge and Minecraft's EULA


mehrcraft

Recommended Posts

I am very confused by Minecraft's EULA as it relates to mods.  It states that you can't profit in any way from mods, but there are obvious signs that it is not quite so, as virtually every mod download goes through something like AdFly and so many modders ask for donations on Patreon.

So, it seems that the real question is "how do you profit from mods without violating the EULA?"

Also, since most modders seem to prefer Forge, the most successful mods that have not been abandoned after a few years are Forge mods, and Forge seems to operate through a standard interface to the Minecraft code instead of by modifying the code itself... it leads me to suspect that Forge was designed to allow profiting without violating the EULA.

Am I guessing correctly?  Are there basic principles or maybe a guide on how to do it safely?

I ask because I am an experienced Java developer, loved Minecraft since Beta, and I would like to create AND properly support mods, but without a steady income (obviously assuming the mods are successful) it is obvious that I would sooner or later get bored and abandon any mod I wrote... so I don't see much point in nodding unless this was viable.

Link to comment
Share on other sites

Paragraph before last of the section "Using our game".

Am I misreading it?  Are you saying that making a Forge mod and earning income through ads and patreon is NOT a violation of the EULA?  That is what I suspected and hoped for, and the reason for this post.

if yes, is there a source of advice on how to do it without getting in legal trouble?

Also, assuming that I were able to design a mod that got millions of downloads and promoted it correctly... would I be able to live on that income?

Edited by mehrcraft
Link to comment
Share on other sites

TLDR: We live in Mojang's good graces and legal grey areas. Forge is not `designed to allow profiting` It was designed too help people not violate the EULA's 'dont distribute our stuff' part. 
Basically, if you're asking this question then you're most likely going to violate their EULA. Just make mods for fun, and if you host it yourself feel free to put non-intrusive ads on your page.
Do not say "Pay be $10 and you can have access to my mod"

But again, nobody here is lawyers, nore would it have any effect if Mojang decided to go after you as Microsoft has more money then you do, and we all know the side with the most money wins thee lawsuit.

I do Forge for free, however the servers to run it arn't free, so anything is appreciated.
Consider supporting the team on Patreon

Link to comment
Share on other sites

That is exactly it LexManos, it is flat out impossible to produce good mods and support them for the long term if you are only doing them for fun.  If the only motivation is "for fun" sooner or later something else will attract your attention and you'll stop updating the mod as new versions of Minecraft come out and the mod ends up abandoned and no longer functional.  That is easily seen in 80-90% of mods made.

But there are some mods that have stood the test of time.  Most players wouldn't even consider playing without mods like Optifine, Xaero's or Journey maps, and some others from the mods with millions of downloads.  All of those are very obviously making an income from ads, Patreon donations and possibly other means.  Neither Mojang nor Microsoft have gone after them.  That is why I strongly suspect that there is a way to make an income without violating the EULA, although the EULA is very vague about how you would do it. 

Some of the obvious steps are:

- Don't charge for access to a mod.  The mod must be given for free.

- Don't make any of the features dependent or even remotely related on any kind of financial contribution.

- Don't distribute any of Minecraft's stuff.  That part this thread seems to be what Forge (not Fabric as far as I can tell) helps achieve. 

- Don't make any claims of any kind of relationship with Mojang and Microsoft.

 

So I think my question remains, and is valid and clearly possible as those many mods have done it:  "What additional steps must be taken to earn income without violating the EULA?" 

Link to comment
Share on other sites

Ya I think this is getting along the line of trying to skirt their license for the sake of trying to abuse users for profit.
I also reject your assertion that its impossible to produce good mods unless you're paid too do so. Yes, being paid helps you not have to worry about income and other jobs. But that is no guarantee that you won't get "distracted" by other things. Or run into burnout from the Minecraft upgrade grind. 
However the ONLY legal way to make a mod for profit without violating the EULA is to get explicit permissions from Mojang to form a business relationship with them to utilize their IP for profit.
Good luck doing that. I don't think this needs to be discussed any further because your intention seems clear.

I do Forge for free, however the servers to run it arn't free, so anything is appreciated.
Consider supporting the team on Patreon

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.

Announcements



  • Recently Browsing

    • No registered users viewing this page.
  • Posts

    • I am not using hardcoded recipes, I'm using Vanilla's already existing code for leather armor dying. (via extending and implementing DyeableArmorItem / DyeableLeatherItem respectively) I have actually figured out that it's something to do with registering item colors to the ItemColors instance, but I'm trying to figure out where exactly in my mod's code I would be placing a call to the required event handler. Unfortunately the tutorial is criminally undescriptive. The most I've found is that it has to be done during client initialization. I'm currently trying to do the necessary setup via hijacking the item registry since trying to modify the item classes directly (via using SubscribeEvent in the item's constructor didn't work. Class so far: // mrrp mrow - mcmod item painter v1.0 - catzrule ch package catzadvitems.init; import net.minecraft.client.color.item.ItemColors; import net.minecraft.world.item.Item; import net.minecraftforge.registries.ObjectHolder; import net.minecraftforge.fml.event.lifecycle.FMLClientSetupEvent; import net.minecraftforge.fml.common.Mod; import net.minecraftforge.eventbus.api.SubscribeEvent; import net.minecraftforge.client.event.ColorHandlerEvent; import catzadvitems.item.DyeableWoolArmorItem; @Mod.EventBusSubscriber(bus = Mod.EventBusSubscriber.Bus.MOD) public class Painter { @ObjectHolder("cai:dyeable_wool_chestplate") public static final Item W_CHEST = null; @ObjectHolder("cai:dyeable_wool_leggings") public static final Item W_LEGS = null; @ObjectHolder("cai:dyeable_wool_boots") public static final Item W_SOCKS = null; public Painter() { // left blank, idk if forge throws a fit if constructors are missing, not taking the chance of it happening. } @SubscribeEvent public static void init(FMLClientSetupEvent event) { new Painter(); } @Mod.EventBusSubscriber private static class ForgeBusEvents { @SubscribeEvent public static void registerItemColors(ColorHandlerEvent.Item event) { ItemColors col = event.getItemColors(); col.register(DyeableUnderArmorItem::getItemDyedColor, W_CHEST, W_LEGS, W_SOCKS); //placeholder for other dye-able items here later.. } } } (for those wondering, i couldn't think of a creative wool helmet name)
    • nvm found out it was because i had create h and not f
    • Maybe there's something happening in the 'leather armor + dye' recipe itself that would be updating the held item texture?
    • @SubscribeEvent public static void onRenderPlayer(RenderPlayerEvent.Pre e) { e.setCanceled(true); model.renderToBuffer(e.getPoseStack(), pBuffer, e.getPackedLight(), 0f, 0f, 0f, 0f, 0f); //ToaPlayerRenderer.render(); } Since getting the render method from a separate class is proving to be bit of a brick wall for me (but seems to be the solution in older versions of minecraft/forge) I've decided to try and pursue using the renderToBuffer method directly from the model itself. I've tried this route before but can't figure out what variables to feed it for the vertexConsumer and still can't seem to figure it out; if this is even a path to pursue.  The vanilla model files do not include any form of render methods, and seem to be fully constructed from their layer definitions? Their renderer files seem to take their layers which are used by the render method in the vanilla MobRenderer class. But for modded entities we @Override this function and don't have to feed the method variables because of that? I assume that the render method in the extended renderer takes the layer definitions from the renderer classes which take those from the model files. Or maybe instead of trying to use a render method I should be calling the super from the renderer like   new ToaPlayerRenderer(context, false); Except I'm not sure what I would provide for context? There's a context method in the vanilla EntityRendererProvider class which doesn't look especially helpful. I've been trying something like <e.getEntity(), model<e.getEntity()>> since that generally seems to be what is provided to the renderers for context, but I don't know if it's THE context I'm looking for? Especially since the method being called doesn't want to take this or variations of this.   In short; I feel like I'm super super close but I have to be missing something obvious? Maybe this insane inane ramble post will provide some insight into this puzzle?
  • Topics

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.