CentOS - Nov 2011 - Changes at Red Hat confouding CentOS (was: What happened to 6.1)

These seems to me to be the first message in the series and provides a
really good summary of the changes at Red Hat which seem to be making
life a lot more difficult for CentOS.

Just figured I'd pull it out of that thread and change the subject line.

Below Johnny's email I've copied another from the original thread,
written by Lamar Owen, which gives some good explanation on how Red
Hat is able to get away with this.

Basically from what I gather, while Red Hat cannot restrict access to
sources, they can restrict access to binaries.  And since CentOS has a
goal of binary compatibility with upstream, they are essentially left
trying to hit an unknown target.  But (now I'm stretching my limited
knowledge even further) Scientific does not have this restriction
since they are less concerned about exact binary compat.

On Fri, Oct 21, 2011 at 12:54 PM, Johnny Hughes <johnny at centos.org>
wrote:
> On 10/21/2011 10:01 AM, Les Mikesell wrote:
>> On Fri, Oct 21, 2011 at 9:51 AM, Nicolas Thierry-Mieg
>> <Nicolas.Thierry-Mieg at imag.fr> wrote:
>>
>>>> Johnny, chill. I don't blame him for being confused. Up
until right now,
>>>> you updated to a point release, then, over the weeks and
months, there
>>>> were updates. All of a sudden, there are *no* updates for the
6.0 point
>>>> release, which is a major change in what everyone expected,
based on
>>>> history.
>>>
>>> this is the way it has always been: once upstream releases x.y+1 ,
there
>>> are no more updates to x.y (in upstream and therefore also in
centos),
>>> until centos releases x.y+1 .
>>
>> Yes, but that used to be transparent, because the centos x.y+1 release
>> happened quickly so it didn't matter that the update repo was held
>> back until an iso build was done.
>>
>
> Yes, and NOW the release process is MUCH harder.
>
> Red Hat used to have an AS release that contained everything ... we
> build that and we get everything. ?Nice and simple. ?Build all the
> packages, look at it against the AS iso set ... done. ?Two weeks was
> about as long as it took.
>
> Now, for version 6, they have:
>
> Red Hat Enterprise Linux Server (v. 6)
> Red Hat Enterprise Linux Workstation (v. 6)
> Red Hat Enterprise Linux Desktop (v. 6)
> Red Hat Enterprise Linux HPC Node (v. 6)
> Red Hat Enterprise Linux Workstation FasTrack (v. 6)
> Red Hat Enterprise Linux Server FasTrack (v. 6)
> Red Hat Enterprise Linux Desktop FasTrack (v. 6)
> Red Hat Enterprise Linux Scalable File System (v. 6)
> Red Hat Enterprise Linux Resilient Storage (v. 6)
> Red Hat Enterprise Linux Load Balancer (v. 6)
> Red Hat Enterprise Linux HPC Node FasTrack (v. 6)
> Red Hat Enterprise Linux High Performance Network (v. 6)
> Red Hat Enterprise Virtualization
>
> They have the same install groups with different packages based on the
> above groupings, so we have to do some kind of custom generation of the
> comps files to things work.
>
> They have created an optional channel in several of those groupings that
> is only accessible via RHN and they do not put those RPMS on any ISOs
> ... and they have completely changed their "Authorized Use
Policy" so
> that we can NOT login to RHN and use anything that is not on a public
> FTP server or on an ISO set ... effectively cutting us off from the
> ability to check anything on the optional channel.
>
> Now we have to engineer a compilation of all those groupings, we have to
> figure out what parts of the optional channels go at the point release
> and which ones do not (the ones that are upgrades). ? Sometimes the only
> way to tell is when something does not build correctly and you have
> reverse an optional package to a previous version for the build, etc.
>
> We have to use anaconda to build our ISOs and upstream is using
> "something else" to build theirs .. so anaconda NEVER works
anymore out
> of the box. ?We get ISOs (or usb images) that do not work and have to
> basically redesign anaconda.
>
> We can't look at upstream build logs, we can't get all the binary
RPMs
> for testing and be within the Terms of Service.
>
> And with the new release, it seems that they have purposely broken the
> rpmmacros, and do not care to fix it:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=743229
>
> So, trust me, it is MUCH more complicated now than it was with previous
> releases to build.
>
> With the 5.7 release, there were several SRPMS that did not make it to
> the public FTP server without much prompting from us. ?And with the
> Authorized Use Policy, I can not just go to RHN and grab that SRPM and
> use it. ?If it is not public, we can no longer release it.
>
> So, the short answer is, it now takes longer.
>
> Thanks,
> Johnny Hughes

