Mixed License FOSS Projects: Unintended Consequences, Worked Examples, Best Practices

Many projects start out with the intention of staying single license FOSS projects. As your project grows, reality hits: some components or files may need to use different licenses than originally ant …

Many projects start out with the intention of staying single license FOSS projects. As your project grows, reality hits: some components or files may need to use different licenses than originally anticipated. There are many reasons why this can happen: you may need to interface with projects of another license, you may want to import code from other projects or your developers may not understand the subtleties of the licenses in use. Besides the obvious challenges of managing mixed license FOSS projects, such as license compatibility and tracking what licenses you use, you are running the risk of exposing your project to unintended consequences. This talk will explore unintended consequences, risks and best practices using some examples from the recent history of the Xen Project. In particular we will cover: Refactoring can lead to licensing changes: best practices and unintended consequences when importing code from elsewhere. Making code archeology easy from a licensing perspective and why it is important. A worked example of a license change of a key component: process, pain points, their causes and how they could have been avoided The perils of LGPL/GPL vX (or Later): the unintended consequences of not providing pre-defined copyright headers in your source base We will conclude with a summary of lessons and best practices from both the Xen Project and a quick overview of how usage of SPDX and other tools may help you.