Please pardon this additional request for clarification, although to 
make my bias clear, I do agree with the analysis of Patrick LoPresti 
below (perhaps with somewhat less acidic language).

From:

http://en.wikipedia.org/wiki/GPL#Copyleft

Conversely, if one distributes copies of the work without abiding by the 
terms of the GPL (for instance, by keeping the source code secret), he 
or she can be sued <http://en.wikipedia.org/wiki/Lawsuit> by the 
original author under copyright law.

End quote.

I am not a JD (or equivalent in any nation-state), but I do teach the 
professional computer science ethics course my School ("Department") 
uses to meet ABET accreditation.  This includes an article by Stallman 
on the concepts of "free" software.  My understanding is that under the 
GPL the full source code must be made available -- full, including 
whatever is required to "build" the software application.  Thus, the 
statement that the actual binaries for non-Red Hat RHEL that are built 
(before the actual "clone" distribution that no longer uses the Red Hat 
logos, etc.):

  RH sometimes uses an unreleased version
of bar in order to build foo. Rebuilders like CentOS and SL have to
make do with the released version of the bar srpm in order to build
foo.  (From:

Date: Tue, 1 Jul 2014 05:05:56 -0400
Message-ID: <[log in to unmask]>
Subject: Re: Clarity on current status of Scientific Linux build
From: Tom H <[log in to unmask]> )

End quote

seems to violate the GPL as there is a (very important) bit of source code that is not released.

It is true that Oracle, as a for-profit USA corporation model, wants to sell service/support for the Oracle EL clone, and thus has motivated Red Hat, another for-profit USA corporation model, to retaliate, including the acquisition of CentOS.   I too strongly fear that under the for-profit model, the CentOS source to be made available to "cloners" will not be faithful to the original RHEL sources as actually used to construct RHEL licensed for fee executable "binaries".

No one at CERN has commented why CERN and the rest of the CERN research community not paid for nor housed at an official CERN facility simple does not license RHEL for fee, and add -- given the full RHEL SRPMs that could thereby be made available -- what is needed to produce RHEL-C, containing the extra drivers, applications, etc., required for the CERN research community, running the LHC and LHC consortia experiments.  At one time (ancient history?), HEPnet effectively required licensed-for-fee DEC DECnet and DEC licensed-for-fee operating systems environments for all USA sites -- not a new approach. (At that epoch, the now purchased and defunct Digital Equipment Corporation used a proprietary set of network protocols, no open source or full protocol details available to the public, that were not directly interoperable with IETF -- "TCP/IP" -- RFC-covered protocols.  If one reverse engineered those DECNet protocols, even running entirely on a DEC hardware system but not using a licensed-for-fee DEC operating system environment, DEC would start legal proceedings.)

I assume that if the CentOS SLC 7x distribution has fundamental problems (security, amongst others), CERN will switch to the RHEL SLC 7 (... 8 ...) model -- hopefully not keeping this reality secret from the rest of the non-LHC community.

Unfortunately, given our fiscal resources, we cannot license RHEL for all of our nodes.

Yasha Karant

On 07/01/2014 08:16 AM, Patrick J. LoPresti wrote:
> On Tue, Jul 1, 2014 at 6:17 AM, Lamar Owen <[log in to unmask]> wrote:
>>
>> ??? That is not at all what I got from his reply.  What I got was that CERN
>> will still be committing resources, but instead of duplicating effort
>> they're joining up with the CentOS effort.
> Whatever. The relevant questions are: (1) Will SL's goal continue to
> be creating a re-spin of Red Hat Enterprise and *not* CentOS, since
> Red Hat's clear goal in acquiring CentOS is to create divergence
> between the two; and (2) what mechanism(s) will SL use to achieve that
> goal? (Specifically, will SL compare the git sources against actual
> SRPMs obtained via subscription?)
>
>> That's part of the
>> reason the CentOS team has changed the statement '100% binary compatible' to
>> 'functionally compatible' since they do mean different things, but the
>> latter is more indicative of reality than the former ever has.
> The *goal* of CentOS used to be binary compatibility, even if it was
> never 100% achieved. Since the acquisition by Red Hat, that is no
> longer even the goal, for obvious reasons.
>
>> Red Hat is being as close to a good member of the community as is
>> possible within the constraints of a publicly traded corporation,
> Disingenuous claptrap. Red Hat is blatantly violating the clear intent
> of the license that the authors of the code placed on their work. Why
> Red Hat does this is frankly irrelevant.
>
>> No one yet in this thread has provided a public, no
>> login required, link to up-to-date sources for SLES 11.
> Yes, you keep bringing this up as if it were an argument.
>
> No one has provided a public, no login required link to an up-to-date
> photo of my bare rear end, either, which would be precisely as
> relevant. We are talking about Red Hat; the actions of SUSE, Oracle,
> Microsoft, Tesla, and your cat have zero bearing on the discussion.
>
> Nobody cares about SUSE because nobody cares about SUSE.
>
>   - Pat