Lamar Owen lowen at pari.edu via centos.org
Oct 28
to CentOS
On Friday, October 21, 2011 02:22:26 PM Les Mikesell
wrote:
> Which is explicitly imposing additional restrictions.  Which is
> explicitly prohibited in section 6.  I don't see any exceptions
> relating to what the consequences of those restrictions might be.
The RHN AUP simply says that if you redistribute information from RHN
you lose access to RHN.  It does not restrict your right to
redistribute anything; it restricts access to future information
distributions from RHN.  I know that's splitting hairs, but it does
seem to meet the letter of the license.  After all, RHN access is not
required except for updates; if I really wanted to do so I could
redistribute everything I have from RHN at this point in time and
upstream has no legal recourse against that distribution that I know
of (but I am neither a lawyer nor a paralegal; Russ on the other hand
knows of what he speaks....).

They can, however, choose to not distribute anything else to me in the
future, and nothing in the GPL or any other license used by upstream
forces them to distribute anything new to me.  And that's the gestalt
of the RHN AUP; it states under what conditions RHN will distribute
the compiled binary code (treated specially by GPL and not as a
derived work) to you, its customer.  Once you have received the binary
of a particular version you have the right, under GPL and only for
GPL-covered packages, to receive the source code for that particular
version of that package.

Upstream is very gracious (in my opinion, at least) and distributes
all of its source, not just GPL source and not just to customers but
to the public at large (I say all; I haven't personally verified that
all source in any given RHN channel is indeed available publicly on
ftp.redhat.com, primarily because I don't have access to all
channels).  They could distribute only the source that they legally
have to under those licenses that require it, but not for the source
covered under other licenses that do not require redistribution of
source plus modifications.

But just because I have version 1.2.3 of a package does not give me a
guaranteed right under GPL to get 1.2.4 from them.  And just because I
can get the source to the 1.2.4 package they distribute does not give
me an automatic right to the corresponding binary as the GPL does
treat the compiled code specially.  If you get the binary, you have
the right to the source; if you have the source it is assumed you can
generate the binary yourself (as is proven by the various EL
rebuilds).

The level of difficulty required to generate the binary is not
specified or even addressed by the GPL, nor does the GPL guarantee
your ability to generate the exact same binary as someone else
distributes..... nor is the distributor of the binary restricted at
all in how difficult generating their exact binary, or a 100%
compatible binary, can be.  This seems to be the current holdup with
C6.1, in my opinion; you can build *a* binary but will it work just
like *the* binary?  Upstream can make it even more difficult than they
already have (and I know it's currently very frustrating to the CentOS
team just from reading this thread!).

Russ, is that summary even close to accurate in your opinion?

These are the facts of life for an EL rebuild distribution user.  If
you want a primary access distribution (rather than a secondary
rebuild) you need to find one that meets your needs, either by paying
up for upstream or by going to something else (and there are really
only two suitable enterprise choices for 'something else' in this case
(and in my opinion): OpenSuSE or Debian Stable).

 I'm evaluating Debian Stable on IA64 myself, as Debian Stable is the
only actively maintained enterprise-grade distribution (again, in my
opinion) freely available for IA64 (yes, upstream's EL5 is still
available and is still maintained, but it costs six arms and eight
legs to purchase for the machines I have; SLES likewise).

