Relicensing Part II

[Toshio Kuratomi]

Alright!  So the last two weeks there wasn't much comment on:
  https://fedorahosted.org/fedora-infrastructure/ticket/1524
  https://fedoraproject.org/wiki/Infrastructure_Licensing

but I think people were either sleeping or didn't entirely understand
what the AGPL's requirements mean for us as this week we filled the
whole meeting with discussion[1]_.

We arrived at a few conclusions about options we did not want to explore
but got into a few questions that need answers from legal before we can
continue.  Please clarify the questions or add new ones if you can think
of other things that we need to know from legal.  Once that's done or
tomorrow (whichever comes first) I'll make sure that spot gets the list
so we can get some input and better consider our options.

Questions follow:

== What we decided ==

* Continue to deploy as rpms to production and as the basis of staging.

* In production, hotfixes need to have tickets in trac.  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 protect passwords, 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?

* Can we be just as liberal with what's running on the publictest
machines as we are with staging?

.. _[1]: Meeting Minutes
http://meetbot.fedoraproject.org/fedora-meeting/2009-07-16/fedora-meeting.2009-07-16-20.00.html

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-infrastructure-list/attachments/20090716/ce7c91e3/attachment.sig>