Bottom-line summary for the impatient.

(Some items in the initial "Q & A" section now need revision on a couple of minor factual points, now that I've carefully examined RHEL 3.0 product media and packaging — but the section surrounding the "summary" is up to date.) Exception: James Sparenburg pointed out to me, on 2004-08-18, that compiling RHEL's all-open-source software SRPMs with its two trademark-and-copyright-encumbered non-software SRPMs strews some of the latter's contents through binary packages created for the former. If true, this is presumably the most compelling reason why the various forks recompile from source. Also: James told me he'd asked White Box Linux's lead developer the reason why, and had been told it was simply because the SRPMs had been downloadable, whereas the developer hadn't want to pay for a full RHEL kit.

For those reasons, the essay below is a little out of kilter, but I'm hoping it's useful in its current state while I rebuild it to accomodate this new information.

People frequently ask where to download ISOs (CD images) of Red Hat Enterprise Linux (RHEL) - a software distribution formerly known as Red Hat Advanced Server (RHAS), now in three service-level variants: RHEL AS (the old RHAS), RHEL ES ("entry level" servers), and RHEL WS (for workstations).

The answer appears to be: You can't.

Q: What do you mean "can't"?
A: Literally what I said. Look around. There simply aren't any ISOs.

Q: Doesn't the GPL require that they put ISOs up?
A: No. Don't be a moron. First, the GPL applies only to individual packages issued under that licence by their copyright owners. Second, the GPL says nothing about required access to binaries in any form, let alone ISOs. Third, the access that is required, to source code (if done according to the method specified in clause 3b as opposed to the other two methods) need not be either free of charge or via Internet access.

Q: But I've seen entire directories of RHEL packages on Red Hat mirror sites!
A: Yes, those were source-code RPM packages, aka "SRPMs". You'll notice that all their names ended with ".src.rpm".

Q: If there are public ftp/http trees of SRPMs, doesn't that imply that there can be source-package ISOs?
A: I don't know. Maybe nobody's bothered to assemble one and put it up, and felt like underwriting other people's downloads. Maybe RH, Inc. asserts compilation copyright - or asserts right to allow or disallow copies that display its trademarks (images of the "shadowman" logo, and certain trademarked phrases). In any event, I really doubt you'll find any. I've looked.

Q: Is there anything stopping someone from compiling the distribution from the source RPMs and distributing either the binary .rpm files or an entire ISO of them?
A: Not that I know of. My recollection is that it consists solely of packages with licences allowing redistribution. The same questions apply as for source-code ISOs.

Q: Your last couple of answers have been a bit vague. Can't you get some more-definitive answers to those questions?
A: Sure. Just buy me a (US $600 or so) boxed-set copy of Red Hat Enterprise Linux AS, and I'll be glad to licence-audit all of its contents to determine if all or almost all of it may be lawfully redistributed in public. That may involve some surgery to find and remove expressions of Red Hat's trademarks, but I'm up for it, if you're footing the bill. (I am not an attorney, and nothing in my work will constitute legal advice.) If it can be done, you (not me) are welcome to then put up the ISOs at your expense for every cheapskate in the world to download. (If you think I'm going to pay large amounts of money to buy the product required to get those answers, you're dreaming.)

Maybe the reason you don't find ISOs is that nobody's willing to carry out the massive amount of work required to check for legal encumbrances and either pay for a boxed set or laboriously compile from SRPMs, and then worry about whether they've missed a legal encumbrance and pay to underwrite other people's downloads.

Please note that trademark encumbrances would be an obstacle only to some reselling of the product (absent alteration), not offering it for public ftp. It's also possible that one or more of the constituent packages has been licensed by its copyright holder under a restrictive licence interfering with redistribution, but this reportedly isn't the case.

Q: I'm pretty sure I read somewhere (e.g., that RHEL is licensed for fixed terms that must be paid for, that later expire, and that must be renewed at extra cost.
A: Are you sure? The above page says that the services bundled with the software expire and must be renewed. Red Hat, Inc. clarifies on that "that the code is open and protected by the GPL license. It's not proprietary. We're licensing the services, not the software."

Q: If it's possible to build RHEL from source, and if it's probably lawful to redistribute either such builds or (probably even) the binary ISOs from a boxed-set RHEL distribution costing many hundreds of dollars and an expensive support contract, why do companies buy the boxed set anyway?
A: Presumably for the paid priority technical support, access to Red Hat engineers, the entitlement to get automated maintenance via Red Hat Network, etc. That's, after all, one of the classic business models for open-source software.

Q: So, would it be lawful for someone who acquired a set of the RHEL binary CDs, either by buying the RHEL retail product or otherwise, to give me a copy?
A: As far as I can tell, yes. The Subscription Agreement for Red Hat Enterprise Linux at , to which a RHEL purchaser ostensibly agrees, nowhere purports to restrict duplication and redistribution of the software. It does restrict access to the bundled services.

There is one exception: That agreement does purport to restrict how many running instances of RHEL the customer may operate on customer's facilities during the service agreement's one-year (renewable) term, saying essentially that there must be a service entitlement for each RHEL host on site.

[06/2004 addition: Two RH-owned (but strictly non-software) packages, redhat-logos and anaconda-images, turn out to have mildly restrictive proprietary licensing, requiring that all commercial redistribution respect a company-issued trademark-usage policy on the company Web site. The matter is detailed further down this page.]

Q: Doesn't that restriction on RHEL deployments within customer sites violate the GPL?
A: Let's not be melodramatic. Some would say — and I do not agree, for reasons outlined below — that it conflicts with the GPL licence terms of some contents, in that it constitutes "further restrictions" of the sort discussed in GPLv2 sections 6 & 7. Per section 7, if anything imposes further restrictions over the covered code onto recipients beyond the requirements of the GPL itself, then the code may not be distributed by parties thus encumbered. On that basis, the works' copyright holders might have a claim against Red Hat, Inc. for copyright violation, for passing on their copyrighted property in a way that denies some rights that the licence (to which Red Hat consented) states must be unrestricted. (Section 0: "The act of running the Program is not restricted....")

A slightly different view might be that the GPL actually specifically does not address rights of program execution. (Section 0, again: "Activities other than copying, distribution and modification are not covered by this License; they are outside its scope.") However, this doesn't mean Red Hat, Inc. is off the hook, because the corpus of copyright caselaw has clarified that anyone who lawfully acquires a software work also acquires the implied right to run it. It is unclear to me whether Red Hat, Inc. can restrict by contract a right already granted by a third-party copyright holder whose licence Red hat, Inc. has (in fact) already assented to, in receiving the work subject to those licence terms.

Essentially, if you acquire RHEL software by buying the retail product, it comes bundled with a services agreement running a minimum of one year, that purports to limit and regulate deployments at your site. Those restrictions in the services agreement might or might not be enforceable as written (or non-conforming usage might just terminate the support contract, in which case inherent right of code access under open-source licences might defeat any claim of damages); the point could be debated.

Beyond that matter, you're free to acquire RHEL software via some other means, e.g., by convincing an RHEL retail customer to burn you a copy (which appears to be lawful), or getting one from a customer that has terminated his service agreement - but Red Hat, Inc. itself doesn't offer RHEL binaries without an attached services bundle, and isn't obliged to. Nobody else is obliged to offer you a software copy at all.

Disclaimer: I am not a lawyer. This is not legal advice. Nowhere in the foregoing do I speak for Red Hat, Inc. or anyone but myself.

Some comments about building RHEL (initially called RHAS) from source RPMs follow:

Date: Tue, 1 Apr 2003 13:50:22 +0100
From: Ronan Waide <>
Subject: Re: [ILUG] compiling RHAS2.1 from src rpms
X-Mailer: VM 7.13 under Emacs 21.2.1
Organization: poor at best.

On April 1, said:

> 1.)Does anyone see any problems with this scenario?
> 2.)Some of the RPMS don't compile, eg the following which are only the
> first 12 of those src.rpms which won't compile. If I can somehow get a
> bare bones RHAS system up, then I should be able to compile these later
> on I think, so long as I have enough to get me to a barebones stage. Am
> I right?
> 3.)Has anyone tried compiling the RHAS2.1 src.rpms for i686?

