Sublicensing

Sublicensing is the ability to grant some of your license rights to others. Under the CodeLibra License, sublicensing is carefully defined to balance flexibility with protection of developers' interests. This page explains what you can and cannot sublicense.

What Is Sublicensing?

When you have a license to use software, sublicensing means granting permission to others to use that software based on your license. It's a way of extending rights from yourself to third parties.

In everyday terms: you're licensed, and you pass some rights on to others.

The Two Types of Rights

The CodeLibra License distinguishes between two categories of rights:

Use Rights

The ability to:

• Execute, run, and operate the software
• Deploy it in production
• Use it for its intended functional purpose
• Include it as part of a working product

These can be sublicensed.

Development Rights

The ability to:

• Modify the software
• Create derivative works
• Make changes to source code
• Adapt or transform the software

These generally cannot be sublicensed.

What You CAN Sublicense

Sublicensing Use Rights to End Users

When you purchase a CodeLibra license to a module, you can sublicense use rights so that others can use your software products that incorporate the licensed module.

Example: You build an application using a CodeLibra-licensed database driver. Your customers run your application, which uses the driver. This is permitted—your customers have sublicensed use rights to the driver.

Sublicensing to Affiliates and Contractors

You can sublicense to:

• Your subsidiaries and related companies (Affiliates)
• Employees working on your behalf
• Contractors working for you

This enables normal business operations without requiring separate licenses for every team member or business unit.

Sublicensing for Use of Your Product

Your sublicensees can do what's necessary to use your product:

• Install it
• Run it
• Configure it
• Maintain it operationally

As long as they're using your product (not developing independently with the module), this is covered.

What You CANNOT Sublicense

Development Rights to Third Parties

You cannot grant your customers or other third parties the right to:

• Modify the licensed module
• Create their own derivative works of the module
• Use the module as a foundation for their own development

If your customers need development rights, they need their own CodeLibra License. See Bundled Licensing for how to enable this through CodeLibra.

Independent Use

You cannot grant sublicensees the right to:

• Use the module separately from your product
• Extract the module for their own purposes
• Redistribute the module independently

The sublicensed use is tied to using your product.

Further Sublicensing for Development

Your sublicensees cannot further sublicense development rights to others:

• Your customers can't grant their customers development rights to the underlying module
• The chain stops at use rights

Why These Restrictions Exist

Protecting Developer Interests

Module developers choose dual licensing to create a sustainable business. If licensees could freely sublicense development rights, it would undermine this:

• One license could serve an unlimited number of developers
• Developers would lose their revenue stream
• The incentive to maintain and improve modules would diminish

Maintaining Fair Economics

The restrictions ensure that:

• Each organization doing proprietary development has their own license
• Developers are compensated proportionally to their commercial impact
• The licensing system remains sustainable

Clear Boundaries

By separating use from development rights, the license creates clear boundaries:

• End users know they can use products built with licensed modules
• Developers know they need their own licenses for development
• Everyone knows where they stand

Practical Scenarios

Scenario 1: SaaS Application

You build a SaaS product using a CodeLibra-licensed module.

What's sublicensed: Your customers use your SaaS (which runs the module). They have sublicensed use rights.

What's not needed: Your customers don't need their own licenses—they're using your service, not the module directly.

Scenario 2: Desktop Software

You create desktop software that includes a CodeLibra-licensed library.

What's sublicensed: When customers install and run your software, they're using the library under sublicensed use rights.

What requires more: If customers want to modify your software or the library, that's development—they'd need their own licenses.

Scenario 3: Developer Tool

You build an IDE plugin using a CodeLibra-licensed parser.

The challenge: Your customers (developers) might reasonably expect to extend or modify the plugin.

The solution: Use Bundled Licensing so customers get direct development licenses to the parser.

Scenario 4: API Service

You run an API that internally uses CodeLibra-licensed modules.

What's sublicensed: Customers calling your API are using your service. The modules are your implementation detail.

What's not: Customers aren't directly using the modules, so sublicensing isn't really the frame here—they're just using your API.

Sublicense Terms Requirements

When you sublicense, certain requirements flow through:

Required Disclaimers

Your sublicenses must include warranty disclaimers and liability limitations at least as protective as those in the CodeLibra License. You can't make promises about the module that the original license doesn't make.

No Expansion of Rights

You cannot grant more rights than you have. The sublicense is bounded by your own license.

Compliance

Sublicensees must comply with the terms that flow through. If they violate the terms, it can affect your license too.

Documenting Sublicensing

For End Users

In your software's license agreement or terms of service, you typically:

• Note that your product includes third-party components
• Reference that some components are licensed under the CodeLibra License
• Include appropriate disclaimers and limitations
• Clarify that users receive use rights, not development rights

For Affiliates and Contractors

Internal policies should:

• Identify which CodeLibra-licensed modules are in use
• Clarify that development rights are tied to the corporate license
• Ensure work done under the license stays within the organization

Common Questions

Do I need to tell my customers they're receiving sublicensed rights?

Good practice is to acknowledge third-party components in your software. You don't need detailed sublicensing notices, but transparency is good.

What if my customer wants to modify my software (which includes the module)?

If they want to modify the licensed module portion, they need their own license. If they're modifying your code (which you own), that depends on your agreement with them.

Can I sublicense to a distributor or reseller?

For use (e.g., they bundle and resell your product): Generally yes. For development: No, they'd need their own licenses.

What about open-source derivatives?

If someone uses your open-source code (licensed under the open-source license), the CodeLibra License sublicensing rules don't apply—they're using under the open-source license instead.

Can I charge for the sublicense?

Your customer is paying for your product, which includes sublicensed rights to components. You don't need to break out the sublicense as a separate charge.

Summary

Related Documentation

• Bundled Licensing — Enabling downstream development
• The CodeLibra License Explained — Full license overview
• Getting Started for Subscribers — Understanding what your license includes