This wsgi script also helps illustrate some of smooge's concerns about what happens when configuration information is mixed into a script. It has two areas that differ between upstream's distribution and our own:
The first is bad application design but I've seen this done frequently in PHP apps (and it sounds like Java frameworks like JBoss promote this as well). The fact that our apps are doing it shows it can occur in any language although we should be able to change our apps to work around it fairly easily:
The scripts that start up our web applications under mod_wsgi all seem to have a bit of config tweaking. Historically, this is because we deployed with a start-app.py script that used the config file exclusively and started as a standalone daemon. The app.wsgi script would load the standalone daemon config file and then make some config changes in the wsgi script before starting the application server. This can be seen in the attached wsgi script in lines like this::
turbogears.update_config(configfile="/home/ricky/work/fedora/fas/fas.cfg", modulename="fas.config") turbogears.config.update({'global': {'server.environment': 'development'}})
For our TurboGears apps it should be pretty easy for us to work around that by moving all such lines into the config file instead of being in the script. But for third party PHP scripts licensed under AGPL and single file cgi scripts that we write what is our responsibility? I can see several options:
1) We must patch every script/app/etc to put the config into its own file. Those changes fall unde the AGPL and we try to get them upstream. The config file falls outside of the AGPL either via explicit license or some other way.
2) configuration, even embedded inside of an AGPL script is not subject to the AGPL because it's not copyrightable data.
Second piece of code that varies between installations:: import sys sys.path.append('/home/ricky/work/fedora/fas/fas/')
Setting the path at which to find the code must be done otherwise the script won't be able to find the code related to the web application itself. On different installations (our servers, developers' test machines, etc) this path will vary. Are those changes that are covered by the AGPL or are they non-copyrightable? Is there a difference if this is done manually by the system administrator vs automatically by the Makefiles/build scripts provided by upstream?
This issue is harder to work around in code since finding the path to files is a chicken and egg problem. At some point, the executable has to hardcode at least one path to be able to load the rest of its information.
-Toshio