Slashdot Mirror


Should Dual Cores Require Dual Licenses?

sebFlyte writes "The multi-core debate continues. HP and Intel have laid into Oracle and (to a lesser extent) BEA over their their treatment of multi-core processers. Oracle's argument that 'a core is a CPU and therefore you should pay us all your money' isn't a popular one, it would seem. What does Oracle's stubbornness imply for the industry as a whole, with multicore chips coming to the fore so strongly?"

17 of 425 comments (clear)

  1. Wait... I thought it was $/user?!? by ka9dgx · · Score: 4, Interesting
    The ad on the back of the trade magazine I read said $149/user. Do I get a clone of myself when I use a dual processor machine?

    Let them be stupid...the market will correct them.

    --Mike--

  2. makes no sense by bird603568 · · Score: 3, Interesting

    i just hope that isp's dont start charging double if you have multiple computers connected to the same connection. just like the software, your not paying per processor, its buy machine.

  3. That's mainframe thinking... by Dinosaur+Neil · · Score: 5, Interesting

    This is sort of scam is used on pricing for mainframes all the time. One place where I worked used this as an excuse to (finally!) dump some crappy and archaic Computer Associates products when they started charging us double for a dual processor, even though one processor was partitioned to another OS that didn't run any of their products.

    --
    "I'm a scientist! I don't think, I observe!" - Dr. Clayton Forrester
  4. Not all companies have that policy by hckn · · Score: 2, Interesting

    The company that I work for has never had that policy. We have products for AIX, Linux and Solaris; while we charge per processor, it's never been our policy to charge per core. We had to tweak things recently for our Linux products to understand about multi-core processors. Before we did that, we'd issue the users licenses that would be double the number of processors if they were using hyperthreading.

  5. Re:As long as.... by servoled · · Score: 3, Interesting

    Where they are sold is completely irrelevant. I think its more a question of how the chips are marketed (i.e. how does Intel/AMD define them) and to a greater extent how they interact with the OS. If the OS treats them as two individual processors then Oracle probably has a case. Someone with more of a CS background can probably shed more light on this area.

    Also remember that you are entering into a contract with Oracle when you purchase their software. Oracle can define the terms of that contract however they want. If they want to start charging "per core" there is no reason why they can't. On the other hand, if you don't like the terms of their contract you can always find a new database to run things off of.

    --
    "I have a porkchop, you have a porkchop. I have a veal, you have a veal".
  6. Portable code solves this problem by Decaff · · Score: 5, Interesting

    Oracle's stubborness says, time to start looking at DB2.

    Absolutely. But how many can easily switch?

    For a long time I have had (occasionally heated) arguments with SQL addicts who insist that almost everything about an application should be coded in SQL and stored procedures. Meanwhile I have been moving all my logic away from the database engine, using APIs such as Java Data Objects, which makes my code very rapidly portable between databases. Now I am in a position to switch my code (and data) easily between different database vendors if there is a licensing or price issue.

    I strongly believe we should start to think of databases simply as engines for storing and retrieving inter-related objects and not as platforms for writing applications.

    1. Re:Portable code solves this problem by Decaff · · Score: 5, Interesting

      Whereas for my part I am absolutely sick of dealing with software that does not perform well on ANY platform and cannot be moved rapidly to a new technology.

      Me too. That is why I use Java+JDO, and not DB-specific SQL.

      Too bad they don't support the neato language where we put the business logic.

      Good point. Show me a platform that does not support Java. I would rather have the logic there than in some neato DB language that has to be ported, at great expense.

      whereas if the business logic had been stored in the database, reimplemention would be a few weeks work.

      A few weeks work? Have you actually worked on such a re-implementation? This is nonsense. A moderate project can take months, and a large scale project years, especially on a live system. I know this from personal experience.

      and the result will be 2 systems each faster, more scalable, and more secure than your portable system.

      This is simply a statement with no foundation.

      There are no security, scalability or speed issues with the system I use - JDO. It is designed to be secure and scalable, to work at high performance on clustered systems and to generate optimal SQL for each version of major databases. Large corporations use it for this purpose.

      Which doesn't even touch on the topic of data integrity...

      Why should the matter of data integrity be relevant? Systems like JDO and Hibernate and Toplink fully support all aspects of transactions, clustering and cache management. Data integrity is, of course, not an issue. If it were, these products would not be so widely and successfully used in critical projects.

  7. Oracle is asking for it... by keeboo · · Score: 2, Interesting

    What does Oracle's stubbornness imply for the industry as a whole, with multicore chips coming to the fore so strongly?

    I can't say about the whole thing... What I do know is that because Oracle inflexibility, high pricing and intrusive license-checking they will certainly lose clients on the long run.

    And it's not just about multi-core processors...
    Let me give an example:

    I do work in a Federal University in Brazil, and we don't have exacly much money available.
    Several months ago we bought a 4-CPU Sun E450 and we were going to pay for an Oracle license accordingly to that machine (a MHz-based license), it was just a matter of waiting the money to come for that.
    In the meantime, Oracle decided to change the license so it's now based on the number of CPUs. When FINALLY the money arrived and we noticed the money wouldn't be enough anymore.
    In the end we've got a 1-CPU license and we had to physically remove the other 3 CPUs from the machine.

    Because of this and many other things (like a license-monitoring software from Oracle we HAD to install, as if we were some sort of criminals) we're now planning the migration to PostgreSQL and never again to use Oracle.

  8. Re:Kinda torn by Builder · · Score: 4, Interesting

    Exqueeze me please?

    Everything I've read so far says that two separate chips will give better performance than a dual core at the same clock speeds.

    So if you have a dual Xeon 3.6Ghz, you're likely to get better performance than a machine with a single dual core 3.6Ghz.

    This comes down to cores having to wait for access to resources, etc.

    This is why I don't like the dual core == dual licence scheme. I'm _NOT_ getting twice the performance as with a single chip, but I have to pay twice.

    In fact, this is something that makes Fujitsu servers attractive as competition for Sun. You can get equivalent performance to a dual core Sun Sparc IV 1.25Ghz with a single 1.8Ghz Fujitsu Sparc processor. Those clock speeds might be slightly out, but find the nearest :) So not only are you getting the processor cheaper, you're HALVING your licence costs.

    Remember, it's not just a few players in the enterprise market that licence like this. Veritas, Oracle, HP Openview, Websphere MQ, they all do this. So if you can get the same performance from a single core CPU as you can from a dual core, halving your licence costs can be a big deal!

  9. Makes more sense than per chip or per core by frovingslosh · · Score: 4, Interesting
    Although there are still issues about what makes a machine when there is a very tightly coupled network, this actually makes the most sense. After all, the major flaw in the per CPU (chip) but not per core argument is that it allows some companies (Intel, for example) to put multiple processors into a machine that only needs one license, but prevents another company (Asus, for example) to build a motherboard (machine) that takes multiple processors by acomplish the exact same end. By what logic should an Intel motherboard running one Intel chip but containing four complete core processors pay a lower licensing fee that an Asus motherboiard with (for example) two AMD cores, each one on it's own chip, for a total of only two cores?

    And it can hardly be argued that it's an issue of chip count, what if I were to take a dozen or more chips (PLAs, slice processors, and other exotic devices) and from these build up a single 386 class CPU? Clearly such a device would only require one license to run software, even though it was made of multiple chips. And since there are already court rulings that instruction sets can not be copyrighted, it is clearly my right to build such a device and software vendors would have no valid reason to keep me from legally buying copies of their software and running it on my creation.

    One should also consider that my "single core" desktop computer actually contains at least two significant processors, the CPU and the graphics card (which may very well have more processing power than the CPU). While software like Oracle doesn't take advantage of the processing power of the graphics processor today, if some sophisticated user were to enhance his OS such that some improvements were made that could take some small advantage of the processing power of the graphics card, would this somehow change the processor count as far as Oracle was concerned?

    If a 386 computer with a 387 co-processor counts as only one CPU, shouldn't I be able to designate one of two Athlon processors on my dual CPU motherboard as a "co-processor" and pay for only one machine? Sure, each of the Athlon processors is far more powerful that the 396 and 397 combined, but that's not the issue. And if chip count is the issue then the 386 and 387 certainly use as many or more chips (and more support chips).

    --
    I'm an American. I love this country and the freedoms that we used to have.
  10. Re:Cell processors by Too+Much+Noise · · Score: 2, Interesting

    Nevermid Cell, that's not going to show in big db servers soon enough. What about Sun's Niagara? if you have some 32 cores in your server, one Oracle license for each is going to be huge.

    Maybe that's why Sun is hinting at its own db? to try and push "per-core" db vendors to change the tune?

  11. Re:Kinda torn by hackstraw · · Score: 2, Interesting

    so why not charge based on clock rate?

    I guess your not familiar with Oracle licenses? They do charge by clock rate and a different rate depending on the type of processor. If its a regular x86 proc the multiplier is 1x, if its something like a RISC chip, its 2x the clock rate.

  12. Re:Competition by kokoloko · · Score: 2, Interesting

    The seemingly quaint idea of "fairness" still has some currency in this world, believe it or not.

    It would be bizarre if humans being stopped reflecting on such things.

  13. Re:There _Are_ Other DBMS's by sploo22 · · Score: 3, Interesting

    YOU DO NOT HAVE TO AGREE TO THE GPL TO USE FREE SOFTWARE.

    It drives me crazy when I see the GPL text and the "I Agree" button on the installer for a GPL'd program. The GPL is a copyright and patent license, NOT a license to use the program. You have the right to use it, whether you agree or not. The only thing that you should need to agree to is a warranty disclaimer.

    --
    Karma: Segmentation fault (tried to dereference a null post)
  14. Re:There _Are_ Other DBMS's by yem · · Score: 2, Interesting

    Just curious - what datawarehouse features is it missing? I wrote a small DW app for work to pull transation data from a dozen remote databases and consolidate into one nice clean schema in pgsql. Currently it has around 6Gb of data. I didn't miss any features, but then I'm not a DW expert.

    What special features would help pgsql compete here?

    --
    No, I did not read the f***ing article!
  15. Two issues by SJS · · Score: 2, Interesting

    There are two issues here, not one.

    First, should a multi-core processor chip count as more than one CPU. Second, should software be licensed on a per-CPU basis.

    I think it's obvious that a multi-core processor chip should count as multiple CPUs. Arguments otherwise seem to equate a "chip" and "CPU", something laughably oversimplified. You can have "processors" that involve no chips at all (remember TTL "CPU boards"?), or that are made up of dozens of chips -- so there is really no inherent relation between "processor" and "chip".

    Put a dual-core chip, or a quad-core chip, into your machine, and you have to deal with the same issues as a dual-processor or quad-processor machine.

    [I would love to see how many 6502s or 6800s could fit in the space of a "modern CPU" die, possibly with some RAM on-chip for each "core". Play the games with clock speed on top of all that, and it might be something quite interesting to program for.]

    The second issue is harder, and shouldn't be allowed to influence the definition of what is or is not a "CPU". If you don't agree with per-CPU licenses, then don't fudge the definition of "CPU", rail against the real grip: per-CPU licenses. If you do claim to agree with per-CPU licenses but are too cheap to actually PAY them once you get a machine with multiple CPUs, stop trying to muddy the water by claiming your multiple-CPU machine really isn't a multiple-CPU machine.

    If your concern is that *all* new machines will eventually end up as multiple-CPU machines, that's yet another legitimate concern, but if you chase the bleeding edge, you're going to bleed. Don't pretend to be suprised by it.

    Personally, I don't much care for multiple-CPU licenses. I'd rather deal with a per-machine, per-user, per-organization, or site license. But not all businesses want to play that game, and that's okay, so long as there's always an alternative.

    --
    Pick One: http://www-rohan.sdsu.edu/~stremler/sigs/sigs.html (Note - disable Javascript first!)
  16. Re:There _Are_ Other DBMS's by Anne+Thwacks · · Score: 3, Interesting
    Would you trust PostgreSQL for a high-volume high-turnover commercial project

    Would you put your business's future in the hands of Larry Ellison?

    My high volume business IS using PostgreSQl. The money not paid to Oracle (part) funds a programmer. One day, some money will even go to the PostgreSQL project.

    Oracle has shafted me twice. I won't risk a third time.

    --
    Sent from my ASR33 using ASCII