Instead of arguing about what counts as a "real" or "proper" quine, which I suspect is too subjective and context-dependant to ever permit a non-contentious definition, let me try to instead suggest a related, hopefully slightly less loaded dichotomy:

> Definition: A quine is **payload-capable** if it can be extended, in some systematic manner, to include a "payload" of additional code capable of performing arbitrary computation, in addition to printing its source code. A payload-capable quine, in its base form, must include all the code necessary to execute a payload, even if no actual payload is present.

*Examples:*

* `{whatever}` is a GolfScript quine, but it is not payload-capable. Neither is `1` or an empty program.

* `{".~"}.~`, however, *is* a payload-capable quine in GolfScript, as it can be extended to `{".~"anything}.~`, where `anything` is arbitrary GolfScript code that is executed by the GolfScript interpreter.

* `` ".`\\".`\ `` is also payload-capable, as it can be extended to `` ".`\\foo".`\foo ``, where `foo` is arbitrary GolfScript code (and where any special characters in the first instance of `foo` are escaped according to the GolfScript double-quoted string escaping rules).

* Any file that does not include the string `<?` is a PHP quine, but no such quine is payload-capable (as they'd have to include `<?` to execute the payload).

* `open+0;print<0>` is a payload-capable Perl quine, although it "cheats" by reading its own source code. 

*Notes:*

This definition deliberately focuses on a single aspect, the ability to carry out arbitrary computation as part of the quine. It does not even attempt to rule out other types of "improper" quines, such as those that read their own source code or that use string eval. If one would like to exclude such, one might require e.g. that:

> "Solutions must be [payload-capable](http://meta.codegolf.stackexchange.com/a/4924), and must not read their source code or use string eval."

(Tangentially, as a fair warning, `{".~"}.~` is still a valid payload-capable quine even if string eval is forbidden, as is `function q(){return q+";q()"};q()` in JavaScript; both simply exploit a convenient language feature that makes functions stringify to their own source code.)

I was tempted to call a payload-capable quine "non-trivial", and those that cannot carry a payload "trivial", but in the end, deliberately chose to use the most literally descriptive and non-loaded term possible. In particular, the term "payload-capable" has the virtue of having no likely alternative interpretations: a person seeing it will either recognize (or guess) what it means, or will have to ask (or Google it, or follow a link, if provided).

Some level of judgement may be required when deciding whether, in the absence of an actual payload, a given quine really does "include all the code necessary to execute a payload". For example, the Perl quine `open+0;print<0>` might require an extra semicolon between itself and the payload, but this is not true for *all* payloads; indeed, for some payloads, it might be optimal to include the payload expression as an extra argument to the `print`.

In any case, the *intent* of this clause is simply to rule out silly and obtuse claims that, say, an empty program should be considered a payload-capable quine in GolfScript, just because the `{".~"}.~` can be added together with the payload. Where there is ambiguity, I would recommend lenience in enforcing this rule.

In any case, by far the best and least subjective way to decide the matter, at least in my personal opinion, is to simply design your challenge to include some extra task, in addition to merely printing out your source code, **that requires an actual payload** to be included. By doing so, any quibbles about whether a given quine is really payload-capable, or what counts as necessary code to execute a payload, are eliminated &mdash; any quine that can perform the required extra task *is* payload-capable by definition, and demonstrably includes all the necessary code.