And I don't really currently have the time to rebuild C6 for IA64
myself.  I'd love to, and I've had conversations with like-minded
people, and I don't really want to go to Debian on it since I really
want the IA64 boxes to work like all the other servers here which are
running upstream EL rebuilds.  But I have more important and necessary
things to do with my time at the moment than to get into the game of
maintaining a private rebuild for IA64 (I say private; even if I had
time to maintain the build I don't have time to deal with the
'issues'
of a public build!).


-- 
?Don't eat anything you've ever seen advertised on TV?
? ? ? ?? - Michael Pollan, author of "In Defense of Food"

On Mon, Nov 14, 2011 at 5:57 PM, Alan McKay <alan.mckay at gmail.com>
wrote:
> Basically from what I gather, while Red Hat cannot restrict access to
> sources, they can restrict access to binaries. ?And since CentOS has a
> goal of binary compatibility with upstream, they are essentially left
> trying to hit an unknown target. ?But (now I'm stretching my limited
> knowledge even further) Scientific does not have this restriction
> since they are less concerned about exact binary compat.
You are stretching your knowledge to a wrong direction :)

Both CentOS and Scientific Linux *aim* at 100% binary compatibility
and they are both doing their best toward that goal. However, neither
is perfect.

http://lists.centos.org/pipermail/centos/2011-November/119250.html

Akemi

Make centos a new distro and forget about rh

