Decoding Software Licenses: An Introduction for Developers

Engineering teams are increasingly relying on open source software, with 80% of organizations reporting an uptick in its use over the past year[1]. This trend reflects a broad adoption of open source across various elements of the tech stack, from programming languages to operating systems and databases[1]. However, this surge in usage brings forth challenges, particularly in license compliance. This Bug Driven Development post is a Developer’s guide to license compliance, specifically we will be covering👇️ 

• Navigating Challenges with License Compliance

• Introduction to Common Open Source Licenses

• Understanding Licenses Faster using AI

• Incorporating License Compliance in your CI/CD Pipeline

🧭 Navigating Challenges with License Compliance

Tracking and maintaining an accurate log of all licenses used, along with providing proper attribution for each, stands as one of the most significant challenges in license compliance for engineering teams.

A striking 58% of organizations still handle attribution notices manually, and only 26% have fully automated their license compliance policy implementation[2]. This manual approach to compliance is not only time-consuming but also prone to inaccuracies, especially given the complexities and risks associated with direct and transitive dependencies in open source software[2]. Consequently, there's a pressing need for more automated and efficient processes to manage the increasing adoption and intricacies of open source licenses.

Further compounding the issue is the dynamic nature of software development projects. Open source components are frequently updated, and each update can bring new licensing terms or dependencies, creating a moving target for compliance teams. This fluid environment makes it challenging to ensure continuous compliance, as teams must constantly monitor and adjust their usage to align with the changing licensing terms. The manual processes traditionally used for this task are becoming increasingly unsustainable, highlighting the critical need for more advanced, automated solutions that can adapt to the rapid pace of open source software development and its associated licensing complexities.

I personally encountered these licensing challenges first hand, as the VP of Software Development at a prominent Telehealth startup. Our legal team delineated the licenses we could use, those we couldn't, and the ones requiring their approval. To ensure adherence, we conducted an annual third-party audit for compliance. However, while these audits are valuable, they're not sufficient. Developers need ongoing feedback on whether the components they use align with the licensing guidelines established by their organization. In the fourth section of this post, we'll explore setting up a GitHub action that helps facilitate this type continuous compliance monitoring process.

📚️ Introduction to Common Open Source Licenses

In the world of software development, understanding open source licenses is crucial. These licenses dictate how software can be used, modified, and distributed. Each license has its own set of rules and requirements, affecting everything from redistribution to attribution. Knowing these details helps developers make informed decisions and remain compliant. Below, we delve into some of the most common open source licenses, highlighting key aspects that developers should be aware of 👇️ 

1. MIT License

• Redistribution: Allowed

• Modification: Allowed

• Attribution: Required

• Notes: One of the most permissive and widely used licenses. It allows for great freedom in usage and modification but requires attribution in derivative works.

• More information about the MIT License can be found here

2. GNU General Public License (GPL)

• Redistribution: Allowed, but must remain under the GPL

• Modification: Allowed

• Attribution: Required

• Notes: Ensures that derivative works are also open source (copyleft). Requires that the source code be made available when distributing the software.

• More information about the GPT License can be found here

3. Apache License 2.0

• Redistribution: Allowed

• Modification: Allowed

• Attribution: Required

• Notes: Provides an explicit grant of patent rights from contributors to users. Requires preservation of copyright and license notices.

• More information about the Apache License can be found here

4. BSD License

• Redistribution: Allowed

• Modification: Allowed

• Attribution: Required, with variations depending on the specific BSD license (2-clause, 3-clause)

• Notes: Similar to the MIT License but includes clauses regarding the use of the name of the project or its contributors.

• More information about the BSD License can be found here

5. Creative Commons Licenses

• Redistribution: Varies by license

• Modification: Varies by license

• Attribution: Generally required

• Notes: More commonly used for creative works. The specifics of what is allowed (commercial use, modifications, etc.) vary depending on the specific Creative Commons license.

• More information about Creative Commons Licenses can be found here

Understand Licenses Faster using AI

Navigating the intricate landscape of software licenses on your own can be a daunting task, given their complexity and the nuanced legal language involved. Fortunately, advancements in AI offer a promising solution. Leveraging the cutting-edge capabilities of OpenAI's new GPTs, I've built a custom GPT designed to demystify software licenses called ‘License Guide’. License Guide is currently released publicly for free on ChatGPT 👇️ 

