6 ms·

Controversy surrounds Red Hat's "obfuscated" source code release

53 points by ibejoeb 16y ago

joe_the_user 16y ago
Wow, It certainly gives you a feel Red Hat is feeling some resentment concerning those who "take" "their" source code. RH is one of the largest businesses based on open source software. What's up? Are they feeling so much pressure they feel a economic need to stop "free loaders?" Is it simple greed? There was a lot of sniping concerning Red Hat and Ubuntu's contribution to desktop Linux a while back. Another salvo in the "free loaders" battle?
- sgk284 16y ago
  My understanding is that this has a lot more to do with Oracle representing Red Hat's work as their own to their customers.
  - joe_the_user 16y ago
    Well, it seems like that could be dealt with through an information campaign...
    - rbanffy 16y ago
      Oracle can outspend Red Hat very easily in advertising. Going head-to-head against them like that would be insane. Besides that, Oracle has also made a lot of important contributions to Linux that Red Hat also benefits from (BtrFS is my favorite). We don't need an arms race here...
- burgerbrain 16y ago
  If it encourages those companies to invest in linux in a similar way as Red Had does, I'm all for it. And really, this is a very stupid definition of "obfuscate". This article is a non-article.
  - cageface 16y ago
    I've always felt that CentOS was in rather poor taste, even if it adheres to the spirit of the GPL. If you're really getting value out of Red Hat's enhancements to the system, then compensate them for their work.
    - vivekl 16y ago
      Clearly you mean oracle here. Being an ex RH-er I can tell you RH sees great value in centos. It keeps small shops on the RH reserve even if they don't pay for a support contract - yet. Oracle has recently tried to position itself as an "enhanced" rhel especially wrt the kernel and this seems like an attempt by RH to make things a bit harder for them. I don't agree with the move though - you don't want to follow oracle down such slippery slopes...
      - cageface 16y ago
        What value does RH see in CentOS? I know quite a few admins using CentOS because it essentially gives them the benefits of RHEL without having to pay license fees. None of them have any intention of ever paying for a RHEL license.
sx 16y ago
I think it's fair if it's aimed at Oracle given Oracle's record in terms of "supporting" open source. It will probably hurt a lot many others though, including CentOS. I would be happy to provide a free copy to anyone that might want to use Patch Miner (http://patterninsight.com/patchminer/ http://patterninsight.com/patchminer/) to verify patches in one of the free distros
__david__ 16y ago
> CentOS is built from the RHEL source by a limited number of volunteers and Red Hat's change in policy will mean more work for them unless more volunteers or other companies step in and provide them with assistance. I don't understand this statement. I thought CentOS basically just recompiled the source RPMs--why does pre-applying the patches affect them negatively?
- sliverstorm 16y ago
  CentOS has been taking it further than a simple recompile, particularly in the kernel. They will often have updates and patches and customizations on the base RHEL distribution.
  - sagarun 16y ago
    citation needed!
    - CrLf 16y ago
      Indeed. The lure of CentOS is pretty much that it is RHEL with replaced artwork. And Red Hat benefits a lot from CentOS... Red Hat sells to businesses, and any business with money to spend on RHEL subscriptions will do so. Management doesn't like free-as-in-beer very much. But they also don't like to see a piling amount of licensing costs on development and testing machines. Having a paid-for distribution and a free distribution with separate brandings allows RHEL to have a higher subscription cost while not losing customers to the competition because of the added cost of development/testing machines. I think this is even the reason why Red Hat is much more successful than Novell: the existence of a low-resistance path to the "enterprise" distribution without that meaning less quality or bleeding-edge distributions.
      - rbanffy 16y ago
        Interesting. You basically made the point I use to describe Microsoft's relationship to software piracy. CentOS allows Red Hat to compete in price with, say, Debian much like pirated copies of Windows allow Microsoft to compete in price with various Linux distros.
