• Illustration: Decompilers in Action

Software Licensing and Protection Services (SLP) will serve two purposes for commercial software developers: preventing unauthorized use through product activation and other technologies, and protecting the developer's intellectual property by making it harder to reverse-engineer .NET source code from the executable. In addition, although SLP doesn't share any underlying technology with Microsoft's Windows and Office activation systems, broader adoption of product activation would serve to validate Microsoft's use of the antipiracy technology. Up to this point, customers have tolerated Microsoft's use of activation, but they may not be eager to see widespread use by other vendors.

Gained in Microsoft's Jan. 2007 acquisition of Israeli firm Secured Dimensions, SLP helps developers protect their code by transforming selected portions of it into a secure format, called Secure Virtual Machine Language (SVML), and incorporating an additional run time, the Secure Virtual Machine (SVM), that enforces a desired set of licensing restrictions and makes reverse engineering more difficult.

Preventing Unauthorized Use

SLP could help developers thwart piracy and experiment with different sales and distribution models, such as subscription-based software, by making it easier for them to implement product activation and protection mechanisms similar to those used by Microsoft's Windows Genuine Advantage and Office Genuine Advantage programs.

SLP tools will allow developers to mark blocks of code as "licensable entities," which an SVM will allow to execute only if an appropriate digital license has been obtained. Digital licenses are provided by a server, operated either by the ISV or by Microsoft as a for-fee hosted service.

Developers will be able to choose from four different licensing models:

Machine-based licenses will allow the protected software to run only on specific computers and will prevent an application from being copied to an unauthorized computer. This model can be used to implement the type of activation system used by Windows and Office. Like Windows Genuine Advantage, SLP will examine a combination of several hardware components on a system to determine whether it is a "new" system or not.

Time-based licenses will allow the software to run for a specific period of time and can be used to create full-featured demonstration versions that stop working after a specific period of time, or software that is licensed on a subscription basis and stops working if the customer doesn't renew the subscription.

User-based licenses will allow a licensed user to use the software on a number of systems but prevent unauthorized users from using it. In the initial release, users will be identified by their Windows logons.

Feature-based licenses will allow developers to implement a pay-as-you-go model in which specific features of an application are unlocked only when the user has paid for them.

In addition, the developer will be able to opt for either a one-time activation model or a system more akin to Windows Genuine Advantage, in which the system periodically rechecks and validates that the user is still allowed to use the application.

Either way, by helping and encouraging other vendors to adopt similar methods, Microsoft could make its own product activation system seem more acceptable in the eyes of corporate customers.

Protecting Code

In addition to helping prevent piracy, SLP helps developers protect their intellectual property by making it harder for competitors, pirates, or malware authors to reverse-engineer the application back to the original source code.

With traditional native-code development, reverse engineering is a time-consuming process available only to developers with significant experience in low-level assembly language programming. Environments like the .NET Framework and Java, however, make the process considerably easier because programs running on those environments also include metadata, information about the code used to support important run-time features, but that also make it easier for tools to reverse-engineer (or decompile) the code. Existing tools attempt to make decompiling less effective, but none are fully effective. (For a detailed illustration of how managed environments like .NET differ from native code in this regard, see "Decompilers in Action".)

SLP goes beyond existing tools by transforming the actual code. Developers use a tool to mark sections of code they want to protect, and SLP tools transform the code into SVML. The resulting SVML will run only on a specific SVM that is linked into the resulting executable. Each SVM is unique—although developers can have multiple SVMs to use in different applications, a given set of SVML will run on only one SVM.

Developers need not protect an entire application: they can protect specific bodies of code that represent important intellectual property, such as core algorithms, while leaving unimportant sections, such as user interface code, as is.

Giving developers a way to prevent reverse engineering may help make the .NET Framework more attractive to commercial ISVs, who, thus far, have shown much less interest than have corporate developers. Although other considerations also play a role in the slow adoption by ISVs, such as the large bases of existing code they must deal with, SLP could eliminate one potential roadblock.

The Devil Is in the Details

Microsoft says it will ship SLP in Oct. 2007, but as of July 2007, pricing or licensing terms are not yet publicly available and technical documentation is lacking. Based on the information that is available, there are reasons for both developers and IT managers to exercise caution.

First, managing protected applications could be more complex. For example, the list of authorized users for an application will be maintained by the ISV, or by Microsoft if the ISV is using the hosted service. Therefore, provisioning a new account will not only require adding the user to AD but also to the list of authorized users for any applications protected by user-based activation. (AD groups are not supported.) In addition, although a tool will be available to enumerate the licenses installed on a desktop system, such information will not be available through Windows Management Instrumentation (WMI) or other centralized management systems.

Second, developers will want to exercise care in selecting sections of their code to protect because unlike normal .NET code, SVML code is interpreted at run time instead of being converted to native code (a process referred to as just-in-time compilation), and therefore runs more slowly. The size of the performance penalty will vary based on the specifics of the application. In addition, some features will require developers to modify their code. For example, supporting feature-based activation requires not only using the tools to mark the appropriate sections of code but also changing the application to ensure that when a user attempts to use features he or she is not authorized for, the application fails gracefully instead of presenting an "unhandled exception" message. The difficulty of making such changes will vary greatly, depending upon how the individual application was designed.

Finally, although customers have thus far accepted product activation systems from Microsoft (and a small number of ISVs, such as Adobe), it's not clear that they will be happy to see broader use of the concept. Developers need to consider the possibility that their customers will turn to products that don't use activation.

Resources

A Web site devoted to SPL at www.softwarepotential.com promises to provide white papers and other technical information, but as of July 2007, it contains only high-level marketing information.