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.
No factories can hold state. It depends on what is needed.
I'd suggest that making is static seems good choice in the first instance - hovewer the moment you try to unittest statics you tend to run into problems.
Steer away until you specifically need them.
No, factory class by default shouldn't be static. Actually, static classes are not welcomed in OOP world since they can also convey some state and therefore introduce global application state. If you need only one factory object to be present, you can control it's creation through singleton pattern.
In case of factory method - it is ok to keep it static (actually there's no other reasonable way to go :)).
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.
I guess that my BlueCarFactory and my RedCarFactory both have a method createCar. It's just common sense to reuse the actual creation method by parameterizing it. One would then create a CarFactory(blue) and a CarFactory(red). This means that the CarFactory object needs a member variable to store the color of the produced cars.
Concluding: it makes no sense to make the method of a Factory class static. It does make sense to create a singleton Factory object.