You say that you add this stuff on the project's "release page" (presumably the same place where people can download a release). This is not in any way enforceable. When you make free software publicly available, people can share it with anybody without ever seeing your release page, so users may not been made aware of your terms. No court is going to let you enforce any such terms.
In all jurisdictions I am aware of, including the EU and the USA, when you have a specific legal document such as a license or a contract, a court will refuse to look at anything except the specific license or a contract and any additional document specifically mentioned in the license or contract, to settle any dispute between two parties.
This means that if you put anything on the project page that conflicts with the main license, it will be considered null and void. I.e.:
- This is not enforceable.
- It will not tamper with the enforceability of the main license.
- It will not even pollute the open/free status of the main license.
The same goes for a blog post written by the project head and linked from every project page. Sharing your thoughts about what you think should be "fair attribution" is fine, but it only counts as a suggestion. When staffers sometimes pretend that is more than that, such pretense does not change its legal status to being a requirement that can be enforced by legal means. I.e. such additional notes, in the shape of blog posts or otherwise, can not be enforced through courts, and will not tamper with, or pollute the main license.
I.e.: Doing this will not have any effect at all on the project's licensing situation.
However. it may identify the project head as a bozo and potentially quarrelsome (NB: I am not saying that this makes the project head a bozo, etc., only that it may make some people may think so). This may make some people stay away from using code from the project. As for the SE, the (then) project head's blog post goes on to name and shame two specific websites that does not live up his attribution expectations. This sort of enforcement technique is IMHO not an ethical way to enforce your additions to a license, but if you don't want this to happen to you, you may need to follow the SE recommendation if you reuse materials from SE, even if lacks any legal foundation.
However, some licenses such as the GPL allows additional terms. Read below the line for a more specific analysis of various ways of adding additional notices and how this applies to specific licenses.
Disclaimer: IANAL and all that.
The text above the line is my answer.
However, looking beyond the "project page" it may also be interesting to look at attempts to add additional terms to the projects distribution archive.
For instance, let us assume that you add your additional terms below the license text is the license file (e.g. LICENSE.txt) included in the distro.
If you try to add or remove anything to or from license itself, the license is no longer a recognized free software license. Doing so will make your license a crayon license (this is more or less how crayon licenses are defined), with all the problems that follows from the use of crayon licenses.
But what if you put your additional terms is a separate document? E.g. you but your terms in a file named EULA.txt, NOTICE.txt, README.txt, or some other conspicuous name) that lives in the distribution archive along with LICENSE.txt when people download the project directly from you.
Then you need to read the license text to find out whether this is permitted and if it will be enforceable. By means of example, I shall look at two popular free software licenses, GPLv3 and MIT:
GPLv3 very explicitly allows additional terms (see sec. 7. Additional Terms). but only if they provide additional permissions to the user, or "supplement the terms of this License with terms" [followed by a bullet list of six permitted types of additional terms]. Any other additional terms are not allowed, and permission to delete them is explicitly granted downstream recipients:
All other non-permissive additional terms are considered “further restrictions” [...]. If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term.
MIT/Expat grants a series of permission "without restriction". If you add terms somewhere in the distribution that contradict the license grant by imposing some restrictions, these would not be enforceable if the language used do not make it clear that the intent of the drafter was to provide a precondition or a covenant for use. If this additional document is not a license, then it will be ignored by courts (see my introduction). If it is an additional license, then, as explained in this answer it would amount to dual licensing and users would be free to pick the permissive license (MIT) that is provided over the more restrictive (the EULA).
There is no room here to run through all recognized free software licenses, but my general impression is that they do not give you much opportunity to impose restrictions on your users. I cannot completely rule out that there exists a free software license that cuts more slack than GPLv3 or MIT/Expat - but I doubt it.
However, for all free software licenses, provided you hold the sole copyright, or have permission from all contributors (e.g. through a Contributor License Agreement), adding terms that gives further permissions are generally allowed.
For instance you add a file with the following notice to a the distribution of a project licensed under MIT/Expat:
To the extent allowed by applicable law, I waive the right of attribution, and the requirement that a copyright notice and a permission notice shall be included in the program.
Such a waiver would allow people to reuse your code without having to comply with the attribution, etc. requirements of the license. If you add the following restriction to the waiver:
Removing this waiver is not allowed.
Then, that would not be enforceable, as it contradicts the main license grant.
