Comparison of Internal vs External Licensing

A comparison of the internal and external license methods and their use follows.

Internal

Work flow: Create a model that will be encrypted. Choose which tools the IP author wishes to support, and work with each tool vendor to create a license file for that tool ("work with" may require communication with the vendor, or may be an automated process). The IP author adds a license pragma for each license file created to the model, encrypts it, and distributes it with any needed license files to users. When the user performs operations on the IP, the tool will check the license using the license file specified.

The license pragma will include the name of the license file and a feature name.

  • Implemented by each EDA tool, using whatever licensing mechanism is already used by the tool (for most existing tools, that's Acresso's FlexLM). This means minimal extra technical work, unless the tool uses no licensing. The licensing implementation benefits from knowledge used in implementing encryption.
  • Creating a license as an IP author will involve some business relationship with the license manager vendor, with the tool vendor as an intermediary. The technical problem of creating licenses that can be used with the tool is left up to the tool vendor.
  • The IP author must create a different license for each tool they wish to work with. That also requires a separate license specification for each tool.
  • The IP author and each EDA tool vendor must agree on license feature names.

External

Work flow: Create a model that will be encrypted. Acquire a license manager that supports the standard (this will require some additional technical work on the part of the license manager vendor or the IP author). Create a license file. The IP author adds a license pragma for the license file to the model, encrypts it, and distributes it with the license manager and license file to users. The user places the licensing dynamic library in a directory specified by the modeling tool. When the user performs operations on the IP, the dynamic library will be loaded to retrieve the license.

In addition to those specified in the internal case, the license pragma will include the name of the dynamic library (instead of the license file), function names to call to acquire and optionally ping and release a license, an encryption key that is shared with the dynamic library, and an expected return value. These directives must be encrypted.

  • The license manager exists as a dynamic library (which will be referred to as a DLL) that's loaded by the tool at runtime.
  • Securing a license manager is left up to the IP author, and will likely involve an additional cost to the author.
  • Requires the implementer to have experience with security. Some vendors may choose to provide license managers and take on the business responsibilities mentioned in the "Internal" case. A reference implementation could be provided, but due to the obfuscation requirements to secure the DLL, would require additional technical knowledge to use.
  • Security is more difficult than the "Internal" case. Two techniques to minimize the security risk are to encrypt all function calls to the DLL and use an initialization vector to randomize every call, and to use obfuscation techniques to hide any keys kept in the DLL.
  • A license created by the IP author for a particular license manager could be with any tool, on any platform supported by the license manager.

If an IP author wishes to license their IP, it is possible to construct a system where the licensing is implemented with static libraries internal to the consuming tool, or to construct a system where the licensing is implemented with dynamic libraries external to the tool. There are both technical and business issues to compare as follows:

Issue Internal External
Overview License feature managed by
existing EDA tool license
daemon
License feature managed by
license daemon outside the
EDA tool
Basic business relationship
with licensing vendor
Already exists Different possibilities, but
assume a new entity here that
would become a customer of
licensing vendor
Security No shared library. No security
vulnerability beyond what is
present in EDA tool.
Shared library and API. Need
to create secure interface
between EDA tool and
licensed IP manager application
as described in next section.
Next generation security IP licensing automatically
inherits any anti-piracy work
in EDA tool (eg - Arxan)
Separate effort
Extended business relationship
with licensing vendor
Add-on required to allow
licensing for benefit of third-party
Build in to new entity
agreement. Concerned that
small separate entity may not
have leverage to ask for new
buisness terms.
Engineering dev/test Very little incremental work All new
Operations impact Could vary from tiny to huge
with asynchronous additions
to EDA vendor license file
No impact on EDA tool vendor
operations. Drives operations of
new entity
Platform support Automatically identical to
what is in EDA tool
Entity needs to support
platform requirements of all
EDA tools as appropriate to their business
Licensing version support Automatically identical to
what is in EDA tool
API needs to be tolerant of
different licensing between
EDA tool and IP licensing
Feature String Portability Separate licenses and likely
license pragmas required for
each EDA tool
One license, library and pragma
that works with any EDA tool

Notes: Basic business relationship with licensing vendor, Extended business relationship with licensing vendor, and Operations impact for External licensing are the same as Internal licensing if the license daemon vendor and EDA tool vendor are the same entity. The new work in Engineering dev/test for External licensing can be reduced with a reference implementation.

Issues: Configuration - each license specification needs an identifier that the tool associates with a user-specified IP-address and port.

Topic revision: r1 - 2011-04-17 - 23:29:32 - MichaelSmith
 
Copyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback