On Fri, 2005-06-03 at 22:26 -0400, Lamar Owen wrote: > On Friday 03 June 2005 11:48, Les Mikesell wrote: > > I'd put it this way instead: Red Hat is responsible for any > > difficulty in creating the CentOS distribution, while sharing > > the same upstream developers as all other Linux distributions. > > I'd put it this way: > Red Hat makes CentOS possible at all by providing Source RPMs (which they are > not required to do; source doesn't have to be provided in SRPM form to meet > the GPL-covered packages license requirements). This I disagree with ... to quote the GPL: "For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable." So, they can't just publish the tar.gz files, they have to publish the SRPMS. The spec file and SRPM controls the compilation of the source code to make the executable. Now, whether they have to give to everyone, or just their customers (and how to define who is their customers), is a different story. > The CentOS teams builds upon > a foundation laid; the building is the work of the CentOS team, but it would > fall were it not for the foundation. > Agreed ... CentOS (as it is currently done) depends upon RedHat to distribute their SRPMS. I wasn't implying that is not the case, just that CentOS builds upon it. > Also, while Red Hat may share the upstream developers as all other Linux > distributions, let's not forget that Red Hat (as well as SuSE and others) > employ many of these upstream developers and share their work product open > source with their competitors. This is also true ... but who employs the upstream employees doesn't matter. No one is saying that Slackware is Redhat because they include PostgreSQL and Red Hat employees a significant amount of the people who produce changes to that project. It is CentOS that supposedly has no added value, not slackware. > > Or, more bluntly, the SRPM tree for RHEL didn't just magically appear out of > nothing. And there is a significant difference in a tree of SRPMs ready to > roll (with some modifications, as Johnny said, since RHEL isn't self-hosted) > and having a tree of upstream tarballs with no spec files to tell where to > put the files, build with the unified options, etc. I have written spec > files, and have maintained a specfile of moderate complexity; spec file > hacking is not trivial. Then there's the work of building an installable ISO > image or image set; this is nontrivial as well. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.centos.org/pipermail/centos/attachments/20050604/e56f93a6/attachment-0004.sig>