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: <CAOdo=SzsNsJWn2c-u+sjE_tigvGhVe0_=_hy_5gcgej38kn...@mail.gmail.com>
Subject: Re: Clarity on current status of Scientific Linux build
From: Tom H <[email protected]> )
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 <[email protected]> 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
