Pick any book with has the name Lisp on it, take example code and try to run it in Cloure.

Chance that it does not work is high.

Now change the code that it runs. Chance that you had to rewrite the code mostly is high.

It's a dialect of Lisp in the sense that it is an incompatible branch / fork with a Java runtime (it's a hosted language) and a bunch of newer functional data structures replacing old-fashioned lower-level stuff from Lisp.

Take Lisp code written in the last 50 years and odds are that Common Lisp, Emacs Lisp or Scheme can run it with zero/minimal/moderate modifications.

Clojure needs a total and complete rewrite which doesn't only affect the syntax but program logic. Thus Clojure does not run Lisp code. How can it be a Lisp when it does not run Lisp code?

I've actually ported some Clojure code to Common Lisp no later than two weeks ago and it was pretty much as straightforward (if not more) as porting R5RS to CL. In my (admittedly limited) experience both CL and Clojure favor a certain high-level coding style with complicated macros versus the more simplistic style of Scheme. Contrast CL's loop construct, Clojure's for statement and Scheme's typically more recursive approach to iteration.

You're welcome to draw the line wherever you want, maybe for you conses are mandatory in a Lisp language but I don't really understand what you hope to gain from this discussion. I might as well say "tail call optimization is absolutely mandatory in any self-respecting Lisp, therefore CL isn't a proper Lisp dialect".

This is effectively the same level of discussion as a Java programmer saying that C++ isn't "true OOP" or an Haskell enthusiast claiming that Scheme isn't a true functional language because it allows side-effects. It's just silly gatekeeping that doesn't lead anywhere interesting.

The chance that you can port code without actually rewriting it is pretty slim. But then, people have been rewriting Lisp code to run in C++.

If you want TCO in CL then use one of the dozen implementations which supports it.

People btw. used to write some non-trivial code which ran in both Scheme and CL with the help of a Scheme on top CL, a compatibility layer or a translator. But that's now relatively rare.

But C++ in fact isn't true OOP (and neither is Java), and Scheme isn't a functional language.

This argument only works if you think of "Lisp" as a single, linearly developing language. It hasn't been that for decades. (That's why they created "Common" Lisp, after all.)

Lisp is a family of languages - within which Scheme and CL are just as syntactically incompatible as CL and Clojure.

CL was created such that it is compatible with a main line of Lisp dialects (those btw. have usually Lisp in their name) -> Lisp 1, Lisp 1.5, MacLisp, ZetaLisp then Common Lisp.

Other Lisps in that main line are Portable Standard Lisp, Le-Lisp, Emacs Lisp, ISLisp, ...

There are quite a few branches with less (Scheme) or more incompatible languages (ML, Dylan, Clojure, ...).