hasenj 16y ago
That's hardly "obfuscation". > Now though, the company ships a tarball of the source code with the patches already applied. No obfuscation what so ever. Unless you define "source" as "source code + version control history".
- davidw 16y ago
  It is 'lossy' though - they're providing you with less information than what was put in.
  - hasenj 16y ago
    Well, one could argue that "the preferred form" of changing the program is the source + version control, but the version control is not really "part" of the source, for all intents and purposes it's something "internal" they use to manage their development work. It's part of the developer's environment so to speak; not much unlike the editor and compiler. As far as the GPL is concerned, the purpose of providing the source is not to "participate in the community", but to have the ability to change the program. Do the clients of RedHat lose their ability to change the "program"? I think they don't.
    - davidw 16y ago
      You don't think there is any degradation in your ability to deal with source code if you have no idea that it's got various patches and where they come from? If your copy includes patches and a process to install them, it's a matter of a few minutes to compile without one of them (if it has no dependencies) because you don't want it. With a big ball of source code, you'd have to track down the original patch and see about how to reverse it - much more complicated. It's clearly not impossible to change the program, but you have lost information. I don't think it's "obfuscation" in the traditional sense, but it's certainly not what I'd call friendly, either.
    - roel_v 16y ago
      As the article points out, legally there is nothing wrong, they are perfectly in line with the GPL and anything it was meant to protect. That doesn't take away from the fact that (apparently, it's not like I know anything about it...) some actions are being taken to make it more difficult for downstream 'users' (as in, repackagers) to make their modifications. Not impossible, just more difficult.