2011/11/14 Alan McKay <alan.mckay at gmail.com>
> These seems to me to be the first message in the series and provides a
> really good summary of the changes at Red Hat which seem to be making
> life a lot more difficult for CentOS.
>
> Just figured I'd pull it out of that thread and change the subject
line.
>
> Below Johnny's email I've copied another from the original thread,
> written by Lamar Owen, which gives some good explanation on how Red
> Hat is able to get away with this.
>
> Basically from what I gather, while Red Hat cannot restrict access to
> sources, they can restrict access to binaries.  And since CentOS has a
> goal of binary compatibility with upstream, they are essentially left
> trying to hit an unknown target.  But (now I'm stretching my limited
> knowledge even further) Scientific does not have this restriction
> since they are less concerned about exact binary compat.
>
> On Fri, Oct 21, 2011 at 12:54 PM, Johnny Hughes <johnny at
centos.org> wrote:
> > On 10/21/2011 10:01 AM, Les Mikesell wrote:
> >> On Fri, Oct 21, 2011 at 9:51 AM, Nicolas Thierry-Mieg
> >> <Nicolas.Thierry-Mieg at imag.fr> wrote:
> >>
> >>>> Johnny, chill. I don't blame him for being confused.
Up until right
> now,
> >>>> you updated to a point release, then, over the weeks and
months, there
> >>>> were updates. All of a sudden, there are *no* updates for
the 6.0
> point
> >>>> release, which is a major change in what everyone
expected, based on
> >>>> history.
> >>>
> >>> this is the way it has always been: once upstream releases
x.y+1 ,
> there
> >>> are no more updates to x.y (in upstream and therefore also in
centos),
> >>> until centos releases x.y+1 .
> >>
> >> Yes, but that used to be transparent, because the centos x.y+1
release
> >> happened quickly so it didn't matter that the update repo was
held
> >> back until an iso build was done.
> >>
> >
> > Yes, and NOW the release process is MUCH harder.
> >
> > Red Hat used to have an AS release that contained everything ... we
> > build that and we get everything.  Nice and simple.  Build all the
> > packages, look at it against the AS iso set ... done.  Two weeks was
> > about as long as it took.
> >
> > Now, for version 6, they have:
> >
> > Red Hat Enterprise Linux Server (v. 6)
> > Red Hat Enterprise Linux Workstation (v. 6)
> > Red Hat Enterprise Linux Desktop (v. 6)
> > Red Hat Enterprise Linux HPC Node (v. 6)
> > Red Hat Enterprise Linux Workstation FasTrack (v. 6)
> > Red Hat Enterprise Linux Server FasTrack (v. 6)
> > Red Hat Enterprise Linux Desktop FasTrack (v. 6)
> > Red Hat Enterprise Linux Scalable File System (v. 6)
> > Red Hat Enterprise Linux Resilient Storage (v. 6)
> > Red Hat Enterprise Linux Load Balancer (v. 6)
> > Red Hat Enterprise Linux HPC Node FasTrack (v. 6)
> > Red Hat Enterprise Linux High Performance Network (v. 6)
> > Red Hat Enterprise Virtualization
> >
> > They have the same install groups with different packages based on the
> > above groupings, so we have to do some kind of custom generation of
the
> > comps files to things work.
> >
> > They have created an optional channel in several of those groupings
that
> > is only accessible via RHN and they do not put those RPMS on any ISOs
> > ... and they have completely changed their "Authorized Use
Policy" so
> > that we can NOT login to RHN and use anything that is not on a public
> > FTP server or on an ISO set ... effectively cutting us off from the
> > ability to check anything on the optional channel.
> >
> > Now we have to engineer a compilation of all those groupings, we have
to
> > figure out what parts of the optional channels go at the point release
> > and which ones do not (the ones that are upgrades).   Sometimes the
only
> > way to tell is when something does not build correctly and you have
> > reverse an optional package to a previous version for the build, etc.
> >
> > We have to use anaconda to build our ISOs and upstream is using
> > "something else" to build theirs .. so anaconda NEVER works
anymore out
> > of the box.  We get ISOs (or usb images) that do not work and have to
> > basically redesign anaconda.
> >
> > We can't look at upstream build logs, we can't get all the
binary RPMs
> > for testing and be within the Terms of Service.
> >
> > And with the new release, it seems that they have purposely broken the
> > rpmmacros, and do not care to fix it:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=743229
> >
> > So, trust me, it is MUCH more complicated now than it was with
previous
> > releases to build.
> >
> > With the 5.7 release, there were several SRPMS that did not make it to
> > the public FTP server without much prompting from us.  And with the
> > Authorized Use Policy, I can not just go to RHN and grab that SRPM and
> > use it.  If it is not public, we can no longer release it.
> >
> > So, the short answer is, it now takes longer.
> >
> > Thanks,
> > Johnny Hughes
>
>
> Lamar Owen lowen at pari.edu via centos.org
> Oct 28
> to CentOS
> On Friday, October 21, 2011 02:22:26 PM Les Mikesell wrote:
> > Which is explicitly imposing additional restrictions.  Which is
> > explicitly prohibited in section 6.  I don't see any exceptions
> > relating to what the consequences of those restrictions might be.
>
> The RHN AUP simply says that if you redistribute information from RHN
> you lose access to RHN.  It does not restrict your right to
> redistribute anything; it restricts access to future information
> distributions from RHN.  I know that's splitting hairs, but it does
> seem to meet the letter of the license.  After all, RHN access is not
> required except for updates; if I really wanted to do so I could
> redistribute everything I have from RHN at this point in time and
> upstream has no legal recourse against that distribution that I know
> of (but I am neither a lawyer nor a paralegal; Russ on the other hand
> knows of what he speaks....).
>
> They can, however, choose to not distribute anything else to me in the
> future, and nothing in the GPL or any other license used by upstream
> forces them to distribute anything new to me.  And that's the gestalt
> of the RHN AUP; it states under what conditions RHN will distribute
> the compiled binary code (treated specially by GPL and not as a
> derived work) to you, its customer.  Once you have received the binary
> of a particular version you have the right, under GPL and only for
> GPL-covered packages, to receive the source code for that particular
> version of that package.
>
> Upstream is very gracious (in my opinion, at least) and distributes
> all of its source, not just GPL source and not just to customers but
> to the public at large (I say all; I haven't personally verified that
> all source in any given RHN channel is indeed available publicly on
> ftp.redhat.com, primarily because I don't have access to all
> channels).  They could distribute only the source that they legally
> have to under those licenses that require it, but not for the source
> covered under other licenses that do not require redistribution of
> source plus modifications.
>
> But just because I have version 1.2.3 of a package does not give me a
> guaranteed right under GPL to get 1.2.4 from them.  And just because I
> can get the source to the 1.2.4 package they distribute does not give
> me an automatic right to the corresponding binary as the GPL does
> treat the compiled code specially.  If you get the binary, you have
> the right to the source; if you have the source it is assumed you can
> generate the binary yourself (as is proven by the various EL
> rebuilds).
>
> The level of difficulty required to generate the binary is not
> specified or even addressed by the GPL, nor does the GPL guarantee
> your ability to generate the exact same binary as someone else
> distributes..... nor is the distributor of the binary restricted at
> all in how difficult generating their exact binary, or a 100%
> compatible binary, can be.  This seems to be the current holdup with
> C6.1, in my opinion; you can build *a* binary but will it work just
> like *the* binary?  Upstream can make it even more difficult than they
> already have (and I know it's currently very frustrating to the CentOS
> team just from reading this thread!).
>
> Russ, is that summary even close to accurate in your opinion?
>
> These are the facts of life for an EL rebuild distribution user.  If
> you want a primary access distribution (rather than a secondary
> rebuild) you need to find one that meets your needs, either by paying
> up for upstream or by going to something else (and there are really
> only two suitable enterprise choices for 'something else' in this
case
> (and in my opinion): OpenSuSE or Debian Stable).
>
>  I'm evaluating Debian Stable on IA64 myself, as Debian Stable is the
> only actively maintained enterprise-grade distribution (again, in my
> opinion) freely available for IA64 (yes, upstream's EL5 is still
> available and is still maintained, but it costs six arms and eight
> legs to purchase for the machines I have; SLES likewise).
>
> And I don't really currently have the time to rebuild C6 for IA64
> myself.  I'd love to, and I've had conversations with like-minded
> people, and I don't really want to go to Debian on it since I really
> want the IA64 boxes to work like all the other servers here which are
> running upstream EL rebuilds.  But I have more important and necessary
> things to do with my time at the moment than to get into the game of
> maintaining a private rebuild for IA64 (I say private; even if I had
> time to maintain the build I don't have time to deal with the
'issues'
> of a public build!).
>
>
> --
> ?Don't eat anything you've ever seen advertised on TV?
>          - Michael Pollan, author of "In Defense of Food"
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos
>


