Dual-core Processors Challenge Licensing Models

ffub writes "Changes in hardware (such as dual-core processors and virtualisation) are making software licensing increasingly difficult for software firms. Companies still prefer the per-seat one-off license, while subscription models are favoured with software firms. But neither model reflects well the way software is used these days. The Economist looks at the situation and briefly touches on how Open Source could benefit from the muddle."

Comments

Maybe

[BHearsum]

Maybe this will get rid of licensing models that are 'per cpu'. I've never understood the logic in charging per CPU, anyone care to explain? One computer, one license. Or even better, no licenses.

Re:Maybe

[ForumTroll]

My feelings exactly, for the vast majority of software I really can't see why they would charge based on the number of CPUs used. Especially since dual core etc. is going to become so common in the next few years.

Re:Maybe

[BHearsum]

To me, it's like charging the driver of a larger car more to renew his plates, than the owner of a compact car. It doesn't make any sense.

Re:Maybe

[inode_buddha]

I would bet that the "per CPU" license model dates back to a time when CPU's were much more expensive; it could reasonably be assumed that there would be many users using one CPU. In other words, the business model is a couple of decades behind the technology.

Re:Maybe

[Anonymous Coward]

To me, it's like charging the driver of a larger car more to renew his plates, than the owner of a compact car. It doesn't make any sense.

In many jurisdictions, to encourage the population to drive smaller, more fuel efficient vehicles, they do exactly that. The US had a gas guzzler tax (don't know if they still have it) that was a one-time tax if your car didn't get 20 mpg or so.

Re:Maybe

[captaineo]

Rendering software is usually licensed per-CPU. It's a decent model since the number of CPUs in a studio roughly indicates how much it can afford to pay for software :). Though it seems likely that "per CPU" will soon become "per box" or "per OS instance" to avoid splitting hairs over the expanding jungle of multiprocessing technologies.

Re:Maybe

[byteherder]

To me, it's like charging the driver of a larger car more to renew his plates, than the owner of a compact car. It doesn't make any sense.

Most states charge based on the value of the car. This makes no sense other than trying to stick it to the rich. If you have a expensive compact car, you could pay more than someone with a inexpensive but larger car.

Charging based on weight makes more sense. The heavier the vehicle the more damage it does to the roadway. Thus larger cars should pay more, they cause more maintance to have to be done to the roads.

Re:Maybe

[sykjoke]

The more CPU's you have the more concurrent operations you can perform. With one CPU you can only ever process one task at a time, with Four CPU's you can process four tasks at one time, as if you had installed the software on four separate servers. Per CPU seems a lot more logical than per connection licensing.

Re:Maybe

[camcorder]

Well easy, Profit! We should be thankful they don't change per transistor basis.

Re:Maybe

[Tim C]

I'd imagine that it's partly due to how much harder it is to write good multi-threaded code that scales well with increasing numbers of CPUs.

Yes, you're running the same code whether you have 1 CPU or 8, but if you do have more than one then you're actually benefiting from the additional effort (design, development, testing, etc). I imagine that the rationale is that it was harder and more expensive to write, why not charge more for it?

On top of that, the vast majority of multi-CPU users are business users, which tend to have more money and be prepared to spend it; you charge what the market will bear.

Re:Maybe

[nurb432]

I think it was more to get around the fact you could use one 'licensed seat' to access your application, but have 100's of people route thru that single seat. So they 'lose' revenue.

This way they can stick you for 'expected load'.

Remember too that once upon a time you were charged for use of that cpu TIME, not just a flat charge for access to it.. ( actually some of the big iron licenses is still based on a per cycle fee.. )

Re:Maybe

[Daniel Dvorkin]

No, it's the other way around; if you have many users on one CPU, charging per CPU makes no sense (unless you charge a lot.) The idea, of course, is for the software company to maximize its revenue, so by charging per CPU for big multiprocessor systems built on cheap commodity processors (which, of course, describes the majority of server setups these days) they can make more money. The justification (other than "we want more money") is that roughly, they expect the number of CPU's to scale with the number of users.

Re:Maybe

[S.O.B.]

Servers come in configurations of single up to 8 or even 16-way processors. Is it fair that a company with a server that has a single processor serving 100 users pays the same as a company that has a server with an 8-way processor serving 1000 users.

Per CPU licensing was a simple metric that allowed software companies to scale their pricing so that it was fair to both the entry level and high end customers.

As the article points out multi core processors are the processor companies' way of increasing performance without having to increase the clock speed and therefore keep temperatures down. Since software companies didn't care about the performance of a given processor, just how many you had, they shouldn't arbitrarily change the licensing model.

At the company I work for I know that because of the per CPU model we intentionally bought servers with fewer faster processors. Even though in most cases those servers were more expensive than machines with more processors the amount we saved on licensing costs more than made up for the additional hardware costs.

I suspect that in the end they'll end up with more of a performance based model similar to the MIP based licensing model on mainframes.

Re:Maybe

[Rich0]

The problem with per-computer licensing is that it encourages a company to just create one massive 500-processor computer and use VMWare to run all their software on that one computer. Then a 50,000-employee company only needs 1 license for their entire company.

You can't just charge a fortunate for 1 license, since then nobody would ever start using your software, since most software tends to get piloted with small groups before working its way up to enterprise scale.

I always thought a concurrant-user model would work better, although for a database that gets murky.

Of course, the open source model is nice since you aren't charging a dime for anything and hence you don't need to fight out how to charge for your product... :)

Re:Maybe

[fa2k]

define: "computer"?

Re:Maybe

[sznupi]

