
Controversy surrounds Red Hat's "obfuscated" source code release - ibejoeb
http://www.h-online.com/open/news/item/Controversy-surrounds-Red-Hat-s-obfuscated-source-code-release-1200554.html
======
hasenj
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
It is 'lossy' though - they're providing you with less information than what
was put in.

~~~
hasenj
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.

~~~
roel_v
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.

~~~
hasenj
Not to make modifications, but, as far as I understand, to merge/integrate
patches to the vanilla kernel from other sources.

~~~
rbanffy
Unless they start renaming files, interfaces, functions and structures for no
reason, it's really trivial to start with tree A and get a set of differences
between it and tree B.

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.

~~~
davidw
> it's really trivial to start with tree A and get a set of differences
> between it and tree B.

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.

~~~
rbanffy
> now figure out which patch each of those differences belongs to

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.

~~~
davidw
> Why would I have to do that?

Come on, I'm sure you can think of a reason or two why you might want to
enable or disable _specific patches_.

~~~
rbanffy
There is a difference between disabling a Red Hat patch and a group of changes
between a set of files. Separating the large diffsets by fileset alone may
provide good cues as to what they do.

You can always pay Red Hat to have their patches.

------
__david__
> _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
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
citation needed!

~~~
CrLf
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
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.

------
sx
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

------
CrLf
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
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
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?

------
rbanffy
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.

------
joe_the_user
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?

~~~
burgerbrain
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
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
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
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.

------
dedward
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.

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

------
gradschool
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
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.

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

