XP is a collection of practices and principles. One of the principles is not to expend effort on a complete design before beginning construction of the system. If you consider only this one aspect of XP, then you might well describe XP as a "licence to hack."
But XP advocates much more than this one principle. Other XP practices work in conjunction with rapid, iterative, incremental implementations of a system to circumscribe the "licence to hack". (XP is a collection of principles and practices; it is not a methodology and does not dictate specifically how things should be done. So there can be variation in how different groups adopt XP. So anything below that sounds like a dictum of XP should be read as an example of an XP principle.)
One XP practice outlaws working beyond a normal work day/week. (Ok, so just hack during working hours.) Additionally, all coding is done in pairs. This does not preclude hacking, but does mean another member of the development team is working with you as you evolve your design and develop your code -- following your line of thought and your design decisions, asking questions and suggesting alternatives as the work progresses. Further, XP says that you always build unit tests for your classes. These are not practices I associate with "just hacking," but maybe you know more disciplined hackers than I do.
XP also says that you should "refactor mercilessly." One aspect of that is that when you need to extend a class, and the class implementation does not readily admit your extension, rather than "just add something that will work for now," you refactor the class so that your extension fits easily and naturally.
Because XP teams practice "collective code ownership," everyone can see everyone elses code. So if someone violates the team coding standard, that is obvious. If someone builds a bad abstraction, everyone is free to see it, discuss it, and refactor it. (Although the code is "owned collectively," that does not mean that the team doesn't discuss changes and use a source code management system. It just means that no code is hidden, and no one person is a procedural bottle-neck to fixing code that needs fixing or enhancing. One of the fundamental principles of XP is communication. So, of course, the team is expected to let each other know about significant changes and refactorings they make along the way.)
Earlier notes in this thread suggested that the practice of a continually evolving design might be considered to emphasize design, rather than deemphasize it. Good point! A key point about refactoring is that you are not randomly reimplementing a class. You are making incremental improvements to enhance the clarity and structure of your classes. Hacking says you never go back to fix something with more than chewing gum and duct tape. XP says that you refactor and clean it up when you need to fix it. One of the benefits of pair programming is that, while you might do the chewing-gum it if working alone late at night, working with a co-worker in broad daylight may encourage you to respect the agreed-upon team practices.
So, is XP a "license to hack"? Well, if by hacking you mean pair programming, building unit tests, continuously improving the design of your individual classes and your program, always trying to keep your code as simple as possible, and refactoring (at least a little) when you encounter existing code that is no longer clean and simple, then you can say XP is a "licence to hack".