How to successfully roll out developer-first license compliance

License compliance has traditionally been perceived by developers as a blocker but it does not need to continue to be regarded as such. License compliance is crucial for being able to minimize the risk to the business but the only way to do so at scale and without impeding development is with a developer-first mindset.

Ultimately, developers are the ones deciding what to use in their software. Achieving software license compliance can only happen if developers are properly empowered to make the right compliance decisions, have the right tools to do so, and are working together with compliance teams exercising the right degree of governance.

The importance of developer autonomy

Software is the engine driving digital transformation and the world today revolves around the builders of this software—developers. For us to remain competitive in our respective markets, we expect these builders to do everything in their power to deliver value at a rapid pace. They need to own their systems, end to end—i.e. understand the need, devise the solution, implement it, deploy it, operate it, and learn from the experience. Rinse and repeat.   

For this process to succeed, developers require the autonomy to make decisions and the right tools to implement them. Every time an interjection by an external team is required, the process is slowed down and friction is created. Fundamentally, this goes against what the business is trying to achieve—speed at minimum risk.

License compliance is notoriously one of those areas where developer interaction has not been successful. Usually applied late in the development lifecycle, manual and rigid compliance processes tend to impede development workflows.

But it doesn't have to be so. License compliance can be rethought and made developer-first by addressing three key concerns—developer empowermentand developer usability to ensure developers can embrace license compliance, and governance to ensure the right decisions are being made.

Empower compliance decisions

Developers make countless decisions every day and so the goal should be to help them make the right compliance decisions.

Test as early as possible

Presenting developers with a list of license issues after the build process has been completed is not only counterproductive but it only adds to the friction between developers and the controllers. To empower developers to make compliance decisions, they need to be able to detect a non-compliant component as early as possible to save them the trouble down the road. This starts with their local development environments, and continues throughout their Git flow and subsequently during CI/CD.

Separate the black and white from the gray

With more than 200 open source licenses being used today, developers need a clear understanding of the risk they might be introducing when making the decision to include one component over another.

Not every license is a GPL license, presenting a clear hard line for the developer. Some licenses are much more ambiguous and open to interpretation. Consider, for example, an open source component with a license requiring attribution. Developers can then determine whether indeed attribution has been given or not. Or an unknown license, where the developer needs the knowledge and tools to decide whether to proceed and inform compliance in the background or to stop developing until the green light is given.

The more context is given to developers, the better equipped they are to assess the risk vs. the value associated with the open source component being considered. This context can be provided with developer training on the one hand, and developer tooling that provides contextual information on license issues such as copyright info, on the other.

Progress in parallel

Development teams cannot afford to wait for the end of the project before engaging with the controllers. This sequential approach is no longer tenable in the world of continuous development and will only cause friction where it is not warranted. Instead, developers and controllers need to foster a good relationship in which compliance is implemented in parallel.

Developers, on their part, need to know how and when to engage controllers early on by initiating contact even if inconvenient or tough. Controllers should support the conversation and guide it in the form of advisories, training and information sharing.

Drive adoption with developer usability

Developers are being tasked with a lot of new responsibilities, security and compliance included, but are not experts in each of these new areas. If we want them to embrace compliance, it’s important for us to invest in making it easy for them to make and implement the right license compliance decision.

Integrate into development workflows

The likelihood of a development team implementing time-consuming and counter-productive license compliance workflows is highly unlikely, and forcing them to do so will, of course, result in mistrust and animosity.

Fitting into existing Git-based workflows in a frictionless and native way—as opposed to external integration—will go a long way in driving developer adoption.

Provide visibility

The more visibility developers have, the easier it is for them to act upon license issues once detected. Look for a solution that goes beyond simply presenting you with a list of license issues and that can provide a clear path to resolution.

Snyk’s approach, for example, is to describe license issues in an application context and not an artifact context, presenting developers with a full dependency tree to understand the precise path by which the issues were introduced. This gives developers the clarity they need to make quick, informed decisions.

“Continuous compliance”

In a world where the adjective “continuous” precedes almost every process in the modern software development lifecycle, it goes without saying that automation is a key consideration for making license compliance more developer-friendly. 

Automating license compliance throughout the SDLC helps reduce friction and maximize developer productivity. CI/CD builds that include license testing as a step is a great way to start, providing testing is accurate. Automation is important but if builds are continuously failing because of bad policies, the opposite result will likely be achieved.

Flexible vs. rigid governance

To have the confidence to empower development, visibility is key. The components going into every iteration of the build must be tracked automatically and consistently, with the support of dashboards that present that information in an easy to consume fashion.

This is true for any risk management, but it's especially true for legal compliance. Organizations need to know what's going on and cannot rely on review meetings as the sole source of information—it has to be in the technology.

Once that's in place, an investment must be made in making the crucial distinction between hard lines and soft lines in governance.

Every compliance officer knows that not everything is black and white, and sometimes all that’s required is a demonstration that a reasonable effort was made. For areas that aren’t black and white in our context, let’s consider whether finding an issue shortly after its deployed and addressing it then could be deemed as “reasonable effort”. It often does, and embracing that approach will allow us to disrupt development less.

Making that distinction makes a world of difference to the development team. It separates between not allowing a developer to get something out and breaking the build to alerting the compliance team that a questionable license has been deployed so they can quickly assess it and decide whether to take action or not.

Ideally, that conversation happened in parallel. The better the interaction between the development team and the compliance team, the more this conversation would have happened at the beginning of the development workflow. But if it happened later, it doesn't mean the cord needs to be pulled and everything stopped. That just creates animosity.

Summing it up

In a world increasingly focused on developer autonomy and speed, license compliance is typically anything but empowering to developers. This doesn’t need to be the case—we can make license compliance developer-first.

Snyk empowers developers to embrace license compliance by providing a developer-first solution, with developer-friendly tooling, flexible governance, and end-to-end visibility, resulting in more compliant code and, ultimately, reduced risk. Learn more here, or get started yourself for free.