To answer all three in one:

I've built RHAS from source. The main thing about building a Red Hat system from source is that, generally speaking you need to compile the packages in the environment in which they'll run; i.e., an RHAS system should be built by another RHAS system. Probably the handiest way to do this without paying attention to what you're doing is to build using a different root fs, and install all your packages there. The rpm commands provide the -root flag to help you with this. You will not be able to build the 6.2-compat packages, because they're supposed to be built on a 6.2 system. Everything else will eventually build.

Once you've got a system built, you can use it to make proper boot disks, as opposed to hammering them together from RH 7.2. Note, it's been several months since I went through this, but the approximate process was to crawl over the source to anaconda (the installer) to find out what order it starts installing packages in, install those packages, then work my way up from there. Once I enough stuff installed in the fake root, I chroot'ed to it and rebuilt everything from scratch. Several iterations of "build all packages, then install all successfully built packages" were required before I got to a full build, after which I rebuilt all the packages again to create the "final" install set.

Hope this gets you some of the way there.


From: John Newbigin <>
To: rhel-rebuild list <>
Date: Thu, 13 Nov 2003 10:15:07 +1100
Subject: [cAos] Some things to watch out for

I just though I would post some things I have found in my rebuild of RHEL21AS.

Red Hat it seems don't rebuild any packages that have not changed since last time they built them. This explains why many of the packages do not build, or do not build well, on a self-hosted system.

