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

http://www.h-online.com/open/news/item/Controversy-surrounds-Red-Hat-s-obfuscated-source-code-release-1200554.html

by ibejoeb • 15 years ago

53 35 15 years 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• 15 years 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_user2• 15 years ago

Well, it seems like that could be dealt with through an information campaign...

burgerbrain• 15 years 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.

cageface2• 15 years 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.

sx• 15 years 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/) to verify patches in one of the free distros

__david__• 15 years 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• 15 years 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.

sagarun2• 15 years ago

citation needed!

cagenut• 15 years ago

The opposite is true. The CentOS maintainers have been very explicit, the goal is as exact a reproduction as possible. "bug for bug".

The only place they get creative is in the "centosplus" yum repo, which is disabled by default.

hasenj3• 15 years 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".

davidw4• 15 years ago

It is 'lossy' though - they're providing you with less information than what was put in.

hasenj3• 15 years 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.

sagarun2• 15 years ago

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

CrLf3• 15 years 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• 15 years 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.

CrLf3• 15 years 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• 15 years 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• 15 years 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.

rbanffy6• 15 years 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• 15 years 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• 15 years ago

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

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

Related Stories