This afternoon, we went to Microsoft office to have a discussion with Rashish Pandey, Product Marketing Manager (Developer Tools) for Microsoft Singapore. The agenda of the meeting is to discuss various options to buy Visual Studio 2005 for our plan to migrate to Visual Studio 2005.
Noted below are what I extracted from the discussion plus a few hours of surfing Microsoft site to seek further clarification. Bear in mind that those notes are my personal opinion and should not be taken as it is. If you are in the position of evaluating VS.NET 2005 licensing as well, I suggest to start from Microsoft site then seek more explanation from Microsoft representative.
To begin with, Visual Studio 2005 licensing scheme is per user/developer basis, not per installation basis. Simply speaking, if there are 20 developers, then we need 20 licenses to adequately cover all the usage, regardless on how many instances of Visual Studio is installed.
VS.NET 2005 comes in 4 editions: Express, Standard, Professional, and Team System. Visit Visual Studio 2005 Product Feature Comparisons for more comprehensive comparison among those editions. In my opinion, the Express and Standard editions are more suitable for hobbyist or individual developer working at home rather than for enterprise use. Both editions come bundled with SQL Express Edition, so we know how Microsoft positions these editions. Surprisingly, both Express and Standard editions support SQL Reporting Service, so theoretically they can be used to create and publish reports to SQL Reporting Service.
Beginning from the Professional Edition and up, there are SQL Server 2005 integration and XML/XSLT editor, two major features which are missing in the first two editions. Microsoft positions the Professional edition for individual developers, but I believe in practice due to overwhelming features and high price tag of the Team System edition, most companies will stick to the Professional edition.
In the high end side of the product line is Visual Studio Team System, which consists of 4 products offered in 5 different packaging. The products are Architect, Developer and Team Tester, each one targets specific role in the software development lifecycle, plus the Team Foundation Server to enable collaboration among those roles. You can buy the Team System Suite which consists of 3 Team System, one copy for each role, bundled together. The Team Foundation Server is sold separately and will be available in March 2006.
Users connecting to the Team Foundation Server needs a license known as CAL (Client Access License). Every individual Visual Studio Team System edition comes with 1 CAL, which means the user automatically has license to access the Team Foundation Server. The Professional edition does not include CAL, so you need to buy a CAL if you want the developer using the Professional Edition to use the Team Foundation Server.
Microsoft has a scheme called Software Assurance, which entitles you for free upgrade to the next version of the product as long as you has a valid subscription for the corresponding product. In VS.NET 2005, MSDN Subscription is a superset of Software Assurance. Other than offering free upgrade to the future release of Visual Studio, it also gives you phone-based support, newsgroup support, and a bundle of Microsoft operating systems, server products, betas, etc. licensed for development and testing only (Developer Edition). In my view, this is the most important benefit of MSDN Subscription. Developers can try various Microsoft products and run their applications in various environments without needing to buy licenses.
The Team System edition with MSDN Subscription bundle comes with a 5-user-limited edition of the Team Foundation Server called 'Workgroup Foundation Server'. This product is functionally equivalent to the Team Foundation Server, but it is limited for 5 users only. IMPORTANT NOTE: You cannot buy extra CALs to increase beyond 5 users.
Finally, there is a downgrade licensing scheme available for VS.NET. It means you can buy VS.NET 2005 to license your VS.NET 2003 installation. It sounds uncommon, but it might be useful in the situation where you still have projects in VS.NET 2003, not quite ready to jump to VS.NET 2005, and need more licenses to cover additional developers.
Showing posts with label licensing. Show all posts
Showing posts with label licensing. Show all posts
Thursday, February 23, 2006
Wednesday, February 15, 2006
GPL vs LPGL
The company I am working on is heading for the annual audit process. Apart from the security and compliance issues that the internal auditor needs to find, the auditors will find whether we have unlicensed and underlicensed applications. Underlicense situation will rise if the current licenses we have do not adequately cover all the software installation or deployment.
In our discussion, we come across several licensing schemes and surprisingly nobody has a clear understanding about them. Two most prominent licensing schemes: GPL (General Public License) and LGPL (Lesser GPL) seems to confuse many as they look similar but actually are very different.
The GPL license allows free use and modification of the software, as long as we credited back to the original author and release the application (that utilizes the GPL'ed software) as open source. This is a major road block for commercial project to use GPL'ed software.
On the other hand, the LGPL license does not require the application to be distributed as open source and thus can be used in a commercial application. This licensing is increasingly popular among software libraries. However, there is an extra complication: any modification or addition (and even wrapper) to the LGPL'ed library must also be released under LGPL/GPL scheme. Other parts of the software which do not use the library are not affected and therefore can be released under any licensing scheme. Therefore, in practice, if we create a wrapper class of the LGPL'ed library, or create a class that inherits from the library, then our library code must be released under LGPL scheme. In the .NET project, as a class library is compiled into an assembly, then the assembly and its source code must be released under LGPL. Not a pretty situation for a commercial project!
In summary, whenever your software project needs to use a third-party library/application, make sure you understand its licensing very well and judge carefully whether it fits with the licensing of your software.
In our discussion, we come across several licensing schemes and surprisingly nobody has a clear understanding about them. Two most prominent licensing schemes: GPL (General Public License) and LGPL (Lesser GPL) seems to confuse many as they look similar but actually are very different.
The GPL license allows free use and modification of the software, as long as we credited back to the original author and release the application (that utilizes the GPL'ed software) as open source. This is a major road block for commercial project to use GPL'ed software.
On the other hand, the LGPL license does not require the application to be distributed as open source and thus can be used in a commercial application. This licensing is increasingly popular among software libraries. However, there is an extra complication: any modification or addition (and even wrapper) to the LGPL'ed library must also be released under LGPL/GPL scheme. Other parts of the software which do not use the library are not affected and therefore can be released under any licensing scheme. Therefore, in practice, if we create a wrapper class of the LGPL'ed library, or create a class that inherits from the library, then our library code must be released under LGPL scheme. In the .NET project, as a class library is compiled into an assembly, then the assembly and its source code must be released under LGPL. Not a pretty situation for a commercial project!
In summary, whenever your software project needs to use a third-party library/application, make sure you understand its licensing very well and judge carefully whether it fits with the licensing of your software.
Subscribe to:
Posts (Atom)
