| |||||||||||||
Kuhn: Thoughts On GPL Compliance of Red Hat's Linux DistributionKuhn: Thoughts On GPL Compliance of Red Hat's Linux DistributionPosted Mar 12, 2011 21:12 UTC (Sat) by ballombe (subscriber, #9523)Parent article: Kuhn: Thoughts On GPL Compliance of Red Hat's Linux Distribution
I think the reason there are so much reaction to this in that the kernel is the only interesting component of RHEL for people using non RHEL-based distribution, because first it is very far of the upstream kernel and second there are applications that are "certified" only when running under this kernel (and some will actually fail to work under any other kernel). For that reason, there have been Debian packages made of the RHEL kernel in the past.
The other issue is that the ability to avoid vendor-locking and change the enterprise that provide support is always listed as an advantage of using free software, which RedHat try to remove.
For that reason, French administration tenders sometimes require Debian, because this a vendor-neutral platform that does not favor any company.
(Log in to post comments)
Kuhn: Thoughts On GPL Compliance of Red Hat's Linux Distribution Posted Mar 13, 2011 0:48 UTC (Sun) by vonbrand (subscriber, #4458) [Link] This "Debian packaged exact RHEL kernel" would not be inconvenienced in the least by getting a monolithic patch, er even just a tarball. Not any more than it is a (non)problem for CentOS or Scientific Linux.
Kuhn: Thoughts On GPL Compliance of Red Hat's Linux Distribution Posted Mar 13, 2011 10:38 UTC (Sun) by jrn (subscriber, #64214) [Link]
Let me make a non-sequitur: the Debian packaged libbdb certainly seems to be inconvenienced by getting tarballs without patches split out. Of course this is different from CentOS, I think, since CentOS is meant to have almost identical sources to RedHat, to the extent allowed by trademark law, right? For what it's worth.
Kuhn: Thoughts On GPL Compliance of Red Hat's Linux Distribution Posted Mar 14, 2011 23:45 UTC (Mon) by rahvin (subscriber, #16953) [Link]
I don't think RedHat is trying to stop anyone from supporting RHEL. That is still trivially easy to do as you wouldn't be changing the kernel, just offering support on it.
There is a very small subset under attack by this change and is the subset that is trying to use all of RedHat's work, but up-sell a better kernel that more closely matches mainline but at the same time contains all of RedHat's work on bug fixes that are rolled into dozens of different kernel versions. This small subset is now presumably forced to reverse engineer every single change and security update RedHat does on their kernel. That could possibly be a very costly task depending on how difficult acquiring the reverse engineering is. Time will tell if this change is effective or if the reality of RedHat moving everything upstream makes the reverse engineering easy.
|
|||||||||||||