In developing applications for Fedora Infrastructure we have to worry about how the licenses we use in various bits of code we write interact with each other. This page is to help formulate a plan of action for hw we are going to license works we generate in Fedora Infrastructure to make optimal use of our work.
- Be able to share code among the various pieces we write.
- Not have our libraries force a specific license on the apps that we write.
- Not have conflicting licenses between our apps and our libraries
- Have a clear understanding of the steps we must take whenever we want to move code from an application under one license to a library under a different one.
- Protect the code we write from being taken proprietary (note, this is not the same for every author, MM for instance is under the MIT/X11 License).
We need to understand how our licensing choices help or hinder accomplishing our goals in order to come up with a plan of action.
- Can the authors of a work (especially Red Hat employees) relicense their code at will?
- Can Fedora relicense code under the CLA?
- GPLv2 and AGPLv3/GPLv3 are incompatible for combining and linking in compiled languages. How does that work in dynamic languages? Especially python.
- With code licensed under the AGPLv3, do we need to link/be able to distribute to people the exact code that is part of the applications? ie: if we hotfix something on hte server, do we need to distribute the hotfix as well?
- Does this extend to libraries that the app depends on?
In general, Fedora Infrastructure has chosen to use the family of Fedora GNU Public Licenses in order to keep the software free. The particular licenses chosen aim to make the software compatible with as much software as possible while still keeping this goal.
The preferred license for web applications written for Fedora Infrastructure is AGPLv3+. This license protects the web application from being taken proprietary as it covers the use of the application as a service provider, not just redistribution of the modified software.
The preferred license for python modules and other libraries is LGPLv2+. This lets us use the library with applications with different licenses like MIT and not force the application as a whole to fall under the GPL.
The preferred license for scripts and non-web applications that we write is GPLv2+. This lets our code be used in both GPLv2 and GPLv3 code bases.
Note that working with upstreams that have their own licenses or preference of a developer who is not Red Hat employed can lead to different licensing choices on a case-by-case basis. This guidance is meant to make life easier for us as we develop web applications while supporting the expansion of free software. We must be be flexible when a different license is better for growth of free software.
- All web apps written by Red Hat employees for Fedora Infrastructure should be AGPLv3+ unless there's a compelling reason not to.
- All python modules written by Red Hat employees should be LGPLv2+ unless there's a compelling reason not to.
- Web apps written for Infrastructure by others must be code-sharable with this but do not need to be the same license (ie: MIT, BSD, Public Domain, are okay for either libraries or apps. GPLv2 and GPLv3 web apps are okay. LGPLv2 or LGPLv2+ libraries are okay).
- Authors of applications can be asked to shift code into modules which requires relicensing to LGPLv2+. In general we want to do this even though it might take code to a more permissive license as having it in a library is being done to promote sharing of code.
- Except in exceptional cases, we will not relicense if the author disagrees with the change in license.
- All hotfixes to web apps running on the server needs to be made available under the AGPLv3+ so that users can get the code that we're actually running. We still need to discuss the best method of making this happen (a branch in source control for precisely what's running at any given time? hotfixes distributed by puppet and also uploaded to a web site?)