AGPL Licensing: Another "configuration" file example

Toshio Kuratomi a.badger at gmail.com
Mon Jul 27 17:46:02 UTC 2009


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
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fas.wsgi
URL: <http://listman.redhat.com/archives/fedora-infrastructure-list/attachments/20090727/4134782b/attachment.ksh>
-------------- 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/20090727/4134782b/attachment.sig>


More information about the Fedora-infrastructure-list mailing list