On Friday, October 21, 2011 10:17:18 AM Giles Coochey wrote: > It appears that this is not the case, and my only option is to take my > servers down the beta route to Centos 6.1 Release Candidates. This is one area in which CentOS and Scientific Linux are different (and it's interesting, reading the SL lists, how that some of the folks that went SL a few months ago are confused about SL's direction, even to the point of calling it a waste of resources....). This is just one area, by the way. So on Scientific Linux you can indeed 'stay with SL 6.0' and still get security updates only (as best as can be provided without other package updates) for the full length of the support period. There are and have been exceptions, but that was and is one of the primary goals, it appears, of SL. However, the speed at which SL has put out 6.1 seems to imply that they aren't quite as picky about binary compatibility (library linked versions, and all of the other things that 'binary compatibility' means) as CentOS seems to be. (I say 'seems' in both cases because I do not have inside knowledge of either projects' binary compatibility tests). And it appears that the 'binary compatibility' piece coupled with upstream's new acceptable use policy (which, since it has changed, might be something to ask FSF about anew) is the primary reason for the slowdown of CentOS, along with the secondary reason that there are packages in upstream's EL6 that aren't distributed on any media at all. I haven't looked closely enough to check if there are source packages in an RHN channel that don't exist on the public FTP. But GPL does not cover the entire distribution; PostgreSQL, just to pull one of many packages out of thin air, is not GPL and thus source redistribution is not required, even to customers. Even GPL only requires redistribution by upstream to its customers.