To justify the proposed scheme, we present a brief outline of the advantages, as well as a brief summary of alternatives that were ruled out for various reasons.
- Convenience for web authors - while a sophisticated authoring tool could make the design-time process completely invisible for web authors, even a simple design-time utility could make creation of .LPK files quite easy for authors that write HTML directly using tools such as Notepad.
- Extra convenience for web sites - a site with many web pages and many licensed controls could easily create one .LPK license package file containing all the licenses for all the pages on the site. After the one-time creation of this .LPK file, it is easy to refer to it from all pages on the site.
- Inconvenience for pirates - the average web developer cannot accidentally pirate licensed controls without realizing that they are breaking copyright laws. Although intentional piracy is not impossible, it is rather inconvenient and requires knowledge of the .LPK file format.
- Tying the .LPK file to a particular site(s) - one could achieve additional security by tying a license package to the site at which it would be used (for example, by including a list of URL prefixes or an X.509 certificate in the .LPK). However, the additional security is not worth the inconvenience to web authors, especially for publishers that host many sites, or for HTML-designer contractors that write HTML pages for many different publishers.
- Tying the .LPK to a particular HTML page - it is possible to use CRC digests to link a .LPK to a particular .HTML page. This was widely rejected as being too difficult at design time, and impossible for dynamically generated content.
- Using digital certificates for foolproof security - although in the future Microsoft intends to pursue 100% foolproof solutions to the licensing probleme, for short-term needs (Internet Explorer 3.0) a simpler solution is much more practical.