License Properties
The License Properties section in a Babel Licensing template defines the specific attributes and constraints of licenses generated from the template. This section is divided into four key categories: Assemblies, Components, Fields, and Features. Each category serves a distinct purpose in defining the scope and characteristics of the license.
Assemblies
The Assemblies tab specifies which .NET assemblies are covered by the license. This is crucial for software composed of multiple assemblies, as it allows you to precisely control which parts of your software are licensed.
Assembly Properties
Each assembly entry in a license template includes the following information:
- Name: The name of the assembly (e.g., “MyCompany.ProductName”)
- Version: The version number of the assembly (e.g., “1.0.0.0”)
- Culture: The culture information of the assembly (e.g., “neutral” or specific culture codes)
- Public Key Token: The public key token that verifies the assembly’s identity
Version Wildcards
Babel Licensing supports wildcard expressions for assembly versions, allowing a single license to cover multiple versions of the same assembly:
- Exact Version:
1.0.0.0(covers only version 1.0.0.0) - Major Version Wildcard:
1.*(covers all 1.x.x.x versions) - Major and Minor Version Wildcard:
1.2.*(covers all 1.2.x.x versions) - Version Range:
[1.0.0.0-2.0.0.0](covers versions from 1.0.0.0 to 2.0.0.0, inclusive)
Examples
-
Single Assembly, Exact Version:
Name: MyCompany.Core Version: 1.5.2.0 Culture: neutral Public Key Token: a5d85ef2c81d0f8a -
Single Assembly, All Versions in Major Release:
Name: MyCompany.Core Version: 2.* Culture: neutral Public Key Token: a5d85ef2c81d0f8a -
Multiple Assemblies with Different Version Rules:
Name: MyCompany.Core Version: 3.* Culture: neutral Public Key Token: a5d85ef2c81d0f8a Name: MyCompany.Extensions Version: [1.0.0.0-2.5.0.0] Culture: neutral Public Key Token: a5d85ef2c81d0f8a
Components
The Components tab allows you to license specific components or modules within an assembly, providing finer granularity in licensing control. Components are represented as string identifiers that your application code can check against.
Component Usage
Components are typically used in scenarios where:
- Your application has distinct modules that can be licensed separately
- You want to enable or disable specific functionality based on license level
- You need to implement feature-based licensing within a single assembly
Properties
- Name: A string identifier for the component (e.g., “ReportingEngine”, “AdvancedEditor”)
Examples
-
Module-based Components:
Name: DataAnalysis Name: Reporting Name: Visualization -
Feature-tier Components:
Name: BasicFeatures Name: AdvancedFeatures Name: EnterpriseFeatures -
Integration Components:
Name: SqlServerConnector Name: SapIntegration Name: RestApiClient
In your application code, you can check if a specific component is licensed using the Babel Licensing API:
if (license.Components.Contains("AdvancedFeatures"))
{
// Enable advanced features
}Fields
The Fields tab allows you to add custom key-value pairs to the license template. These fields can store additional information that might be relevant for license validation, tracking, or business purposes.
Common Uses
- Define custom license parameters
- Store encrypted passwords for features
- Include metadata for license management
Properties
- Name: The identifier of the field (e.g., “Metadata”, “ContractNumber”)
- Value: The associated value for the field
Examples
-
Application-specific Fields:
Name: MaxConcurrentProjects Value: 10 Name: StorageQuota Value: 500GB -
Feature Configuration Fields:
Name: EncryptionLevel Value: AES256 Name: ApiRateLimit Value: 1000
Your application can access these fields through the Babel Licensing API:
string encryptionLevel = license.Fields["EncryptionLevel"].Value;
int apiRateLimit = int.Parse(license.Fields["ApiRateLimit"].Value);Features
The Features tab defines specific features or capabilities that the license enables within your application. Unlike Components, which are simple string identifiers, Features can include additional data that can be used to configure the feature.
Properties
- Name: The identifier of the feature (e.g., “CloudSync”, “BatchProcessing”)
- Data: Optional binary data associated with the feature, which can store configuration parameters, feature-specific keys, or other data
Examples
-
Basic Feature Enablement:
Name: AdvancedReporting Name: DataExport Name: CustomBranding -
Features with Configuration Data:
Name: SecurityModule Data: [Encrypted configuration data] Name: DatabaseConnectors Data: [Serialized list of allowed connectors] -
Tiered Features:
Name: UserQuota Data: [Serialized value representing maximum users] Name: PerformanceTier Data: [Encoded performance settings]
Your application can check for feature availability and retrieve associated data:
if (license.Features.Any(f => f.Name == "AdvancedReporting"))
{
// Enable advanced reporting features
}
var securityConfig = license.Features
.FirstOrDefault(f => f.Name == "SecurityModule")?.Data;
if (securityConfig != null)
{
// Initialize security module with the provided configuration
}Integration Strategy
When designing your license templates, consider how these four property categories work together:
- Assemblies define the scope of what software components are licensed
- Components provide modularity within those assemblies
- Fields add custom information and parameters
- Features enable specific capabilities, potentially with configuration data
By carefully structuring these properties, you can create flexible licensing schemes that adapt to different customer needs, business models, and product editions while maintaining control over your software’s usage and distribution.
This comprehensive approach to license properties in Babel Licensing gives you the tools to implement sophisticated licensing strategies that protect your intellectual property while providing a seamless experience for your customers.