Actually, basing it on weight would be also flawed a little. A car, according to law, can weight max 3,5 tonnes (here of course; if it's heavier then than it's classified differently (some would probably say it's SUV...), you need "better" license to drive it and...taxes are higher (quite the opposite tha with SUVs, huh?)). However for a road 3t makes almost no difference in comparison with 1,5. But a 15 or 25t truck...
So in case of vehicles used for cargo this makes sense...not for cars IMHO.

Here it's all based on size of the engine (and how old the car is, if you're buying it). Not sure if I could come up with something better...

Re:Maybe

[Uber Banker]

The problem with per-computer licensing is that it encourages a company to just create one massive 500-processor computer

They've not seen my penchant for circular references, clearly!

Re:Maybe

[karmatic]

"Is it fair that a company with a server that has a single processor serving 100 users pays the same as a company that has a server with an 8-way processor serving 1000 users."

Yes. When buying something, the fact that someone got a better deal than you is not "unfair", it's simply business. You can always try to use that as leverage while purchasing, but that still doesn't change the fact that what you pay is between you and the seller.

Is it fair that there are people out there who paid less for the exact same model car you drive? Of course it is! I'd imagine some of them probably use it in about the same manner, too. That doesn't mean you were ripped off, it just means they managed to get a better deal.

Re:Maybe

[Jeff DeMaagd]

The problem is that multi-processor app scaling isn't easy, and the people to pay for that development should be the people that use multiple processors, hence, per-CPU licencing.

If multi-processor coding were easy, wouldn't there be a lot more such programs?

Re:Maybe

[NuclearRampage]

From that standpoint the licensing should be based on users, not the CPU. What if the multiple CPU's the 1000 person company were 4 1 GHz CPU's and the CPU the 100 person company had was a 4 GHz. They could just as easily spend less on a single CPU license and serve just as many users. In this case the smaller company ends up with a better deal just by having better hardware.

Re:Maybe

[TheCaptain]

Or even better, no licenses.

That is a really oversimplified and dangerous line of thought, IMHO. Even Linux and BSD have licenses...

Re:Maybe

[Chris Snook]

MIPS based licensing is feasible when the software vendor knows that there's one vendor delivering all the hardware components, and can use their authoritative performane data. When you've got interchangeable commodity components from several vendors, and these components are themselves assembled on the circuit boards from interchangeable commodity chips from several other vendors, it's a nightmare.

Re:Maybe

[Creepy Crawler]

Person who computes ;-P

Re:Maybe

[Spoing]

Maybe this will get rid of licensing models that are 'per cpu'. I've never understood the logic in charging per CPU, anyone care to explain? One computer, one license. Or even better, no licenses.

Where do you draw the boarders between one 'computer' and another?

If the licence were based on a per-metal-box basis, some clever folks would buy systems that are really clusters but are contained in a single box. Good for them, though it causes problems if you are the seller and supporter of the sofware.

Re:Maybe

[IntlHarvester]

Per CPU licensing was a simple metric that allowed software companies to scale their pricing so that it was fair to both the entry level and high end customers.

Which works as long as the hardware companies scale their prices with # of CPUs. Historically, going from 2 CPUs to 4 often quadrupled the price of a server, and going to 8 quadrupled it again.

The issue is that Intel and AMD are currently breaking this model. There isn't a substantial price difference between today's dual core system and yesterday's single core. But yet some software costs have doubled.

It's only a year or so until even laptops have dual-core chips, and $3000 Xeon/Opteron servers have chips with 4 or more cores. The whole assumption that 4 CPUs = Big Expensive System is going to have to change.

Re:Maybe

[S.O.B.]

So you agree that it's OK for the seller to charge different amounts to different users based on a negotiation.

Well, performance based licensing allows companies to do just that without having to go through the negotiation. The price is stated up front rather than hidden behind closed doors.

Also, performance based licensing allows even the smallest mom and pop shop, who likely can't afford a professional negotiator, to use the same software as multi-billion companies.

Using your car analogy, people pay more for higher performance vehicles. If you want to haul a 30 foot trailer you buy a truck. But if all you need is to drive to the local grocery store then all you may need is a Honda Civic. In the real world you can't turn that Honda Civic into a Ford F-350. In the virtual world you can, hence performance based pricing.

Re:Maybe

[InvalidError]

Per-socket seems like the fairest for those who insist on per-core or similar licensing.

No matter how many cores or CMT/SMT virtual cores each core has, overall performance is ultimately bound by IO bandwidth and latency. Once a CPU's IO is maxed out, it no longer matters performance-wise how many cores/threads it has, any further processing power will be spent executing NOPs while waiting after IOs. With NUMA architectures (like Opterons), potential IO bandwidth scales (roughly) with the number of CPUs so application throughput can scale more smoothly.

In Intel's case though, the Xeons's shared bus makes multicore MP fairly uninteresting. Per-socket licenses halve licensing costs (or even quarter if a socket license replaces an execution unit (per HT/SMT thread) license) but the shared bus significantly compromises scalability.

Re:Maybe

[S.O.B.]

User based licensing could work as well but it adds to the complexity of the code potentially increasing the number of bugs and creates an administrative hassle for the customer.

In the past, per CPU licensing worked because as a measure of the work a given machine was capable of it was a crude but relatively accurate measure. Now with hyper-threading and multi-core CPUs it's not as accurate.

I don't think software companies will switch to a flat rate licensing but I do think performance based licensing isn't too far off. In your example, using a performance based licensing the two companes would pay the same.

Re:Maybe

[S.O.B.]

I agree MIPs based licensing isn't perfect either but I think you'll agree it's better than CPU based. A 1 Ghz P3 is nowhere near as powerful as a 3 Ghz P4 but under the current scheme a license would cost the same.

I agree that servers with identical CPUs from two different venders can have slightly different performance but they won't deviate too far from each other. An industry standard CPU spec should allow vendors to compare the relative performace of different CPUs and price their software accordingly. Mainframe vendors have been doing it for years.

Re:Maybe

[S.O.B.]

I agree totally. I don't think it'll be too long before we have performance based licensing. Likely the day after the first customer realizes that he has to buy 16 licences for the shiny new 8-way Pentium-D server they just bought and threatens to go to a different vendor.

Re:Maybe

[jd]

The distinction is highly artificial. For example, it would be perfectly possible to modify OpenMOSIX to be totally transparent, so that your 65535-node cluster appeared as a single virtual computer. Now, is it one computer or 65535?

(This requires all resources, all of memory, everything to be directly addressable from every node, which is getting closer with DSM and the Plan9 filing system.)

Per CPU makes some sort of sense in clusters and grids, as the more CPUs you have, the more powerful the system, the more users can be served, etc. Clusters and grids are a real problem with licensing models - on the one hand, the computing power has obviously gone up, so for CPU-intensive applications, there is an obvious gain in running more CPUs. On the other hand, the increase in power is non-uniform, increasingly difficult to determine (is hyper-threading one CPU or many, as it is a parallel architecture?) and very difficult to quantify (think: distributed.net).

Licensing per instance (a-la the bookware licence of Borland's) would seem the obvious solution as that is architecture-independent. However, the lack of other examples of companies using it suggests that it is not popular with software vendors.

Multi-core has been around with the UltraSPARC for a while - I believe the UltraSPARC is up to 6 CPUs on a die - so I guess that companies are going to take Sun's lead on this issue.

Re:Maybe

[donny77]

Per user licensing breaks down when you throw it on a webserver. Should Slashdot have to pay for 1 million licenses since there are 1 million people who come to this site? Better yet, how do you know there are 1 million people that come to this site. How do you differentiate one AC from another? What if I have two logins and use whichever I feel like?

If you can't determine the number of users on a webserver, or if webserver users aren't counted, then the company ports all apps to web based javascript/php/asp and buys one license for the whole company.

Re:Maybe

[Jasin Natael]

The logic is that if you have a more powerful machine, you're able to serve up more customers with less hardware. Companies assume that you'll buy the fastest (or near-fastest) processors to acheive that. In theory, the software is being used to serve your business needs relating to x consumers, in direct proportion to the state of computing today. However, if you buy an SMP box, you're effectively "cheating" (i.e., jumping ahead of Moore's curve) by getting a product that will serve x * 1.387 or somesuch number of customers, so they artificially penalize you for it.

It's a bunch of crap. If these companies really charged you the way they want to, you'd pay a rental fee based on the maximum capacity of your server -- they'd send out some asshole to benchmark your system running their software and based on the horsepower of the machine, they'd charge you a proportionate amount of money. If you upgraded, it'd phone home and need re-calibrating so you could pay the additional licensing charge. IMO, it's extortion -- they're saying that they want a percentage of your profits, rather than just selling you a product.

Jasin Natael

Re: Maybe

[gidds]

Where do you draw the boarders between one 'computer' and another?

Well, I've never been known for my artistic skills, but if I had to, I'd probably choose to draw them waiting outside the headmaster's office. In a corridor with good lighting. And maybe a dictionary.

Re:Maybe

[Chris Snook]

If you're supporting your product, encouraging your customers to run on more modern hardware is usually a very good thing. Even if you're doing per-incident support, performance-related problems will take far more resources to solve than your average case, so you're probably losing money on that too. I guess it works if you're selling them by-the-hour consulting though.

In any case, there are a whole lot of things that mainframe vendors have been doing for years that aren't a particularly good idea, but every time they want to change anything qualitative or remove something, their customers pummel them with suitcases full of $100 bills until they agree to leave things exactly how they've been for a decade or two.

Commodity hardware vendors are much more likely to be struck with rocks than suitcases full of $100 bills.

Re:Maybe

[S.O.B.]

In any case, there are a whole lot of things that mainframe vendors have been doing for years that aren't a particularly good idea, but every time they want to change anything qualitative or remove something, their customers pummel them with suitcases full of $100 bills until they agree to leave things exactly how they've been for a decade or two.

I didn't mention mainframe vendors in order to suggest that they are doing it better. I merely meant to suggest that they are already doing MIP based pricing so it's an approach that has a fair amount of history and practice.

I've been working in a mainframe shop for almost 20 years now and I've never seen a situation like the one you've described. Quite the opposite, in that time I've seen it evolve dramatically into a super server that can do anything that a regular server can do (email/groupware, web services, enterprise Java, DBMS, transaction processing, Linux in a VM) but with a stability and scalability that few platforms can match.

Sure there are products that reach their end of life and the vendor drops support but that's life in IT no matter what the platform. You do what you have to do and move on.

Re:Maybe

[Stankatz]

Per CPU licensing was a simple metric that allowed software companies to scale their pricing so that it was fair to both the entry level and high end customers.

It may be good for business, but I wouldn't exactly say it's fair. If you came up to a lemonade stand that sold lemonade for $0.50 per glass with a friend and they charged you $1 for a glass because they assumed you were going to share, would you call that fair. I think if you get the same software, you should pay the same price.

Re:Maybe

[SJ]

Is it fair that a company with a server that has a single processor serving 100 users pays the same as a company that has a server with an 8-way processor serving 1000 users.

Is it fair that a large company pays an artificially inflated price to use the software?

Re:Maybe

[S.O.B.]

First of all, if you had read the post I was responding to you would see that I did not pick the car analogy so it is not my analogy. Next time you may want to read the entire conversation before you jump in.

Secondly, your addition to the analogy is flawed. The price of gas is the same for all vehicles, bigger vehicles just need more.

Current per CPU licensing works the same way. The unit price is the same for all users although bigger machines need to purchase more units just like the F350 needs more gas.

Re:Maybe

[S.O.B.]

The alternative is to have a flat rate per server pricing structure so everyone pays the same amount, right? In that case the software company will likely increase the cost to maintain their income.

Let's say the average server has 4 processors with a cost of $10,000 per CPU. In a flat rate pricing structure they would now have to charge $40,000 for the same software to maintain their income. So the small company that has a single processor machine now has to pay $40,000 instead of the $10,000 they used to pay.

A flat rate pricing model discriminates against the user at the lower end.

A performance based licensing scheme, per CPU licensing being an example, lets anyone at any performance level afford the software. The difficulty is that per CPU pricing is no longer accurate and a new performance measurement needs to be developed.

Re:Maybe

[arakasi]

The idea behind multi-processor licensing stems from the possibility that you could consolidate your servers and thus pay less if you only bought a license per computer. Multi-processor licensing captures the revenue that would other wise be lost.

Re:Maybe

[drsmithy]

Maybe this will get rid of licensing models that are 'per cpu'. I've never understood the logic in charging per CPU, anyone care to explain? One computer, one license. Or even better, no licenses.

Because the easiest way to differentiate between a "high end" (ie: large, critical computer-based business processes, more able and more willing to pay more $$$) and a "low end" (ie: small, business is probably not completely dependent on computers, not a lot of $$$ to throw around) business is the presence of multiprocessor hardware.

Basically it's just a crude way of identifying rich customers from poor customers and charging both as much as possible.

Re:Maybe

[Chris Snook]

I don't question that it's been evolving rapidly. In fact, mainframes seem to be acquiring major new architectural features at an alarming rate, but without retiring any old ones. I've seen *versions* EOL, only to be replaced with something more complicated and faster if and only if expertly configured. Maybe it's just because I work in support and only see the problem cases, but it seems in a lot of these shops which are spending their suitcases full of $100 bills underwriting the impressive engineering decide that the administrators of these systems are so individually critical they can't afford to send them away to train on the new stuff for a week or two, so they can't tolerate losing any of the legacy stuff they already know.

Re:Maybe

[sillybilly]

Licenses are contracts. If they feel like it, they can offer to charge you based on the number of heartbeats you have during a computer game - mandatory pulse monitor wearing required, or the game won't run. If they feel like it, they may may offer to charge you based on which way the wind blows, or the position of stars.
It's your job as a customer to say, you know what, screw you, stick your heart rate monitor up your precious ass, because I'd rather not play under these circumstances. They can offer, nothing wrong with that, but you have to learn how to say no, even when you're addicted.
It becomes a problem when there is a monopoly, and you don't have another supplier to turn to, that will respect you as the customer, instead of dictating you the terms. You can cry foul under such circumstances, and say look, I can't find anybody else.
So what they can do is setup a puppet competitor, that charges more, still, subsidiary of the monopoly, you just can't prove that, and then say, well, here, you have a choice. So what do you do? Now you can't even cry foul.
So you just bend over and touch your toes, and don't keep it tight, cuz the more you fight it, the more it's gonna hurt. Nice and easy. You're getting fucked either way.

Database Licensing and the Web

[inmate]

This won't be the first time that licensing has faced such a crises.

In the early days of the web, I worked on a web-based project which connected to a MS SQL-Server database. The licensing issue was very confusing since the information in the database would be made available to anyone who came to site (and we expected a few hundred regular users), but technically everything would be accessed by through only one account (the webserver!).

I called the local MS office and they confirmed that we only need one licence for this model.
Based on this information, we rewrote a major internal application to be entirely browser based - and then dropped all our seat licences bar one.

Needless to say, MS had a absolute fit!

About a year later we received an incredibly confusing document outlining license-requirements for internet and intranet applications.

Re:Database Licensing and the Web

[blowdart]

There's actually a specific internet connection license for that sort of setup, however it's interesting to note that Microsoft have said, for licensing purposes, dual core CPUs count as a single cpu.

Compare to Oracle; if you buy a licence for a dual core machine, the second core is only counted as .75 of a CPU, as is each succeeding core. However Oracle rounds all numbers up, so .75 = one for licensing, and 1.75 = two, roughly the same cost as if you bought two licences. And so on. It's only a saving if you have 3 dual core cpus or more.

Re:Database Licensing and the Web

[mgv]

There's actually a specific internet connection license for that sort of setup, however it's interesting to note that Microsoft have said, for licensing purposes, dual core CPUs count as a single cpu.

Compare to Oracle; if you buy a licence for a dual core machine, the second core is only counted as .75 of a CPU, as is each succeeding core. However Oracle rounds all numbers up, so .75 = one for licensing, and 1.75 = two, roughly the same cost as if you bought two licences. And so on. It's only a saving if you have 3 dual core cpus or more.

Of course, microsoft used to allow you to have 4 cpu's for windows NT (this was back in the days when dual core stuff hadn't started).

