What is Component License Risk?
What is License Risk?
A component is open source when its author(s) distribute it with an open-source license attached. Open-source licenses place restrictions on the component’s use, and these restrictions are the source of all license risk.
License risk can be divided into two categories: the cost of complying with the license and the cost of failing to comply.
Complying with the license could mean notifying customers of their rights, the license, and your modifications to the component. It may mean granting certain patent rights to the user. Most impactfully, it may require that you release your software as open source.
Failing to comply with the license means that the component’s author can issue take-down demands or request payment. You could also end up in court. **There’s significant legal precedent around open-source licenses,** and courts have a history of affirming them as legally binding.
Identifying License Risk
As a general rule, it’s good to assume that any component that appears in the final build of your application has the potential to introduce risk.
To get a sense of a component’s license risk, check the package for a readme or a text file called “license” and review it carefully. License terms are usually written in plain language. Pay attention to the name of the license. Most common licenses have their own websites that help make things more clear.
Look for language that describes what the end-user must be notified of, if anything. Also look for language about “derivative software” – in the context of open-source components, your app is derivative of a component if it contains that component in the final build.
Components do not need to be reachable by the user in order to introduce license risk into your component. If the component is present in the final build of your app, license restrictions apply.
Gauging Your Risk and Risk Tolerance
When trying to reconcile your level license risk with your risk tolerance, consider the following three factors:
- The level of difficulty of compliance. Some restrictions are easy to comply with. For example, notifying the end-user about the presence of a component in your app could be as simple as adding a page to your public-facing documentation.
- The method of distribution. Restrictions, and therefore license risk, “activates” when the app is distributed. An app you host, or an app that’s only used internally, may avoid license risk altogether.
- The business goals of your app. For example, if you’re distributing an app at no cost as part of a free-to-paid pipeline, a restriction that the app must be made open-source may be acceptable.
Worst-Case Scenarios
If you fail to comply with an open-source license’s restrictions and you end up in court, your business could face serious consequences besides the cost of the legal battle. In one famous example, Cisco, through their subsidiary Linksys, was taken to court by the Free Software Foundation. As a result of the lawsuit, Cisco released its software as open source and made an undisclosed financial contribution to the FSF. Take that as proof that no one is exempt from license risk.