Onboarding a Module

This guide provides a detailed walkthrough of the module onboarding process, including all options and considerations.

Before You Begin

Eligibility Requirements

To onboard a module to CodeLibra, you must:

• Be at least 18 years old
• Have the legal right to license the code (you own the copyright or have appropriate agreements)
• Be able to complete identity verification for payouts
• Agree to the CodeLibra Account Terms

What You're Committing To

By onboarding a module, you represent and warrant that:

• Your organization owns all rights in the module or has proper authorization
• The module does not infringe any third-party intellectual property rights
• All information provided about the module is accurate and complete
• The module complies with applicable laws and CodeLibra's Acceptable Use Policy

The Onboarding Process

1. Starting the Process

From your dashboard or organization page, click Onboard Module to begin.

If you haven't created an organization yet, you'll be prompted to do so. Organizations are the entities that own modules and receive payments. Even individual developers need an organization (which can simply be named after yourself).

2. Connecting Your Repository

Supported Repository Hosts

Currently, CodeLibra supports:

• GitHub (public and private repositories)

Additional hosts are planned for the future.

Authorization

When you connect GitHub, you'll authorize CodeLibra to:

• Read repository metadata (name, description, visibility)
• Read repository contents (to verify license files)
• Read tags and releases

CodeLibra does not:

• Write to your repository
• Access other repositories without your permission
• Store your code (we only reference it)

Selecting a Repository

After authorization, you'll see a list of your repositories. Select the one you want to onboard.

If you don't see your repository:

• Check that you authorized access to the correct GitHub account
• For organization repositories, ensure CodeLibra has access to that organization
• Private repositories require explicit authorization

3. Basic Module Information

Module Name

Choose a display name for your module. This is how it will appear in the CodeLibra catalog and on license documents.

Tips:

• Use the same name as your repository/package for consistency
• Keep it concise but descriptive
• Avoid generic names that could confuse users

Slug

The slug is a URL-friendly identifier for your module (e.g., my-awesome-library). It must be:

• Lowercase letters, numbers, and hyphens only
• Unique across CodeLibra
• Between 3 and 50 characters

Description

Provide a brief description of what your module does. This appears in search results and the module page. Keep it clear and focused on the value proposition.

Module URL (Optional)

Link to your project's website, documentation, or landing page. This helps potential licensees learn more about your module.

4. Choosing Your Licensing Model

This is the most important decision in the onboarding process.

Option 1: Classic Dual Licensing

• Open-source license: A copyleft license (typically AGPL-3.0)
• Commercial license: The CodeLibra License (required for proprietary use)

This model means:

• Open-source users can use your module freely under AGPL
• Any company building proprietary software must purchase a CodeLibra License
• Strong incentive for commercial users to pay

Best for: Modules with clear commercial value where you want to ensure paid licensing for proprietary use.

Option 2: Voluntary Dual Licensing

• Open-source license: A permissive license (typically MIT)
• Commercial license: The CodeLibra License (optional)

This model means:

• Everyone can use your module freely under MIT for any purpose
• The CodeLibra License is available for users who want:
  • Formal commercial licensing terms
  • Support or service level agreements
  • Clear liability protection
  • To support your work

Best for: Modules where you want maximum adoption but offer optional paid licensing.

Selecting Your Open-Source License

Choose from the supported licenses:

• AGPL-3.0 (recommended for classic dual licensing)
• GPL-3.0
• LGPL-3.0
• MIT (recommended for voluntary dual licensing)
• Apache-2.0
• BSD-2-Clause
• BSD-3-Clause

Ensure your repository already uses this license or that you have the right to change licenses.

5. Creating Your First Release

A release represents a licensable version of your module.

Version Identifier

Use semantic versioning (e.g., 1.0.0, 2.3.1) for clarity. This version appears on license documents.

Selecting a Reference Point

Choose the git reference for this release:

• A tag (recommended)
• A specific commit
• A branch head (not recommended—branches change)

Release Notes (Optional)

Describe what's included in this release. These notes appear on the module page and help licensees understand what they're getting.

6. Identifying License Dependencies

What Are License Dependencies?

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.

When to Add License Dependencies

Add a license dependency when:

• Your module contains/bundles code from another CodeLibra module
• Your module is a derivative work of another CodeLibra module
• Proper functioning requires the other module's code to be present

Do NOT add a license dependency when:

• Your module merely calls an API or service (no code inclusion)
• The dependency is available under a permissive license outside CodeLibra
• It's a runtime dependency that users obtain separately

How to Add Dependencies

1. Search for the module by name in the CodeLibra catalog
2. Select the appropriate module
3. Confirm it should be added as a license dependency

Impact of License Dependencies

• Your licensees automatically receive licenses to all dependencies
• The total price includes your price plus all dependency prices
• Revenue is automatically distributed to all developers in the chain
• See License Dependencies for more details

7. Setting Your Price

What You're Pricing

Set the annual subscription price for your module only. Dependency prices are added automatically.

Price Guidelines

Consider:

• The value your module provides to commercial users
• Time saved vs. building the functionality from scratch
• Comparable pricing in your ecosystem
• Your module's maturity and reliability

You can always adjust pricing later—changes apply only to new subscribers and renewals.

Minimum and Maximum

• Minimum price: $1.00 per year
• Maximum price: No hard limit, but be realistic

8. Review and Publish

Before publishing, review:

• Module information (name, description, URL)
• Licensing model and open-source license choice
• Release details
• License dependencies
• Pricing

Once you click Publish, your module is live and available for licensing.

After Publishing

Making Changes

You can modify most settings after publishing:

• Description and metadata: Update anytime
• Pricing: Changes apply to new subscribers and renewals only
• License dependencies: Update with each new release
• Licensing model: Generally cannot be changed after first license is sold

Adding New Releases

As you develop your module:

1. Go to your module's management page
2. Click Create Release
3. Select the new version/tag
4. Update license dependencies if needed
5. Publish the release

Existing subscribers automatically have access to new releases.

If You Add New License Dependencies

When a new release adds license dependencies that existing subscribers don't have:

• Existing subscribers receive licenses to the new dependencies at no additional charge
• You (the developer) pay for these licenses from your revenue or another payment method
• This payment is required when publishing the release and is non-refundable

This ensures existing subscribers aren't suddenly charged more, while upstream developers are still compensated.

Common Questions

Can I onboard multiple modules? Yes, there's no limit on the number of modules you can onboard.

Can I onboard a module I contribute to but don't own? Only if you have authorization from the copyright holders to license the code commercially.

What if my module is already available under a commercial license elsewhere? That's fine, but ensure you're not granting conflicting rights. CodeLibra licensees receive rights under the CodeLibra License terms.

Can I remove my module from CodeLibra? You can stop offering new licenses, but existing licenses remain valid according to their terms.

Next Steps

• Setting Prices — Detailed pricing guidance
• License Dependencies — Deep dive on dependencies
• Revenue Sharing — How earnings work