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.
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.
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.
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.
> 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.
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.
> 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?
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.
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.
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.
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
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.)
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.
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.
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?
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.
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...
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.
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.
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)
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.
> 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".