Easy Licenses

  • Comments posted to this topic are about the item Easy Licenses

  • What a scary concept, giving visibility into how many distinct users are actually connecting.. My god, you might license near the correct number and not over pay..

    I see it costing companies licensing revenue so they would resist it.. FUD is a good way to force you over-license..


  • Or the developers could implement a service-hosted data access layer, meaning that all connections to SQL Server come through one account. 1 user == 1 CAL, irrespective of how many real life users connect to that service! 😉

  • lokkers (11/19/2009)

    Or the developers could implement a service-hosted data access layer, meaning that all connections to SQL Server come through one account. 1 user == 1 CAL, irrespective of how many real life users connect to that service! 😉

    I seem to remember something from the license precludes that method..


  • For a 100 person company, i think you're missing a zero, it'd be $16,200 for licensing CALs wouldn't it?

  • This is a great idea, and I would like to see (and use) such an utility too !

  • Using an app the mutliplexes means you still must license all clients. It's not just the one connection.


  • A number of our enterprise applications use the Flexlm system. It automatically manages license counts, users can come and go (some applications even allow a user to 'check out' a license for use while travelling), administration is really quite straightforward.

    I would like to see MS do that (as an open system, so that other vendors can also use it for their products)


    -- FORTRAN manual for Xerox Computers --

  • Don't many companies, including MS, license by user requests even if they go through one unique user?

    EG: you many have 1000 users accessing SQL Server through one account.

  • Easy enough to have a trace that grabs the host data for the connection, and then dump that into a table for analysis.

    Would probably want to use events 14 and 17, columns 6, 7, 8, 11. (sp_trace_setevent)

    Property of The Thread

    "Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

  • Licensing issues for enterprise wide products:

    Small organizations may not be able to afford to overpay, so tracking individual licenses is worth it. Large organization may not be able to track individual licensing even with staff to do it, so they will overpay to avoid headline making allegations.

    Scenarios in my organization where enterprise wide licensing is in use (SQL or MS or other):

    1) One person: 1 computer daily, regular weekly use of one of several "check out" laptops

    2) One person 2 computers: One desktop, one laptop, uniquely assigned them, both used daily.

    3) Two computers: a pool of between 10 and 30 (seasonal) staff who use it regularly

    4) One computer: the possibility of any of 50 local users who could use it in order to access particular hardware capability in any one month

    5) One computer: one primary user but when out of office, one of 7 staff members uses it one - two hours at a time

  • In our shop we have a SQL Agent job running hourly that performs a count of how many distinct users are connected (sysprocesses) to each database on each server of interest and writes the date, hour of day, and user count to a table. We analyze that data periodically to ensure licensing compliance, but we also look to see how many users are connected to each db at different times of the day to help ensure that we have sufficient hardware resources employed.

  • That's a good idea, Dean. Probably across time that gives you a good idea of how many people are using the server.

  • Why might anyone contemplate using individual user CALs rather than server side per CPU licensing for anything other than a system with a very small numbert of users? Especially given that a quad core counts as one CPU for per CPU licensing, and that a replicated server (or a log-shipped backup) used only as hot standby doesn't require a separate license? I can only once recollect us once telling a customer to buy CALs because his number of users was small enough to make it cheaper than per CPU licensing - and that was for a customer who had a considerably smaller number of users than we normally handle.

    Or has SQL licensing changed so much since last I specified the licenses for a production system that the break-even point between CALs and CPU licences is now at a much much higher user count than it used to be?

    The editorial is talking happily about using CALs at what I reckon is something like three times the break-even point for CALs vs CPU licenses for typical database servers. That's scary. Or maybe it means SQL Server licensing in the USA is quite different from SQL Server licensing in the Carribean, in Europe, in Asia, and in Africa? That would be very odd.

    It really would be nice to have an accurate count of users if that number affected the licensing costs, but as far as I can see it has no such effect beyond a very small (about 34:1) user to server ratio, so in my experience it's never been something that would be useful for licensing purposes. (Of course there are other uses for the number - but there are far better ways than license manager of getting the number.)


  • I can think of a couple reasons, the first one is an organization with dozens of SQL servers, the CAL is applicable to ANY SQL server of the version it is licensed for. So if you have 100 SQL 2008 CALs then the users of those CALs can connect to ANY SQL server in your organization.

    The statement I would make is don't assume a particular licensing scheme, work the numbers.


Viewing 15 posts - 1 through 15 (of 15 total)

You must be logged in to reply to this topic. Login to reply