Yes, I got that. I didn't feel that the "alternative definition" was offered disingenuously, but it's still a problem when you want to have a discussion and you use certain commonly accepted terms, but with a different definition in mind. Imagine if I talked about "democracy" and in my mind I meant "The Athenian model that only allowed men over the age of 30 to vote", when everybody else was talking about, well, democracy.
In case you're not familiar with the book (i.e. "M. Feathers, 2004. Working effectively with legacy code."), it is a classic and widely regarded as "The" book on how to approach legacy codebases (even if a bit dated by now). A highly recommended read. It was also very enjoyable to read, which is remarkable for an otherwise technically-oriented book. Here is the relevant except from the introduction, defining what legacy code is and why it's a problem:
> In a strict sense, Legacy code is simply code you've gotten from someone else. However, clean, easy to work-with code is rarely referred to as 'legacy' code; the term usually implies a tangled, unintelligible structure, difficult-to-change code that is difficult to really understand. Therefore, a more pertinent description is:
>
> Legacy code is where any of the following questions fail to apply:
>
> - Is your code easy to change?
> - Can you get nearly instantaneous feedback when you do change it?
> - Do you understand it?
>
> If the answer to any of these questions is no, you have legacy code, and it is draining time and money away from your development efforts.
Further down, he offers this simpler, provocative definition, which introduces the main theme of the book:
> Legacy code is code without tests: Code without tests is bad code. It doesn’t matter how well written it is; it doesn’t matter how pretty or object-oriented or well-encapsulated it is. With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don’t know if our code is getting better or worse.
In a more modern setting, presumably 'tests' would be extended to include other good software engineering practices, like version control, CI, etc. But the book's theme still applies in the more general since, so it's still relevant today. If you've not read it, then pick a copy up, you're in for a treat :)