Mostly, this is just about extorting as much money out of a paying customer as they can. If they charged a license per gigahertz of cpu speed, there would be an uproar when your software costs doubled when you upgraded your 1 GHz cpu to a 2GHz cpu.

When you look at it like this, you can see what a contrived concept that charging per core is.

Even if you argue that it takes more to write multithreaded code, that shouldn't make any difference between 2-4 cpu's. And in many cases the program utilisation might never even require that second core.

My 2c

Michael

Re:Database Licensing and the Web

[jZnat]

If they charged a license per gigahertz of cpu speed, there would be an uproar when your software costs doubled when you upgraded your 1 GHz cpu to a 2GHz cpu.

Well, if they did that, that'd be all the more incentive to get an AMD with its high number of clock cycles compared to the Intel equivalent. :P

Re:Database Licensing and the Web

[bill_mcgonigle]

You're in pretty good company from what I've seen. Much of it has to do with the greed of a the database companies.

For instance, I know of an academic institution which used an Oracle database to back a user directory which the e-mail system queried for address resolution. If they had 20,000 e-mail users, Oracle wanted them to buy a 20,000 user license.

So, a proxy was written and the licensing requirements were satisfied. It made financial sense to do so at the time but today the right answer today might just be to use PostgreSQL in a similar situation. There's a point where a company can put itself out of business.

Re:Database Licensing and the Web

[mabhatter654]

