It's common place for factory classes to be static, and factory methods to be static also.
Did the GOF in the Design Patterns book ever stipulate that factories and their methods MUST be static in order to meet the strict definition of the pattern?
Is having factories+/methods static just a consequence of the pattern? state data is not normally maintained by the factory class, so they're normally static.
I don't believe there is such a thing as a "strict definition" of a pattern. By their nature patterns exist to capture the essence of a problem which crops up time and time again in software and outline how a solution might look.
Specifically with the Factory pattern, no, there is no requirement that the factory methods be static. The essence of the pattern is that you have one object which is responsible for creating instances of another class. How you do this is really up to you, although a common way, as described in the pattern, is to use a static method on a class. However, we have a factory mechanism in one of our systems which is actually two-stage. You use a static method on a class to create the factory object, which can be configured to choose amongst a set of implementations, and then use the factory object to stamp out instances of the object that you need to do the real work.
Also consider the implementation of the factory pattern in a language which does not have static methods. For example, in Scala you would use an object instead of a class. Although the behaviour of this is a lot like using static methods on a class in Java, the nature of the implementation is quite different.