Infrastructure Licensing

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
(Add staging and publictest implementation)
(Update for GPLv2+)
Line 1: Line 1:
{{admon/warning|Draft Documents|This document is in a draft state.  Infrastructure is still deciding whether we can use the AGPLv3+ for web applications or will stick with the GPLv2.}}
 
 
 
All software used in Fedora Infrastructure is Free Software.  When we develop applications for Fedora Infrastructure, we have to license them under a free software license to continue to meet this goal.  However, with each application, we have to choose one particular license and that means we need to think about how our choices will influence our ability to share code with each other.  This page gives guidance on making licensing choices that will expand the amount of free software while causing us the least pain when we want to share code with each other.
 
All software used in Fedora Infrastructure is Free Software.  When we develop applications for Fedora Infrastructure, we have to license them under a free software license to continue to meet this goal.  However, with each application, we have to choose one particular license and that means we need to think about how our choices will influence our ability to share code with each other.  This page gives guidance on making licensing choices that will expand the amount of free software while causing us the least pain when we want to share code with each other.
  
Line 10: Line 8:
 
* 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.
 
* 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).
 
* 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
  
 
== Preferred Licenses ==
 
== Preferred Licenses ==
Line 15: Line 14:
 
In general, Fedora Infrastructure has chosen to use the family of 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.
 
In general, Fedora Infrastructure has chosen to use the family of 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 anything that we write is GPLv2+.  This lets our code be used in both GPLv2 and GPLv3 code bases.
  
 
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 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 needs of the community that will be using the software 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 code while supporting the expansion of free software.
  
