Controversy surrounds Red Hat's "obfuscated" source code release
h-online.com
h-online.com
> 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".
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.
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.
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.
Almost a decade ago, I wrote some utilities that did exactly that, for merging and finding commonalities between the many (almost a dozen) different versions of the C programs that ran on our electronic voting systems.
Ok, now figure out which patch each of those differences belongs to, and for extra credit figure out in which order they were applied.
The point is not that it's impossible or something, it's that it now takes up extra time to find out information that they're basically hiding.
Why would I have to do that?
And don't forget we not only have the current tarball, but we can analyze every release for differences, capturing some history with it.
Reconstructing each original patch may not be possible (it's an interesting problem), but reconstructing a set of distinct patches is. Humans would then be better at assigning meaning to them, even if it means calling Red Hat's support line and paying for the answer.
Come on, I'm sure you can think of a reason or two why you might want to enable or disable specific patches.
You can always pay Red Hat to have their patches.
I don't understand this statement. I thought CentOS basically just recompiled the source RPMs--why does pre-applying the patches affect them negatively?
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.
The only place they get creative is in the "centosplus" yum repo, which is disabled by default.
I would be happy to provide a free copy to anyone that might want to use Patch Miner (http://patterninsight.com/patchminer/) to verify patches in one of the free distros
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.)
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.
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?
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.
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?
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...
And really, this is a very stupid definition of "obfuscate". This article is a non-article.
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.