infrastructure July 2009

infrastructure@lists.fedoraproject.org

42 participants
66 discussions

A discussion on licensing and the AGPLv3
by Tom Callaway 28 Jul '09

28 Jul '09

Hi guys, After several rounds of discussion with Richard Fontana, I think we have more information about how to move forward here. This is Fedora's general policy around license compatibility concerns: * If the code is bundled together in the same tarball, and it is compiled together, then we worry about license compatibilities. * If the code is not bundled together, we worry about it if there is an incompatibility across shared library linking (e.g. GPL incompatible library cannot be used by GPL code) * For interpreted languages (Python, Java), we don't worry about it outside of the tarball. (This policy is subject to modification in specific cases but represents our default approach to license compatibility issues.) I've proposed that we apply this logic to the AGPLv3, and Red Hat Legal agrees. So, if we apply this to the AGPLv3, it means that we only need to be distributing the bits under AGPLv3 that make up our web app, and any other code that would be "bundled in the same tarball" for distribution. All of the other interpreted dependencies should be listed, but do not need to be provided. Now, there were some specific questions about how we should be distributing the sources to comply with the AGPLv3, here are the answers from Red Hat Legal: Q: 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) * Red Hat Legal feels this is not sufficient. + Source repository at no particular version (assuming all of our patches are applied to a branch that mirrors production) * Red Hat Legal feels this is not sufficient. + Pointing exactly to source repository branch or tag of the exact version we're running * Red Hat Legal says that this is OK. + Home page of the project (example: http://fedorahosted.org/fas) * Red Hat Legal feels this is not sufficient. + Just a page specifically linking to the sources and all of the patches we've applied * Red Hat Legal says that this is OK. + links to base srpm and page listing patches * Red Hat Legal says that this is OK. + links to base srpm and tickets in trac that have patches attached * Red Hat Legal says that this is OK. + 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) * Red Hat Legal feels this is not sufficient. + 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). * Red Hat Legal says that this is OK. + 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 * Red Hat Legal confirms that these are all OK Q: Do config changes count as code changes if the config file is marked as being AGPL? Red Hat Legal feels that changes to configuration lines inside a script do not represent a copyrightable change to the script, and therefore they do not trigger the AGPLv3 section 13 requirement (this is the requirement on sharing the AGPLv3 covered code), because the config change does not result in a "modified version" as that term is used in AGPLv3. They advise that it would be preferred if applications clearly separated the configuration files from the actual web application code and scripts, as it minimizes licensing concerns. Q: What do we have to do to make config files not be licensed under AGPL? (We want to keep passwords private, for instance). Red Hat Legal advises that for config files included in an AGPLv3 distribution, you can cause them to fall outside of the AGPLv3 (at least section 13), by explicitly granting an additional permission stating that such files (assuming that they are copyrightable) are covered by the AGPLv3, but are not subject to the AGPLv3 section 13 requirement. Red Hat Legal would be happy to draft up wording for such an additional permission for our needs. Q: Does each page of the web app have to have a link to the source? A: No, you just have to make sure that users are "prominently offered" an opportunity to get the source. Links from the main page of the web application meet this criteria. Hopefully, this will provide a solid groundwork for Thursday's discussions. Thanks, ~spot

3 8

Thursday meeting.
by Stephen John Smoogen 28 Jul '09

28 Jul '09

Mike will be out at training for this meeting. Please send me any agenda items that you feel need to be addressed so we can get through them in the requisite 50 minutes or so. 1) AGPL Licensing updates. 2) Mirror madness 3) ... 4) ... -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning

1 0

bash_history on x86-5
by Dennis Gilmore 27 Jul '09

27 Jul '09

I just deleted my bas_history on x86-5 i typed my password on accident Dennis

1 0

AGPL Licensing: Another "configuration" file example
by Toshio Kuratomi 27 Jul '09

27 Jul '09

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

2 1

blogs.fedoraproject.org Update
by Nick Bebout 27 Jul '09

27 Jul '09

This is just a quick note to update everyone on the status of blogs.fedoraproject.org We have the FAS authentication plugin working, puppet set up, and are now working on installing and testing a spam filter plugin, currently we are testing bad behavior. As soon as this is done we plan to deploy it. Nick

6 6

Fwd: Re: Is F-community using its FAS account?
by Toshio Kuratomi 27 Jul '09

27 Jul '09

-------- Original Message -------- Subject: Re: Is F-community using its FAS account? Date: Mon, 27 Jul 2009 14:35:50 -0400 (EDT) From: John Palmieri <johnp(a)redhat.com> To: Toshio Kuratomi <a.badger(a)gmail.com> It is used for getting a user's info when you are not logged in similar to the functionality of the bots in #fedora-devel. Going to this link (https://admin.fedoraproject.org/community/?username=jkeating#people) works so the password change worked. ----- "Toshio Kuratomi" <a.badger(a)gmail.com> wrote: > Hey, > > lmacken and I realized that we probably hadn't changed Fedora > Community's password since moving it from the publictest machines to > production so I did that today. But when I went to test it we > couldn't > figure out where it would actually be used:: > > [10:00:02] <lmacken> abadger1999: hmm, I'm actually not sure if > that > account is getting used at all. It looks like it is only used when > the > user is not logged in, but in that case they can't view users or > anything FAS related as far as I can tell. J5 would know for sure > > So, is the account being used? If so how can I test that the > password > update worked okay? If not, can we disable the account? > > -Toshio -- -- John (J5) Palmieri Software Engineer Red Hat, Inc.

1 0

Is F-community using its FAS account?
by Toshio Kuratomi 27 Jul '09

27 Jul '09

Hey, lmacken and I realized that we probably hadn't changed Fedora Community's password since moving it from the publictest machines to production so I did that today. But when I went to test it we couldn't figure out where it would actually be used:: [10:00:02] <lmacken> abadger1999: hmm, I'm actually not sure if that account is getting used at all. It looks like it is only used when the user is not logged in, but in that case they can't view users or anything FAS related as far as I can tell. J5 would know for sure So, is the account being used? If so how can I test that the password update worked okay? If not, can we disable the account? -Toshio

2 1

Re: Cron <nobody@xen11> /bin/rpm -Va --nofiles --nomd5
by Stephen John Smoogen 26 Jul '09

26 Jul '09

On Sat, Jul 25, 2009 at 6:00 PM, Cron Daemon<root(a)fedoraproject.org> wrote: > Unsatisfied dependencies for hpadu-8.10-4.i386: hpsmh > Probably noted somewhere but this is the HP System Management Homepage. Product looks like it only works on RHEL-4 and before and seems to be considered dead software by HP (all the main pages say go find another product...) I am downloading the latest tools for this and see what it comes up as. -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning

2 1

torrent1 warnings.
by Stephen John Smoogen 26 Jul '09

26 Jul '09

Found some very old log btt files that were huge gzipped from January. Look like they were left over before new naming structure in logrotate was used. Removed them to give space. Looks like the service did not properly rotate logs last time and has been writing to a bad file descriptor for a while. Restarting bttrack btseed to reset log files. -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning

2 1

Second try, patch set for sigul
by Jesse Keating 25 Jul '09

25 Jul '09

Here is a second try. This time I fixed with Ricky pointed out and squashed everything into one commit since it is all related. Arguably it should be two commits, one for the addition of the module and another commit for the .pp changes, but I'm already writing this so oh well. -- Jes

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

infrastructure July 2009