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.
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,
- Maven has a licenses section in pom.xml; ideally, use an SPDX identifier in the
- npm uses an SPDX identifier in the
- PyPI packages list license classifiers
- Rubygems has
licensesfields which can be set to an SPDX identifier
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.