The bottom line to this issue seems to have two parts:

1.  Is it feasible with the same personnel resources and hardware 
computational resources to acquire and build current, maintained SL 7 
from the current, maintained RHEL 7 production source?  Note this query 
also means to keep SL 7 production (sl7x) as current as RHEL 7 
production, except for the (hopefully short) delay from the time RH 
releases production source updates/enhancements to the time SL can 
release the same as installable RPMs.

2.  Is it verifiable, not just on a claim of trust, that the production 
source from which SL 7 (and 8 and ... ) is built is the same production 
source used for the commercial for-profit RH supported RHEL 7 RPM 
distribution?  This latter statement is the basis for the validity of 
open source -- the source can be inspected (audited, if necessary), and 
the two sources compared. If this cannot be verified, then we do not 
know how CentOS, SL, etc., differ from RHEL (other than trivial logos 
and the like), and what software defects exist that are not present in RHEL.

Yasha Karant

On 06/19/2014 10:27 AM, Lamar Owen wrote:
> On 06/19/2014 11:47 AM, Patrick J. LoPresti wrote:
>> I do not care what any lawyer has to say on this topic, because this 
>> is not a legal question. 
>
> Sure it is.
>
>> Absolutely everyone reading this, including you, knows full well that 
>> the intent of the GPL -- indeed, its entire purpose -- is to enable 
>> precisely the kind of effort performed by the Scientific Linux 
>> maintainers _without undue burden_. 
>
> The release of source code the way Red Hat is currently releasing that 
> source code is fully within the spirit of the GPL, at least in my 
> opinion.
>
> Building packages out of git isn't really that much harder than 
> setting up mock to build from a directory full of source RPMS (I've 
> done this for EL5 on IA64, by they way, and it's not exactly easy to 
> do, either); it's just different, and there is and will be a learning 
> curve.  The CentOS team has a publicly accessible QA tree out there 
> already for testing-only purposes.  The issue with the lack of 
> signatures is not a GPL compliance problem; GPL requires modified 
> sources to be released, but it has never required that release to be 
> signed.
>
> Would I like things to be the way they were when Red Hat Linux 7 was 
> still named after a city (not RHEL 7; RHL 7, back before the turn of 
> the century)?  In some ways yes; in other ways no.
>
> On the bright side, the flurry of effort and collaboration is 
> downright refreshing.  It almost makes me want to jump in and maintain 
> something again.... almost.  I did that for five years, ten years ago, 
> and still get e-mails demanding that I fix something for free....
>
>> If some shyster finds some nuanced loophole that allows his employer 
>> to thwart this purpose, that says a lot more about the shyster and 
>> the employer than it does about the GPL. - Pat 
>
> Again I ask you to point me to a publicly accessible download repo of 
> current SLES source RPMs.  Now ask yourself why SLES source is hard to 
> find relative to RHEL source.
>
> Now, the Red Hat model is really pretty simple: you could, if you want 
> to and have a current RHEL subscription, download all the current 
> GPL-covered source RPMs of EL7 and post them to a public server and be 
> within your rights granted by the GPL.  But Red Hat can remove your 
> access to updates if you do so (GPL doesn't give you the automatic 
> right to receive future versions of source from your current version 
> of the binary;  you only have the guarantee to the version of the 
> source that matches the version of the binary that you received).  
> Nothing in the GPL requires the one who distributes the binary to 
> provide public access to the sources, either; only the person(s) to 
> whom the binaries are distributed have the right to demand source from 
> the distributor (and only for the version of those binaries that they 
> possess).
>
> But namecalling isn't really necessary, is it?