This post was written by Shane Coughlan and originally published on the FOSSA Medium Publication.

If you work in consumer electronics, drones, IoT, or automotive devices based on generic Linux or Android codebases, chances are you have encountered a variant of the GPL License and had to comply with the applicable terms.

For the most part, compliance engineering is centered around the GPL Version 2 (GPL hereafter), a copyright license that is triggered when distributing code. Software such as the Linux kernel or commonly-used versions of GNU userland tools fall under this license. To comply with the GPL, you must engineer your process with a good approach, toolbox and policies. Sometimes this means scanning source code and automating compliance work with tools like FOSSA. Sometimes it means scanning binary code to confirm its content. In practice, a lot of work is centered around distributed code — especially firmware downloads and physical products sent to market.

Armijn Hemel and I released a book that covers many of the practical details in April. Since then we have been releasing components to the OpenChain Project as tools for everyone to use, study, share and improve. In this blog post, I’m taking some of the best content and present to you the “The Ultimate GPL Survival Guide”.

Rocking copyleft requirements

One of the areas where people have the most difficulty understanding how the GPL’s copyleft requirements translate to practical, real-world action items.

Open Source professionals like Arnoud Engelfriet  have been sharing suggestions for various flowcharts for years — below we will explore some of the most helpful charts to deal with common cases when interacting with GPL code.

Creating a governance process

Flowchart #0 is a great example of what we need to assist our work as compliance engineers to keep code clean. It is short, clear and applicable to physically distributed devices. It pre-assumes relatively light and responsive infrastructure to support it:

  1. An “approved” list of Open Source licenses.
  2. A “rejected” list of Open Source licenses.
  3. A contact in the legal department to deal with any edge cases.
Flowchart #0: General Approval Flowchart. With thanks to Royal Philips Electronics

Handling obligations around distributing code

The bulk of the work you do with the GPL ends up popping up around when/how you distribute code. Different mediums of patching, updating and shipping software fundamentally affects what the GPL requires you to do:

Flowchart #1: How Do I Distribute?

Flowchart #2: Device or offline distribution

Flowchart #2: Offline Distribution

Flowchart #3: Updating firmware

Flowchart #3: Firmware Updates

Flowchart #4: Over-the-air updates

Flowchart #4: Over The Air

Naturally not all code is GPLv2. Sometimes you are dealing with Library or Lessor GPL (LGPL) code. Sometimes you are dealing with Modified BSD or Apache licensed code. Simple, clear flowcharts can be created for these use-cases too.If you are using a weak copyleft license like the LGPL, you can use this example in Flowchart #5 that covers LGPL distribution:

Flowchart #5: LGPL Code

Adding compliance “checklists” to your process

Apart from individual tasks when you distribute, staying on top of compliance involves integrating ongoing processes at your organization.

When used properly, checklists can be a useful way to manage GPL compliance as well as communicate a process inside your company. They key is to start simple to avoid too much upfront process and review. Good compliance processes are ultimately a balance of work and risk.

Use the template below as a way to start, and then add/customize as your organization grows in complexity:

General Compliance Checklist

When it comes to more custom or complicated use cases, you might elect to add more specific checklists to address specific compliance goals. For example, when running builds of your product, the GPL requires you to distribute the “complete and corresponding” source code if incorporated in certain ways. Below you can find another checklist for this use case:

Checklist for Rebuilding Product X

Plenty of options exist for more comprehensive checklists. A great place to start is the Open Compliance Program Self-Assessment Compliance Checklist. This is a more detailed list running through the whole process and may be required for a larger organization. This checklist, like the material above, is free of charge and freely available so you can explore what is best to meet your requirements.

Learn More

Practical GPL Compliance is a book written by Armijn Hemel and myself that was released at the end of April 2017. It is the culmination of ten years of working together in the Open Source compliance field. We started in European NGOs like GPL-violations.org and FSFE. As time went by our activities became more global and we started to address a more business-orientated audience. Our book bridges some of the knowledge obtained from and useful for both sectors: https://www.linuxfoundation.org/news-media/research/practical-gpl-compliance

OpenChain is the industry standard for open source compliance in the supply chain. The OpenChain Project builds trust in open source by making open source license compliance simpler and more consistent. The OpenChain Specification defines a core set of requirements every quality compliance program must satisfy. The OpenChain Curriculum provides the educational foundation for open source processes and solutions, whilst meeting a key requirement of the OpenChain Specification. OpenChain Conformance allows organizations to display their adherence to these requirements. The result is that open source license compliance becomes more predictable, understandable and efficient for participants of the software supply chain: https://www.openchainproject.org/

Footnote — Flowcharts and Checklists

Want other formats?

Get the checklists in DOCX, ODT or PDF format.

Get AI, PDF, PNG, PSD and SVG formats of the Flowcharts at:
https://wiki.linuxfoundation.org/_media/openchain/practical-gpl-compliance-flowcharts.zip