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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