A downside to this is that there are many builds with RPM 4.0.3, 4.0.2, 4.0.1, 4.0, 2.2.0 and 4.0.5. These older versions of RPM do some things differently to 4.0.4, which is probably the version most people are using. I don't know about 4.0.5, but there might be changes there, too.

rpm 4.0.4 strips debug symbols only from ELF executables that use shared libs. This is in contrast to older versions, which strip all symbols. This means there are 200+ rpms that, when you build, might not have stripped executables.

The solution to this is to edit /usr/lib/rpm/brp-strip and remove the -g from the strip command.

There may be other rpm-based problems. I am comparing things now, to make sure I find them all.

I have also found some strange results with time zones. The changelog entry dates are somehow affected by the time zone. I don't know if this is a bug or by design, but have the feeling that something is going wrong in the date processing.

Another thing to watch for is the library versions used. For many packages this is not a problem, but, with the compat packages, which need to use and provide specific historical versions, it can be a problem. If you build your own version of these, then at least compare the contents to the RH versions, and make sure they contain what they should.


Information Technology Innovation Group
School of Information Technology
Swinburne University of Technology
Melbourne, Australia

[Portions of an e-mail exchange that my correspondent branched off into private e-mail from a related thread on OSI's license-discuss mailing list.]

Date: Mon, 7 Jun 2004 12:23:50 -0700
From: Rick Moen <>
To: [omitted]
Subject: Re: Dual licensing
User-Agent: Mutt/

Quoting [name omitted]:

> Hi Rick,

Hi, [name omitted]! I note without objection that you seem to have gone into private mail.

> I think you're skipping a step. If I understand it correctly, Red
> Hat's CDs contain numerous copyrighted, non-software components, so you
> do NOT have the right to simply duplicate and give away and/or sell
> their CDs.

That is possible; to be absolutely certain, one would have to do a licence audit.

(I have in front of me a CD set of RHEL 3.0 for AMD64, but, as before, don't really have the time to do a full examination. What's new is having the CD images. Previously, I had only the SRPMs, downloaded from the Net.)

I think you're referring to clause 2 in the EULA, which is very trickily tied into (a maximalist observance of) Red Hat's trademark rights.

Intellectual Property Rights. The Software and each of its components, including the source code, documentation, appearance, structure and organization are owned by Red Hat and others and are protected under copyright and other laws. Title to the Software and any component, or to any copy, modification, or merged portion shall remain with the aforementioned, subject to the applicable license. The "Red Hat" trademark and the "Shadowman" logo are registered trademarks of Red Hat in the U.S. and other countries. This agreement does not permit Customer to distribute the Software using Red Hat's trademarks. Customer should read the information found at before distributing a copy of the Software, regardless of whether it has been modified. If Customer makes a commercial redistribution of the Software, unless a separate agreement with Red Hat is executed or other permission granted, then Customer must modify the files identified as "REDHAT-LOGOS" and "anaconda-images" to remove all images containing the "Red Hat" trademark or the "Shadowman" logo. Merely deleting these files may corrupt the Software.

This is a very crafty attempt to tie a copyright licence (as to those images) to a particular type of observation of Red Hat, Inc.'s trademark rights. Of course, the indicated way of respecting Red Hat's trademark rights is the way Red Hat, Inc. would like people to act. It is not the only way to respect those rights — and substantially exceeds the actual requirements of trademark law.

(Trademark law requires only that you not sell competing goods that use someone's established marks in a fashion likely to confuse the mark owner's customers into thinking that the mark holder produced or endorsed your goods. It does not, contrary to common belief, give the mark's owner a monopoly on its use in business. I have more about this at "Trademark Law" on

So, Red Hat, Inc. are saying that they condition your right to commercially redistribute the copyrighted images they speak of on your compliance with the trademark policy viewable on their Web site — which states conditions above and beyond those actually required by trademark law. Note that they place no such condition on non-commercial distribution.

And that is pretty much exactly what I said in my mailing list post.

Just as a thought-experiment, please imagine that I replaced all of the identified image files in those two packages with essentially identical images that I drew on my workstation. The substitute images would be copyrighted by me (since I created them), so I would no longer be bound by the provisions of clause 2 (under copyright law) for any commercial redistribution. The distribution might, at that point, be visually indistinguishable from stock RHEL 3.0.

But I would potentially have a problem with trademark violation, since RH, Inc. would probably prevail on a trademark tort lawsuit, by claiming that I was misleading likely RH customers into thinking they had produced or endorsed my competing commercial product.

As a further thought-experiment, imagine that I plastered the installation screens and the GNOME desktop background with a notice saying "This is Rick Moen's Enterprise Linux 3.0, and has exactly the same software contents as RHEL 3.0 but is neither produced nor endorsed by Red Hat, Inc." With that change, RH, Inc. might still threaten and possibly sue me (since firms in danger of their trademarks becoming generic tend to be trigger-happy), but they would lose.

Thus, to recap, concerning RHEL3.0 binaries (including ISOs):

> Yes, you have rights to all the software, but you'd need to figure out
> a way to rebuild all the binaries in such a way as to exclude the
> proprietary bits. Which is straightforward, and several groups are
> doing it, but it doesn't seem to be entirely trivial.

To the best of my understanding, White Box Linux, cAos Community Linux, FermiLinux LTS, and Tao Linux are merely being (1) courteous to Red Hat, Inc., and (2) extra-cautious to maintain distance from RH's trademark concerns.

I have never heard a convincing explanation of why the entire distribution needs to be rebuilt for strictly reasons of legal rights. Some (not all) of the projects choose to do so in order to make their projects self-hosting.

> Just my very non-expert opinion based on second-hand information....

Same here, but I've been trying to study the matter carefully for quite some time.

Stuff I have relevant to the matter is linked from my knowlegebase's Red Hat category, .

(Just a question: If the matter gets pursued on-list, would you object to my posting this message back to the list thread? I'm ethically obliged to ask because my message quotes your private mail.)

Date: Mon, 7 Jun 2004 13:36:07 -0700
From: Rick Moen <>
To: [name omitted]
Subject: Re: Dual licensing
User-Agent: Mutt/

Quoting [name omitted]:

> The reason I replied in private is that I am a very unsure of my
> ground, and hence would hate to be quoted in public purveying
> inaccurate information. :-) You're welcome to quote the text on the
> public list, but please drop my name.

Of course. I very much sympathise, having been there very often myself. (It's annoying but far too common to enter a discussion to try to find out more, and politely one's present tentative understanding, only to be jumped on verbally by one or more random hothead. I have numerous singe-marks from past experience!)

> My understanding is that at least some of the non-software items on the
> CD — e.g., images, installer bits, things like that — are not
> themselves open source, and thus one can not simply reproduce the CD in
> its entirety. But it would be interesting to see what the 'experts'
> on the list think.

Yes. I've tried to look over significant packages in the RHEL system, to examine their copyright licences — but of course there are thousands of packages, and I haven't given even a cursory look to all of them.

I can tell you of a certainty that the installer (net of trademark-encumbered image files) is licensed under GNU GPL terms: It's the anaconda codebase.

Nonetheless, I always try to qualify what I say on this matter as being true "to the best of my understanding", etc.