License Dependencies

When your module incorporates code from other CodeLibra modules, you need to declare these as license dependencies. This guide explains what license dependencies are, how they work, and how to manage them effectively.

What Is a License Dependency?

A license dependency exists when your module includes code from another CodeLibra module in a way that requires a license to that module for your module to function properly.

Not every software dependency is a license dependency. Your code may rely on many packages and libraries, but only those that require licensing through CodeLibra—because they're on CodeLibra with a commercial license requirement and your use constitutes incorporation—are license dependencies.

When you declare a license dependency:

• Your licensees automatically receive licenses to the dependency
• The composite price includes both your module and all dependencies
• Revenue is automatically shared with the upstream developer
• You don't need to handle licensing coordination manually

When to Declare License Dependencies

You SHOULD declare a license dependency when:

• Your module contains or bundles the dependency's code. If your module includes source files, compiled code, or other content from another CodeLibra module, that's a license dependency. Example: You build a framework that bundles a CodeLibra-licensed logging library.

• Your module is a derivative work. If your module is based on or derived from another CodeLibra module (in the copyright sense), that's a license dependency. Example: You fork a CodeLibra-licensed library and build additional features on top.

• The dependency's code must be present for your module to work. If your module cannot function without the dependency's code being distributed with it, that's a license dependency. Example: Your application embeds a CodeLibra-licensed image processing library.

You should NOT declare a license dependency when:

• Your module calls an API or service. If your module communicates with an external API or service but doesn't incorporate the service's code, there's no license dependency.

• The dependency is available under a permissive license. If the dependency is available under MIT, BSD, or similar permissive licenses (even if also on CodeLibra), you don't need a CodeLibra license dependency—the permissive license already covers your use.

• It's a runtime dependency users obtain separately. If users install the dependency separately (not bundled with your module), there may not be a license dependency—but this requires careful analysis.

• The dependency is not on CodeLibra. You can only declare license dependencies for modules that exist in the CodeLibra catalog. Dependencies on modules outside CodeLibra are handled through their own licensing.

How License Dependencies Work

Declaration

When you onboard a module to CodeLibra, you identify which other CodeLibra modules are license dependencies. This creates a dependency graph:

Your Module
├── Dependency A (CodeLibra)
│   └── Dependency C (CodeLibra)  ← transitive
└── Dependency B (CodeLibra)

At Purchase Time

When a licensee purchases your module:

1. The system identifies all license dependencies (direct and transitive)
2. Calculates the composite price
3. Credits any existing licenses the buyer holds
4. Processes a single payment
5. Issues individual licenses to each module
6. Distributes revenue to all developers

Pricing

Composite Pricing

When a licensee purchases your module, they see a total price that includes your module's price plus each license dependency's price (set by the respective developers).

For example:

• Your module: $100/year
• Dependency A: $50/year
• Dependency B: $30/year
• Dependency C: $20/year (transitive through A)
• Total to new licensee: $200/year

Existing License Credits

If a licensee already has active licenses to some of your dependencies, they receive credit and aren't charged twice:

• Your module: $100/year
• Dependency A: $50/year (licensee already has this)
• Dependency B: $30/year
• Dependency C: $20/year (licensee already has this)
• Total price: $130/year (credited $70 for existing licenses)

Revenue Distribution

Revenue flows to each developer based on their module's price. Using the $200 composite example:

• You: 80% of $100 = $80
• Developer A: 80% of $50 = $40
• Developer B: 80% of $30 = $24
• Developer C: 80% of $20 = $16
• CodeLibra: 20% of $200 = $40

You receive 80% of your module's price regardless of dependencies.

Transitive Dependencies

Transitive dependencies are dependencies of your dependencies. If Module A depends on Module C, and your module depends on Module A, then Module C is a transitive dependency of your module.

CodeLibra handles transitive dependencies automatically. You only need to declare your direct dependencies:

1. Your module declares Dependency A
2. Dependency A has already declared Dependency C
3. When your module is licensed, both A and C are included

The total price reflects the entire chain. You don't need to manually declare transitive dependencies—they're included via their parent modules.

If your dependencies update their own dependencies, this affects the composite price for your module. Stay aware of changes in your upstream dependencies.

Managing License Dependencies

When You Onboard a Module

During initial onboarding:

1. Review your module's code to identify any incorporated CodeLibra modules
2. Search the CodeLibra catalog for each potential dependency
3. Add each relevant module as a license dependency

Be thorough—missing a dependency could create licensing issues for your licensees.

When You Add a New Release

With each new release:

1. Review any new code you've added
2. Check if you've incorporated any new CodeLibra modules
3. Update your license dependencies if needed

Each release records its direct dependencies, so different releases can have different dependency configurations.

Adding Dependencies to Existing Modules

If you add a license dependency in a new release of an established module, there's a special consideration: existing subscribers receive the new dependency license at no additional charge, but someone has to pay the upstream developer. CodeLibra requires you (the module developer) to cover this cost.

How it works:

• When you publish a release with a new dependency, you're charged for licenses to that dependency for all existing active subscribers
• This is a one-time charge, deducted from your account balance or charged to a payment method
• The charge is non-refundable
• New subscribers pay the full composite price going forward

Before adding dependencies to an established module with many subscribers, calculate the one-time cost: Number of active subscribers × Dependency price = Your cost.

This approach ensures existing subscribers aren't surprised with new charges, upstream developers are fairly compensated, and the licensing chain remains consistent.

Removing Dependencies

If a new release no longer requires a previously-declared dependency:

• Remove it from your license dependencies
• New subscribers won't pay for it
• Existing subscribers keep their existing dependency licenses (they're perpetual for the releases they cover)

No refunds are issued for previously-paid dependencies, and existing licenses aren't revoked.

Circular Dependencies

A circular dependency exists when Module A depends on Module B, and Module B depends on Module A (or longer chains that loop back). CodeLibra prevents circular dependency declarations—the dependency graph must be acyclic.

If you encounter this situation, redesign your module structure by extracting common code into a shared module that both can depend on.

Best Practices

Be conservative about declaring dependencies. When in doubt, declare the dependency. It's better to have a clear licensing chain than to risk licensing gaps.

Plan ahead. If you know you'll add dependencies in future releases, factor this into your initial pricing and planning. Remember: you'll cover the cost for existing subscribers.

Minimize dependencies. Only include what's necessary. Consider the composite price impact on your licensees and evaluate whether you could implement functionality yourself.

Document your dependencies. Keep track of which dependencies you've declared and why. This helps when reviewing for new releases.

Stay aware of upstream changes. Be aware of changes in your dependencies' licensing and pricing. Consider what happens if a dependency changes pricing significantly.

Common Questions

What if I'm not sure whether something is a license dependency? The key question is: "Does my module include code from this other module in a way that requires distributing that code?" If yes, declare it. If genuinely uncertain, declaring it is the safer choice.

What if a dependency is available both on CodeLibra and under a permissive license elsewhere? If you're using the permissive-licensed version (e.g., from npm), you don't need to declare a CodeLibra license dependency. But if you want the benefits of the CodeLibra version (support, updates through subscription), you can declare it.

What happens if a dependency is removed from CodeLibra? Existing licenses remain valid. However, new subscribers couldn't get that dependency through CodeLibra. This is rare and would be handled case-by-case.

Related Documentation

• Revenue Sharing — How earnings flow through the dependency chain
• Setting Prices — Pricing with dependencies in mind
• Bundled Licensing — Technical details of how bundling works