-- 
Analista de Sistemas
*MBA em
Log?stica:<http://www.logisticadescomplicada.com/a-auto-regulacao-dos-servicos-de-transporte-publico-urbano-de-passageiros/>Ger?ncia
Executiva de Transportes, Mobiliza??o e Meio Ambiente - GETRAM
*
*
*
Provedor <http://www.InstitutoFederalista.com/debate/> de Servi?os na
InterNet

Aten??o: Esta carta pode conter anexos no formato *ODF* (*Open Document
Format*)/*ABNT* (extens?es *odt*, *ods*, *odp*, *odb*, *odg*). Antes de
pedir os anexos em outro formato, voc? pode instalar gratuita e livremente
o *LibreOffice* <http://www.libreoffice.org/download> ou o seguinte
Aditivo
para Microsoft Office (R) (
http://www.sun.com/software/star/odf_plugin/get.jsp).

Converse na rede em:

http://iso27000.speeqe.com/
http:/Federalistas.speeqe.com/<http://iso27000.speeqe.com/>

http://onsync.digitalsamba.com/go/viabsb/federalistas
(senha: *federalistas**)*

O GMail n?o permite que voc? retire sua correspond?ncia do servidores da
empresa, *IMPEDINDO AO CIDAD?O LIVRE ACESSO ? SUA PR?PRIA CORRESPOND?NCIA*!

DENUNCIE

para o *Minist?rio P?blico Federal* em
prdc at prdf.mpf.gov.br.<prdc at prdf.mpf.gov.br>