[rhelv6-list] RHEL6 kernel 2.6.32-71.14.1.el6.x86_64 panic...

Musayev, Ilya imusayev at webmd.net
Fri Mar 4 20:35:22 UTC 2011


Chris

I agree, stealing is not the right word - i guess "steering away" would sound more appropraite, but you get the context :)

-ilya

-----Original Message-----
From: Chris Adams [mailto:cmadams at hiwaay.net] 
Sent: Friday, March 04, 2011 3:29 PM
To: Musayev, Ilya
Cc: Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list
Subject: Re: RHEL6 kernel 2.6.32-71.14.1.el6.x86_64 panic...

Once upon a time, Musayev, Ilya <imusayev at webmd.net> said:
> I'm under assumption, this also explains why latest RHEL release notes disclose the bug numbers with slight description of what was discovered but when you try to open the BZ id, it tells you that you dont have permissions - essentially hiding all the details. This is probably a way of showing a middle finger to Oracle but unintentianlly also to everyone else.

Most RHEL bugs that are put in BZ from RH support are like that, as they can contain customer-private information (I haven't seen any big change in that).

> I think they could have addressed this issue with new licensing clause that would forbid Oracle like usage and possible permit community release - like CentOS. Come to think about it - CentOS also steals a large piece of "would be financial gain" pie - there are countless commercial CentOS users outthere.

Calling what CentOS does "stealing" is rather rude.  Red Hat can't really use any new licensing clauses that would prevent something like CentOS or Oracle anyway (the kernel is already GPLv2 for example).  This change just makes it more difficult for others that want to cherry-pick patches from RHEL kernels and apply them to their own (which AFAIK Oracle is the only major group doing that).

--
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.






More information about the rhelv6-list mailing list