Many vendors (including Oracle and Microsoft) have previously only licensed 'Processors' in the past. Neither of them had any detailed definition that went on about the details about what is to be seen as a 'Processor'. Only once the MCM/Multicore phenomenon started to arise around 2004/2005, people started thinking what it could mean for their licensing agreements. This is what each vendor did:
Microsoft: Stated they will regard multicore processors as one Processor, in terms of licensing. They will only look at the physical processor that fits the socked: 1 Socket is for 1 processor. Oracle: Always preached that the 'Processor' in the existing definition was already to be regarded as a separate 'Core'.
Result: So for Dual-Core processors, Microsoft clients would pay one Processor license, while Oracle made clients pay twice (this has since been changed, and nowdays Oracle has their own core-counting methods). My point is that both Oracle and Microsoft clients had different interpretations to the same definition.
Question: What seems to be the fairest way to you to count the amount of Processors licenses required in regard to multicore/MCM's, when one only taking the word "Processor" as a baseline for the outcome? Microsoft's approach or Oracle's approach? And: Why?
Right now, the consensus is that each unique Die will be classified as a unique processor. With core counts expected to rise fairly quickly, unless you wanted to license out software to customers multiple (soon to be 6x) times, theres really no other interpretation that makes any financial sense for anyone.
Yep, definitely go with sockets. By saying it's based on "dies" you stifle the demand of MCM chips, which may cause AMD/Intel/ARM manufacturer's to avoid MCM as the demand is lower (if people have to pay double for software, MCM chips will be less desirable). That stifles innovation, and that's bad.