sagarun 16y ago
Submitted something on the same topic 2 days back http://news.ycombinator.com/item?id=2272535 http://news.ycombinator.com/item?id=2272535
deleted 16y ago
[deleted]
deleted 16y ago
[deleted]
CrLf 16y ago
This is a rather negative spin on something that probably is much more simple... The kernel has always been the most heavily patched package by distributors. In the old days of Red Hat desktop, when they had a 6-month release cycle, it had maybe 10-15 patches. Now, with them having to support the same base kernel version for 7 years with bug fixes and backported features, I can only imagine how many patches it has. The line has to be drawn somewhere. At some point it stops being a somewhat patched kernel to become an effective fork. And for the major distributions it has become a fork for quite some time now. And the Linux kernel is heavily forked already. In fact, the whole Linux development model is based on particular forks by all the different subsystem groups and distributions, with periodical exchange of features and fixes between them leading eventually to the canonical Linux fork (Linus'). Today it doesn't make sense to be extracting patches from git just to produce a "tarball with patches" source RPM. It isn't a conspiracy, people. (If they started doing this to other packages, that would be another matter.)
- masklinn 16y ago
  The issue to your assertions is this: RedHat still uses patch stacks internally (that much is reported by RH engineers). It simply is not feasible to work on the kernel without patch stacks, unless you're OK with throwing it all away from one kernel to the next. The difference is that previously, as just about everybody else, they provided a stock kernel and their patch stacks which got applied on top of it locally. Now, unless you have a redhat support account, you only get the patched kernel, not the original one, not the patches. The patches are still there but applied on their side before distribution, it's actually more work for them to do it the new way, not less. And it generates exponentially more work for everybody else.
  - CrLf 16y ago
    The people working on, say, "ext4" also have to maintain their own patch stack in the form of a git repo. How to they manage to do that while still being able to go from one kernel to the next? How is that different from what Red Hat does?
gradschool 16y ago
Why couldn't anyone infer the patches by grabbing the original kernel source from kernel.org and using diff on them? (sorry if this is a naive question)
- ootachi 16y ago
  Well, that will give you one patch, not the original series of patches. You'll get a big pile of code diffs, but grouping them logically together will be tough.
rbanffy 16y ago
It may be difficult to tell what patches were applied, but it should be trivial to start with redhatskernel.tar.bz2, make a diff from the kernel.org corresponding release and generate one massive patch that should be applied to other different kernels. It reminds me of the first WebKit release and how KHTML folks got mad by it being supplied as a gigantic tarball and not a series of diffs. Much like CrLf said, this is an exaggeratedly negative spin on something really simple.
dedward 16y ago
I'm fine with this - this is within Oracle's rights. It goes against what we've come to expect with regards to Linux and GPL projects in general - but it's perfectly valid. Oracle is under no obligation to provide source patches back to anyone, with any additional meta-info. They are only required to provide unobfuscated source for the binaries they distribute - which they are doing. Think of it as a big kernel fork that runs it's project a different way. The community is free to analyze and take back what they want - that's all the GPL is about. If they had actually obfuscated the CODE to make it unreadable, that would be another matter possibly - but while not providing patches and possibly stripping comments, etc, is a form of obfuscation to the outside community, it's not code obfuscation. It's too bad they did this.. it's probably some paranoid manager at Oracle thinking this will make a big difference... but there's nothing wrong with it. you are free to take the current kernel, hack away on it all you want and just provide new copies whenever you release, without talking to, explaining, or helping anyone with anything, as long as you stick to the GPL.
lamby 16y ago
The lwn article has a number of insightful comments http://lwn.net/Articles/430098/ http://lwn.net/Articles/430098/

53 points by ibejoeb 16y ago

Wow, It certainly gives you a feel Red Hat is feeling some resentment concerning those who "take" "their" source code. RH is one of the largest businesses based on open source software. What's up? Are they feeling so much pressure they feel a economic need to stop "free loaders?" Is it simple greed? There was a lot of sniping concerning Red Hat and Ubuntu's contribution to desktop Linux a while back. Another salvo in the "free loaders" battle?

sgk284 16y ago
My understanding is that this has a lot more to do with Oracle representing Red Hat's work as their own to their customers.
- joe_the_user 16y ago
  Well, it seems like that could be dealt with through an information campaign...
  - rbanffy 16y ago
    Oracle can outspend Red Hat very easily in advertising. Going head-to-head against them like that would be insane. Besides that, Oracle has also made a lot of important contributions to Linux that Red Hat also benefits from (BtrFS is my favorite). We don't need an arms race here...
burgerbrain 16y ago
If it encourages those companies to invest in linux in a similar way as Red Had does, I'm all for it. And really, this is a very stupid definition of "obfuscate". This article is a non-article.
- cageface 16y ago
  I've always felt that CentOS was in rather poor taste, even if it adheres to the spirit of the GPL. If you're really getting value out of Red Hat's enhancements to the system, then compensate them for their work.
  - vivekl 16y ago
    Clearly you mean oracle here. Being an ex RH-er I can tell you RH sees great value in centos. It keeps small shops on the RH reserve even if they don't pay for a support contract - yet. Oracle has recently tried to position itself as an "enhanced" rhel especially wrt the kernel and this seems like an attempt by RH to make things a bit harder for them. I don't agree with the move though - you don't want to follow oracle down such slippery slopes...
    - cageface 16y ago
      What value does RH see in CentOS? I know quite a few admins using CentOS because it essentially gives them the benefits of RHEL without having to pay license fees. None of them have any intention of ever paying for a RHEL license.

sx 16y ago

I think it's fair if it's aimed at Oracle given Oracle's record in terms of "supporting" open source. It will probably hurt a lot many others though, including CentOS. I would be happy to provide a free copy to anyone that might want to use Patch Miner (http://patterninsight.com/patchminer/ http://patterninsight.com/patchminer/) to verify patches in one of the free distros

__david__ 16y ago

> CentOS is built from the RHEL source by a limited number of volunteers and Red Hat's change in policy will mean more work for them unless more volunteers or other companies step in and provide them with assistance. I don't understand this statement. I thought CentOS basically just recompiled the source RPMs--why does pre-applying the patches affect them negatively?

sliverstorm 16y ago
CentOS has been taking it further than a simple recompile, particularly in the kernel. They will often have updates and patches and customizations on the base RHEL distribution.
- sagarun 16y ago
  citation needed!
  - CrLf 16y ago
    Indeed. The lure of CentOS is pretty much that it is RHEL with replaced artwork. And Red Hat benefits a lot from CentOS... Red Hat sells to businesses, and any business with money to spend on RHEL subscriptions will do so. Management doesn't like free-as-in-beer very much. But they also don't like to see a piling amount of licensing costs on development and testing machines. Having a paid-for distribution and a free distribution with separate brandings allows RHEL to have a higher subscription cost while not losing customers to the competition because of the added cost of development/testing machines. I think this is even the reason why Red Hat is much more successful than Novell: the existence of a low-resistance path to the "enterprise" distribution without that meaning less quality or bleeding-edge distributions.
    - rbanffy 16y ago
      Interesting. You basically made the point I use to describe Microsoft's relationship to software piracy. CentOS allows Red Hat to compete in price with, say, Debian much like pirated copies of Windows allow Microsoft to compete in price with various Linux distros.

hasenj 16y ago

That's hardly "obfuscation". > Now though, the company ships a tarball of the source code with the patches already applied. No obfuscation what so ever. Unless you define "source" as "source code + version control history".

davidw 16y ago
It is 'lossy' though - they're providing you with less information than what was put in.
- hasenj 16y ago
  Well, one could argue that "the preferred form" of changing the program is the source + version control, but the version control is not really "part" of the source, for all intents and purposes it's something "internal" they use to manage their development work. It's part of the developer's environment so to speak; not much unlike the editor and compiler. As far as the GPL is concerned, the purpose of providing the source is not to "participate in the community", but to have the ability to change the program. Do the clients of RedHat lose their ability to change the "program"? I think they don't.
  - davidw 16y ago
    You don't think there is any degradation in your ability to deal with source code if you have no idea that it's got various patches and where they come from? If your copy includes patches and a process to install them, it's a matter of a few minutes to compile without one of them (if it has no dependencies) because you don't want it. With a big ball of source code, you'd have to track down the original patch and see about how to reverse it - much more complicated. It's clearly not impossible to change the program, but you have lost information. I don't think it's "obfuscation" in the traditional sense, but it's certainly not what I'd call friendly, either.
  - roel_v 16y ago
    As the article points out, legally there is nothing wrong, they are perfectly in line with the GPL and anything it was meant to protect. That doesn't take away from the fact that (apparently, it's not like I know anything about it...) some actions are being taken to make it more difficult for downstream 'users' (as in, repackagers) to make their modifications. Not impossible, just more difficult.

