12:09 p.m.
Resending since spot didn't get it the first time.
Okay, at the infrastructure meeting this week we had a long discussion
about using AGPL in infrastructure and we decided we need more
information about what the AGPL requires of us. Here's a run down and
then the questions we had.
== What we decided ==
We arrived at a few conclusions with the amount of knowledge we
currently have:
* Continue to deploy as rpms to production and as the basis of staging.
* In production, hotfixes need to have tickets in trac (this is current
policy). Those tickets may be required to contain patches applied to
the server if we determine that's the best course under legal.
- If that's not the best course, hotfix tickets still need to contain
an indication of what the hotfix does but this could be "I reverted
commit 12345" or "I changed three files to import simplejson instead of
json (python-2.4 compatibility)"
* In staging, we want to deploy with a base rpm and may add patches and
local changes on top of that to test things. When we get to the point
where we are satisfied, this needs to be turned into an rpm and be
deployed to production/installed in the staging env.
* In publictest, we want people to be able to deploy from SCM, make
local changes, etc. publictest are pure development machines.
== Explain the linking requirements ==
How the running app leads people to the source for the app is causing
the most concerns. Here's a list of questions. There's a lot because
we don't have a feel for what's allowed and not allowed yet.
Where relevant, assume that the running applications have rpms/srpms
present on infrastructure.fedoraproject.org, an upstream trac/scm
instance on fedorahosted.org, and that we are running with some number
of hotfixes to the live application.
* Do we need to link to the source from every page of the app?
* What are legal means of giving people access to the corresponding source?
+ Source repository at no particular version (assuming all of our
patches are applied to trunk -- and trunk might contain other changes as
well, including full or partial reversions of those changes in a later
revision)
+ Source repository at no particular version (assuming all of our
patches are applied to a branch that mirrors production)
+ Pointing exactly to source repository branch or tag of the exact
version we're running
+ Home page of the project (example: http://fedorahosted.org/fas)
+ Just a page specifically linking to the sources and all of the
patches we've applied
+ links to base srpm and page listing patches
+ links to base srpm and tickets in trac that have patches attached
+ links to base srpm and tickets in trac that point to commits in
SCM that are applied against different versions (HEAD vs the last
release, for instance)
+ A page linking to the sources and a page linking to any hotfixes
we've applied to any of our apps (ie, a query in infrastructure's trac
that gets all hotfixes for all of our apps).
+ I'm assuming these to be fine: tarball, srpm that matches what's
running, actual links to base tarball and to all of the patches
* Do config changes count as code changes if the config file is marked
as being AGPL?
- If yes, what do we have to do to make config files not be licensed
under AGPL? (We want to keep passwords private, for instance).
== Related to Other Apps ==
Our original impetus for relicensing is so we can freely share code with
fedoracommunity. The cost of maintaining AGPL compliance with other
apps needs to be weighed against the cost of reinventing code in
fedoracommunity (or waiting for fedoracommunity developers to relicense
their code for use elsewhere *cough CSRF middleware cough* :-) ).
* Is it really "absolutely critical" that fedoracommunity be AGPL?
* Can we get a clarification of what the consequences would be if fedora
community stays AGPL but our apps stay as they are (GPLv2)?
== Related to Staging ==
We use the staging environment for both some development duties and
integration testing. Because of that we want to be able to deploy into
staging things that we aren't providing exact corresponding source for
at the moment. The staging environment is reachable by members of the
general public but we'd like to find out if we can consider it an
internal service that doesn't need to track every little change we make.
Here's the portions of the AGPL we think is relevant:
From the preamble:
"""
public use of a modified version, on a publicly accessible server, gives
the public access to the source code of the modified version.
"""
Section 13:
"""
Notwithstanding any other provision of this License, if you modify the
Program, your modified version must prominently offer all users
interacting with it remotely through a computer network (if your version
supports such interaction) an opportunity to receive the Corresponding
Source of your version by providing access to the Corresponding Source
from a network server at no charge, through some standard or customary
means of facilitating copying of software.
"""
* Is the preamble legally binding/part of the AGPL or should we ignore
anything there?
* admin.stg.fedoraproject.org is accessible by the general public but it
isn't meant for the general public's use -- it's for developers to
collaborate on what will be on the production site,
admin.fedoraproject.org. Those developers collaborate over the internet
which is why it's available on the internet. Does this excuse us from
providing source to people who do not have shell access to the server
itself?
* If we can run apps in staging without providing source to those
without shell accounts there, can we also run apps on publictest boxes
without providing source to those without shell accounts there?
.. _[1]: Meeting Minutes
http://meetbot.fedoraproject.org/fedora-meeting/2009-07-16/fedora-meeting...
.. Proposed Guidelines:
https://fedoraproject.org/wiki/Infrastructure_Licensing
-Toshio