The FSF says of the JSON License:

This ["not-for-evil" term] is a restriction on usage and thus conflicts with freedom 0. The restriction might be unenforcible, but we cannot presume that. Thus, the license is nonfree.

Similarly it is not open source because it conflicts with term 6 of the Open Source Definition, "No Discrimination Against Fields of Endeavor".

The use of this license by some FLOSS project is as roughly as problematic as any other non-FLOSS license. It introduces a non-free term in how the software may be used, just like a license that restricts, e.g., commercial use of the software.

• If the project is otherwise permissively-licensed, this doesn't cause a legal problem, but only a practical one about how the resulting software may be used (i.e., only for "good", rather than for all purposes).

• If the project uses a copyleft license like the GNU GPL, this does introduce a legal problem. The GPL applies to the work as a whole, and the GPL forbids the introduction of restrictions beyond what the GPL itself requires. If a project maintainer accidentally included code under the JSON License within the distribution of a GPL-licensed work, copyright holders of the GPL-licensed parts could take legal action for violation of their software's GPL terms.

As the FSF notes, it's possible that this not-for-evil term might be altogether legally void. If that possibility proves true in any particular jurisdiction, then the JSON License would, in effect, be a FLOSS license in that jurisdiction.

You can put the database and the images in a subdirectory of your project and identify in a licenses.txt within this subdirectory that all parts are there licensed under CC-BY. To make it perfect, you can additionally include a SPDX identifier in each of the files (if the file format allows).

You should inform others in the license.txt of your GitHub project that it is under Apache license with the exception of files in that certain subdirectory.

If you are using 3rd party images you should include their license and attribution language in an 'About' page of the web project. Obviously that is also a good place for the information about your own code and images.

You should increment the version number of your project on GitHub with each change in the database or images, even if the code remains unchanged. I would increment the minor version or one level below (e.g. from x.y.2 to x.y.3) for that, but that's up to you. Obviously, if you use your own project for a website and you change the pictures there without feeding each change back into the GitHub project, then you don't need to bother with the sub-versioning.