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?
