Over the past few months, Fedora Infrastructure has been discussing having a consistent set of licenses for applications and scripts we create for Fedora. The goals of doing this were to
* Be able to share code among the various programs that 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. Mirrormanager, for instance, is under the MIT/X11 License). * Be able to stay compliant with licenses within our production, staging, and publictest environments
At last week's meeting we made a decision about which licenses would best fit our needs. The results are recorded here: https://fedoraproject.org/wiki/Infrastructure_Licensing
The basics are: * license code that is meant to be used as a library as LGPLv2+. * license code that's meant to be used as an application as GPLv2+. * If we want to write something and use another license we should discuss it to figure out how it's going to impact us and whether there's a better way to achieve our goals first.
Most of our apps are currently under GPLv2(only) so we're going to be working to change the licensing on those apps over time to reflect GPLv2 or later. If you find something that we've written that's not under GPLv2+ (or LGPLv2+) that you want to use, please let us know so we can either get to work on making the license match the guidelines or let you know why it's not being changed.
The one other thing for Infrastructure developers and System Admins to note in the Policy is the section on handling AGPLv3 applications. During the discussions about whether to use AGPLv3+ for our web applications we found and delimited many issues that need to be addressed when deploying AGPLv3+ licensed code. The aGPL portion of the policy is our first attempt at keeping us compliant with any code that is under this license. Highlights are:
* Apps deployed to production under AGPL must be deployed from RPMs. Any hotfixes to those apps must have the patch in a ticket in trac on http://fedorahosted.org/fedora-infrastructure with the keyword HOTFIX. * Any AGPL app deployed in infrastructure must have links in the footer to the fedora-infrastructure SRPM repo and the trac query that pulls up our hotfixes so that people can find the exact source that we're running at any given time. * Staging must follow the same rules regarding SRPM and hotfixes. Once again, failing to link to the exact source for what we have running would put us out of compliance. * No AGPL apps can be hosted on publictest boxes at this time as publictest boxes are intended for development and the high rate of change in development is not conducive for constantly updating RPMS or patches in trac. If there's demand for publictest hosting of AGPL apps we'll need to design some method of restricting who can access the applications running there to satisfy the legal requirements.
-Toshio
On Thu, Sep 03, 2009 at 02:17:44PM -0700, Toshio Kuratomi wrote:
At last week's meeting we made a decision about which licenses would best fit our needs. The results are recorded here: https://fedoraproject.org/wiki/Infrastructure_Licensing
I don't see any listing of content licenses. Other than what you put on the wiki that is covered by that license (soon to be CC BY SA), have you thought about specifying what you license content under?
- Karsten
On 09/03/2009 11:38 PM, Karsten Wade wrote:
On Thu, Sep 03, 2009 at 02:17:44PM -0700, Toshio Kuratomi wrote:
At last week's meeting we made a decision about which licenses would best fit our needs. The results are recorded here: https://fedoraproject.org/wiki/Infrastructure_Licensing
I don't see any listing of content licenses. Other than what you put on the wiki that is covered by that license (soon to be CC BY SA), have you thought about specifying what you license content under?
For content inside of apps/libraries (Like the documentation for python-fedora http://fedorahosted.org/releases/p/y/python-fedora/doc/ generated from the tarball) I would think it would follow the app's licensing. If you can think of good reasons to put it under a different license, we should talk about it. (Note that parts of the documentation there are extracted from the source. Not sure if that affects things).
For content on the wiki we're covered by the license for the whole wiki.
For content like CSI, I don't think we had thought about it. I would lean towards going with the license that docs uses. mmcgrath has been the most prolific in that area, though.
-Toshio
On Thu, 3 Sep 2009, Karsten Wade wrote:
On Thu, Sep 03, 2009 at 02:17:44PM -0700, Toshio Kuratomi wrote:
At last week's meeting we made a decision about which licenses would best fit our needs. The results are recorded here: https://fedoraproject.org/wiki/Infrastructure_Licensing
I don't see any listing of content licenses. Other than what you put on the wiki that is covered by that license (soon to be CC BY SA), have you thought about specifying what you license content under?
We don't have a policy on this but should. For the CSI docs I've been using OPL1.0 or later. But I'm also curious about licenses regarding the data in our databases. I had a brief discussion with Tiemann several months ago and there are some interesting freedoms we can do here, for example licensing some of the account system information so that we Fedora don't own it, but instead each user ownes their own data and have sole responsibility over what happens with it. But that's a longer discussion for another time.
-Mike
infrastructure@lists.fedoraproject.org
-
Karsten Wade -
Mike McGrath -
Toshio Kuratomi