How GitHub license compliance works Under the hood, license compliance checks are enabled via rulesets. We target repositories via a custom property, where the value of the property determines whether license checks are enabled in “Active” or “Evaluate” mode. In repositories that are targeted by a ruleset, pull requests that modify a project’s dependencies trigger a scan that looks up the licenses used by each of the new dependencies. If the new dependencies’ licenses are already permitted, or there are package-specific exceptions, the checks pass. If there are failures, either in the direct or transitive dependencies, the tool comments on the pull request with alerts for each problematic package. 
The developer then reviews the alerts. If they decide the dependency is unacceptable, they can update their code or close the pull request to remove it. If they believe the license or package should be allowed, they can raise an exception request which will notify a specific team in the organization who can decide whether and how to amend the policy. A day in the life of the license policy team GitHub’s license policy team consists of OSPO members and engineers with expertise in license reviews and supply chain analysis. Since we are a worldwide company, our policy review team has members across time zones to review alerts in a timely manner. We are in the process of formalizing an SLA for reviewing license requests, but in practice it’s rarely more than a couple of hours before we can triage an incoming request. Team members receive email notifications of new review requests and can also access a dashboard to see the backlog of pending requests. 
When approving a request, we have two decision points: first, whether to permit the license or the package. Then, decide what scope – enterprise or repository – to use. If it’s a safe license that simply hasn’t shown up before, we’ll add it at the enterprise level and thus allow dependencies with that license anywhere at GitHub. Some packages carry a commercial license which can’t be permitted everywhere but should be allowed in the repository owned by a team which has paid for the software, so those policy amendments get added at the repository level. Package exceptions are useful for internal software which usually doesn’t have license data associated with it. Helpfully, the tool supports wildcard matches for package exceptions. For example, we’ve permitted everything in the @github-ui/* React namespace, so we don’t need to approve those packages one by one. Making it easy for developers To support this process, we’ve established procedures about contacting the GitHub OSPO, and how to use an emergency “break glass” override. These situations should be rare, but a clear emergency override process is essential for critically time-sensitive pull requests. As we mentioned above, the license policy enforcement happens via ruleset, and the ruleset condition keys off a custom property. So toggling the value of the property can temporarily turn off enforcement if there’s a critical fix that’s blocked by a license alert. So far, we’ve only needed to use this once, but it was very helpful to have the option. We’ve also provided internal documentation and training to help developers understand the importance of license compliance. Ultimately, it’s everyone’s job to help ensure compliance and manage risk and it’s our job to make that as easy as possible. Wrapping up License compliance is a critical part of managing our software supply chain. By helping developers make informed dependency choices aligned with GitHub’s license policy we prevent costly rewrites and potential legal problems. We’ve been enthusiastically using and providing feedback on the new GitHub License Compliance feature for several months. Now that it’s in public preview, we are excited to see more companies adopt it and hope our experience provides some guidance if you’re just getting started. GitHub Enterprise Cloud customers can use the License Compliance feature across repositories which have an active GHAS Code Security license. For more information, see About open source license compliance. The post How GitHub maintains compliance for open source dependencies appeared first on The GitHub Blog. Source: https://github.blog/enterprise-software ... endencies/