We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Mixed License FOSS Projects

Formal Metadata

Title
Mixed License FOSS Projects
Subtitle
Unintended Consequences, Worked Examples, Best Practices
Title of Series
Number of Parts
611
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language
Production Year2017

Content Metadata

Subject Area
Genre
Abstract
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.