I was part of this conversation in the C3 thread as well. A major concern of mine in regards to not being able to encrypt one's assets is that sometimes assets from a third party are licensed under the condition that the developer takes the appropriate steps to protect those assets by encrypting them.
This is done in order to protect the developer from legal litigation by said third party. Simply stated: plausible deniability. You as the developer took steps to protect the assets, and when someone hacks that encryption, you cannot be held legally responsible.
I came upon this at the GraphicsRiver asset foundry in their extended license:
[quote:2s9rz8if]11. You must not permit an end user of the End Product to extract the Item and use it separately from the End Product.
I read this, and in my opinion unencrypted assets potentially break this requirement. Tom's opinion is that as long as a Terms and Conditions statement (txt file) accompanies your game, you should be fine.
Definition of "Permit": officially allow (someone) to do something.
So in my understanding of this, as long as you do not give official permission for them to take the assets you're good. Put in your T&C something along the lines of "You are not permitted to extract and use any assets in this game for any purpose". I can see how this might be interpreted in the way you say though, but doubt that's the spirit of it because it's impossible to enforce imo.
Probably best to check with Envato though of course. If you don't want to clarify that with them, let me know and I can send them an email if it's a big concern for you.
* This is my opinion, IANAL etc.
So I contacted Envato (owners of GraphicsRiver) and today Envato Market Help got back to me:
Thanks for taking the time to thoroughly research the terms of our license usage. Many people buy the assets without caring. That being said, you should be fine with an extended license but adding the statement on what is not allowed is wise. I can see how GraphicRiver assets would commonly be distributed in other items but that should cover you legally, if needed. The buyer would then be essentially doing what we ask of our buyers in our disclosures.
Go forth and prosper!
Now, the part that worries me once again is the "you should be fine" and "should cover you legally" parts. "should" will not hold up in the worst legal scenario.
Of course, it is a very slim chance that someone will care about all this, I agree. But let's just assume someone develops a game in Construct 2/3 that becomes incredibly successful, and sells tens of millions of copies. The game uses a number of assets from GraphicsRiver. The designer of those assets notices this, and downloads/installs the game on a Windows machine, and discovers that his/her assets are unencrypted, and anyone can have access to them by merely unzipping them. The designer (US based) is aware of point (11) of the extended license, and decides to take legal action against the game developer in the US.
Even though the developer included a T&C, I could imagine that US copyright lawyers shred it to pieces because of the fact the plaintiff's assets were not encrypted at all and left out in the open, because in my view (11) implies that the developer must take appropriate steps to help protect the plaintiff's assets, and a case could possibly made by high-flying lawyers that the defendant failed to do so.
I am aware that it is highly unlikely and doubtful that such a situation may occur, but the point I am making is simple: if Construct allows for a simple asset encryption option during export, the game developer won't have to run any such risk at all in the first place.
All the other game engines allow the user to encrypt their files. Yes, assets can be hacked/ripped anyway, yet I think it is a fundamental option to have anyway. At least provide the option to do so.