MS SQL Licensing

  • If I have a developer reaching over from a SQLDev instance using a linked server into production is this a violation on licensing? I know about the performance, why, ect,  and so on. I am just having a difficult time with the is developer who refuses to listen to anybody.

    MCSE SQL Server 2012\2014\2016

  • lkennedy76 - Friday, March 10, 2017 11:55 AM

    If I have a developer reaching over from a SQLDev instance using a linked server into production is this a violation on licensing? I know about the performance, why, ect,  and so on. I am just having a difficult time with the is developer who refuses to listen to anybody.

    The development licence is for design, development, test and demonstration purposes only. Anything that falls outside of this is in violation of the dev licence.

    In my opinion, connecting to prod via a linked server on dev does fall outside of that & therefore is a violation. But I'm no licensing expert.
    It's also a rather bad practice.

    If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.

  • lkennedy76 - Friday, March 10, 2017 11:55 AM

    If I have a developer reaching over from a SQLDev instance using a linked server into production is this a violation on licensing? I know about the performance, why, ect,  and so on. I am just having a difficult time with the is developer who refuses to listen to anybody.

    yes it is a break of licensing.

    https://download.microsoft.com/download/9/C/6/9C6EB70A-8D52-48F4-9F04-08970411B7A3/SQL_Server_2016_Licensing_Guide_EN_US.pdf

    although the above is for 2016, the previous versions on this matter pretty much state the same

    SQL Server Developer Edition
    SQL Server 2016 Developer Edition is a fully featured version of SQL Server software—including all of the features and capabilities of Enterprise Edition—licensed for development, test and demonstration purposes only. SQL Server Developer Edition may not be used in a production environment or with product data. Any test data that was used for design, development or test purposes must be removed prior to deploying the software for production use.
    Customers may install and run the SQL Server Developer Edition software on any number of devices. This is significant, because it allows customers to run the software on multiple devices (for testing purposes, for example) without having to license each non-production server system.
    Note: A production environment is defined as an environment that is accessed by end-users of an application (such as an Internet website) and that is used for more than gathering feedback or acceptance testing of that application. Other scenarios that constitute production environments include:
    • Environments that connect to a production database

  • frederico_fonseca - Friday, March 10, 2017 12:14 PM

    lkennedy76 - Friday, March 10, 2017 11:55 AM

    If I have a developer reaching over from a SQLDev instance using a linked server into production is this a violation on licensing? I know about the performance, why, ect,  and so on. I am just having a difficult time with the is developer who refuses to listen to anybody.

    yes it is a break of licensing.

    https://download.microsoft.com/download/9/C/6/9C6EB70A-8D52-48F4-9F04-08970411B7A3/SQL_Server_2016_Licensing_Guide_EN_US.pdf

    although the above is for 2016, the previous versions on this matter pretty much state the same

    SQL Server Developer Edition
    SQL Server 2016 Developer Edition is a fully featured version of SQL Server software—including all of the features and capabilities of Enterprise Edition—licensed for development, test and demonstration purposes only. SQL Server Developer Edition may not be used in a production environment or with product data. Any test data that was used for design, development or test purposes must be removed prior to deploying the software for production use.
    Customers may install and run the SQL Server Developer Edition software on any number of devices. This is significant, because it allows customers to run the software on multiple devices (for testing purposes, for example) without having to license each non-production server system.
    Note: A production environment is defined as an environment that is accessed by end-users of an application (such as an Internet website) and that is used for more than gathering feedback or acceptance testing of that application. Other scenarios that constitute production environments include:
    • Environments that connect to a production database

    do you have a link to SQL 2012 Licenses agreement that I can share with my boss that states the same thing?

    MCSE SQL Server 2012\2014\2016

  • lkennedy76 - Friday, March 10, 2017 12:27 PM

    frederico_fonseca - Friday, March 10, 2017 12:14 PM

    lkennedy76 - Friday, March 10, 2017 11:55 AM

    If I have a developer reaching over from a SQLDev instance using a linked server into production is this a violation on licensing? I know about the performance, why, ect,  and so on. I am just having a difficult time with the is developer who refuses to listen to anybody.

    yes it is a break of licensing.

    https://download.microsoft.com/download/9/C/6/9C6EB70A-8D52-48F4-9F04-08970411B7A3/SQL_Server_2016_Licensing_Guide_EN_US.pdf

    although the above is for 2016, the previous versions on this matter pretty much state the same

    SQL Server Developer Edition
    SQL Server 2016 Developer Edition is a fully featured version of SQL Server software—including all of the features and capabilities of Enterprise Edition—licensed for development, test and demonstration purposes only. SQL Server Developer Edition may not be used in a production environment or with product data. Any test data that was used for design, development or test purposes must be removed prior to deploying the software for production use.
    Customers may install and run the SQL Server Developer Edition software on any number of devices. This is significant, because it allows customers to run the software on multiple devices (for testing purposes, for example) without having to license each non-production server system.
    Note: A production environment is defined as an environment that is accessed by end-users of an application (such as an Internet website) and that is used for more than gathering feedback or acceptance testing of that application. Other scenarios that constitute production environments include:
    • Environments that connect to a production database

    do you have a link to SQL 2012 Licenses agreement that I can share with my boss that states the same thing?

    Thank you so much!

    MCSE SQL Server 2012\2014\2016

  • touching the data via a linked server, in itself, does not violate the license agreement.
     it depends on what the developer is DOING with the data.

    populating dev with prod data: no problem, right?
    if he is querying production data to validate, verify, or populate local tables for development, no problem.
    If he's using this to distribute a load to releive pressure off of production yes.
    if he's using the development instance to do production work, then yes, it's a problem.

    Lowell


    --help us help you! If you post a question, make sure you include a CREATE TABLE... statement and INSERT INTO... statement into that table to give the volunteers here representative data. with your description of the problem, we can provide a tested, verifiable solution to your question! asking the question the right way gets you a tested answer the fastest way possible!

  • Lowell,

    Not according to the license terms - None of the SQL Developer blocks (SSIS, SQL Server itself, SQL Server Agent, SSAS, Report Services) can connect to a production database as that will then be considered a production environment.

    Yes it can populate dev with prod data.. using one of the following methods
    1 - C# (or other tool that is not part of SQL Server) to copy data accross
    2 - restore from backup files
    3 - Manually on Visual studio with SSIS - but does need to be executed manually, can not use dtexec on the command line.

    Note that using SSMS to connect to production is ok as this is not a licensed feature. But doing it through a linked server on his own SQL Developer instance does require a license.

  • It's not actually as cut and dried as you suggest, frederico - certainly not in SQL Server 2012..
    If the developer concerned has a CAL for the production system,  he can access that data from his desktop (assuming he has the required permissions, which is NOT a licensing issue).   If he can do that, he can push that data into any other server he has licensed access to, so no problem.    Alternatively, if the production systmem is licensed on a per-virtual core basis, there is effectively no restriction on his access to that data (again subject to permissions, which again is not a licensing issue).
    Doing that is pretty appalling practice, or course - lousey security and failure of proper separation of functions, but as I read the licensing rules it is not a licensing violation unless the production system is licensed by CAL and there is no CAL assigned to the developer. 

    As those licensing conditions explicitly state: 'It is rare that someone whose primary role is designing, developing, or testing software would also qualify as
    an “end user” of the software.'  But "it is rare" does not mean "it can't happen because the license rules forbid it".  And the rarity is, I think, more due to security considerations than to licensing rules.

    But I suggest that anyone who wants to know what to do about this should carefully read both the licensing conditions and the security policy applied to the production data before allowing development access to production data, and should probably forbind access outside of support emergencies.  But they should also look carefully at what they want to happen when a bug is discovered in production and first line support (the people who ask if you've switched your equipment on) throws it up to second line support and the second line team throws it back to development who then have to act as third line support.  This can be a real nightmare when the two support groups work for one company, the developers work for another company,  and the production data belongs to/is the responsability of a third company (that third company has to define many of the rules).

    Tom

  • Tom,

    Yes its never clear cut - but on this case we are talking about using a particular piece of software (Sql Server Developer) to access a production server, not if a User has access to that server or if it needs a CAL or not.

    It is the use of SQL Server Developer that is restricted, not the User access to production.

Viewing 10 posts - 1 through 9 (of 9 total)

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