my companies poor system engineer went thru much the same thing last year. We run lots of plant monitoring software from a half dozen different vendors and several were really upset when the guys pointed this MS boondoggle out to them.. we ended up sprining for several extra unlimited user licenses [which really wasn't that bad for our size company] but but it really put the panties in a twist of some of the vendors that said we could just "plug it in" to our network and let lots of people pull the data...

the whole thing is a joke!! When you figure in the whole week of engineering time, that was probably nearly more than the actual license fees.. and people say OSS software causes problems??

Article mentions virtual servers

[putko]

I had not thought about the problem of virtual servers.

E.g. suppose I have a big-ass mainframe that emulates a few PCs, just to run Excel now and then (for legacy reasons). Once a month, we reconfigure the mainframe just for a batch job, so that some of its resources are used to simulate 10 PCs.

How do you price that? A mainframe license? 10 separate PC licenses? What about the fact that I'm only doing it now and then, and not using it regularly (8-10 hours a day)?

I just wish the article had used the term "price discrimination" -- that really explains it all.

Q: How much does it cost?
A: "How much ya got?"

Re:Article mentions virtual servers

[Billly Gates]

Many in the software industry including Microsoft would like a per user + [per cpu license.

They do this shit all the time in negotations with large firms. If two people use one machine then you need to pay for Excel twice.

Re:Article mentions virtual servers

[Poltras]

Actually, if you don't use your laptop at the same time you use your desktop (or you're not at work at the same time you're at home, etc), you don't need to have 2 licenses for using software from Microsoft.

Some times ago, we asked Microsoft if a big guy from the company could share an Office license with his daughter, and they just said that "as long as they both didn't use it at the same time".

Otherwise, what would be the use of installing the shortcuts in "common/start menu" instead of the installing users?

Re:Article mentions virtual servers

[spazimodo]

Working with VMWare ESX, I've found that most vendors charge per physical CPU.

This works out pretty well if you have high enough VM density to take advantage of it (>n VCPUs where n is the number of physical CPUs in the box.)

It kind of sucks when you just have a single instance of a server which won't be hit very hard (perfect case for slapping in a VM) and you would have to buy a 4 CPU license if you virtualized it.

Re:Article mentions virtual servers

[weave]

I have a dual-processor dual-core VMWare ESX server that doesn't emulate SMP so to each host it looks like a single processor. So I figure if I have 8 hosts running on that ESX server, each averages out to half a CPU so Oracle and others should only charge me half price since I'm only using half a processor Right?!

Re:Article mentions virtual servers

[Billly Gates]

I know.

Personally I think its bullshit. This crap is what got me into Linux in 98.

The problem is we no longer own our machines if Windows is required and MS comes in and dictates hwo we use their software.

Still years ago we had a blanket license that covered everything but the MS salesmen still convinced teh CIO to purchase per user + per cpu licensing just to make sure because they did not want to scare poor old MS from doing an audit.

Then another MS salesmen/consultant would say something different about not needing licenses (I think he was saying this to make his project look cheaper) but still. God?

Good thing I am not in IT anymare.

Re:Article mentions virtual servers

[drsmithy]

They do this shit all the time in negotations with large firms. If two people use one machine then you need to pay for Excel twice.

No, you don't. This blatant FUD.

Indeed, Microsoft specifically have a licensing scheme that allows employees to have a copy of something like Excel at home and use it, without having to purchase an additional copy.

per box/machine

[justforaday]

I've always thought that per box/machine licensing made the most sense. Although, the concurrent user model works well in environments where users float between machines (school computer labs, huge offices, etc). Hence different licensing plans for different scenarios. The whole one license per core thing seems somewhat outdated to my feeble mind...

We've heard this before...

[Zweideutig]

I know we have heard about this quite awhile ago on Slashdot, when Oracle wanted to consider a dual core CPU two processors I think companies like Oracle will be forced to think of dual core CPUs as simply one CPU that handles multiple threads well, especially with dual core CPUs not only coming from the Intel side, but also from IBM If I remember correctly Oracle found it difficult to determine the difference between dualcore and two CPUs. In the end, everyone will buy dual core, for the same reason everyone buys LCD monitors (it is seen as better, even if maybe it isn't.) Software companies will be forced to bend, hardware companies won't have to, because consumers are not going to put up with paying twice as much for what appears (on the outside) as one CPU. Should I be charged twice the parking fee because my 2001 Excursion has twice as many cylinders as the car beside it? I don't think so.

Re:We've heard this before...

[linj]

Well, apparently, Oracle has changed (http://news.zdnet.com/2100-3513_22-5788788.html).

Still, charging 1.5x the price for each piece of software run on dual-core boxes (or more) is really evil.

Re:We've heard this before...

[Jonny_eh]

How are LCDs NOT better than CRTs?

They both have their advantages and disadvantages, but that does not mean that LCDs are not better for some people (or most).

LCDs are lighter to carry (good for LAN parties), use less desk space (good for saving space), offer a totally different way of viewing images (the image you see is not scanned to the screen 72 times a second), some people can't stand CRTs. And newer LCDs have a very high response time, so they're good for gaming. Plus, they use less power.

Am I missing something? (BTW, I'm writing this on a CRT ;)

I also think that people will buy dual-cores eventually because eventually they will be utilized properly and their favourite apps + games will require (or benefit) them.

Will buying the latest video card benefit you more than a mid-range card NOW? Probably not, but down the road when games use the fancier shaders, its' value will show. These technologies need to be released BEFORE they're taken advantage of, since this isn't a perfect world.

Lots of people have Athlon 64's, yet use Windows XP (which is 32-bit). But down the road, a 64-bit Windows may come out, or they may decide to switch to Linux.

Re:We've heard this before...

[Zweideutig]

I think people will buy dual core for the same reason they bought 64-bit CPUs and ran Windows (32-bit) on them. The G5 Macs are still running mostly 32-bit software (except in some places), yet use a 64-bit CPU. Dual core may not be too useful if you aren't running many applications simeltaneously, and your applications do not take advantage of multithreading (as a programmer, I make sure to use pthread whenever it is at least somewhat beneficial to my application, which usually is anything that is not very simple.) Anyway, about the CRTs and LCDs. I am too using a CRT monitor. In fact, out of my eight machines I am running right now, three have CRTs and only two have LCDs (laptops, and everything else is router and servers, which are headless *BSD machines.) I think you got a little off whhat I mean about LCDs vs. CRTs. Regardless to which is truely superior (which depends on who you are, I like CRTs because I don't have to worry about the dead pixels and LCD inverter problems that have forced me to take my laptops apart many times for this problem. I like LCDs in laptops because I wouldn't want to drag around a Compaq portable with a CRT in it around. I can't tell the difference between the image of an LCD or a CRT to be honest, but I have "slow" eyes and some colour blindness.) Alot of people will buy LCD displays just because of the inherent "cool" feeling about having one, just like many will buy 64-bit dual core machines and run non-multithreaded 32-bit games. Disclaimer: I am not a gamer. Slashdot is enough of a time spender for me. ;)

Re:We've heard this before...

[kesuki]

LCDs have advantages over CRTs... they also have disadvantages.. the 'advantages' are percieved tob e greater than the disadvantages. the only difference, is that dual cores only real 'disadvantage' compared to single core is that by having dual cores you can't have as many transistors in each core, as compared to an identical silicon die size single core design. but it's difficult to design a single core processor that effeciently uses all it's transistors. especially as transistors get smaller, and you can keep packing more on the core. so they've gone to 'dual core' designs, and leave part of the hard work in the hands of the programmers. but technically, modern operating systems have all become so complicated, that Everyone benfits from dual core designs. but probablly itr would be better if one core was a 'main' core, and there was a 'secondary' core, that was much smaller/slower, and was just there to increase the effieciency at executing code..

no-one is really trying to do that, because it's vastly easier to simply make two identical cores. and for most users identical speed cores is going to work great... even though most won't utilize both cores fully ever. asymetric dual core technology is probabbly the optimal solution, but no one wants to build it. why whould you want to put as small a say 500 mhz core as you can as a co-prosessor to a 4ghz core ;) even if it's the most efficient use of silicon for optimal performance... it doesn't sell itself... it's not glitzy and people don't understand why the second core is only 500 mhz. it's because the second core only Needs to be that fast, to become fully utilized why allowing the 4ghz core to be fully utilized by single processor intensive applications ;)

Re:We've heard this before...

[Evro]

Should I be charged twice the parking fee because my 2001 Excursion has twice as many cylinders as the car beside it?

Just as a point of interest, I have seen places that charge per-axle.

Re:We've heard this before...

[Snocone]

Am I missing something?

Yeah, a fair bit actually. If you're doing professional press work, digital photography, or video, you need the best true-to-life colour fidelity achievable on your monitor, and that means (very expensive) CRT, not LCD.

Also, I don't think any LCDs can match the pixel response time of CRTs, so the hardcore FPS gamer might notice a difference enough to prefer a CRT. My idea of a good game is more along Nethack lines, so I wouldn't personally know.

Re:We've heard this before...

[slazar]

Should I be charged twice the parking fee because my 2001 Excursion has twice as many cylinders as the car beside it?

yes because your fat ass SUV needs some serious downsizing.

Re:We've heard this before...

[Zweideutig]

I disagree. My Ford Excursion's size is proportionate to the 6.8 litre v10 310 HP engine. It doesn't lag too bad on hills, and I don't have too much trouble going through the Dunkin' Donuts drive through or Burger King. I try to get enough food so that I only have to go to Burger King and twice, and I make the twelve donuts last the whole day. That way I don't have to worry about trying to manuever through the drive through too much.

Re:We've heard this before...

[mrchaotica]

1. Yes, you should be charged twice as much to park your SUV, because it takes up twice as much space as a normal car!
2. Yes, your fat-ass SUV does need some serious downsizing, because although its size is proportionate to its engine, the engine is too damn big too.
3. I can't tell if you're being sarcastic or not about the Dunkin' Donuts and Burger King thing, but given that you don't appear to be joking about the Excursion I suspect you might not be. If that's the case, you should also feel sad about what a fat-ass you are.

Have a nice day.

Re:We've heard this before...

[deaddrunk]

For heaven's sake what do you need a nearly 7 litre car for?

Re:We've heard this before...

[rfunches]

I'm being nitpicky but I have to point out the problem with this analogy:

Should I be charged twice the parking fee because my 2001 Excursion has twice as many cylinders as the car beside it? I don't think so.

You are not getting more out of your parking space because you have more cylinders. As long as your vehicle fits within that one space, you are using up the same amount of space as a tiny little Honda Civic.

A better analogy would be "Should I be charged a higher toll because my car has twice as many cylinders as the car beside it?" (Assume they have the same number of axles, two.) They are roughly the same size (compared to vehicles with different numbers of axles -- a small desktop compared to a huge Blade or Beowulf cluster) but one could travel quicker with the extra cylinders (do more work than the other). The companies need to charge based on utilization, not on CPUs, with the advent of consumer dual-core CPUs. A consumer may have a dual-core proc but more than likely they won't be trying to push it for commercial purposes, while a server is designed to serve as many people as possible, and usually to generate a profit.

Re:We've heard this before...

[cecil_turtle]

... yet use Windows XP (which is 32-bit). But down the road, a 64-bit Windows may come out...

64 bit Windows is out...

XP Pro x64
Server 2003 Standard x64 (Enterprise and Datacenter editions also available in 64 bit)

But you are correct that many people run 32 bit XP on Athlon 64's, or even Windows 2000 Server or Server 2003 32 bit versions on Opterons.

Re:We've heard this before...

[slazar]

The point is, you really don't need an SUV. Why not a more fuel efficient vehicle, like a sedan or something. I take great offense at the SUV mentality. "I can afford it, it's big, I like being above people on the road, it makes me feel powerful, I don't give a shit about the environment." 12.4 Mpg! sheesh. And the mpg isn't even listed on Ford's website...

Re:We've heard this before...

[Zweideutig]

My vehicle is very fuel efficient for its size. How fuel efficient would some toy sedan be if it had the same weight? When I drove the Ford Explorer, Burger King and dunkin' donuts trash would build up quickly and I would run out of space. With the excursion, I brobably have 100 kg of trash and I still have plenty of space. Also, it is not that bad on the environment, it has a catalytic converter. And I have relatively good fuel economy too. I don't have to fill up more than twice a week, ever. I like driving big cars, don't shove your liberal, noisey PETA-like idealisms about what car to drive. I run FreeBSD and NetBSD on my servers, but I don't go around forcing it on others. No offense.

CPU Licensing??

[lizdog]

Are we getting to a point where the term CPU loses its relevance? In gaming, is the power of monitor card selected as important than the speed of the CPU? Does the disk array attached to the database have more impact on speed than CPU? Should these also be factors in license models?

Re:CPU Licensing??

[PitaBred]

In gaming... but gaming is a very niche market. This is talking about enterprise computing, where processors are still being pushed very hard. I don't think those are really factors because there are still many things you just throw more and more CPU's at to get 'em done.

Re:CPU Licensing??

[jZnat]

Shh, you're giving them ideas! ;p

At least MS Got it right...

[Anonymous Coward]

Microsoft per cpu licenses are considered per socket, not per core. Makes getting a single dual-core cpu preferable to dual single-core cpus.

Re:At least MS Got it right...

[JimmehAH]

Also XP (Professional) and 2000 (too young to remember how it was for NT4) allow you to use up to two processors anyway (don't know if they're multicore aware).

Maybe they'll limit the number of cores in Longhorn instead of sockets (especially with this talk of 4 core or more processors).

Robber Barons

[forq]

The software industry has gotten away with robbery for too long. Year over year they astound us with their skyrocketing costs, and as computing complexity goes up, they find more and more excuses to not deliver the support you're paying for. "We cannot support you because of X." X being any reason they can find. Upgrades, new hardware they don't have in their support matrix, virtualization. Whatever the reason, the very first order of business for those support folks when you call for help is to find a reason to not support you. And now they want more money. To pay the outsourced first level support folks that know all about how to determine if you're unsupportable, and nothing about how to support the products.

Ridiculous.

Re:Robber Barons

[tshak]

The software industry has gotten away with robbery for too long.

You have obviously never worked on a medium to large sized quality software package before. The cost for market research, design, development, QA, marketing, etc. is in the millions for even smaller projects. Even for "open source" projects where people donate their personal time to work for "for-profit" organizations, there is still a cost around the non-dev related tasks that are required to get a commercial level product shipped. I used to think software was way overpriced too. That was before I had eight years of experience in the industry.

Re:Per-CPU never made sense to me

[ak3ldama]

I could understand a performance based pricing model, but two CPUs which were slower than one really fast costing more in licensing fees never made sense anyway.
Right on.

per seat licence

[vally_the_poo]

> Companies still prefer the per-seat one-off license

I understand now why they don't have any seat at my new work: everybody just sit on the floor, in a hippie style...

duh !

Re:per seat licence

[mederjo]

I understand now why they don't have any seat at my new work: everybody just sit on the floor, in a hippie style...

You'd better get them to check the fine print of the license again :

The software is licensed per seat(1)...

(1) Seat is defined as sitting apparatus, seat-of-your-pants or as a simile for backside/butt/buns/arse [ covering hippies who might not be wearing pants ].

You might want to get that sorted out before the next BSA audit or your company could be in for a rude surprise ! Actually, if the hippies have no pants on, it might be the auditors who are rudely surprised first, but that doesn't mean you shouldn't make sure you're in total compliance with the license, because it takes more than that to throw off the BSA.

I shall have to make sure our software, which is licensed per seat, adds a clause which requires pants to be worn at all times while using the software, just to avoid embarassment. Nobody should have a problem with that, unless of course they're no-pants-wearing open source hippies, who wouldn't be using our software because of the draconian proprietary pants clause anyway.

Re:per seat licence

[mabhatter654]

Actually, and OEM can't sell a dual boot system at all because MS bootloader doesn't support anythign else.. and the OEM contract specifically specifies that all OEMS MUST use the windows bootloader!! that was the downfall of BeOS... what good is a second OS if you're not allowed to show the user it's there!!!

What you point out is what MS has been doing to Universities for years now!! Because the "university" is responsible for all the machines on its network, M$$ simply add up the number of students and pick a price. That's a bit excessive when they have a 99% lock on the OEMS that most college students would buy from!!!

How about per cycle?

[wandazulu]

I'm surprised no one is talking about this, as it seems it was all the rage back-in-the-day (and I believe still going today): charge by the cycle for the app.

Case in point: I worked with IBM's MQSeries product as a link between a mainframe and a webserver. The MQSeries license for NT was something like a flat $6000. On the mainframe, however, it was some ungodly amount for the tapes, then they charged a per-cycle fee *and* a monthly maintenance contract.

As part of load testing, I wrote a program that would spit the complete works of shakespeare back and forth, over and over, to the mainframe and back using multiple threads. Two weeks of testing cost the company an extra $12,000 because of the cycles expended.

I noticed too that starting with SQL Server 7.0 that the explain plan feature can also show the number of cycles spent on a particular step. I would think Microsoft, with that info, could, if they wanted, go to a similar model with SQL Server if they so chose (and wanted to effectively kill the product).

And now that I think about it, my Unix account back in the early 90s had a cost associated with it too...I was allotted something like $1000 worth of what I assume was cpu time, and sure enough, enough attempts to get Nethack to compile and I was back in the office begging for more "money".

Ah, the good old days. I think.

Re:How about per cycle?

[Tablizer]

As part of load testing, I wrote a program that would spit the complete works of shakespeare back and forth, over and over, to the mainframe and back using multiple threads. Two weeks of testing cost the company an extra $12,000 because of the cycles expended.

To bilk or not to bilk

Dual processor computers exist for years

[kanweg]

Amazing that this is turned into a problem. I've dual processor Macs for years. On the other hand, given the pricing of terrible (buggy and user-unfriendly) software like Adobe Acrobat standard and MS Office, their developers seem to have implemented double pricing as standard, even for single processor machines like laptops.

Bert

Re:Dual processor computers exist for years

[qzulla]

Dual cores does not equal dual processors. If you had dual processors either your software had a dual+ licence, or if it knew it was restricted to a single processor, it would stick to that.

What if the OS does the slicing and the app never sees beyond this?

q

... yeah, cause they had to

[argoff]

Lets make no mistake about this, MS didn't do this because of some enlightened generosity, they did it because Linux is kicking their teeth in over the server space.

Funny how open source models aren't having any of these licensing "problems". To Linux unrestricted copying on the internet and huge multicore systems are a benefit, to proprietary vendors they are a threat ... now which side do we think is going to win out over the long term here?

IBMs BlueGene runs Linux

[sandmaninator]

Licensing an OS on a per CPU basis would have made BlueGene prohibitively expensive.
So it runs Linux.

Re:schmucks

[DrSkwid]

Plase learn to type whole words. thanks.

Re:additional work put in

[Wonko]

Most of the current software do not optimally utilize the multiple cores.

Can you name one piece of software that is licensed per processor/core that is unable to take nearly full advantage of however many processors you have in a machine? I sure can't.

Sure, there is a default performance gain based on the OS itself, but its nowhere near what it can be. Lots of work has to be done for the softwares to fully take advantage of the multiple cores and in such cases you do see a massive improvement in turn around time.

There is plenty of software running in datacenters all over the world that can take full advantage of as many processors as you can put in a box. When you posted your comment you hit a web server running Apache. Apache can spawn as many processes as needed to take advantage of more processors.

As for this licensing issue... It really doesn't matter much to me anyway. I don't personally use much closed source software. Anytime I have used expensive software, it sure wasn't on my dime :p.

Re:Per-CPU never made sense to me

[qodfathr]

Agreed. However, market pressures pretty much demanded this. In the not so distant past, Oracle's database was licensed by 'power units' (or some other similar term). Basically, they had this huge multidimensional chart based upon OS, CPU type, CPU speed, etc. It resolved to the 'power' of the system, and you paid based upon that.

If your computer died and you had the gaul to replace it with a faster machine (for the very likely reason that the slower speed machine was no longer available for sale), Oracle expected you to fork over more money.

In the end, the licensing scheme became way too confusing and out of control, so Oracle backed down and went with a strict # of CPUs based model. But, as you have observed, this led to the odd situation where a slower, dual-processor machine could actually have a higher licensing fee than a faster, single processor machine.

Oracle now faces the same problem mith mutli-core chips. Originally, they went to a # of cores licensing model. But, people complained that a dual core, single CPU machine is not as fast as a dual processor machine running at the same CPU individual speed. Oracle's response? Each core is a .75 CPU, oh, and please round up. So an 11 core machine would be licensed as 11 * .75 = 8.25. Ceiling(8.25) = 9 CPUs. I guess you might as well add a 12th core, because it will be 'free'.

not just linux!

[ecalkin]

novell dropped server licenses. you pay per user, get your first server license in the box that the user license came in and download extra server licenses for free.

5 users and one server costs (software wise) the same as 5 users and 20 servers!

eric

Per CPU licensing makes no sense anyway..

[wfberg]

Per CPU licensing makes no sense anyway. It gives no indication how heavily an application is used, or how important it is to a business. For databases, it would make more sense to have a license for X thousand transactions, or Y amount of data. After all, databases are used for doing transactions and storing data. (Don't let Oracle get wind of this idea though, I've got an Oracle database that's more than 1GB in size but compresses down to 30MB! This pricing model will be the ideal excuse for them to take up even more disk space..)

The reason licenses are tied to hardware or to seats is probably because it's easy to justify these as a "cost of doing business" to suits. While projects usually have the greatest difficulty getting an OK for money to go towards programmers, expensive hardware is purchased willy-nilly, on the basis of "well, now we've got this application, we need to run it, or else the money we spent on programming it is wasted!". So tying your database license to CPUs makes more of an afterthought. (Just like performance, scaleability and actual volumes are an afterthought).

The same goes for seats; you just HAVE to license one copy of Microsoft Office or an OS or a database for every employee, otherwise you're paying (some) employees for basically standing around! Then, to recover costs, you make sure they have very little access to things like notepads, pens, or copying machines, since those dimes add up, don't you know?

Call me a cynical bastard if you will..

Re:Per CPU licensing makes no sense anyway..

[e4tmyl33t]

I noticed this as well, I work as a Best Buy computer sales drone (beep beep) and I constantly hear people whining and complaining about how they just bought Office or they just bought antivirus software and now they have to buy another one for their new machine... I just wish I could pass out open-source disks or free software disks at work without getting fired...i'd be handing out openoffice and avg/avast AV programs left and right

Re:Per CPU licensing makes no sense anyway..

[tepples]

I just wish I could pass out open-source disks or free software disks at work without getting fired

Does any of the Windows free software distributions (such as TheOpenCD) carry a UPC bar code? If so, talk to your boss's boss's boss (et cetera) to get that SKU added to Best Buy's product line.

Re:Per CPU licensing makes no sense anyway..

[jZnat]

You cynical bastard!

I like my notepads, pens, and Xerox® machines! They're a lot more reliable, don't crash (well, the Xerox jams and shit every so often, but that's usually because someone was copying their 'cheeks and let one loose), and are sometimes faster.

Now if you'll excuse me, I need to get back to my 8086-powered machine running DOS 4.0. I swear, my company will only upgrade once Microsoft fixes the bugs in 5.0 or releases a compatible 4.1 patch...

Re:Per CPU licensing makes no sense anyway..

[cecil_turtle]

For databases, it would make more sense to have a license for X thousand transactions, or Y amount of data.

That'd be like making your car payment based on how many miles you drive it each month. What difference does that make to the manufacturer (of the car or of the software). Not to mention the pain in the ass of tracking it. Per CPU does make some sense for server applications, but it could probably be even more simple.

Re:Per CPU licensing makes no sense anyway..

[Tim C]

For databases, it would make more sense to have a license for X thousand transactions, or Y amount of data.

So you continue paying over time? Or you licence your RDBMS for X thousand transactions, and when it hits that limit, it stops serving requests? Similarly, what if you licence it for Y GB of data, and your needs increase?

I've got an Oracle database that's more than 1GB in size but compresses down to 30MB! This pricing model will be the ideal excuse for them to take up even more disk space..

So? If you're paying for Oracle RDBMS, cost of disk space is the least of your worries. (I believe that the licensing for Oracle on my current project is around 12K/CPU, and the DB machine has 4 CPUs...)

Re:Per CPU licensing makes no sense anyway..

[wfberg]

So? If you're paying for Oracle RDBMS, cost of disk space is the least of your worries. (I believe that the licensing for Oracle on my current project is around 12K/CPU, and the DB machine has 4 CPUs...)

You'd think so, but it's pretty annoying when your laptop's harddrive fills up.. It's not just 8-way opterons that Oracle gets installed on during development and testing..

licensing = overhead

[bromoseltzer]

In my experience in academic computing support, one of the biggest headaches is license management on Windows and Macs. We tend to have lots of different software packages installed in ad-hoc seats or small networks. Each one may want a dongle or a dedicated server environment. Each one has different contractual terms about student vs faculty vs research use. Etc.

All this, as I see it, is a pure waste of scarce resources. It is somewhat alleviated by sitewide licensing of a few products, but even these are not easy to administer. The whole scene is like the U.S. medical or tax system -- value is being delivered, but the administrative overhead is huge. All the costs of compliance are passed on to the end users and institutions.

What a difference with Linux and OSS! Easy licensing is a big plus and it's not well enough appreciated.

License by transaction rate

[Anonymous Coward]

License by the maximum number of transactions per second that the database can perform. This can be enforced by the database. That pretty much covers everything and you don't have to worry about number of cpu's, number of users, number of accounts, etc... Move the database to a faster machine with more cpu's? No problem as no license change is required. But if you want to increase the rate from the old maximum to the maximum rate the new machine can handle, then you will need upgrade the license.

This is so obvious given that databases are benchmarked in transactions per second, one has to wonder if something else is at work. Most likely just simple greed.

per-thread

[rhythmx]

Why don't the software companies license by something that they can control? A "number of threads" model would be more fair. Or at least, the license can't assume that all the hardware is there for it to use and profit from.

If I had an 8 processor server running an existing application that I also wanted a low-end DB server on, I could just buy a single thread license instead of an 8 cpu one. Later, if the DB server couldn't handle the load, I could simply upgrade it to a 2 or 3 thread server.

Re:per-thread

[jZnat]

Hmm, interesting idea. A "per-thread" license could do well for us who only need that low-end DB server or for those who need a 16-server array database server to serve us our CS:S stats.

If Apache ever costs money to license, however, PLEASE don't tell them about this or my 260 Apache2 threads will really bite me in the ass! =/

Re:per-thread

[ThinkingInBinary]

This is very smart! I've always wondered why someone couldn't take a dual-core box and buy a single-core license for a webserver and a database server and run them both using "half" the system each!

Adapt or die

[Racal Vadic]

Yeah, the RIAA is pretty pissed about what's happening to their traditional business model too. Look for more of that in the future.

Gaming has moved from the PS/2 to the PS2

[tepples]

calling gaming a niche market is plain wrong.

Calling 3D Windows gaming a niche market isn't nearly as wrong. Most 3D video games other than perhaps first-person shooters are played on PlayStation 2, GameCube, and Xbox.

Prove you have a single-package dual-core system

[tepples]

What if the OS does the slicing [of a process's threads across cores of CPUs] and the app never sees beyond this?

Then you're charged extra for the version of the application that supports operating systems that lack a Slicing Reflection API.

It's better than power unit licences for a start

[xixax]

Until quite recently, our database software was on power unit licences. A formula number of CPUs x MHz x architecture is used to work out how much it will cost you to run the database. Why? Well they want people who are running huge databases to pay more, and size of server(s) is a pretty good measure, Amazon isn't going to run on a single CPU. That is, they charge as much as they think the customer can afford.

While an interesting question, how does this question manage to rate as a "insightful"?

Xix.

Re:Mainframes Solved the Problem Already

[IntlHarvester]

Yeah, Mainframes "solved" this problem by charging people X or more the licensing price of Unix or Windows platforms. All of this "MUS" and "LC" nonsense is just basically a license for IBM to remove money from your bank account.

Which is not to say that mainframes are not appropriate for certain applications, only that it is ridiculous to pretend that you can cost-justify the things on licensing grounds.

WebSphere Business Integration Message Broker for z/OS and for Windows. The z/OS version at 3 MSUs -- all we needed -- was 60% less expensive than a single Windows CPU.

Excluding all of the other ongoing maintenance fees for the mainframe, of course. I wouldn't be suprised if a $20K server with W2003 license was cheaper than one month of keeping the 'frame running.

Re:Mainframes Solved the Problem Already

[IntlHarvester]

Looks like I hosed my post somehow. That's supposed to be "10x", not "X", and "VWLC" instead of "LC".

Didn't MS say something about dual-core licensing?

[cecil36]

I remember reading on /. a while back that MS decided that it would treat a dual-core processor as a single processor in licensing its software on a per-processor basis. I thought with MS pretty much dictating what goes in IT, all other vendors would follow suit.

One license per-disc and shut the hell up ?

[billcopc]

I love capitalism. No really, I love watching people test just how hard they can screw each other in the ass for money without getting shot. Here's how I see it:

Company ABC invests X money into developing product. They estimate sales of Y quantity. Divide X by Y to get a per-item cost, mark it up for profit and a support allowance, then sell it.

The fact that I might run their software on multiple CPU's, or that it might be accessed by Terminal Server, doesn't change a single thing for the developer. They don't need to work harder, they don't lose sleep at night, their kids won't end up on Springer. It doesn't matter whether I use it to index my MP3 files, or run a Fortune-500 business with it. They did their work, and they get paid for that work. What happens afterward is not their problem, and more importantly none of their goddamned business.

When people learn to take just compensation for their efforts, and give up the "fight" for riches, we'll wonder how we ever survived through capitalism. There is a set amount of monetary value in the world, the more you have, the less someone else has, and the more that person is likely to do nasty things to make up for the loss. So why don't you just be happy to eat every day and give me a goddamned break with your license gouging.

Re:One license per-disc and shut the hell up ?

[Fulcrum of Evil]

Company ABC invests X money into developing product. They estimate sales of Y quantity. Divide X by Y to get a per-item cost, mark it up for profit and a support allowance, then sell it.

You've got it backwards - Company ABC forecasts a market for product Z and determines Y sales at N pricepoint. If N * Y is less than the projected costs of development and support (plus a decent margin), then the product is built.

When people learn to take just compensation for their efforts, and give up the "fight" for riches, we'll wonder how we ever survived through capitalism.

We tried communism (sort of) and it doesn't work. A product is worth what people are willing to pay for it. If we tried to only charge a just amount, we'd miss out on the potential huge profits from trying something new and stop creating new stuff so quickly.

Re:One license per-disc and shut the hell up ?

[billcopc]

I know I have it backwards. Nobody "needs" huge profits. Profit itself is flawed. You're making money for what ? A corporation! I'd be quite content in creating hundreds of jobs and recirculating this money.

Money's power rests in its ability to change hands quickly. You don't accomplish shit by sitting on a huge pile of cash, you have to keep it moving around. It's kind of like electricity; sure, you could have the biggest batteries in the world, but if you don't plug anything into those batteries they're useless.

Stupid....

[Chanc_Gorkon]

I think if they get too stupid with the costs of licensing, then Open Source software will start to take off even more. Why? It costs me ZERO or close to it to download a iso and run Linux one ANY number if servers or cores. Need support too? No problem. Run Red Hat Enterprise Linux with a support contract or find a company that sells support on a per incident basis. The thing is with all this dual core multiprocessing thing is people want a reasonable all you can eat pricing model. Charging per CPU or even per core is not that model. We'll go away.

Re:Mainframes Solved the Problem Already

[bar-agent]

I think the point was, that the licensing works like metered utilities. You get charged based on how often and "strongiy" (in the case of dual-core, etc.) the program is running. With variations like rolling peak usage or whatever to make book-keeping easier.

And I think this is the right way to do licensing, for enterprise, web, small companies, individuals, whatever. It makes sense, and scales absolutely.

The rate will be determined by market forces. Just because mainframe software is expensive to run doesn't mean than PC software will be anywhere near as expensive.

But in order for this model to take off, some sort of metering faciilty will have to be added to the various operating systems. If one does not already exist, I see an opportunity for a third-party developer to write it and get it licensed and incorporated in every other major product!

Power

[PhYrE2k2]

Per CPU is done in server modules or anything that does a lot of processing (databases, rendering engines, etc). The idea is that these systems will always have the latest CPUs or close to it, and they are generally large enterprise machines.

Take for example a big enterprise database- you could have 16 single processor machines or one 16-way machine- You get the same use out of it, yet in the traditional model, the view of one machine doesn't work.

The more CPUs, the more processing power, the more movies you can put out, transactions per second you can do, etc. It's a usage model like anything else.

Now they could charge by frame rendered, by transaction, but then how would you compare a complex or simple transaction or video? What you are capable to do, you will utilize.

Also keep in mind, that the more CPUs the deeper the pockets above 2 or so. A small business will have single or dual processor systems, whereas a large provider would spend hundreds of thousands on a vendor-lock-in solution for IBM mainframes and many-way Sun systems. If they're willing to pay more, charge them more! Oracle/Maya/etc want a piece of their latest upgrade, so this is a good way to get it, without being prohibitive to small business.

-M

Wha-Whuuu?

[TheoMurpse]

Linux, the open-source operating system for Pentium-style processors

Did anyone else notice that line and do a doubletake? I parse that sentence as implying that Linux is only for Pentium-style processors.

Re:We create wealth by working ?

[zmollusc]

"Money only has meaning in that it is an abstract representation of materials and the time spent by people to make those materials useful. I could sit here for 3 months reading Slashdot and I wouldn't be creating wealth OR I could spend those three months developing some product that people would want to buy (give me money for, or, actually, do some work to create some wealth that they can then trade for the work I did)"

A reasonable view, but the monetary value is set by the market, not by the owner. The effort put in to distort the market by byzantine licencing and usage restrictions does not create wealth.

Actually, no.

[mcc]

Even Linux and BSD have licenses...

Linux and BSD have distribution licenses. What they don't have are user licenses.

No license is needed to use BSD or Linux, on as many machines or CPUs or whatever as you desire, unless you count the "no warranty" disclaimers in the distribution licenses as being "user licenses". This seems like a pretty nice model to me, though it may be considered a dangerous line of thinking from the perspective of some people (i.e. Microsoft).

Re:Actually, no.

[leuk_he]

Linux and BSD have distribution licenses. What they don't have are user licenses.

True, but in order to use it you have to get it anyway.

Re:Actually, no.

[mabinogi]

A distribution license is something you have to agree to if you want to distribute it, not receive it.

Re:It's better than power unit licences for a star

[AlphaJoe]

Oh yeah, Oracle Power Units. What a ridiculous concept in license pricing.

Re:Mainframes Solved the Problem Already

[IntlHarvester]

Sounds like the exception which proves the rule. One particular ueber-expensive IBM package which has better pricing on mainframes. It's almost nearly always the opposite case. Plus, I would not be suprised if this particular package was only of interest to IBM shops, and they've tweaked the pricing to keep you from moving away from the more profitable mainframes.

Re:Automotive (was Re:Maybe)

[S.O.B.]

You're saying it's fair that running a car costs less than running an SUV. I'm saying it's fair that running a single processor server costs less than an 8-way server. So we agree.

There is no change to the price/gallon as you put it. The unit costs per gallon/litre for the car and SUV are the same. The SUV just needs more of it. Similarly, the unit costs per CPU are the same. The 8-way processor server just needs more of them.

Thank you. Your analogy illustrates my point very nicely.

Re:Mainframes Solved the Problem Already

[IntlHarvester]

I disagree. In most cases it won't be worth the complexity and overhead to introduce a metering facility into the OS.

The overall trend of the industry is towards cheap clusters, so I can see the argument for renting per-node, but certainly not mainframe-style load management.

Reminds me of a funny story...

[sanermind]

In college, for a chemistry class, the textbook included some a CD-ROM with some java software that we were supposed to use at home for our homework (or in a provided computer lab for the less fortunate). Anyway, I couldn't legally run it at home, because the shrink-wrap EULA prohibited running it on more than one CPU ...As my home system was a SMP athlon system (an affordable one too, using the XP-to-MP trick), I could not legally run it at home! What was even funnier was that when I mentioned this to the professor, he seemed terribly suprised that I actually read the EULAs. I suppose that most people don't, which you would think would strongly challenge their enforcability, but alas.

Re:Reminds me of a funny story...

[Tablizer]

Sounds like you are getting a good education in Reality 101

IBM and Oracle

[wideBlueSkies]

I am in the process of buying a bunch of Sun Hardware. 2900's and 25K's. All with Ultra IV Dual Core processors.

When I was putting together my hardware and software budget I got assurances from both IBM (for Websphere and MQ) and Oracle (9i and partitioning...(yes you actually have to pay for partitioning, per CPU)), that I would continue to pay 'per cpu', not 'per core'. So my 6 CPU 2900's will count as 6 each, not 12.

Same for Veritas for their clustering and disk management software, now that I think about it...it's outragiously expensive software, but still 1 licence per CPU.

So I guess that I'm not really seeing the dual core licensing problem that I've been hearing about... not sure if it's because I work for a huge Mega-Bank with lots of pull with the vendors, or if the vendors genuinely don't want to upset customers in general. Either way it feels right.

A CPU is a CPU. It's not like the dual core gives you 2x performance or anything. It's more like a 30% boost.... It would be like them chanrging more every time a faster processor came out. Which would be ridiculous.

wbs.

What about the GPL???

[mabhatter654]

How does this affect the GPL?? I mean, will dual core processors allow users to "steal" extra usage from the hard working Linux programmers... The horror!!!

Great article topic!!!

[mabhatter654]

That would be a GREAT topic for a slashdot article!!! Let's see a breakdown of IBM's "trophy" systems according to their own licensing models!!!

Re:Didn't MS say something about dual-core licensi

[mabhatter654]

IBM is KING of per CPU licensing.... Almost all the vendors use some kind of per-cpu fee. What makes it worse is that all of IBMs machines for several years now have used multi-core processors.. often with 4-8 on a "socket" but they've been getting a way with it for a while now!

Silly

[sad_]

the whole license scheme is plain silly. and each vendor has his own license model, it just drives people crazy and hard to predict total costs sometimes.
but there are some things that make me even more mad. the cost of the software _increases_ because of factor X, but it is the same freaking software, there is nothing special about agent Y running on machine A or B except the price! Imagin gas stations calculating the price of fuel depending on your average speed on the highway, while giving you the same fuel anyway.
ok, for some reason you manage to live with this, the next thing makes things even worse. a _lot_ of these products have bugs in their license code, so you'll walk into the office one day and all hell broke lose during the night because for some @#!$ reason the program/agent/etc. though you didn't have a certain license anymore. ARGHLK!
The license model is braindead, and so the OSS companies are mostly a little bit more sensible about it and try to make a living by charging for support. But wait! those horrible licensing bastards are charging for support to, and a lot (you know, in case the license code bugs out again and you have to request a new license whatever). Double ripoff, and still companies are putting up with this crap, what is the deal here? you stab me in the back, i'll stab you, we're all stabbing together...