How can we scale the legal work when projects get bigger?
This talk is based on a paper that Ibrahim published for Linux Foundation.
Open source strategy
Smart companies have an open source strategy and the tools to support it.
- Clear internal open source governance
- Clear policies
- Clear guidelines
- Clear process
The process of compliance: starting from incoming software, resulting in outgoing software and the text accompanying it.
- Audit (using scanning tools) and identify issues
- Resolve issues
- Approve the results
- Register the components
- Collect the notices
- Create a distribution
- Verify the result
Many different people are involved in the process. Open source compliance staff scans the code and collects results. Legal counsel reviews it and advises.
Legal counsel is often the bottleneck: you don’t have many of them, and even fewer are familiar with OSS. Roles:
- Establish the compliance program.
- Train developers etc. around open source licenses.
- Approve OSS software for a specific project – here lies the bottleneck since it has to be done on a daily basis.
Tips and tricks to make legal counsel scalable
= a list of standard licenses with a summary of restrictions and obligations for each of them. Cfr. tldrlegal.com
= which things can and cannot be combined + what will the resulting license be. You can prepare it for the 10-15 most used licenses. EFF provides one for combinations of GPLs. Unfortunately, compatibility is not always objective, and is interpreted differently by e.g. EFF or Apache. Also confusing is the definition of derivative work, which is even different in different countries and in any case depends on how the software is combined.
If you don’t know the answer, send an e-mail to the license author or the package maintainers.
Ranking system that tells you which steps you can skip if this is the license. 1. Not approved, against policy; 2. low chance of approval; … 5. Pre-approved so it is always accepted (e.g. MIT). Diferent buckets require a different level of approval. It’s also possible to bucket things based on obligations, e.g. if it has a patent clause you’ll need additional approval. The idea is that the approval is focused and verifying if the way that it is used agrees with the company policy. You can also pre-approve people, e.g. people contributing to a specific OSS project don’t need additional approval for contributions to that project.
Approved software license interactions
The effects of a license depend on how that piece of software interacts with other software, e.g. through shared libraries, user/kernel space, scripts, … The company can define a number of standard interactions (e.g. function call, sharing headers, …), and then describe how licenses are affected by this. This way, you end up with a compatibility matrix per type of interaction (e.g. static/dynamic linking).
If you go through a checklist a couple of times, it becomes the default behaviour. So each step in the process that you can put into a checklist becomes much more predictable/mechanical/objective.