A quick google suggests space leak == memory leak, is that correct?
That's a statement which could apply to a lot of programs...
Whatever it's called/how it occurs exactly, the result is the same: excessive memory usage. This is what most people will notice, and the term "memory leak" is usually used to encompass all the ways in which this can happen.
While the end results are similar, the mechanisms are wildly different, and just because _you_ don't differentiate between them doesn't mean that other people can't, or that it's not a useful distinction.
Imagine you're in a loop, where every iteration you add one to a number.
In C, you increment the number, write it back, and everyone is happy. In Haskell, the number is not incremented then and there, but instead the runtime replaces the value with the unevaluated expression (n+1). The expression is only evaluated when its used. Then the value is replaced with the result of the expression.
If you don't evaluate the expression, though, then the next iteration you get ((n+1)+1). And then (((n+1)+1+1). And so on until you run out of memory and the process falls over.
While this is, technically, just another memory leak, they're distinctive enough to have acquired a different name. (To distinguish from, say, cached data building up in a data structure.)
This is one of the biggest gotchas with Haskell programming, unfortunately; because the program is actually correct it's very hard to debug these. (Note that the author has to rely on trial and error a lot, and gives up completely on the last one. And the author's an experienced Haskell programmer!)
I wouldn't consider it a memory leak* at all, the memory is not lost as it is in a leak, space leaks get cleaned up if they are evaluated before you exhaust memory. Memory leaks are not cleaned up until your process dies. I can cause a 1gb space leak 100k times and it will only ever use 1gb of memory. I cannot do that with a memory leak.
* the literal combination of "memory" and "leak" greatly imply the loss of the memory, as is generally what happens when you describe something as leaking; you lose it. additionally, wikipedia[0] seems to agree that the loss of memory is part of the definition.
Space leaks are an implementation detail. The program may be correct, but not perform well on some particular implementation of the language; it may perform well on a different implementation. To fix the problem, we can either alter the implementation (eg. adding supercompilation, adding fusion rules, performing speculative evaluation, etc.) or we can alter the source code. In either case, the input/output behaviour is the same: we get a different implementation of the same program.