Added clarification to README

[StandingPadAnimations]

Added clarification that the new rule only applies to assets (applying to all of MCprep is a violation of GPL as I later realized)

[StandingPadAnimations]

Before we merge this, I'll email the FSF regarding the topic of JSON models, since (unless I'm mistaken and the JSON models aren't from the vanilla resource pack) they could actually count as code under GPL (and thus restricting them would violate GPL)

EDIT: I've sent them the email. Unlike Mojang, the FSF is more concerned with making sure open source software stays compliant with GPL, so I'm not too concerned with them asking for MCprep to be taken down. Here's a copy of the email I sent them:

Here there, I hope y'all are doing well. I'm Mahid, one of the
maintainers for MCprep (a GPL licensed addon for Minecraft animation
worksflows in Blender), and I want to ask about some complience concerns
we have at the MCprep project.

Our addon includes a set of assets that use the vanilla Minecraft
resource pack, which is subject to Mojang's EULA. We're looking towards
restricting assets to users who have a valid copy of Minecraft in order
to comply with the EULA. For most assets, we're confident that there
shouldn't be issues as they're non-code assets (blend files, images,
etc), but we're concerned about the JSON models from Minecraft's
resource pack. It can be argued that JSON models count as code assets,
and thus restricting their distribution is a violation of GPL. Would
restricting JSON models be a violation of GPL? If restricting assets at
all would be a violation of GPL, then are there alternative routes that
we could use that would let us comply with GPL but also not break
Mojang's EULA?

- Mahid Sheikh

[StandingPadAnimations]

Yeah, looks like whatever we do, it's going to be a grey area:

Thank you for contacting us and for your willingness to abide by the GPL. Let me start by explaining that the Free Software Foundation (FSF) is working to secure freedom for computer users by promoting the development and use of free software. Please note that we at the FSF do not and cannot help developing proprietary
software, even indirectly. Not only we find it morally wrong, we are also a small organization with limited resources that cannot afford to lose sight of our goal, which is free software. Also, we do not provide legal advice.

As far as I understand your project is an effort to improve rendering animations from a nonfree game. The game is released under a nonfree EULA and it's copyright holder attempts to control modding efforts and reuse of the game's data files by a policy, which can be changed at any time. Your project encourages users to use the nonfree game and results in them being unable to exercise the freedom.

Projects based on proprietary software, such as yours, knowingly live in a gray area. These projects are often one update of a proprietary EULA, or one cease-and-desist letter away from oblivion. So even your best efforts, which are absolutely commendable, to do the right thing in regards with the GPL are overshadowed by this unfortunate state of affairs.

Even though your project is released under the GPL and even though it is an improvement to the free software program Blender, the freedom that the GPL grants cannot be reconciled with the restrictions on the game files imposed by the copyright holder to the game.

The key part is this:

Even though your project is released under the GPL and even though it is an improvement to the free software program Blender, the freedom that the GPL grants cannot be reconciled with the restrictions on the game files imposed by the copyright holder to the game.

I think for now, we'll just add the clarification, and then work towards not distributing Minecraft assets (instead asking users to provide a copy of the Minecraft JAR file for assets). I have sent a follow-up regarding requiring users to supply the Minecraft assets themselves, but I think it's fine if we merge this for now.

[TheDuckCow]

Let me know if we're still waiting for some kind of response here

Ahh, just saw the page update now, will approve and merge then.

In terms of incremental steps we could do, the main one is the distribution of the overall default resource pack. I already use an entirely automated script to populate these files and mappings, so it's not unreasonable to have it run on end-user machines. Although, for reasons like #529, it can lead to other new issues we can't prevent ahead of time.