The Open Policy Agent (OPA) licensing model has changed, and the shift is more than legal fine print. It impacts how you adopt, integrate, and scale policy-as-code across clouds, pipelines, and products. If your team relies on OPA for authorization or compliance, you need to understand not just the code, but the rules around it.
OPA started under the Apache 2.0 license, a permissive open-source model trusted by teams worldwide. That license meant you could take the source, modify it, embed it, and ship it without much restriction, as long as you followed attribution requirements. For companies building authorization layers, this was a green light.
But with the project’s growth and adoption, its licensing model evolved. Parts of OPA now use the BUSL (Business Source License). Unlike permissive licenses, BUSL is source-available, not open-source in the strict definition. You can still inspect the code, run it, and develop with it, but certain commercial uses may require a separate agreement. The BUSL also includes a change date—after which the code falls back to an open-source license—usually after a set number of years.
For teams, the main question is simple: is your OPA usage compliant with the current license terms? If you’re embedding OPA into a product or offering it as a service, you may need to review the rules. For internal use, most scenarios remain straightforward. For public and commercial deployments, the BUSL terms are key.