Many projects start out with the intention of staying single license FOSSprojects. As your project grows, reality hits: some components or files mayneed to use different licenses than originally anticipated. There are manyreasons why this can happen: you may need to interface with projects ofanother license, you may want to import code from other projects or yourdevelopers may not understand the subtleties of the licenses in use. Besidesthe obvious challenges of managing mixed license FOSS projects, such aslicense compatibility and tracking what licenses you use, you are running therisk of exposing your project to unintended consequences. This talk will explore unintended consequences, risks and best practices usingsome examples from the recent history of the Xen Project. In particular wewill cover: 1. 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. 2. A worked example of a license change of a key component: process, pain points, their causes and how they could have been avoided 3. 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.