Note that working with upstreams that have their own licenses or needs of the community that will be using the software 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 code while supporting the expansion of free softwareWe must be flexible when a different license is better for growth of free software.
+
{{admon/note|Historical Note|A draft version of this policy proposed to use AGPLv3+ for web applications but discussion decided that the effort needed for infrastructure to comply would not outweigh the protection afforded to the code basesAt this time we're not going to use AGPLv3+. [http://meetbot.fedoraproject.org/fedora-meeting/2009-08-2#l-194 Meeting] log}}
  
 
=== Implementation ===
 
=== Implementation ===
  
* All web apps written for Fedora Infrastructure should be AGPLv3+ unless there's a compelling reason not to.
+
* All web apps written for Fedora Infrastructure should be GPLv2+ unless there's a compelling reason not to.
 
* All python modules written for fedora Infrastructure should be LGPLv2+ unless there's a compelling reason not to.
 
* All python modules written for fedora Infrastructure should be LGPLv2+ unless there's a compelling reason not to.
* Web apps written for Infrastructure but not falling under the AGPLv3+ must be code-sharable with this but do not need to be the same license (ie: MIT, BSD(no advertising), Public Domain, are okay for either libraries or apps.  GPLv2+ and GPLv3(+) web apps are okay.  LGPLv2 or LGPLv2+ libraries are okay).
+
* Apps written for Infrastructure but not falling under the GPLv2+ must be code-sharable with this but do not need to be the same license (ie: MIT, BSD(no advertising), Public Domain, 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.
 
* 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.
 
* Except in exceptional cases, we will not relicense if the author disagrees with the change in license.
 +
 +
== Third Party Apps under AGPLv3+ ==
 +
Sometimes we will run third party applications under the AGPLv3+.  This section sums up how we need to proceed in order to run those apps on our servers.
 +
 +
{{admon/warning|Draft Documents|This portion of the document is in a draft state.  Infrastructure needs to evaluate how to satisfy the AGPLv3+ with the least intrusiveness to system admins.}}
 +
 +
=== Production ===
 
* 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.
 
* 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.
** All hotfixes need to be added to trac as a patch against our current deployment with the keyword "hotfix".  These will be closed when we no longer apply the hotfix.  (Requirement of an actual patch is the only change  to existing policy).
+
** All hotfixes need to be added to trac as a patch against our current deployment with the keyword "hotfix".  These will be closed when we no longer apply the hotfix.
** We need to have the footer of each application be configurable so that consumers (like us) can point it at the corresponding source.  We can link to two places that give the user a base of what we're running plus hotfixes:
+
** We need to have the footer of each application be configurable so that we can point it at the corresponding source.  We can link to two places that give the user a base of what we're running plus hotfixes:
 
*** The infrastructure repository has the SRPMs for our web apps: http://infrastructure.fedoraproject.org/el/5/SRPMS/
 
*** The infrastructure repository has the SRPMs for our web apps: http://infrastructure.fedoraproject.org/el/5/SRPMS/
 
*** This trac query will list all of our hotfixes: https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&status=reopened&keywords=%7Ehotfix
 
*** This trac query will list all of our hotfixes: https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&status=reopened&keywords=%7Ehotfix
** staging: We need to keep the general public from hitting the staging servers otherwise we'd need to give them access to the source code of the applications running there.
 
*** Set up the staging proxy servers to use mod_auth_pgsql to require Apache Basic Auth from the sysadmin group to get to any website on the staging servers.
 
**** This will be slightly out of sync with production since the servers hit db1.stg.  However, that's probably better as the people who can actually ssh into the staging servers will also be synced from db1.stg.
 
**** Is there an easy way to allow more people to be able to login to this?  For instance, we might want some people from FESCo (or docs, etc) to look at a test setup on staging.  Is the only way to enable that to put them into sysadmin as well?  (note that sysadmin is currently only a tracking group -- it doesn't grant shell access).
 
**** sysadmin doesn't grant shell access on the staging servers.  The actual groups are: sysadmin-main,sysadmin-web,sysadmin-noc.  Just verify with fontana that he understood this at last week's meeting.
 
** publictest: We need to keep the general public from hitting the publictest servers otherwise we'd need to give them access to the source code of the applications running there.
 
*** Set up mod_auth_pam to do apache basic auth on the publictest servers.
 
**** This is slightly more flexible since people can be added to the publictest servers locally.  By the same token, cruft can be built up locally.
 
**** Without any local users, the groups would be sysadmin-main,sysadmin-test,sysadmin-noc: exactly who is allowed to have shell access.
 
  
** Notes.
+
=== Staging ===
*** We could have the links on the front page of the web app instead of the footer.  But this likely needs to be configured for any siteIt's much more likely that configuring what the footer looks like in a config file will work with the design of any app than configuring the front page.
+
At this time, we require that staging follow the same proceedure as Production.  In the future, we may choose to limit who can hit certain web apps on staging instead of enforcing patches in trac for any deviations from upstream sourceDoing that can be done by changing the proxy servers to use mod_auth_pgsql and Apache Basic Auth on those services licensed under the AGPLv3+.
*** We want our solutions to be usable for programs that we are upstream for and projects that we are not upstream forThis is both so *we* can work without commit access to all the projects and so third parties can use us as an example of how to comply with our license.
+
 
*** nirik: Just as a datapoint... http://gnuherds.org is a AGPL site... they have a link like: http://gnuherds.org/gnuherds-online.tar.gz on their pages. (So they're going the whole tree route)
+
=== publictest ===
 +
At present, AGPLv3+ applications cannot be run on publictest machines.  publictest machines are menat for developing code and by their nature do not track changes to the code being run in the way that production doesIn the future we may change this so a specific publictest machine can be used privately or we can allow people to run "demos only" with the same rules as production.
  
==== FAQ ====
+
== FAQ ==
  
 
* Can the authors of a work relicense their code at will?
 
* Can the authors of a work relicense their code at will?
Line 66: Line 64:
 
** No.
 
** No.
  
[[Category:Draft Documentation]]
+
[[Category:Documentation]]

Revision as of 20:16, 25 August 2009

All software used in Fedora Infrastructure is Free Software. When we develop applications for Fedora Infrastructure, we have to license them under a free software license to continue to meet this goal. However, with each application, we have to choose one particular license and that means we need to think about how our choices will influence our ability to share code with each other. This page gives guidance on making licensing choices that will expand the amount of free software while causing us the least pain when we want to share code with each other.

Contents

Goals

  • 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. Mirrormanager, for instance, is under the MIT/X11 License).
  • Be able to stay compliant with licenses within our production, staging, and publictest environments

Preferred Licenses

In general, Fedora Infrastructure has chosen to use the family of 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 anything that we write is GPLv2+. This lets our code be used in both GPLv2 and GPLv3 code bases.

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.

Note that working with upstreams that have their own licenses or needs of the community that will be using the software 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 code while supporting the expansion of free software.

Note.png
Historical Note
A draft version of this policy proposed to use AGPLv3+ for web applications but discussion decided that the effort needed for infrastructure to comply would not outweigh the protection afforded to the code bases. At this time we're not going to use AGPLv3+. Meeting log

Implementation

  • All web apps written for Fedora Infrastructure should be GPLv2+ unless there's a compelling reason not to.
  • All python modules written for fedora Infrastructure should be LGPLv2+ unless there's a compelling reason not to.
  • Apps written for Infrastructure but not falling under the GPLv2+ must be code-sharable with this but do not need to be the same license (ie: MIT, BSD(no advertising), Public Domain, 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.

Third Party Apps under AGPLv3+

Sometimes we will run third party applications under the AGPLv3+. This section sums up how we need to proceed in order to run those apps on our servers.

Warning (medium size).png
Draft Documents
This portion of the document is in a draft state. Infrastructure needs to evaluate how to satisfy the AGPLv3+ with the least intrusiveness to system admins.

Production

Staging

At this time, we require that staging follow the same proceedure as Production. In the future, we may choose to limit who can hit certain web apps on staging instead of enforcing patches in trac for any deviations from upstream source. Doing that can be done by changing the proxy servers to use mod_auth_pgsql and Apache Basic Auth on those services licensed under the AGPLv3+.

publictest

At present, AGPLv3+ applications cannot be run on publictest machines. publictest machines are menat for developing code and by their nature do not track changes to the code being run in the way that production does. In the future we may change this so a specific publictest machine can be used privately or we can allow people to run "demos only" with the same rules as production.

FAQ

  • Can the authors of a work relicense their code at will?
    • For Red Hat employees, the answer is "Within reason." For instance, moving code you've written from an application under the AGPLv3 to a library under the LGPLv2 is allowed as it keeps similar protections for the code itself and is necessary for the adoption of the library. For others, your terms of employment may differ. However, do note that as a Fedora contributor you've signed the CLA which says that when making contributions you have the right to grant a very broad license to your work so if your employer doesn't let you change the license on your work, be sure they allow you to sign the CLA!
  • Can Fedora relicense code under the CLA?
    • Yes, if you did not explicitly put your submission under a license when you contributed it to us, the present version of the CLA allows the Fedora Project to release the code under a different license at a later date. This allows for things such as relicensing code from GPLv2 to AGPLv3+ for web applications or GPLv2 to LGPVv2+ for libraries if the original contributor disappears. It can allow us to relicense the code without your consent but please note the following:
      • The Fedora Project does not own the copyright to your code, only a license to it. If you wish to take your code and do things with that copy that is not a contribution to Fedora, you are free to do so as the Copyright remains yours.
      • Per this policy, Fedora Infrastructure is not going to relicense your code against your wishes unless there's a compelling reason. At the least, this means the reasons for and against would be discussed publically in Fedora Infrastructure meetings and/or mailing lists.
      • Per Infrastructure Policy, all of Fedora Infrastructure is built on Free Software. Fedora Infrastructure will not ask to relicense your code to a proprietary license.
  • GPLv2 and AGPLv3/GPLv3 are incompatible for combining and linking in compiled languages. How does that work in dynamic languages?
    • The answer to this is a bit complex. If you're comfortable, the simple guidance is "It shouldn't be a problem unless you're copying code." If you need more information, please talk to spot with a specific example.
  • 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 the server, do we need to distribute the hotfix as well?
    • Yes. This means that we need to work out a policy for distributing the code that we are running on Fedora Infrastructure even when we want to hotfix something.
  • Does distributing hotfixes to AGPL apps extend to libraries that the app depends on?
    • No.