Licensing

Licensing compliance is a huge blocker for adopting open source packages. Tidelift guides you to meet common compliance requirements, so commercial users are more likely to adopt your package.

We need you to help us ensure that we have the correct information about the licenses of your lifted packages so that subscribers can make informed decisions about dependency usage. If any are incorrect, we'll notify you when the issue has been fixed so that you can verify them again.

See a walkthrough of these tasks.

Use an open source license

Lifted packages must be under an open source license, such as those approved by the Open Source Initiative.

Fixing up license metadata

If a subscriber has thousands of dependencies, they need a way to list the licenses of those dependencies.

We have lifters fill in license metadata fields consistently and accurately. We've found that a surprising number of packages have mistakes in this area.

Our goal is to have an accurate SPDX identifier for the license or licenses associated with each package.

Add missing license metadata

The lifter dashboard will alert you and prompt you to fix it if we couldn't find the license for a package.

Usually the package manager will have a metadata field for this. For example,

Fix conflicting license metadata

GitHub attempts to figure out your repository's license and makes the result available via their API. If GitHub's reported license differs from the one in your package metadata, the lifter dashboard will alert you and prompt you to fix it.

If you have any trouble figuring out where bad metadata is coming from, ask us to help.

Help us understand any dependencies with a more restrictive license

When a package depends on a different package with a legally-conflicting license or more-restrictive license, it may be a mistake, and may raise flags for subscribers.

We don't require that you (or your dependencies) use any particular license, as long as it's open source, but we confirm a situation like this is deliberate. We also provide subscribers any relevant information—for example, the dependency with a conflicting license might not affect subscribers if it's used only during the build and not as part of the library's runtime.

So we'll notify you look at any flags raised here and let us (and subscribers) know what's up.

Agree to work with subscribers to fix violations

In the lifter agreement you sign to become a lifter, you agree that should a subscriber violate your license, you'll work with them to solve the problem prior to filing a lawsuit. This language is based on the GPL Cooperation Commitment.

Agree that you wrote your contributions

In the lifter agreement you sign to become a lifter, you certify that you wrote the code you've contributed to the project, or that you got it from another source where it was under an appropriate open source license. This language is inspired by the Developer Certificate of Origin.

Did this answer your question? Thanks for the feedback There was a problem submitting your feedback. Please try again later.

Still need help? Contact Us Contact Us