Hello Armin,

there are several kind of licencing mode for SQL:
- CAL licencing
- core licencing
- virtual licencing

In the first case, you need one server licence for each station where a SQL Serer is installed, and as many user licences (CAL) that will access the data. And by user, they mean a physical person or a system/device.
In the second case, you only need one core licence for each core used by SQL Server on the computer where the SQL Server is installed.
The virtual licencing mode,... I don't know how it exactly works...

You still can try to discuss with the distributor about that.
- Is it possible to consider a Device-CAL instead of User-CAL(normally they can't say no) ?
- What's the price of core licence

You'll find attached a pdf describing these licencing mode.

Now I ask you something else.
Think about a system where a central app is connected to PcVue through WebServices. Then, connected to this central app, the customer has developped a dedicated app to display data from PcVue. These viewers app are not directly connected to PcVue

In that case, you only need one WebService licence. In the end, we lose money because we only sell one Web licence instead of one per final client application... It's exactly the same problem.

Thank you Florent for this comprehensive response!

Sure I understand the commercial point that every software manufacturer is supposed to make its turnover.
But in this case I prefer to regard the topic from the technical perspective. And when there is only one client connection, only one configured user and the vendor does not integrate any means of checking how many physical users are actually impersonated through this one channel I think it is not okay for the manufacturer to ask for additional license fees.

The example you gave is accurate but in my eyes it excludes one important point: In the case you described, the central app does not take advantage of the PcVue user management and authentication methods. The money that the integrator saves by not buying additional WST-clients he will spend on implementing or adapting his own user management. Sounds fair for me, although it is not really perfect for us. But at least we have a sales argument at hand.
In the context of the SQL Server it is the same: If somebody does not take advantage of the extensive and powerful SQL Server User management (which for sure already represents a big part of the functional extent and justifies a part of the basic license cost) I do not see why he should pay extra for CALs?

In SQL Server a connection is not necessarly a single user. You can create a connection linked to and AD Users Group (like in PcVue...). This is a powerful functionality, which helps you to save time and money when you add or remove a user from your organization.
Then how do you consider it ? As there is only one connction point in SQL, is it only one CAL, or is it one CAL for each user in the group.

An other example. Our intranet portal uses a SQL user to connect to our database. This user only have read and write permissions which is enough for a standard user.
There is only one user configured in SQL Server, but everybody in the company use it when accessing the intranet portal. Do you have to pay only one licence ? (this case is a bit particular, because, as it's an Enterprise edition, we only can have core licence)

Creating an identification method based on the AD is not very long. It's what we dis for one of our internal tool. It's connected to a webservice which communicates with the server. When you identify in this tool, it sends your credntial to the WS which checks on the server if you're in the correct group or not. It took less than half a day to implement.

I completly disagree with what you say (but I may misunderstood what you're saying). There is a part of honesty to have when you use this kind of tool and buy licenses. What about TeamViewer, VMWare,... Are you using only the free non-commercial version that are not controlled ?

Hopefully for us, not all our customers thinks like you... With SvMgr, you can do whatever you want for free licence, especially communication protocols.

Stop! In no way I said that I am using unauthorized software licenses or similar or that I encourage anyone to do so! What I said about Microsoft not checking the impersonated access was purely a technical consideration and probably not articulated well. I wanted to point out that technically nothing speaks against using the SQL Server with only one impersonated user account. In this case the integrator does not have access to the full features of the product and it is good that he hasn't. How all this is handled in terms of licensing however still seems awkward to me.

Of course, I agree with what you say about honesty. We are in the same boat as Microsoft and the vendors of all the other software that you mentioned.
But I think that license models must make sense to be accepted by customers. And in this case I regard it as not comprehensible. I fully understand the complaints of my customer. Why should he pay for user licenses when he does neither use nor take advantage of the SQL Server user rights management? It is like Microsoft charging him for using our authentication provider.
This does not sound reasonable to me. For every new PcVue user or every new station (which may be several dozens in such kind of project) the integrator shall pay 200,- whereas he is not maliciously bypassing the SQL Server user rights management, he is just not using it.

It would definitely be different if using Windows Authentication and connecting several domain user groups to various SQL Server users and roles as you described in some of your examples. This is what in my eyes the User/Device CAL model should be used for.

However, the terms of license are as they are and they are clear in speech. Consequently, my customer is of course going to pay the licenses!
And anyway: thanks again for explaining to me. I am afraid that we could possibly have some problems explaining these circumstances to integrators who try to promote mid-size projects for which the SQL Server Express Edition is too limited.

About the SvMgr thing: yes, why not? If one thinks he can write a driver, test it and maintain it over years for less money than buying an additional communication channel I am fine with that. PcVue is an open platform or isn't it? That is one of its most important characteristics. Maybe it will pay off for him if he can use the driver in enough different projects. Still he won't have support for it, no Cimway-like integration in PcVue, no guaranteed backward compatibility and so on...

Well, I must apologize for having misunderstood you. We will drink a beer together next time we meet !

Consequently to this discussion (and a SQL training session in Lyon) I started writing a small document which explains how the SQL Server licensing model works, and what we should have in front of our PcVue architecture.

Guys,
I have read with interest your conversation and I am really interested having your document Florent.
Right now, we are biding for a project and we have to quote SQL Server Standard Edition....