sagarun 16y ago

Submitted something on the same topic 2 days back http://news.ycombinator.com/item?id=2272535 http://news.ycombinator.com/item?id=2272535

deleted 16y ago

[deleted]

deleted 16y ago

[deleted]

CrLf 16y ago

This is a rather negative spin on something that probably is much more simple... The kernel has always been the most heavily patched package by distributors. In the old days of Red Hat desktop, when they had a 6-month release cycle, it had maybe 10-15 patches. Now, with them having to support the same base kernel version for 7 years with bug fixes and backported features, I can only imagine how many patches it has. The line has to be drawn somewhere. At some point it stops being a somewhat patched kernel to become an effective fork. And for the major distributions it has become a fork for quite some time now. And the Linux kernel is heavily forked already. In fact, the whole Linux development model is based on particular forks by all the different subsystem groups and distributions, with periodical exchange of features and fixes between them leading eventually to the canonical Linux fork (Linus'). Today it doesn't make sense to be extracting patches from git just to produce a "tarball with patches" source RPM. It isn't a conspiracy, people. (If they started doing this to other packages, that would be another matter.)

masklinn 16y ago
The issue to your assertions is this: RedHat still uses patch stacks internally (that much is reported by RH engineers). It simply is not feasible to work on the kernel without patch stacks, unless you're OK with throwing it all away from one kernel to the next. The difference is that previously, as just about everybody else, they provided a stock kernel and their patch stacks which got applied on top of it locally. Now, unless you have a redhat support account, you only get the patched kernel, not the original one, not the patches. The patches are still there but applied on their side before distribution, it's actually more work for them to do it the new way, not less. And it generates exponentially more work for everybody else.
- CrLf 16y ago
  The people working on, say, "ext4" also have to maintain their own patch stack in the form of a git repo. How to they manage to do that while still being able to go from one kernel to the next? How is that different from what Red Hat does?

gradschool 16y ago

Why couldn't anyone infer the patches by grabbing the original kernel source from kernel.org and using diff on them? (sorry if this is a naive question)

ootachi 16y ago
Well, that will give you one patch, not the original series of patches. You'll get a big pile of code diffs, but grouping them logically together will be tough.

rbanffy 16y ago

It may be difficult to tell what patches were applied, but it should be trivial to start with redhatskernel.tar.bz2, make a diff from the kernel.org corresponding release and generate one massive patch that should be applied to other different kernels. It reminds me of the first WebKit release and how KHTML folks got mad by it being supplied as a gigantic tarball and not a series of diffs. Much like CrLf said, this is an exaggeratedly negative spin on something really simple.

dedward 16y ago

I'm fine with this - this is within Oracle's rights. It goes against what we've come to expect with regards to Linux and GPL projects in general - but it's perfectly valid. Oracle is under no obligation to provide source patches back to anyone, with any additional meta-info. They are only required to provide unobfuscated source for the binaries they distribute - which they are doing. Think of it as a big kernel fork that runs it's project a different way. The community is free to analyze and take back what they want - that's all the GPL is about. If they had actually obfuscated the CODE to make it unreadable, that would be another matter possibly - but while not providing patches and possibly stripping comments, etc, is a form of obfuscation to the outside community, it's not code obfuscation. It's too bad they did this.. it's probably some paranoid manager at Oracle thinking this will make a big difference... but there's nothing wrong with it. you are free to take the current kernel, hack away on it all you want and just provide new copies whenever you release, without talking to, explaining, or helping anyone with anything, as long as you stick to the GPL.

lamby 16y ago

The lwn article has a number of insightful comments http://lwn.net/Articles/430098/ http://lwn.net/Articles/430098/