Let’s walk through how License Guide can help you understand software licenses better.

Learn About The Implications Of A Library’s License

When License Guide is asked about a specific library’s license. It does an extensive search and analysis on the library and the license. In the example below I ask License Guide “Am I allowed to distribute my React code given their current license?”. License Guide responds to this question by:

• Searching the web for React’s current license

• Providing an analysis of the license and its impact on distributing React code

• Citing sources of React’s license and articles about React’s license changes so you can further review them on your own or with your legal counsel

Answer Specific Questions about a License

License Guide can also answer specific questions about a License. In the example below we ask it “Can I use GPL-licensed code in a commercial product?”

License Guide then analyzes the GPL License and lets us know the points it recommends we should consider if we are going to use GPL licensed code in a commercial product.

General Information about a License

License Guide can also provide general information about a license so you can learn the generalized implications of a license. In the example below License Guide responds to “What does the MIT license allow me to do?“

I hope you enjoy using and find value in the License Guide tool! It has certainly been helpful for me recently.

Incorporating License Compliance in your CI/CD Pipeline

Integrating license checks into your CI/CD pipeline is a great way to simplify compliance for developers. In the fast-paced world of software development, where hundreds if not thousands of dependencies and rapid deployment cycles are the norms, keeping track of license compliance manually is not just impractical, it's a potential legal minefield. Automating this process within your CI/CD pipeline means every commit and build is scanned for license adherence, mitigating legal risks and ensuring your codebase stays compliant. This kind of automation aligns perfectly with the ethos of agile and efficient software development.

To put this into practice, let’s walk through how to utilize the 'License Compliance' GitHub Action in your GitHub Actions Pipeline 👇️ 

For this tutorial we are going to add the license-compliance action to a project I forked for a recent conference presentation (https://github.com/jtrugman/voxel51-presentation).

Basic Configuration

To get started with the license-compliance action, add a new GitHub Actions file to your .github/workflows directory. The YAML below will set up the action with the default ‘allow-list‘ for license compliance configuration 👇️ 

on: [pull_request]

jobs:
  CheckLicense:
    runs-on: ubuntu-latest
    steps:
      - name: License compliance check
        uses: mikaelvesavuori/[email protected]

Here is what it does:

on: [pull_request] tells GitHub to run this action as a part of you pull request workflow

jobs: CheckLicense: creates a new GitHub Action Job for us to run the license check

runs-on: ubuntu-latest tells GitHub to execute our job with runners that have the latest version of Ubuntu

steps: - name: License compliance check uses: mikaelvesavuori/[email protected] tells GitHub that the steps for the job is to run the license-compliance action and which version of the license-compliance action to use

The default ‘allow-list’ contains a very generous set of allowed licenses that is more than what most legal teams would allow in my experience.

In order for you to configure the license-compliance action to track to your specific compliance standards we need to further configure the action.

Advanced Configuration

In order for us to configure the license-compliance action to only use our specific license we need to add the following

with: allow_licenses: this will tell the action to only allow licenses on the allow list. It accepts a string containing the licenses you want to allow.

The example below is very extreme, but nicely demonstrates how to configure the action to only allow specific licenses (in this instance only MIT and Apache 2.0).

on: [pull_request]

jobs:
  main:
    runs-on: ubuntu-latest
    steps:
      - name: License compliance check
        uses: mikaelvesavuori/[email protected]
        with:
          allow_licenses: "MIT;Apache-2.0"

Here is the output that shows the action checks for licenses and validates that our dependencies are only licensed with MIT and Apache 2.0.

I hope you enjoyed this Bug Driven Development deep dive about license compliance! If you are interested in reading more about software licenses or more Bug Driven Development deep dives be sure to check out the links below.

Cheers,

Justin

Follow Justin on Twitter here

Additional Sources:

1. 2023 State of Open Source Report - Voices of Open Source

2. 2023 Open Source Management Trends, Predictions, and Observations - FOSSA

More Bug Driven Development Posts You May Enjoy:

• A Practical Developer's Guide to Shift Left Security

• Mastering Autonomy: The Path to Becoming a Senior Engineer

• Analyzing the State of Software Development in late 2023: Where We Stand and Where We're Going