Red Hat's "obfuscated" kernel source [LWN.net]

Several readers have pointed out this interview with Maximilian Attems, posted by Raphaël Hertzog. Therein, Maximilian states that, while the cross-distribution cooperation on the 2.6.32 kernel has been a great thing, Red Hat is making things harder by shipping its RHEL 6 kernel source as one big tarball, without breaking out the patches. Your editor has downloaded the 2.6.32-71.14.1.el6 source package and verified that this is the case.

One of the key points behind the RPM and Debian package formats is that source is shipped in its upstream form, with patches shipped separately and applied at build time. Red Hat has always followed this convention; the failure to do so with the RHEL 6 kernel is a new and discouraging change of behavior. Distribution in this form should satisfy the GPL, but it makes life hard for anybody else wanting to see what has been done with this kernel. Hopefully it is simply a mistake which will be corrected soon.

to post comments

Red Hat's "obfuscated" kernel source

Posted Feb 28, 2011 18:01 UTC (Mon) by BenHutchings (subscriber, #37955) [Link] (143 responses)

It's not a mistake; I have confirmation from RH developers that it is a deliberate policy.

Red Hat's "obfuscated" kernel source

Posted Feb 28, 2011 18:04 UTC (Mon) by Rubberman (guest, #70320) [Link] (8 responses)

Well, just download the SL6 (Scientific Linux 6) kernel instead... :-)

Red Hat's "obfuscated" kernel source

Posted Feb 28, 2011 18:08 UTC (Mon) by daney (guest, #24551) [Link] (6 responses)

... or CentOS.

Which points to a possible motivation for the change.

Red Hat's "obfuscated" kernel source

Posted Feb 28, 2011 18:17 UTC (Mon) by smoogen (subscriber, #97) [Link] (1 responses)

I really can't see how sending a tar ball versus a tar ball and 2000 patches is meant to do anything for CentOS beyond making their life easier. CentOS does not have kernel developers or people who are going to disect which patch did what. They have people who do a mock rebuild of a package and put it in a tree. Having just one source ball to deal with cuts down their complexity quite a bit.

Red Hat's "obfuscated" kernel source

Posted Feb 28, 2011 19:08 UTC (Mon) by jebba (guest, #4439) [Link]

How does one huge tarball make it any easier to rebuild with mock? If they are simply doing just `mock kernel.src.rpm` it makes no difference if it is a huge tarball or 2000 patches. If they do go to try to understand the differences, the huge tarball makes it harder.

This has the makings of a short term mistake on Red Hat, Inc.'s part which is going to continually bite them for the next decade (think: old gcc patch, that *still* gets brought up)....

Red Hat's "obfuscated" kernel source

Posted Feb 28, 2011 21:37 UTC (Mon) by lolando (guest, #7139) [Link] (1 responses)

There's another "downstream" that maybe Red Hat wouldn't be too sad to see inconvenienced, because after all they compete directly. Begins with an O, and claims to be unbreakable.

Red Hat's "obfuscated" kernel source

Posted Mar 1, 2011 4:40 UTC (Tue) by jmalcolm (subscriber, #8876) [Link]

This makes sense. It would certainly impact the commerical cloners (like Oracle) more than the open source white boxers (CentOS, SL, etc).

Oracle might have to spend some money understanding what it is they are supporting in order to get those support contracts.

Red Hat's "obfuscated" kernel source

Posted Mar 9, 2017 18:15 UTC (Thu) by phred14 (guest, #60633) [Link] (1 responses)

I thought there was a cozy relationship between RedHat and CentOS since something like 2014. CentOS gets an animosity-free product. RedHat gets a loss-leader. (Oh, you want business-class support?)

Red Hat's "obfuscated" kernel source

Posted Mar 9, 2017 18:19 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

CentOS was essentially acquired by Red Hat.

https://lwn.net/Articles/579551/

So they work together fine.

Red Hat's "obfuscated" kernel source

Posted Mar 1, 2011 4:37 UTC (Tue) by jmalcolm (subscriber, #8876) [Link]

How does downloading from Scientific Linux or CentOS help? Those distributions just download the source from Red Hat, rebrand, rebuild, and redistribute. You are not going to get a differenent source file and patch set than the one that Red Hat provides.

Am I wrong?

Red Hat's "obfuscated" kernel source

Posted Feb 28, 2011 18:18 UTC (Mon) by jonabbey (guest, #2736) [Link] (9 responses)

That's really disappointing. It was always very valuable being able to see exactly what Red Hat had done vs. upstream, on a patch by patch basis.

Red Hat's "obfuscated" kernel source

Posted Feb 28, 2011 19:44 UTC (Mon) by riel (subscriber, #3142) [Link] (8 responses)

You cannot really see that anymore, anyway. Since upstream has adapted git, more and more developers have gotten into the habit of breaking up their changes into small changesets.

As a result, the number of kernel patches from one RHEL update to the next has grown from a few hundred large patches, to a few thousand tiny patches.
I suspect this trend will continue.

That is just not a practical amount to comb through, and it was getting to the point where applying the patches took almost as much time as compiling the kernel on some systems.

Red Hat's "obfuscated" kernel source

Posted Mar 1, 2011 2:02 UTC (Tue) by brouhaha (guest, #1698) [Link] (7 responses)

and it was getting to the point where applying the patches took almost as much time as compiling the kernel on some systems.

So? Computers are also twice as fast as they were ten years ago.

I have a hard time believing that Red Hat's kernel developers can effectively manage kernel development WITHOUT keeping a set of patches against the stock kernel. It seems likely to me that they are just flattening it somewhere in the process downstream from where the actual maintenance occurs.

Red Hat's "obfuscated" kernel source

Posted Mar 1, 2011 4:47 UTC (Tue) by jzbiciak (guest, #5246) [Link] (1 responses)

So? Computers are also twice as fast as they were ten years ago.

I'm glad I don't buy computers where you buy computers.

Red Hat's "obfuscated" kernel source

Posted Mar 1, 2011 9:49 UTC (Tue) by dgm (subscriber, #49227) [Link]

Well, maybe he forgot to mention that they become ten times smaller, too.

Red Hat's "obfuscated" kernel source

Posted Mar 1, 2011 17:02 UTC (Tue) by jengelh (subscriber, #33263) [Link] (4 responses)

>So? Computers are also twice as fast as they were ten years ago.

And yet you win nothing. Your double computing power is again eaten by double-optimizing compilers and a larger set of files to deal with.
(Remember the day when an operating system was just the 100-or-so files in C:\DOS.)

Red Hat's "obfuscated" kernel source

Posted Aug 8, 2012 19:22 UTC (Wed) by hummassa (guest, #307) [Link] (3 responses)

> Remember the day when an operating system was just the 100-or-so files in C:\DOS

Twenty. There were roughly twenty files. DIR C:\DOS did not scroll, nor paused, nor "more"'d or "less"'ed. It just showed less then twenty files, and a little bit less than 120K bytes free space (in a 160k disk).

*sigh* the follies of youth...

Red Hat's "obfuscated" kernel source

Posted Aug 11, 2012 11:03 UTC (Sat) by Jonno (subscriber, #49613) [Link] (2 responses)

FOUR (4) files (io.sys, msdos.sys, config.sys, command.com), the rest was not the OS, just utilities distributed together with the OS.

Red Hat's "obfuscated" kernel source

Posted Aug 11, 2012 17:24 UTC (Sat) by hummassa (guest, #307) [Link] (1 responses)

not all computers had config.sys or autoexec.bat... :-D Technically, MS-DOS was msdos.sys. io.sys was the "device driver pack" and command.com was a (changeable) shell.

Red Hat's "obfuscated" kernel source

Posted Aug 11, 2012 21:50 UTC (Sat) by Jonno (subscriber, #49613) [Link]

io.sys was not a driver pack loaded by msdos.sys, it was in fact the "core" kernel image that also included some io drivers needed to load msdos.sys (e.g. for disk drives and filesystem). In Linux terms it would be equivalent to /boot/vmlinuz.

msdos.sys, on the other hand, was auxiliary kernel functionality loaded by io.sys. The closest things in the Linux world would be loadable kernel modules in /lib/modules. In MS-DOS 7 (only sold bundled with the Windows 9x Desktop Environment) all code from msdos.sys has been merged into io.sys, and in FreeDOS the combination has been renamed kernel.sys.

config.sys was a text file parsed by msdos.sys (or io.sys in MS-DOS 7). Essentially it was the DOS equivalent of the Linux cmdline (on modern x86 systems usually specified in the Grub configuration file). It also allowed loading additional kernel modules and specifying parameters to them (eg replacing the modprobe utility). While not strictly required, still definitely part of the OS.

command.com was the entry point for userspace code. Not part of the kernel, but still part of the OS. In GNU/Linux terms it would be a merge of /sbin/init and /bin/sh as well as most of coreutils. While replaceable, replacing it would pretty much make a different OS with the same kernel (think Android vs GNU/Linux).

I didn't mention autoexec.bat, it was not part of the OS, but a way to autostart non-os stuff on your computer, essentially the DOS equivalent of /etc/rc.local.

Red Hat's "obfuscated" kernel source

Posted Feb 28, 2011 18:22 UTC (Mon) by clugstj (subscriber, #4020) [Link] (10 responses)

Did you ask them why they made this change?

Red Hat's "obfuscated" kernel source

Posted Feb 28, 2011 23:33 UTC (Mon) by jerub (guest, #73225) [Link] (9 responses)

Yes, I have asked why they have made this change. I tracked down and interrogated several Red Hat engineers on this issue, and while they were very reticent to speak about it, I discovered the following things:

- It is not about Centos.

- The primary motivation was to make it harder for Oracle Enterprise Linux to repackage the work that Red Hat do.

- The kernel tarball inside the srpm is created from a git tree that is only accessible to Red Hat engineers.

- This change to the way that kernels are dealt with inside Red Hat has angered and frustrated engineers who work on the product. Employees of the company are Not Happy.

- The orders to do this, to make it harder to rebuild the kernel with and without patches, and to make it harder to extract specific patches from the Red Hat kernel came from the top. This is with the knowledge of, and by the order of, the CEO: Jim Whitehurst.

- There is a web interface (somewhere!) that is available that will allow you to specifically omit specific patches and download a new kernel. This is a clunky web front end to the git tree.

- An Oracle engineer I interviewed on this matter greeted this news with in-credulousness, and quickly got out his notebook so he could provide me with links to the various public git trees that oracle maintains of their kernels, and showed me where I could download them from.

Red Hat's "obfuscated" kernel source

Posted Mar 1, 2011 11:20 UTC (Tue) by nix (subscriber, #2304) [Link]

- There is a web interface (somewhere!) that is available that will allow you to specifically omit specific patches and download a new kernel. This is a clunky web front end to the git tree.

Well, that makes the whole thing completely pointless, doesn't it? One bit of automation, a pile of rather slow downloading and bingo, the patches are split out again. Only effect: lots of extra bandwidth cost for RH.

Red Hat's "obfuscated" kernel source

Posted Mar 2, 2011 17:10 UTC (Wed) by jnh (subscriber, #69758) [Link]

> - The primary motivation was to make it harder for Oracle Enterprise
> Linux to repackage the work that Red Hat do.

This makes me ache. For the past several years, I'd been fighting an
on-again-off-again argument with the lead DBA at my (mercifully former)
place of employment about OEL vs. RHEL. We'd run all our Oracle DB and
grid infrastructure systems on RHEL from day 1, and we used RHEL everywhere
we needed support contracts to back up proprietary software installations.
The sysadmins didn't want to add a distro migration to their TODO list,
particularly one with no obvious benefits to the other applications we ran
on RHEL. The DBAs argument was invariably "we probably wouldn't have
problem $foo if we ran OEL, and even if we did Oracle would owe us an
explanation becuase we have a support contract." (This is ignoring that
we obviously had a RHEL contract too, our DBA didn't like to leave his
little world of all-things-Oracle.) During the last argument of this
nature, which was centered around the kernel's swap behavior, I visisted
both Oracle and RedHat's archives, pulled down the kernel patches, and
compared them to see if there was *any* way the OEL kernel would behave
differently. At the time there was only one patch that was even close to
being relevant in the mm subsystem and there was no way it was going to
make a difference in the behavior we were trying to figure out. I used
that information to *quickly* shutdown the argument and bring the focus
off of switching to OEL and back to actually figuring out the root cause.
While I could have still made the comparison by grabbing the patches from
rhn (which I assume is where this web UI lives) it would have been an
inconvenience. Assuming that OEL really is the primary motivation behind
this, I'm embarrassed for RedHat. It's far easier to inconvenience your
customers than it is to inconvenience somebody like Oracle.

Red Hat's "obfuscated" kernel source

Posted Mar 3, 2011 0:05 UTC (Thu) by BenHutchings (subscriber, #37955) [Link] (6 responses)

I wear another hat as a driver developer, and I can say that it is significantly more frustrating to review and test RH's backport of the driver to RHEL 6 than the backport to RHEL 5 - even though the latter is 14 kernel releases older and consequently needs more changes to the upstream driver.

Red Hat's "obfuscated" kernel source

Posted Mar 5, 2011 16:15 UTC (Sat) by BenHutchings (subscriber, #37955) [Link] (1 responses)

Test comment with Iceweasel 4.0; please ignore.

Red Hat's "obfuscated" kernel source

Posted Aug 8, 2012 11:58 UTC (Wed) by xz (guest, #86176) [Link]

Test comment; please ignore.

Red Hat's "obfuscated" kernel source

Posted Mar 5, 2011 16:18 UTC (Sat) by BenHutchings (subscriber, #37955) [Link]

Test comment with Iceweasel 4.0 and add-ons; please ignore.

Red Hat's "obfuscated" kernel source

Posted Mar 5, 2011 16:20 UTC (Sat) by BenHutchings (subscriber, #37955) [Link]

And one final test comment.

Red Hat's "obfuscated" kernel source

Posted Mar 5, 2011 16:36 UTC (Sat) by BenHutchings (subscriber, #37955) [Link]

Sorry, one more test required.

Red Hat's "obfuscated" kernel source

Posted Aug 8, 2012 13:18 UTC (Wed) by nix (subscriber, #2304) [Link]

The question is why this comment of all comments is receiving so many 'test comment' postings :)

Red Hat's "obfuscated" kernel source

Posted Feb 28, 2011 18:31 UTC (Mon) by patrick_g (subscriber, #44470) [Link] (101 responses)

I contacted Matthew Garrett about this kernel issue and he said he can't comment. He gave me the advice to contact RH press people.
I'm waiting for an official answer from Kerri Catallozzi.

I wrote a little text about this on linuxfr and one of the reader said he was a former RH employee and, according to him, this policy is deliberate. He said that a lot of RH devs are not happy with this new kernel policy. Patches are only visible for RH subscribers (through a web interface).

Red Hat's "obfuscated" kernel source

Posted Feb 28, 2011 19:16 UTC (Mon) by pkern (subscriber, #32883) [Link] (99 responses)

Patches are only visible for RH subscribers (through a web interface).

Especially annoying as this means that every RH subscriber can just leak them to the world, because they're obviously derivative works of a GPL'ed code base.

Red Hat's "obfuscated" kernel source

Posted Feb 28, 2011 19:22 UTC (Mon) by patrick_g (subscriber, #44470) [Link] (98 responses)

>>> this means that every RH subscriber can just leak them to the world

Read part 6 of this text : https://access.redhat.com/site/help/terms_conditions.html

Red Hat's "obfuscated" kernel source

Posted Feb 28, 2011 19:47 UTC (Mon) by azaghal (subscriber, #47042) [Link] (97 responses)

If you take a better look at it, pkern is right on this one. And even the part 6 of the agreement acknowledges this:

----%----
In the event of a conflict, inconsistency or difference between this Section 6 and the terms of a License or Customer Agreement, the License or Customer Agreement will control (for example, for Red Hat Content licensed under a Creative Commons License, you will have the rights set forth in the applicable Creative Commons License).
----%----

Even if the agreement didn't acknowledge it, GPL is _very_ precise on the fact that you cannot further limit the derivative work (from part 6 of GPLv2 license):

----%----
You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
----%----

It's not so simple

Posted Feb 28, 2011 20:51 UTC (Mon) by khim (subscriber, #9252) [Link] (96 responses)

RedHat can not restrict you, that's true, but they can (and probably would) refuse to support your RHEL installations and terminate access to subscriber-only area.

It's not so simple

Posted Feb 28, 2011 20:58 UTC (Mon) by dskoll (subscriber, #1630) [Link] (74 responses)

On what basis could they do that? If you've paid money and not violated the license, RH couldn't unilaterally decide to shut you off.

(Well, I suppose they could do whatever they wanted, but they'd be sued within an inch of their life if they tried, I suspect.)

It's not so simple

Posted Feb 28, 2011 21:24 UTC (Mon) by pzb (guest, #656) [Link] (73 responses)

Because support is not covered under the GPL, but under the Subscription Services appendix of the Red Hat Enterprise Agreement. It says:

Distributing the Software or any portion of the Subscription Services to a third party or using any of the Subscription Services for the benefit of a third party is a material breach of the Agreement even though the open source license applicable to individual software packages may give you the right to distribute those packages

So you breach the agreement if you distribute the packages. If you are in breach, they do not provide services (support or further updates) to you.

It's not so simple

Posted Feb 28, 2011 21:50 UTC (Mon) by jonabbey (guest, #2736) [Link] (5 responses)

Oh, that's a nasty bit of business.

It's not so simple

Posted Feb 28, 2011 23:16 UTC (Mon) by pzb (guest, #656) [Link] (4 responses)

No, the nasty bit is:

Any unauthorized use of the Subscription Services is a material breach of the Agreement, such as (a) only purchasing or renewing Subscription Services based on some, but not all, of the total number of Units of Red Hat Software or other Red Hat Product that you deploy, install, use or execute [...] For the purposes of this paragraph (for example, in calculating the total number of Units of Software), Software would include versions or copies that have the Red Hat trademark(s) and/or logo file(s) removed.

This would suggest that RHEL customers have to pay Red Hat for a subscription for each of their CentOS, Scientific Linux, etc systems in addition to their RHEL systems.

It's not so simple

Posted Mar 1, 2011 0:27 UTC (Tue) by ESRI (guest, #52806) [Link]

Wow, that is sneaky. When was that added?

It's not so simple

Posted Mar 1, 2011 0:40 UTC (Tue) by jspaleta (subscriber, #50639) [Link] (2 responses)

That would be the wrong interpretation. I believe paragraph is meant to address customers who purchase a subscription for a RHEL product, let that subscription expire and keep the system running RHEL and then start a second subscription to start up a second RHEL product instance. On and on such that they have many RHEL instances in service but are only paying subscriptions on a few of them. Even versions that have been manually manipulated to hide the fact that it was a RHEL product installation. You can easily replace small portions of the system software on a running RHEL system such that no trace of the Red Hat protected marks are present on the system and still be using nearly entirely the executable code as built and certified by Red Hat.

Basically the idea is.. if you are going to install RHEL then the deal is you will be paying subscriptions for all the RHEL you run in-house. If you decide the subscription isn't a good value, then you can stop paying it and still run the RHEL system..but you have to stop paying it for _all_ the RHEL systems you have. You can't drop half your system...its all systems or none...no in-between. In for a penny, in for a pound.

I do not believe that the clause is intended to nor can be can be used to enforce payment to count CentOS or Scientific installs..or even Oracle installs. None of these are Red Hat branded products at any point. None of these products were ever eligible for services from Red Hat under the service agreement. They are distinctly different products from distinctly different vendors.

-jef

It's not so simple

Posted Mar 1, 2011 0:45 UTC (Tue) by foom (subscriber, #14868) [Link] (1 responses)

I'm having a bit of trouble figuring how you came by your interpretation. "Software would include versions or copies that have the Red Hat trademark(s) and/or logo file(s) removed." sounds to me like an exact description of CentOS.

You say that clause only applies if I remove RedHat's trademarks, but not if the CentOS project does so?

It's not so simple

Posted Mar 1, 2011 0:55 UTC (Tue) by jspaleta (subscriber, #50639) [Link]

No its not an exact description of CentOS. CentOS is a full rebuild of the underlying source code. It is NOT rebranded Red Hat built and certified binaries.

I'm saying that the act of rebuilding from source is different _product_. CentOS is not a Red Hat product offering in any form. It's not certified by Red Hat and does not get access to subscription services Red Hat sales you when you get RHEL.

An installed RHEL system with with binaries built and certified by Red Hat that has been modified post-install to hide the fact that it was originally installed on the system as a branded Red Hat product. Those are the systems at issue here in this clause. These situations are absolutely most definitely distinctly different than choosing to install CentOS.

-jef

It's not so simple

Posted Mar 1, 2011 0:26 UTC (Tue) by dskoll (subscriber, #1630) [Link] (66 responses)

Distributing the Software or any portion of the Subscription Services to a third party or using any of the Subscription Services for the benefit of a third party is a material breach of the Agreement even though the open source license applicable to individual software packages may give you the right to distribute those packages.

If that isn't against the letter of the GPL, it's certainly against the spirit. The GPL specifically says "You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License." You'd have to be a very creative lawyer to argue that terminating a support contract is not imposing "further restrictions" on the exercise of GPL-granted rights.

It's not so simple

Posted Mar 1, 2011 1:37 UTC (Tue) by JoeBuck (subscriber, #2330) [Link]

If your support contract is terminated, you can continue to use, modify, and distribute the code, and you can continue to ask for source from Red Hat to what you have good for up to three years. What you can't do is expect Red Hat Support to do something about your bugs or provide you with help.

It's not so simple

Posted Mar 1, 2011 14:27 UTC (Tue) by AndreE (guest, #60148) [Link] (64 responses)

The GPL doesn't make demands on your labor. You can choose to support whatever the hell you want.

It's not so simple

Posted Mar 1, 2011 16:49 UTC (Tue) by dskoll (subscriber, #1630) [Link] (63 responses)

So it's ok to sell a support contract and say "By the way, if you exercise rights granted by the GPL, we will unilaterally terminate this contract and not refund your money?"

It's not so simple

Posted Mar 1, 2011 19:52 UTC (Tue) by jthill (subscriber, #56558) [Link] (49 responses)

The GPL license terms also ask you to give up rights. Substantially more valuable rights, imo. If you don't like the terms you're free to not accept them, but if you do accept, what's your complaint?

What's the complaint?

Posted Mar 1, 2011 20:40 UTC (Tue) by dskoll (subscriber, #1630) [Link] (24 responses)

Since I'm not a Red Hat customer, I don't really have a complaint for myself. (I am most certainly never going to be a Red Hat customer while this policy is in place.)

My complaint is that Red Hat seems to feel that it's fine to benefit from the GPL (they've built a billion-dollar business on GPL'd software), but are now imposing restrictions that make it harder for others to benefit from the GPL.

Even if this is legal, it's unethical. It's completely contrary to the intent of the GPL. I do not admire Red Hat's cleverness at finding a legal way to add restrictions to the GPL.

What's the complaint?

Posted Mar 1, 2011 21:55 UTC (Tue) by AndreE (guest, #60148) [Link] (22 responses)

They are not adding restrictions to the GPL. They are adding restrictions to their support contract, which is not under the GPL L. Name one thing the GPL allows you to do that you are prevented from doing under this arrangement

What's the complaint?

Posted Mar 1, 2011 21:56 UTC (Tue) by dlang (guest, #313) [Link] (6 responses)

distributing source code to others

What's the complaint?

Posted Mar 2, 2011 5:35 UTC (Wed) by AndreE (guest, #60148) [Link] (5 responses)

You are still free to distribute this source to others and nothing prevents you from doing so

What's the complaint?

Posted Mar 2, 2011 5:37 UTC (Wed) by AndreE (guest, #60148) [Link] (4 responses)

More specifically, Red Hat cannot and are not preventing you from releasing the source.

What's the complaint?

Posted Mar 2, 2011 5:43 UTC (Wed) by dlang (guest, #313) [Link] (3 responses)

they can make it cost you, potentially cost you a lot to redistribute the source.

at what point does the cost become 'prohibiting'?

What's the complaint?

Posted Mar 2, 2011 5:50 UTC (Wed) by AndreE (guest, #60148) [Link] (2 responses)

That's a good point, although without outlining the exact costs you cannot unilaterally say that they are prohibiting ALL users from redistribution.

What's the complaint?

Posted Mar 2, 2011 5:54 UTC (Wed) by dlang (guest, #313) [Link] (1 responses)

but the GPL doesn't say that you must allow _some_ recipients to redistribute the code, it says you must allow _all_ recipients to redistribute the code.

once you start eroding this, where can you draw the line?

"all animals are equal, but some are more equal than others"

What's the complaint?

Posted Mar 2, 2011 6:09 UTC (Wed) by AndreE (guest, #60148) [Link]

I don't think I wrote what I wanted to write.

I mean the question of whether you are prohibited is trickier to determine than I originally considered. I'm not agreeing that this service agreement means you ARE prohibited from redistribution, but I'm backing down from my position that you certainly are not prohibited

What's the complaint?

Posted Mar 1, 2011 22:07 UTC (Tue) by dskoll (subscriber, #1630) [Link] (14 responses)

The GPL allows you to redistribute derived works under the GPL. Red Hat claims that doing that is a breach of their subscription agreement.

What's the complaint?

Posted Mar 2, 2011 5:44 UTC (Wed) by AndreE (guest, #60148) [Link] (13 responses)

Yes and what does the GPL say about Red Hat's license agreement?

Nothing.

You are still free to distribute the code under GPL, modify it under the terms of the GPL, and utilize the precise freedoms the GPL gives you.

If Red Hat said that you could only distribute the code if you were a subscriber, then THAT would be an additional condition. But that is not what they are saying at all.

What's the complaint?

Posted Mar 2, 2011 5:49 UTC (Wed) by dlang (guest, #313) [Link] (10 responses)

no, they are saying that they will only show you the code if you are a subscriber, and that if you want to be a subscriber you are not allowed to distribute the code.

that sounds very similar to the microsoft 'viewable' source the difference being that microsoft can sue you for damages while RedHat can only stop supplying you with updates and support, potentially shutting your business down while you transition to a different distro

What's the complaint?

Posted Mar 2, 2011 5:59 UTC (Wed) by AndreE (guest, #60148) [Link] (9 responses)

Wait, if I have a subscription, obtain GPL binaries from Red Hat, then cancel my sub, I can no longer access the source to my GPL binaries?

What's the complaint?

Posted Mar 2, 2011 9:12 UTC (Wed) by airlied (subscriber, #9104) [Link] (8 responses)

they are on the ftp site.

all the source code + all the files needed to rebuild are in the srpms.

What's the complaint?

Posted Mar 3, 2011 16:43 UTC (Thu) by smurf (subscriber, #17840) [Link] (7 responses)

Yeah, but they're not in source form.

"Source", in this context, is "a kernel and a heap of patches, as embodied in a git archive". Granted that if you drop the archive and flatten the patches into 200+ patch files, that still counts, because people still customarily edit patches.

A humungous diff, however, is not a patch. It's the source equivalent of a core dump. Nobody uses that for software development.

Therefore, Red Hat is breaking the spirit of the GPL by doing that.

What's the complaint?

Posted Mar 3, 2011 22:29 UTC (Thu) by airlied (subscriber, #9104) [Link] (6 responses)

You have a definition of source that suits your argument.

I'm sure lawyers can define Source == source code, in that context you have the source code to the kernel.

Its easy to make up definitions and then base arguments on them, its harder to prove the definition you made up is backed by the law.

What's the complaint?

Posted Mar 4, 2011 7:56 UTC (Fri) by smurf (subscriber, #17840) [Link] (5 responses)

The GPL says quite plainly:

The source code for a work means the preferred form of the work for
making modifications to it.

Whether combining lots of patches into one large patch constitutes a change in "form" would be an argument for the lawyers if this ever goes to court, which I very much doubt.

In my opinion, however, the case is pretty clear -- you simply do not modify that large a patch file. Therefore it's not a "preferred form". Therefore Red Hat is, ideally if not materially, in breach of the GPL.

Disclaimer: I am not a lawyer, not do I play one on TV.

What's the complaint?

Posted Mar 4, 2011 17:28 UTC (Fri) by dlang (guest, #313) [Link] (4 responses)

you don't normally modify patches at all, normally you modify the source file. the tools then mechanically create the patch files.

What's the complaint?

Posted Mar 7, 2011 22:26 UTC (Mon) by paulj (subscriber, #341) [Link] (3 responses)

Forget the details of patches for a second. What matters is, what is the distributor's preferred form for making modifications? If there is a difference between the form they prefer internally and the form they distribute onward, then we have to ask whether the recipients have been short-changed out of their rights. Precisely how much information is a distributor allowed to obfuscate before there is a problem?

E.g. if the patches are of no import to making modifications to a source code, then why have RedHat decided to try get a competitive advantage by withholding them? Clearly RedHat feel having the split-out patches helps them to maintain and modify the kernel they ship. My experience is that having patches (more precisely, access to the history) can be *very* important to making further modifications (finding recently introduced bugs particularly, and modifying them).

I know RedHat is "Good", I know they put in lots of resources into Linux and free software. I really want them to be able to succeed in their business. However, let's be careful to remain dispassionate about this - do any GPL copyright holders involved really want to concede that it's perfectly fine for distributors to deliberately withhold fairly important source-related information? (Obviously some of those copyright holders also have a strong interest in the continuing success of RedHat).

What's the complaint?

Posted Mar 7, 2011 22:41 UTC (Mon) by foom (subscriber, #14868) [Link]

How about requiring that they disclose all the internal email threads where they discussed the change too? After all, those might have substantially more useful information about the reasoning behind the change than just the commit message...

What's the complaint?

Posted Mar 7, 2011 23:25 UTC (Mon) by dlang (guest, #313) [Link] (1 responses)

I am not a big RedHat fan, but I have no legalistic problem with them not distributing patches, internal e-mail threads, recordings of internal conversations etc.

that doesn't mean that I think what they are doing is good in this area, just that it is within the letter of the rules. I think that them making this change erodes their moral position, but the GPL isn't dependant on people making good decisions for moral reasons, it's only dependant on people making the decisions to comply with the letter of the license (or if it requires more than just compliance with the letter of the license, there may be a need for a license change, but I don't believe that there is)

the only piece I have a legalistic problem is with them releasing code in some form to users, but only under the condition that those users don't redistribute the code (and if the users violate this condition, penalties kick in)

What's the complaint?

Posted Mar 8, 2011 7:38 UTC (Tue) by paulj (subscriber, #341) [Link]

It's still not clear they're following the letter of the licence. Here's what likely is happening:

1. RedHat work on the source in form A

2. Form B is auto-generated from A

3. Form B is distributed to comply with the GPL.

A is the src.rpm with the split patches: the format they've preferred for donkey's years and, I'm presuming to be a dead certainty, are continuing to use internally, and B is the src.rpm with the patches deliberately collapsed. Talking about email or conversations is a misdirection - binaries never get machine-built from such. The patches *are* a source input to the process that builds the distributed src.rpms though, and the reason they are an input is because that's RedHats' preferred means of making modifications.

Look at the flow above again, form B *clearly* is covered by the GPL through the text in which explains what "preferred form" is meant to cover. It's pretty explicit that intermediate transformations of the sources are *not* sufficient, that *all* the files required for input to the build process are required.

Just because an auto-generated file is still human-readable and editable does not take-away from the fact it's not the original source.

What's the complaint?

Posted Mar 2, 2011 12:46 UTC (Wed) by dskoll (subscriber, #1630) [Link] (1 responses)

Yes and what does the GPL say about Red Hat's license agreement? Nothing.

Maybe. Maybe not. The GPL says you are not allowed to add "additional restrictions" on the redistribution of GPL'd works.

Red Hat and others argue that their subscription agreement is not an additional restriction. I argue that it is. I'd like a legal judgement or at least an opinion from the FSF, because it's not clear-cut to me.

What's the complaint?

Posted Mar 4, 2011 1:06 UTC (Fri) by jthill (subscriber, #56558) [Link]

By signing that agreement, you did not bind them, and by signing that agreement, they did not bind you.

The defining characteristic of a coercive offer is that if you refuse it, you're worse off than you were before they made it.

That's not the case here. It's a perfectly good offer. They did not bind you by authority, they did not bind you by coercion, they did not bind you by any means.

You bound yourself, for gain, in a completely voluntary and fully informed choice.

What's the complaint?

Posted Mar 1, 2011 21:57 UTC (Tue) by dowdle (subscriber, #659) [Link]

Let's back up for a moment. Red Hat has historically released things in such a way that made it very easy for others to co-opt. As a result, we have various clones. Red Hat does not seem to mind the free clones... but it looks like they have one particular pay clone they aren't fond of.

Red Hat did NOT have to release the sources the way they originally did... that breaks it into the original source and patches. They could have originally "obfuscated" the source but they did not.

What they are doing now is "obfuscated" one package... the kernel. They are still releasing the source so they aren't hiding anything... and that source is publicly available to all. They are in compliance with the GPL.

What Red Hat has done is just change one package, the kernel source release format. They have not broken the GPL and the added restrictions they have put on their original release format for that package, as far as I can tell, are not a violation of the GPL. They do not have to make the source available in multiple formats, or any one format in particular... as long as the offer the source... which they are.

I'm guessing this won't really help them much technically... and it will anger the community more than it will restrict access to the targeted competition... and they will eventually switch back to the way they were originally doing things... but they have to try it to see how it works out. Now to see how it works out.

GPL does not ask you to give up rights.

Posted Mar 1, 2011 20:43 UTC (Tue) by dskoll (subscriber, #1630) [Link] (23 responses)

The GPL license terms also ask you to give up rights.

That's completely wrong. The GPL grants you rights. If you don't accept the GPL, you have no right to redistribute software it covers. If you do accept the GPL, then you have some rights.

What rights does the GPL ask you to "give up"?

GPL does not ask you to give up rights.

Posted Mar 1, 2011 22:06 UTC (Tue) by jthill (subscriber, #56558) [Link] (22 responses)

You have the right to charge a fee for a license to distribute your copyrighted works, for instance. The GPL asks you to give up that right in exchange for distribution rights on any combined work. So long as value received exceeds value surrendered, that's a win — and it's plainly a huge win, nothing exceptionable about it.

To get excruciatingly correct, the license doesn't actually ask people to surrender those rights, it only offers something on condition that they not exercise them. What the GPL does to people who violate its terms is exactly what Red Hat does to people who violate theirs: it terminates their license.

GPL does not ask you to give up rights.

Posted Mar 1, 2011 22:14 UTC (Tue) by dskoll (subscriber, #1630) [Link] (21 responses)

The GPL asks you to give up that right in exchange for distribution rights on any combined work.

Wrong. You give up that right in exchange for distribution rights on any derived work. There's a huge difference between "derived" and "combined".

To get excruciatingly correct, the license doesn't actually ask people to surrender those rights, it only offers something on condition that they not exercise them.

Wrong again. If a copyrighted work gets dropped into your lap, you have no rights whatsoever to redistribute it. So the GPL cannot offer something on condition you "not exercise certain rights" because you don't have any rights not to exercise in the first place! Again: the GPL grants you rights if you obey certain conditions. It does not remove rights.

Red Hat is removing rights. Their kernel patches are works derived from a GPL'd product and therefore anyone receiving the kernel patch has the rights granted under the GPL. Even Red Hat does not dispute that. However, Red Hat is punishing those customers who exercise rights they have already been granted by terminating their support contracts. While that may or may not be legal, it is certainly unethical.

GPL does not ask you to give up rights.

Posted Mar 1, 2011 23:45 UTC (Tue) by jthill (subscriber, #56558) [Link] (20 responses)

You give up that right [...]

So we agree, then, on the substance: the GPL asks you to give up rights, just as Red Hat does. All that's left is discussing how best to describe the details and whether they're fair offers.

Red Hat asks you not, under particular circumstances, to give away their work. The GPL asks you not, under particular circumstances, to charge for distribution rights on your own. Both offer something valuable in return for your not doing what you have a license or even the right to do.

I think if you check you'll see the GPL v2 does not use "combine" at all, the GPL v3 does not use "derive". Either way, I rejected "derived" because I wanted to highlight the continued existence of your own separate interest in the result.

GPL does not ask you to give up rights.

Posted Mar 2, 2011 4:14 UTC (Wed) by JesseW (subscriber, #41816) [Link] (7 responses)

It is important to clarify something here: If you create, let alone distribute, a derivative work without a license from the copyright holder of the work (or works) it is derived from, that is illegal.

You have no right to sell (or even give away) a license for the derived work unless you already possess a license to do the deriving. What the GPL says is that you can have a license to create a derivative work merely by following certain conditions, which do not include payment or notification to anyone, but do include licensing the derivative work under the GPL.

If the derivative work you want to create has components that are not derivative (i.e. that were written only by you), the GPL has nothing to say about them, and puts no restrictions on what you do with them. You are free to sell licenses for them, or do anything else that is legal.

While you do, in some sense, have a "right to charge a fee for a license to distribute your copyrighted works", you have no right to do so without the consent of all the copyright holders for a work. Derivative works have multiple copyright holders, all of whom need to consent before a license can be granted. All the GPL does is clarify the terms in which the other copyright holders will grant their necessary permissions. It takes nothing away from you.

GPL does not ask you to give up rights.

Posted Mar 2, 2011 8:30 UTC (Wed) by jthill (subscriber, #56558) [Link] (6 responses)

If you create, let alone distribute, a derivative work without a license from the copyright holder of the work (or works) it is derived from, that is illegal

Taken at face value, you've just asserted it's illegal to sing in the shower, and to keep scrapbooks. Perhaps if you clarify your clarification it'll also become clear how it's relevant at all in a discussion of the exercise of distribution licenses.

I don't see the value here in insisting that copyright on derived work is on the work as a whole: to the extent that you have copyright on the result, it's due to your contribution. I say po-tay-to, and we're discussing tays.

And when the reason you may not charge for a distribution license on the resulting work is only that the GPL says you may not, claiming that the GPL takes nothing away is at best pure equivocation.

GPL does not ask you to give up rights.

Posted Mar 2, 2011 15:56 UTC (Wed) by JesseW (subscriber, #41816) [Link] (5 responses)

Come on -- you know as well as I what the clarification that makes the examples you listed legal is: Fair use (or fair dealing in other jurisdictions). Leaving aside that little bit of snark, the point is that a derivative work has multiple copyright holders. You don't dispute that.

I'm not sure what "to the extent that you have copyright on the result, it's due to your contribution" even means. What "result" -- the derivative work? What "contribution", exactly? The specific lines of code that were not present before? What about lines that were modified (say by changing a "==" to "!=")? Whose "contribution" are they?

The reason you can't charge for a distribution license on the derivative (not "resulting" -- it's a work derived from the existing work, which you were allowed to derive from (and copy, and distribute, etc.) by following the terms of the GPL) work is that you are not the sole copyright holder for it. If you get the agreement of all the copyright holders, you all can certainly refuse to grant additional licenses without payment.

GPL does not ask you to give up rights.

Posted Mar 2, 2011 23:52 UTC (Wed) by jthill (subscriber, #56558) [Link] (4 responses)

you know as well as I what the clarification that makes the examples you listed legal

If you check back you'll see I didn't ask for a clarification that would explain why those examples are legal. I asked for a clarification that explains how an assertion about requirements on private derivation is relevant in a discussion about exercising licensed public distribution. The rebuke for the gratuitous overreach on private use stands.

I'm not sure what "to the extent that you have copyright on the result, it's due to your contribution" even means.

Well, I kind of took it as read that copyright in GPL'd works is almost entirely due to application of authors' patches, and that reverting an author's changes means that author has no copyright on the resulting work. Patches are contributions in any sense of the word, contributions in other forms are generally also revertible, "contributor" is the word v3 uses, and the exact extent of the changes necessary to excise an author's copyright interest is irrelevant here. That all seemed so obvious it needed no more than acknowledgment.

If you get the agreement of all the copyright holders, you all can certainly refuse to grant additional licenses without payment.

I think you might have missed that that makes my point: with unrestricted copyright authority, one can demand money for a distribution license. Authors employing the GPL ask that you (as they do) not exercise that and other rights in exchange for the GPL's benefits. You have to give up either the rights or the license to get the other.

To finish bringing it back on topic, Red Hat offers timely, warranted service in exchange for your not exercising the GPL the instant you receive it. You have to give up either the right or the service to get the other.

Don't forget that you (as Red Hat does) still get the software courtesy of the GPL, nor that Red Hat also makes sure no one loses what I think most people regard as its main benefit: they also distribute their work freely. They do so after a delay that takes it out of the realm of service, i.e. current work for which it's ethical to charge the people who want it right now, and into the realm of adequately compensated work that can be distributed at no cost. That they do so completes the GPL's positive-feedback loop.

Publishing a repo is on its way to being the standard way to distribute GPL'd and other free software, but it seems in Red Hat's experience it's only possible to distribute their complete set in a way a little more like software was ordinarily distributed when the GPL was written -- mostly tarballs as I recall, but I wasn't tracking then -- if they want to execute their business model. OK. That feedback loop is what I care about.

GPL does not ask you to give up rights.

Posted Mar 3, 2011 3:23 UTC (Thu) by JesseW (subscriber, #41816) [Link] (3 responses)

OK, I think we are coming to more of an understanding here. You are pointing out differences between two situations:

Distributing software while relying on (one or more) GPL grants by other copyright holders (whether or not you also have some copyright interest in the software), and
Distributing software for which you are the sole copyright holder.

You are claiming (correctly) that you can demand payment for permission to further distribute the software only in the 2nd case, not in the 1st. I agree.

You are claiming that demanding payment for further distribution is a "right" in both cases, which the GPL demands you "give up" in the 1st case. I disagree. I claim that, in the 1st case, you have no right (except for fair use) to distribute the software or permit further distribution (with or without payment). The GPL provides you the ability to distribute the software, but does not provide you the ability to prevent further distribution. You are giving up no right.

As for the Red Hat situation, I don't have a strong opinion one way or another. I tend to agree with the your analysis, since, as you pointed out, a RH subscriber loses nothing if they distribute the materials after their subscription expires.

GPL does not ask you to give up rights.

Posted Mar 3, 2011 6:03 UTC (Thu) by jthill (subscriber, #56558) [Link] (2 responses)

You're presenting a false dichotomy between the GPL and no license at all, and confusing a license to distribute with the right to dictate terms.

The only reason you are constrained at all is that the other copyright holders have the right to dictate license terms. If you create a derived work, you are one of those copyright holders, and you also have the right to dictate terms. If you can't all arrive at a compatible set of terms for a license to distribute, then none of you can distribute — but only because you and they have the right to dictate terms.

Two of the infinite myriad of possible sets of terms you and the other copyright holders may offer are

BSD: you retain, you may exercise, your right to offer any terms at all for a license to your own work, your own copyright interest, in any derived work. You may stipulate any restrictions and charge any fee.

GPL: you give up, you may not exercise, that right: if you distribute at all you must offer specific permissions at no charge.

GPL does not ask you to give up rights.

Posted Mar 4, 2011 23:58 UTC (Fri) by cas (guest, #52554) [Link] (1 responses)

the point you are missing is that in both cases (BSD licensed code and GPL licensed) code, the ability to distribute derived works is *NOT* a right, it is a permission granted by the license of the original work.

without permission being granted, you have no right to distribute works derived from other people's copyrighted works.

i suspect that what is confusing you on this issue is that BSD and GPL have different conditions on that grant of permission, but (in the context of this argument) that is irrelevant.

BSD code is not public domain, any more than GPL code is.

GPL does not ask you to give up rights.

Posted Mar 5, 2011 2:27 UTC (Sat) by jthill (subscriber, #56558) [Link]

Hi, no, please find (at least) all uses of the phrase "the right to" in the history of this conversation. I certainly didn't make that mistake.

GPL does not ask you to give up rights.

Posted Mar 2, 2011 12:41 UTC (Wed) by dskoll (subscriber, #1630) [Link] (11 responses)

So we agree, then, on the substance: the GPL asks you to give up rights

No, we do not. My original phrasing was wrong. Let me spell it out: The GPL only grants you rights. It does not ask you to give up any rights because in the absence of the GPL, you have no rights anyway.

Huh?

Posted Mar 2, 2011 14:42 UTC (Wed) by khim (subscriber, #9252) [Link] (8 responses)

The GPL only grants you rights. It does not ask you to give up any rights because in the absence of the GPL, you have no rights anyway.

Sorry, but this is not true. Just a recent example. GPL asks you to surrender your rights in exchange for a bunch of code. Again: If you want to use said code you must give up the rights copyright gives you. RedHat does the same in reverse: in order to enjoy the support you must give up the rights GPL gives you. In both cases it's up to you to decide if you want to agree to the terms or not.

Huh?

Posted Mar 2, 2011 15:10 UTC (Wed) by dskoll (subscriber, #1630) [Link] (7 responses)

The example you gave with libreadline does not in any way show how the GPL forces you to give up rights. In the absence of the GPL, you would have no right whatsoever to link libreadline against your app, nor could you distribute it. The GPL grants you rights under certain conditions.

RedHat does the same in reverse: in order to enjoy the support you must give up the rights GPL gives you. In both cases it's up to you to decide if you want to agree to the terms or not.

And I think that may be illegal. Red Hat is adding additional restrictions to the GPL. Red Hat's patches that it distributes to paying customers are clearly GPLd and can be distributed under the terms of the GPL. But you can't get the patches unless you agree to the subscription agreement. Therefore, Red Hat is adding restrictions to the GPL.

Heh...

Posted Mar 2, 2011 15:41 UTC (Wed) by khim (subscriber, #9252) [Link] (6 responses)

In the absence of the GPL, you would have no right whatsoever to link libreadline against your app, nor could you distribute it.

Right. But you have the right to demand per-copy royalties, etc. All these privileges given to you by copyright law, you know. For your program, not for readline.

The GPL grants you rights under certain conditions.

Yes. But these conditions are quite interesting: surrender the privileges you usually have - then enjoy the benefits. That's the point of copyleft.

Red Hat's patches that it distributes to paying customers are clearly GPLd and can be distributed under the terms of the GPL.

Sure.

But you can't get the patches unless you agree to the subscription agreement.

Exactly: service agreement gives you rights under certain conditions. Without service agreement you can not even look on patches, let alone distribute them.

Therefore, Red Hat is adding restrictions to the GPL.

How come? You can distribute patches using the GPL - noone disputes this right. Just like nobody disputes your privilege for per-copy royalties. But if you want to enjoy benefits of service agreement (access to the patchlist, for example) you must agree not to exercise your privileges. Actually it's even more generous then GPL: GPL forces you to give up your privileges forever, while service agreement will only bind you temporarily.

Heh...

Posted Mar 2, 2011 16:41 UTC (Wed) by dskoll (subscriber, #1630) [Link] (5 responses)

The difference between the GPL's granting of rights and Red Hat's subscription service is this: The GPL is a license, not a contract. Red Hat's subscription agreement is a contract. You pay Red Hat for support, and in return they give you support. But they also include a landmine in the contract: You are forced to give up rights you'd normally have even in the absence of the support contract. (For example, if Red Hat's segregated kernel patches magically landed in my mailbox, it would be perfectly legal for me to redistribute them under the GPL even though I'm not a Red Hat customer.)

Red Hat's contract adds additional restrictions to the GPL which IMO is a GPL violation. Try this thought experiment:

If Red Hat's contract said: "If you take advantage of the rights under the GPL to redistribute our patches, you agree to pay Red Hat software one billion dollars", then that would clearly be a severe restriction on redistribution.

All that's in dispute is the degree of restriction (which is basically the money you've spent on the support contract.) The existence of an additional restriction cannot be disputed and this violates the GPL.

What rights?

Posted Mar 2, 2011 19:54 UTC (Wed) by khim (subscriber, #9252) [Link] (4 responses)

You are forced to give up rights you'd normally have even in the absence of the support contract.

In the absence of the support contract you have no access to patches in question so you can not distribute them.

For example, if Red Hat's segregated kernel patches magically landed in my mailbox, it would be perfectly legal for me to redistribute them under the GPL even though I'm not a Red Hat customer.

If you can prove that patches arrived in your mailbox from source other then RedHat's site (for example from kernel.org site) you are still free to distribute them.

If Red Hat's contract said: "If you take advantage of the rights under the GPL to redistribute our patches, you agree to pay Red Hat software one billion dollars", then that would clearly be a severe restriction on redistribution.

Sure. This will be like patent license: no matter how you've gotten the patches you are forbidden to excercise your rights. RedHat's agreement only restricts distribution of meta-information. You are free to strip meta-information and distribute raw source/patches. In fact if the meta-information comes from third-party source and not from RedHat you are free to distribute that too - but you must prove that it indeed come from different source.

The existence of an additional restriction cannot be disputed and this violates the GPL.

Sorry, but no. It's said quite explicitly: this Appendix is not intended to interfere with your rights under those individual licenses. If you can prove that you had the right to distribute something under terms of GPL then you are in the free. Just remember that while software included in patches is GPL-licensed different commit messages, ACKs and NAKs are not. And they may even be peceived as trade secrets.

You will need pretty good lawer to properly cleanup the patches from RedHat's web site, but you can distribute the source code itself - RedHat does not interfere with that.

What rights?

Posted Mar 2, 2011 20:18 UTC (Wed) by dskoll (subscriber, #1630) [Link] (3 responses)

In the absence of the support contract you have no access to patches in question so you can not distribute them.

No, that's untrue. Someone with a support contract could (legally) mail me the patches, and I could redistribute them in the absence of a support contract with Red Hat. The person who sent me the patches might be in hot water with Red Hat, but I wouldn't be.

If you can prove that patches arrived in your mailbox from source other then RedHat's site (for example from kernel.org site) you are still free to distribute them.

Nope. Even if I obtained the patches from Red Hat, I can still distribute them because they are GPL'd (being derived products created from a GPL'd work.)

RedHat's agreement only restricts distribution of meta-information.

Are you claiming that Red Hat's patches are not derived from a GPL'd work? I don't think even Red Hat claims that.

Sorry, but no. It's said quite explicitly: this Appendix is not intended to interfere with your rights under those individual licenses.

But it absolutely does interfere with those rights. How can you claim it does not?

You will need pretty good lawer to properly cleanup the patches from RedHat's web site

Why do you think that? Are you claiming that the patches Red Hat distributes to its customers are not derived from a GPL'd work?

Just remember that while software included in patches is GPL-licensed different commit messages, ACKs and NAKs are not. And they may even be peceived as trade secrets.

I am not talking about commit messages. I am referring to the individual kernel patches that Red Hat does make available (only) to its customers (supposedly) under the GPL.

Once again...

Posted Mar 3, 2011 10:39 UTC (Thu) by khim (subscriber, #9252) [Link] (2 responses)

But it absolutely does interfere with those rights. How can you claim it does not?

I'm not claiming that. RedHat does.

I don't think you've read the whole thing. Basically RedHat says the following:
1. You have no right to distribute anything you are downloading from our servers.
2. But if you know that some open-source license gives you such right and can prove that then you are in the clear.
3. Our lawyers are always ready to discuss your proof in the court of law.

See? It does not interfere with your GPL rights - but it shifts the separation issue on your side. You must prove that you have the right to distribute anything - and if you'll do a single error... well, your support contract is no longer valid and that's that.

Why do you think that? Are you claiming that the patches Red Hat distributes to its customers are not derived from a GPL'd work?

They contain mix of the GPLed code and non-GPLed code. For example a lot of files in Documentation subdirectory are not derived works of kernel (even if they are distributed in the same tarball - see "mere aggregation" clause). This means that the fact that patch applies to Linux kernel is not enough to clear you: you must review each and every patch and decide what parts of it are GPL-derived and what parts are not GPL-derived. This is quite non-trivial amount of work.

Once again...

Posted Mar 3, 2011 12:02 UTC (Thu) by dskoll (subscriber, #1630) [Link] (1 responses)

I'm not claiming that. RedHat does.

Red Hat is full of crap if it claims that.

If you think Red Hat is using the threat of lawyers to stop people from distributing the patches ("Our lawyers are always ready to discuss your proof in the court of law."), then that's even worse. That throws a huge chill over collaborative kernel development. Even I don't think Red Hat is that bad; I believe they won't actually sue anyone for distributing the patches.

This means that the fact that patch applies to Linux kernel is not enough to clear you: you must review each and every patch and decide what parts of it are GPL-derived and what parts are not GPL-derived.

If you believe that's what Red Hat is doing, then it's even worse that what I'm claiming it's doing. If what you say is true, then Red Hat is deliberately blocking collaborative kernel development and adding legal threats to its arsenal against anyone using its patches. Do you think that's in the spirit of the GPL?

RedHat had not invented anything

Posted Mar 4, 2011 17:52 UTC (Fri) by khim (subscriber, #9252) [Link]

If you think Red Hat is using the threat of lawyers to stop people from distributing the patches ("Our lawyers are always ready to discuss your proof in the court of law."), then that's even worse. That throws a huge chill over collaborative kernel development. Even I don't think Red Hat is that bad; I believe they won't actually sue anyone for distributing the patches.

If they'll sue or not remains to be seen. But they reserve the right to do so - like Microsoft reserves the right to do so (WRT Mono).

If you believe that's what Red Hat is doing, then it's even worse that what I'm claiming it's doing. If what you say is true, then Red Hat is deliberately blocking collaborative kernel development and adding legal threats to its arsenal against anyone using its patches. Do you think that's in the spirit of the GPL?

Well, it's good question. Probably not. But... FSF itself developed GNU programs (like emacs or gcc) behind the closed doors for years. When the programs were released they were released as tarballs only - access to the VCS was restricted even fater that. Of course they have not threatened you with lawers and when EGCS project decided to fork GCC they they allowed them to take patches from private tree, but it happened when developers convinced RMS to conduct this experiment, not when they decided that they have unalienable right to publish them...

GPL does not ask you to give up rights.

Posted Mar 2, 2011 16:15 UTC (Wed) by jthill (subscriber, #56558) [Link]

I think if you consider the right to relicense you'll find a misstep in your reasoning.

GPL does not ask you to give up rights.

Posted Mar 3, 2011 9:26 UTC (Thu) by jthill (subscriber, #56558) [Link]

http://lwn.net/Articles/430809/

It's not so simple

Posted Mar 1, 2011 21:48 UTC (Tue) by AndreE (guest, #60148) [Link] (12 responses)

Yes because the GPL is a copyrjght licence and should focus on your rights over the work. The GPL is not a labor contract. It shouldn't mandate how you support a product any more than it should mandate how you market it

It's not so simple

Posted Mar 1, 2011 22:18 UTC (Tue) by dskoll (subscriber, #1630) [Link] (11 responses)

That is not the issue. The issue is that Red Hat's kernel patches are works derived from a GPL-licensed work. They must, therefore, be GPL-licensed. This means that Red Hat customers can redistribute the patches under the GPL. Red Hat does not dispute this.

Instead, Red Hat works around the GPL by saying "If you exercise your rights, then we will punish you." This means Red Hat customers effectively cannot exercise their rights (or if they do, they need to do it anonymously to avoid retribution). That's unethical, even if it's legal, and I hope that Red Hat is suitably punished in the marketplace.

It's not so simple

Posted Mar 2, 2011 5:57 UTC (Wed) by AndreE (guest, #60148) [Link] (9 responses)

You may say it's a punishment, I might suggest it's protecting their business. And I still don't see where in the GPL this is prevented, although I will admit reading yours and some other points have made me think of things differently.

We can both come up with extreme cases supporting the legitimacy or illegitimacy of this decision. I might suggest that Red Hat has no obligation to provide support to entities that just repackage their efforts under different logos, although they DO have obligations to respect the GPL when distributing code to all subscribers.

It's not so simple

Posted Mar 2, 2011 6:11 UTC (Wed) by dlang (guest, #313) [Link] (7 responses)

I agree they have no obligation to _support_ people to repackage their code and redistribute it, but they do have an obligation to _allow_ people to repackage their code and redistribute it.

this obligation is based on the fact that most of 'their code' is not actually theirs, it's code from other people who let them use it on the condition that they let others use it (and derived works) as well.

RedHat has traditionally made it easy for people to make rebranded distros by keeping all their branding fairly nicely isolated.

they would be perfectly within their rights to stop doing so, no longer provide broken out patches for anything, and start including trademarked logos embedded in the source files to make it harder for people to strip the trademarked branding out.

and there may even be technical arguments for doing exactly this in the final build code version (and no, I don't buy the argument that a series of patches is the "preferred means of modification" patches aren't edited by humans, they are a way of transmitting changes from one entity to another).

If that is what they were doing, I would be silent, or supporting their right to do so (while not necessarily agreeing that it's a good idea to do so)

It's not so simple

Posted Mar 2, 2011 6:41 UTC (Wed) by paulj (subscriber, #341) [Link] (6 responses)

If RedHat internally keep patches separate and build from stock + patches then that's their preferred source. If the source they distribute has the patches applied in part to frustrate cloners, and if there is sufficient value in having the broken out patches that customer demand still forces them to make these available to customers, then that would clearly seem to make that form of redistribution be of source in a 'less preferred' form. Contrary to the GPL.

Think very carefully about defending RedHat here. While RedHat generally get Free Software and are reasonably trust-worthy[1], and we might feel like cutting them slack, there are plenty of other Linux distributors who don't. Particularly in the embedded world, if you can even get (all) the source, it's usually a giant tarball. To the extent such distributors keep patches separated out internally, users who buy such devices *should* be able to get at those patches. It's not a massive issue yet, because usually the changes they make are small enough that diffing is still tractable - but that need not always remain the case.

1. Even if they've apparently acquired some amount of middle-management that doesn't and may not be, according to daniel (which, if correct, makes for a long-term worry the community should have for RedHat: some of those middle-managers may progress to top-level management one day).

It's not so simple

Posted Mar 2, 2011 7:33 UTC (Wed) by dlang (guest, #313) [Link] (5 responses)

the preferred form of editing is not patch files, it's source files that some tool creates patches from

yes, I know that there are people who edit and write patch files directly. I also know a person who taught himself C from the K&R book by compiling the examples and then reading the machine code that resulted (a long time mainframe systems guy), such people are very much the exception and are not what we base expectations on :-)

I wouldn't expect to require patches, or git trees any more than I would require a someone who used a proprietary compiler to compile GPL source code into a binary provide me with a copy of the compiler because that is what I would need to recreate the binary I got from that person.

so I have no problem with someone just providing one tarball of the result instead of broken out patches (I may have concerns about why someone is doing this, especially if they used to do something more useful, but that's not concerns over what is being done, but rather why they are doing it)

while I think it would be nice to get a git tree of the patches, deciding that such a thing is a requirement gets very ugly very quickly (what if they use a proprietary version control system instead of git? for example?)

It's not so simple

Posted Mar 2, 2011 7:59 UTC (Wed) by paulj (subscriber, #341) [Link] (4 responses)

The GPL doesn't say "preferred form for editing the code" it says "the preferred form of the work for making modifications to it". RedHat internally prefer to make modifications using change-sets on top of a canonical source-code. IME this holds nearly universally in the free software world, and much of the proprietary world. That /edits/ are made after applying the patches is a subset of the work-flow of modifying source code. However, many people /do/ edit diffs directly - Linus in the past (pre version control days) said he did, and patch-utils has a 'rediff' tool to remove the tedium of counting and adjusting the line numbers. Whenever companies distribute their Linux kernel sources as a source tarball, one of the first things recipients do is to diff it against the stock kernel.

I actually agree with you in your caution about drawing firm lines. However, I'd argue such caution should go /both/ ways. Not only should be cautious about concluding that publishing changesets is a GPL requirement, but we should also be cautious about concluding that only publishing the aggregated-together sources and NOT the changesets is sufficient to comply with the GPL. I'm not sure myself where the line is, or what principle can be drawn other than "decide on a case-by-case basis", but I do think that in cases where there clearly is such a large amount of information contained in the deltas that /not/ publishing them effectively frustrates anyone trying to replicate the work, and that the publisher retains a significant advantage by having its own internal work-flow still be based on those deltas, that then there is a strong case to be made that the published source no longer is in preferred form...

It's not so simple

Posted Mar 2, 2011 9:06 UTC (Wed) by airlied (subscriber, #9104) [Link] (3 responses)

so if I download a tarball from kernel.org of Linus kernel, kernel.org is violating the GPL?

just because there is a git tree somewhere I can access if I want it doesn't change the fact that I was given a tarball which wasn't in what you are calling the preferred form.

It's not so simple

Posted Mar 2, 2011 10:24 UTC (Wed) by maks (guest, #32426) [Link] (2 responses)

> so if I download a tarball from kernel.org of Linus kernel, kernel.org is
> violating the GPL?

The point beeing that linus doesn't really hide his git tree on kernel.org, whereas RH does. I'm pretty sure that you know that they didn't before, as up to RH 6.0 beta all patches are visible.

Wow. Talk about fogetting history.

Posted Mar 2, 2011 15:17 UTC (Wed) by khim (subscriber, #9252) [Link] (1 responses)

The point beeing that linus doesn't really hide his git tree on kernel.org, whereas RH does.

Well, Linus did that for a few years. It was not possible to get meta-information from bikeeper.com without agreeing to pretty onerous terms. Note that some developers refused to accept such terms - but none tried to imply that what Linus and other were doing is breach of the GPL!

Sorry, but this ship sailed long ago.

Wow. Talk about fogetting history.

Posted Mar 2, 2011 16:59 UTC (Wed) by paulj (subscriber, #341) [Link]

There may well be a difference between making available what you can versus, versus deliberately withholding things you have easily to hand (or not). The judicial system certainly can take intent into consideration, and does so as a matter of course.

It's not so simple

Posted Mar 2, 2011 10:41 UTC (Wed) by pboddie (guest, #50784) [Link]

You may say it's a punishment, I might suggest it's protecting their business. And I still don't see where in the GPL this is prevented, although I will admit reading yours and some other points have made me think of things differently.

I don't care about Red Hat's business, but I do care about GPL compliance, so let's look at that aspect. To those who receive binaries (as part of their subscription), Red Hat also make the corresponding sources available, albeit in a form that others (who additionally have access to that software) may not prefer. In addition, Red Hat also appear to make the patches available on the condition that these are not redistributed, with the penalty for breaking this condition being that the offending subscriber's subscription is terminated and that they will receive no more patches.

Now, in the context of upholding the terms of the GPL, Red Hat appear to provide the corresponding sources to the binaries being distributed, so they aren't violating the GPL in this respect. Meanwhile, the patches distributed separately, whilst potentially being considered derived works of GPL-licensed work by other authors, still presumably come with all the privileges conferred by the GPL: you may still redistribute them, but Red Hat may then decide not to share any further patches with you.

Clearly, the GPL doesn't make anyone promise that they will continue to share new updates and revisions to a piece of software that has already been shared, so Red Hat can probably get away with making such continued sharing conditional on the "good behaviour" of subscribers. You can even turn this on its head and say that Red Hat only promises to share one revision's worth of patches but may continue to do so on the basis of such "good behaviour".

Having said all this, the divisive and isolating effect such policies might have, disempowering recipients of software and making them mere consumers, arguably work against the spirit of Free Software.

It's not so simple

Posted Mar 2, 2011 15:36 UTC (Wed) by nevyn (guest, #33129) [Link]

> "If you exercise your rights, then we will punish you." This means Red Hat > customers effectively cannot exercise their rights

You have the _right_ to buy a single support contract, and then sell support contracts yourself for CentOS/SL/OEL and log all your problems against RH. Red Hat have the right to refuse your business.

You may feel RH is being "mean" for not letting you screw them over, and you are free to have that opinion (but that doesn't mean others will agree with you).

It's not so simple

Posted Feb 28, 2011 21:00 UTC (Mon) by jmorris42 (guest, #2203) [Link] (20 responses)

> RedHat can not restrict you, that's true, but they can refuse to support..

No, don't think they even do that. But that doesn't matter. What they did was blow enough FUD into the question that no corporate type will want to allow an employee to repost the patches.

I do feel for RH on the patchsets being unwieldy but think they crossed the line to naughty on this one. Hopefully saner heads will prevail.

It's not so simple

Posted Mar 1, 2011 0:29 UTC (Tue) by ESRI (guest, #52806) [Link] (19 responses)

Red Hat needs to provide the source code, but certainly the GPL doesn't compel them to provide technical support and/or binaries to anyone and everyone who grabs their SRPM's ...

It's not so simple

Posted Mar 1, 2011 1:03 UTC (Tue) by dskoll (subscriber, #1630) [Link] (12 responses)

But what Red Hat is doing as far as I can see is saying: "Yes, you can exercise the rights granted you under the GPL, but if you do, we will consider it to be a breach of your support agreement and will no longer provide you with support or updates."

I'm pretty sure that violates the GPL because it is an "additional restriction".

It's not so simple

Posted Mar 1, 2011 2:03 UTC (Tue) by corbet (editor, #1) [Link] (10 responses)

Actually, this kind of question has come up before; remember Sveasoft? The FSF apparently said at the time that threatening to withhold further support if the source was disclosed was not a GPL violation. The FSF is not the final word on such things, obviously, but they do carry a certain amount of weight in this area.

It's not so simple

Posted Mar 1, 2011 2:12 UTC (Tue) by dskoll (subscriber, #1630) [Link] (9 responses)

Ugh, that's really disgusting. The only thing to hope for is that some RH subscriber passes along the patches anonymously and someone in the community publishes them without disclosing who passed them on.

As dirty as that sounds, it's really no worse than what Red Hat is doing.

It's not so simple

Posted Mar 1, 2011 7:33 UTC (Tue) by gnufreex (guest, #70396) [Link]

For example, someone can send sources to WikiLeaks :-)

It's not so simple

Posted Mar 1, 2011 14:39 UTC (Tue) by AndreE (guest, #60148) [Link] (7 responses)

I don't know why it's so disgusting.

Firstly the GPL being a copyright license should be rightly focused on code. It should stay the hell away from mandating how companies support there products, as long as the four freedoms are maintained

Secondly, the GPL allows commercial exploitation. The ONLY way this is even possible is with decent support agreements.

Finally None of the four freedoms are being violated. I see nothing disgusting at all

It's not so simple

Posted Mar 1, 2011 16:51 UTC (Tue) by dskoll (subscriber, #1630) [Link] (6 responses)

It's disgusting because Red Hat can unilaterally terminate a contract you've paid for if you exercise rights granted to you under the GPL. The only thing that would make that OK would be if Red Hat refunded the money you paid originally, or at least a pro-rated portion of it.

I doubt they would do that, though. I'm almost tempted to buy a Red Hat subscription and then test things out. (But not quite tempted. :))

It's not so simple

Posted Mar 2, 2011 3:39 UTC (Wed) by ESRI (guest, #52806) [Link] (5 responses)

Yeah, I seriously doubt they'd do that. By and large Red Hat has been huge at "giving back" and trying to do the "right thing".

They're never going to come out and audit your installation base to make sure you're paying them the correct amount of money (we blatantly told them we were out of compliance for a year plus while we tried to get a handle on our infrastructure and our reps essentially told us they didn't really care).

Let's not forget that it's in Red Hat's best interest to NOT screw over their customers or even create disgruntled former customers who could potentially begin swaying potential new customers.

I say give RH the benefit of the doubt here -- surely they've earned it?

It's not so simple

Posted Mar 2, 2011 12:49 UTC (Wed) by dskoll (subscriber, #1630) [Link] (4 responses)

I say give RH the benefit of the doubt here -- surely they've earned it?

No. Red Hat is a corporation whose primary duty is to its shareholders. It's no longer lead by the same people as the "old days" when it was an exemplary Free Software citizen.

Should we give SunOracle the benefit of the doubt because it opened OpenOffice? Nope... it's a completely different company nowadays.

It's not so simple

Posted Mar 2, 2011 16:14 UTC (Wed) by ESRI (guest, #52806) [Link] (3 responses)

Oracle is a completely different animal than Red Hat. Red Hat's entire business model is built around free software and contributing back. Itss share holders are aware of that. Oracle has no such legacy (the only reason they "open" things up is when they're forced to play with the Linux community, in which you are essentially compelled to give back if you want to participate).

This seems to be more of a situation where you see a boogie-man whether there's one there or not... (in my opinion there isn't).

I think there are more important battles to fight than to take RH to task.

It's not so simple

Posted Mar 2, 2011 16:46 UTC (Wed) by dskoll (subscriber, #1630) [Link] (2 responses)

I think there are more important battles to fight than to take RH to task.

Maybe so, but we have a company that has traditionally grokked Free Software violating the GPL, in my opinion. That's very serious.

It's not so simple

Posted Mar 3, 2011 7:19 UTC (Thu) by airlied (subscriber, #9104) [Link] (1 responses)

Only serious in your opinion, you then have to ask the question whether a) your opinion matters at all, b) RH lawyers opinion matters more.

It's not so simple

Posted Mar 3, 2011 12:04 UTC (Thu) by dskoll (subscriber, #1630) [Link]

It's not just my opinion. And if Red Hat is bringing in lawyers against those who would use its patches, then it has withdrawn itself from the community of collaborative developers and should be shunned.

(For the record, I don't believe Red Hat has done that or will do it. I think it's using FUD rather than actual threats to prevent people from distributing its patches.)

It's not so simple

Posted Mar 3, 2011 17:40 UTC (Thu) by vonbrand (guest, #4458) [Link]

What I understand is that they say there are certain rights Red Hat grants you (under the contract with them), and that you might have additional rights granted by the licenses of whatever underlying code is there. So they aren't taking anything away at all...

It's not so simple

Posted Mar 1, 2011 7:08 UTC (Tue) by ekj (guest, #1524) [Link] (5 responses)

They do - and it's actually not clear-cut that they're allowed to do this. In the context of the GPL, "source-code" has a specific meaning, stated in the license, which is:

<i>"The source code for a work means the preferred form of the work for making modifications to it."</i>

RedHat here made a change SPECIFICALLY to make it harder to "make modifications" to their kernel. (for example the modification of removing a single patch) The *prefered* form of the Linux-kernel for making modifications to it, would be a git-repository, I tend to think. (that's what all the people who -make- modifications to it use, including RedHat)

Thus it -certainly- violates the spirit of the GPL. If it also violates the letter of it, is lawyer-food and not something I feel competent to comment upon.

It's not so simple

Posted Mar 1, 2011 8:44 UTC (Tue) by pLub (guest, #73230) [Link] (4 responses)

> RedHat here made a change SPECIFICALLY to make it harder to "make modifications" to their kernel. (for example the modification of removing a single patch)

The overwhelming majority of the patches that go to Red Hat's kernel tree are already upstream so, to remove a single patch that you know causes a regression or something like that you only need the _upstream_ git tree and the SHA1 of the patch in the upstream git tree (or, for that matter, an URL for gitweb or lkml).

The list of patches is necessary to bisect problems and perform other support chores, but is definitely not necessary in order to "make modifications".

It's not so simple

Posted Mar 1, 2011 10:31 UTC (Tue) by ekj (guest, #1524) [Link] (1 responses)

This is true -- i.e. it's possible to do that modification, even without the patches, and the information is available elsewhere for those who invest the time to do the detective-work.

Adding to this workload was however, if we are to believe the information in the comments here, *explicitly* stated as the reason for the change.

Notice that the GPL does not say "possible", it says "prefered", and a naked kernel-tree with no history, no changesets, no version-control is definitely not the "prefered" starting-point for making changes. (the prefered starting-point seems to be a clone of somebodys git-tree)

When someone changes the distributed form of the kernel-source, explicitly to make it LESS convenient to make changes, it's questionably if the same people can at the same time claim that they distribute it in the prefered form for making changes.

Like I said: I've got no idea how the law would interpret it, but it's definitely against the *spirit* of the GPL. (which is: you should give me the source-code in the form that is *prefered* for making changes, i.e. the form that is most convenient.) Making changes explicitly to make life *less* convenient for people who want to make changes to the code, certainly conflicts with the spirit of that.

It's not so simple

Posted Mar 2, 2011 7:34 UTC (Wed) by pLub (guest, #73230) [Link]

> This is true -- i.e. it's possible to do that modification, even without the patches, and the information is available elsewhere for those who invest the time to do the detective-work.

In theory, there is one kind of modification which is helped by the presence of the patch list, namely reverting a patch. In practice, riel said above that on a modern kernel this is made much harder by the fine-grained structure of the patches. I'll take his word for it.

But if you agree with me that you can do the same work with an upstream clone, you're not talking about _that_ modification, you're talking about _another kind_ of modification. You're talking about one of the following:

1) backporting a patch into the Red Hat kernel from stable, or upstream, or from another distro kernel. In this case the patch wouldn't obviously be in the Red Hat SRPM, so the patches wouldn't help.

2) backporting a patch from the Red Hat kernel to stable, or to the Debian kernel (it is not a coincidence that the problem was raised by a Debian kernel maintainer). In this case the patches obviously help, but in this case you're not talking about modifications to the Red Hat kernel! And the GPL talks about "preferred form for modification" of what you're distributing, not modification of something else.

Besides, I would rather avoid talking about the spirit of the GPL, since it is a very multifaceted spirit. For example, unlike other licenses it includes the "right" for you to make money on Free Software (for example from support), and Red Hat is obviously exercising it.

It's not so simple

Posted Mar 1, 2011 11:28 UTC (Tue) by nix (subscriber, #2304) [Link] (1 responses)

... and you can figure out what the patches are with a diff and a lot of 'git blame' calls. (Actually, you can reduce the git blame calls to a maximum of the number of commits that touch the changed lines.)

And if I can think of this method in three seconds Oracle certainly already have.

This isn't going to slow Oracle down much, but it'll annoy everyone. Great move, RH bosses.

It's not so simple

Posted Mar 1, 2011 13:58 UTC (Tue) by nix (subscriber, #2304) [Link]

Some obvious heuristics (simple-minded ones: they don't need the tool to have any knowledge of C) will also suffice to produce plausible patches even from the set of changes that do not yet exist in an upstream git tree: it seems to me that things like patches introducing API changes can be reconstructed automatically with fairly high precision. With a bit more work (and a lot more CPU time) you can even produce plausible patches which will compile. (Sure, they probably won't be identical to the upstream patches, but they'd be good enough to bisect against.)

(The more I think about a tool to do automatic patch composition like this, the more useful it seems, and not just for this application either. After all, it's not RHEL-kernel-specific: it's a generalized way of turning giant third-party code drops against git-maintained projects into 'this came from git: this did not: of those, these bits look like they are unrelated'.)

Red Hat's "obfuscated" kernel source

Posted Mar 1, 2011 6:05 UTC (Tue) by patrick_g (subscriber, #44470) [Link]

>>> I'm waiting for an official answer from Kerri Catallozzi.

Official (and disappointing) answer from RH press service :

Hi Patrick
We have no comment.

thanks,
Kerri

Red Hat's "obfuscated" kernel source

Posted Mar 1, 2011 15:38 UTC (Tue) by daniel (guest, #3181) [Link] (10 responses)

As a former Red Hat employee I can confirm that there exist significant elements within Red Hat who maintain an unacceptable attitude towards free software and the free software community. When I was acting as community liaison for Red Hat's cluster group I was specifically directed by a highly placed manager to undermine the community, the OpenGFS group in particular (a directive I did not act on, quite the contrary). In a sales meeting/rally I witnessed the sales manager tell the several hundred people about "piracy" of Red Hat systems. I spoke up on that occasion, saying that there is no such thing as piracy of open source software, that is something that happens to Microsoft. I am sure this comment, however obviously true, was not appreciated. I also was informed of a discussion that had taken place amongst Red Hat management along the lines that kernel developers (such as me) had to be "controlled more". At the time I was being managed by an IT guy who had been brought in from Compaq. Needless to say, that did not work out well at all and neither of us are there any more (possibly having more than half an engineering team walk out would not be helpful to a career trajectory). I also witnessed a highly placed manager much loved by a particular division, assassinated and pushed out of the company by peers who one could describe as, ahem, somewhat less than loved. Well there you have it, Red Hat from the inside. Yes, Red Hat is deeply challenged with respect to community values. Yet it is still a good company relatively speaking and a net positive force for free software. In many cases Red Hat does take the ethical high road, but certainly not in all. I still own all my Red Hat shares, which I think is a pretty clear statement of my overall opinion. But those comparisons between Microsoft and Red Hat? There exists an unsettling grain of truth.

Red Hat's "obfuscated" kernel source

Posted Mar 1, 2011 16:20 UTC (Tue) by nix (subscriber, #2304) [Link] (4 responses)

In other news, Red Hat employs humans and is large enough (i.e. >1 person) to have office politics. :)

Red Hat's "obfuscated" kernel source

Posted Mar 1, 2011 21:20 UTC (Tue) by daniel (guest, #3181) [Link]

You are welcome dismiss such issues if it feels good. However given Red Hat's business model, which depends on our community to reduce its cost of sales, I think that would be naive of you.

Red Hat's "obfuscated" kernel source

Posted Mar 4, 2011 23:06 UTC (Fri) by yuhong (guest, #57183) [Link]

Yea, no company is perfect, and sometimes mistakes happen.

Red Hat's "obfuscated" kernel source

Posted Mar 4, 2011 23:09 UTC (Fri) by yuhong (guest, #57183) [Link] (1 responses)

I think the key thing is if the incompetent people have learned from this or have left the company.
daniel: Do you know?

Red Hat's "obfuscated" kernel source

Posted Mar 8, 2011 7:33 UTC (Tue) by daniel (guest, #3181) [Link]

<quote>I think the key thing is if the incompetent people have learned from this or have left the compan. daniel: Do you know?</quote>

Some of the worst offenders are still there. From what I have seen, more competent people have left Red Hat than incompetent. I do not think that is because Red Hat has a surplus of competent people.

Then there are some gems who have arrived, like Ric Wheeler. But does Red Hat management realize how lucky they are and are they willing to give him real power, or will they just abuse him and spit him out as I saw happen to a number of good people when I was there? Let's see.

Red Hat's "obfuscated" kernel source

Posted Mar 1, 2011 18:36 UTC (Tue) by bronson (subscriber, #4806) [Link] (4 responses)

> there is no such thing as piracy of open source software

http://gpl-violations.org/

Red Hat's "obfuscated" kernel source

Posted Mar 1, 2011 21:27 UTC (Tue) by daniel (guest, #3181) [Link] (3 responses)

First, that page says nothing about piracy so I do not understand why you linked it, and second, copying Red Hat's distribution disks may in no way be construed as piracy, a fact not universally understood by Red Hat management.

Red Hat's "obfuscated" kernel source

Posted Mar 3, 2011 17:46 UTC (Thu) by vonbrand (guest, #4458) [Link] (2 responses)

Red Hat's Linux offerings do include certain parts that you aren't allowed to freely redistribute. That they sit on the same DVDs (or even inside the same RPMs) with stuff that you can redistribute freely doesn't allow you to redistribute them.

Red Hat's "obfuscated" kernel source

Posted Mar 4, 2011 15:55 UTC (Fri) by Tet (subscriber, #5433) [Link] (1 responses)

Red Hat's Linux offerings do include certain parts that you aren't allowed to freely redistribute

[citation needed] There used to be an extras disc that contained various non-free apps. I don't know if that still exists. But in the main RHEL, I'm not aware of anything that isn't redistributable. The artwork and logos have restrictions on use, but not on distribution AFAIK. And the various bits of firmware in the kernel have passed the scrutiny of Red Hat's legal team, so although some may claim they're not distributable, it would seem that they are in the real world.

So what are you claiming they are shipping that can't be freely redistributed?

Red Hat's "obfuscated" kernel source

Posted Mar 5, 2011 20:27 UTC (Sat) by vonbrand (guest, #4458) [Link]

I'm talking about the logos and the whole branding as Red Hat. It is on the media you get from Red Hat, and you can't redistribute that freely, extra conditions apply. Same as with the Fedora branding, and (presumably) even Debian.

The "extra software" CD that came with early Red Hat distributions (and wasn't on their website) is something entirely different.

Red Hat's "obfuscated" kernel source

Posted Feb 28, 2011 18:27 UTC (Mon) by criswell (guest, #40091) [Link] (4 responses)

This actually is pretty sad.

I used to work at Progeny, making customized RPM-based distributions derived from RHEL sources, and I actually found the RHEL kernels to be quite sane to work with and customize back then (this was 4+ years ago).

Kernel SRPMs used to contain basically stock kernels from kernel.org along with a large number of patches to be applied in a systematic way by the rpm build process. It still required a fair bit of esoteric knowledge and understanding to be able to grok the process, but it was possible and you could de-couple the patches and modify the kernels as needed (it was part of our bread-and-butter at the the time :-) The fact that they are now just a blob of patched work is pretty disheartening.

Part of me wonders if this is more laziness than anything else on behalf of the RHEL kernel maintainers, because creating the SRPM kernels that way is likely more difficult in the short term (but with the extra added benefit of maintainability in the long term). I can't imagine that this was a result of some serious debate internally as to how they could do some sort of "value add" to the product, or a "lock-in"... because it seems like it's just going to cause more headaches for the RHEL kernel maintainers than it's probably worth.

How come?

Posted Feb 28, 2011 20:55 UTC (Mon) by khim (subscriber, #9252) [Link] (2 responses)

I'm pretty sure internally all changes are kept in git and they can track anything (probably better then they were able before). But when .src.rpm is generated they just dump current state of their git repository.

Makes life easier for in-house developers and harder for out-of-house developers. Win-win situation as far as management is concerned.

How come?

Posted Feb 28, 2011 21:21 UTC (Mon) by abartlet (subscriber, #3928) [Link]

None of the engineers I spoke to mentioned that the workflow was improved by this process, and many were in dismay but unable to change the policy. So sadly it's just the latter.

How come?

Posted Mar 1, 2011 6:48 UTC (Tue) by jamesh (guest, #1159) [Link]

Even if they are using Git to manage their kernel source internally (which would be a sane choice given upstream), the git tree that they cut the source tarball from is probably not the one developers work on.

If they want to send the changes upstream, presumably they would be working on them in a separate branch, in isolation of unrelated RH kernel changes.

Whether those changes are integrated into the RH kernel by merging them into another git tree or producing patches would only really effect the tail end of that work.

Red Hat's "obfuscated" kernel source

Posted Feb 28, 2011 21:22 UTC (Mon) by aristeu (subscriber, #35826) [Link]

While I can't comment about internal processes and decisions, I can
assure I'm not lazy! :)

Red Hat's "obfuscated" kernel source - a git repository anywhere?

Posted Feb 28, 2011 18:37 UTC (Mon) by grantma (subscriber, #5225) [Link] (1 responses)

If they have a publicly available git repository of their kernel source ball, obfuscation is a moot point indeed.

It comes down to what is easier to ship - a ball of C out of a git repository, vs a handmade package manually pieced together from thousand's of patches. They could just be moving to a more saner release model given the technology available.

Let's keep our eyes peeled for this repo, and pressure them to make it available if it can't be found.

Red Hat's "obfuscated" kernel source - a git repository anywhere?

Posted Feb 28, 2011 19:00 UTC (Mon) by mbanck (subscriber, #9035) [Link]

Red Hat kernel devs wouldn't have to refer people to their press department if they could just point people at a git tree. I doubt that tree exists publicly.

Red Hat's "obfuscated" kernel source

Posted Feb 28, 2011 18:49 UTC (Mon) by branden (guest, #7029) [Link] (24 responses)

How much do you want to bet that Red Hat's kernel patches are not being handled as a gigantic monolith by their engineering team?

This means that their SRPM does not contain the kernel sources in the "preferred form ... for making modifications to it." (GNU GPLv2)

That means they are violating the GPL.

Red Hat's "obfuscated" kernel source

Posted Feb 28, 2011 19:06 UTC (Mon) by hp (guest, #5220) [Link] (23 responses)

while it may be that a git tree is the preferred form and the GPL requires shipping the git tree around in the SRPM, certainly a lot more people than Red Hat would be in violation if that's the interpretation.

I don't think an SRPM with hundreds of patches is really the preferred form for modification ... surely a git tree is the actual way work happens

Red Hat's "obfuscated" kernel source

Posted Feb 28, 2011 19:22 UTC (Mon) by branden (guest, #7029) [Link] (3 responses)

The question turns on how you (well, Red Hat and the copyright holders in the kernel, really) want to define "form".

Ordinarily this wouldn't be a very interesting question, and I'd be inclined to view Red Hat's packaging decisions with latitude.

However, in the instant case, the act which brought this matter to the attention of LWN's readership was an act of obfuscation of the source.

Wherever the boundary line of the GPLv2's definition of source code is drawn, this decision has moved Red Hat's kernel SRPMS away from its uncontroversial center.

"Preferred form for modification" in GPL

Posted Mar 1, 2011 13:12 UTC (Tue) by vonbrand (guest, #4458) [Link]

Sorry, but in what way I (as a very minor contributor to Linux) would like to define "prefered form for modifying" of whatever I added is probably totally irrelevant, a court of law would have to sort that out.

Red Hat's "obfuscated" kernel source

Posted Mar 1, 2011 14:46 UTC (Tue) by AndreE (guest, #60148) [Link] (1 responses)

Yes, the actual definition of " preferred form" is quite important.

It's also debatable which is why it is silly to declare so simply that they are violating the GPL

Red Hat's "obfuscated" kernel source

Posted Mar 1, 2011 23:34 UTC (Tue) by branden (guest, #7029) [Link]

Having turned many megabytes of patches to XFree86 from one huge monolith into something resembling changeset patches years ago, and having a pretty damn good idea of what that cost in terms of person-hours, I'm comfortable with my interpretation.

The purpose of GNU GPL is, in part, to keep end users from having to jump through ridiculous or high-cost hoops to make a work of software operate as they desire.

If the Red Hat kernel engineers don't work with a giant monolithic patch, then they are imposing a tax on the rest of the community by forcing everyone else to swallow one.

If I were a copyright holder in the kernel, I'd be talking to the SFLC right about now.

Maybe no copyright holders in the kernel share my interpretation. That's fine; it's their prerogative. My view is that Red Hat is doing the Wrong Thing(tm) here, and if the GNU GPL is a sufficiently long lever to get them to revert their decision, good. If it's not, the perhaps the weight of public opinion will be.

They've clearly made a choice that no sane and educated person can regard as friendly to the community. Part of the solution is to shine light and attention on this hostile decision until they find a better way to solve whatever problem it is they're trying to solve.

Telling the world what that problem is, exactly, would be a great first step.

Red Hat's "obfuscated" kernel source

Posted Feb 28, 2011 19:50 UTC (Mon) by jspaleta (subscriber, #50639) [Link] (18 responses)

Along those lines.... I believe there was actually a discussion in the context of Fedora about hypothetically doing away with the whole concept of tarball and patches inside of source packaging and using a git tree as the corresponding source for binary packages. Sorry I don't have a reference handy to point to. I don't think discussion has cycled back to this idea recently. I just wanted to point out people are thinking about it in the scope of rpm packaging workflow. I think we'll eventually see it happen. Though it might happen sooner if RHEL customers push for it.

-jef

Red Hat's "obfuscated" kernel source

Posted Feb 28, 2011 20:05 UTC (Mon) by zlynx (guest, #2285) [Link] (1 responses)

The git "shallow clone" or a full tree or something in between?

Red Hat's "obfuscated" kernel source

Posted Feb 28, 2011 20:20 UTC (Mon) by jspaleta (subscriber, #50639) [Link]

Sorry, I don't remember how far down the rabbithole the discussion went. Like I said I don't have a reference handy for this comment...uncharacteristic of me. If someone else can't dig up a mailinglist citation reference in the meantime, I'll try to deepdive into my mailinglist cache and see if I can dig up at least a starting point for reading up on what was discussed.

-jef

Red Hat's "obfuscated" kernel source

Posted Feb 28, 2011 21:19 UTC (Mon) by dskoll (subscriber, #1630) [Link] (2 responses)

This was proposed for the Debian source format too, and I think was implemented.

In their FAQ, they have a Q/A pair about archive bloat.

Red Hat's "obfuscated" kernel source

Posted Feb 28, 2011 21:23 UTC (Mon) by jspaleta (subscriber, #50639) [Link] (1 responses)

ah thanks. I'll make it a point to watch how Debian maintainers organically start switching over to this format for source requirements.

-jef

Red Hat's "obfuscated" kernel source

Posted Feb 28, 2011 21:39 UTC (Mon) by pkern (subscriber, #32883) [Link]

One major point that was raised against it was the inability to check if the git tree is distributable. When a package enters Debian the source tarball does get checked if the license allows them to distribute it (and for main if it complies to the DFSG). That's currently file-based. Now, with bad luck, you could have non-compliant files buried deep in the git tree; with potentially undistributable files among them, that have since been stripped from the exported tarball. Getting a solution to this problem would help the format's adoption greatly.

Red Hat's "obfuscated" kernel source

Posted Feb 28, 2011 22:58 UTC (Mon) by daniels (subscriber, #16193) [Link] (12 responses)

I'm curious what your take is on this Jef, particularly as concerns Red Hat's obligations to the community, and its financial situation/cashflow?

Red Hat's "obfuscated" kernel source

Posted Mar 1, 2011 0:07 UTC (Tue) by jspaleta (subscriber, #50639) [Link] (11 responses)

It's obligation to the community? That is multi-faceted.

Red Hat already goes beyond what is strictly required by the GPL by making the source public to anyone..instead of just to their customers. Is that enough?

Are the Fedora kernels which Red Hat manpower helps maintain as part of a community distribution using the large tarball dump yet? A check of the SRPM collection for rawhide says Fedora is still doing things with patchsets. Is that enough?

Have the upstream maintainers of the kernel project delineated what _all_ distributors are meant to do to provide as a preferred corresponding source? _all_ distributors including those who produce linux embedded devices such as my home router and what not. So far we have heard from one peer distributor...a community based project that competes with Red Hat in the server space. Now of course competitors certainly have a voice in helping to keep standards for interaction high, but they are not the...canonical...voice. What is the standard of behaviour expected from the upstream project, the linux kernel project, in terms of being able to pull and merge patches from corresponding source as shipped by _all_ vendors that distribute the linux kernel.

If we are going to have this conversation then the upstream project needs to set the guidance as to what _all_ distributors should be providing so we can measure conformance equitably for _all_ distributors to the preferences of the upstream project. If a public git tree is what is expected from a good downstream citizen, than that needs to be documented somewhere by the upstream project and then we can all go poke our fav vendors in the eye to conform to that..whether that be one of the new-breed android tablet vendors...whether that be Cisco for distributing embedded linux in my router whom I have to contact for the sourcecode...or whether its stodgy old Red Hat and their tarball distribution based packaging.

-jef

Red Hat's "obfuscated" kernel source

Posted Mar 1, 2011 10:44 UTC (Tue) by ekj (guest, #1524) [Link] (4 responses)

Not really. Making source available to everyone, is generally more convenient than making it available just to your own customers. The former is trivial, whereas the latter requires tracking customers for a minimum of 3 years, and implementing access-control so that each customer gets access to the right stuff. That's work-for-nothing in the case of GPLed sources, because if they *did* that, someone would mirror the sources publicly anyway.

Thus I don't consider "source to everyone" some sort of huge gift over "source to the customers" -- the former is a lot simpler and cheaper than the latter. (bandwith is -also- cheap these days - *especially* for Open Source software where it's generally easy to get mirrors for free)

Red Hat's "obfuscated" kernel source

Posted Mar 1, 2011 13:19 UTC (Tue) by vonbrand (guest, #4458) [Link] (3 responses)

Not really. You can just give the customer the binaries and the source in the same deal. I.e., you get binaries + source, even if you don't ask for source. Ditto for any updates. No need to keep track of anything extra this way.

Red Hat's "obfuscated" kernel source

Posted Mar 3, 2011 1:28 UTC (Thu) by dag- (guest, #30207) [Link] (2 responses)

Indeed, and Red Hat already has the distribution mechanism for their customers (already offering these SRPM packages), called Red Hat Network. So offering only to customers would actually be easier than making sure they also hit the FTP site and mirrors.

I guess we can drop that from the list of conspiracies :-)

Red Hat's "obfuscated" kernel source

Posted Mar 3, 2011 7:09 UTC (Thu) by ekj (guest, #1524) [Link] (1 responses)

It wasn't a conspiracy, but merely an observation.

The observation was, that online, the extra work involved in offering sourcecode to everyone - over offering it only to customers, is typically very little, and it can even be easier to offer it to everyone.

Thus, very little gratitude is required for going "above and beyond" the duties by giving sourcecode to everyone, rather than just customers. Yeah it's an advantage, but it's a tiny contribution. (even if they -did- give the source only to customers, free-for-all mirrors of these source-packages would spring up in a matter of days automagically.)

RedHat does however do many things that are significant positive contributions to the Open Source community, for example several paid employees of theirs are regular contributors to central projects.

Red Hat's "obfuscated" kernel source

Posted Mar 3, 2011 10:16 UTC (Thu) by dag- (guest, #30207) [Link]

> The observation was, that online, the extra work involved in offering sourcecode to everyone - over offering it only to customers, is typically very little, and it can even be easier to offer it to everyone.

And my response was that they now are already offering it "only to customers" through RHN. So there's no cost for them to stop offering it to everyone, if they wanted to. Of course, Red Hat has generally benefited from the RHEL-rebuild scene and the wide availability of RHEL-rebuilds in markets Red Hat is not targeting is making RHEL very attractive. That's why I always described the Red Hat/CentOS relation as a symbiosis.

> (even if they -did- give the source only to customers, free-for-all mirrors of these source-packages would spring up in a matter of days automagically.)

Then one can only wonder why this never happened for Novell, which did only offer source-packages to customers. No free-for-all mirrors ever appeared, despite a demand from the community, and hence no community SLES project.

Red Hat's "obfuscated" kernel source

Posted Mar 1, 2011 10:49 UTC (Tue) by daniels (subscriber, #16193) [Link] (5 responses)

OK, thanks. Good to know what you consider acceptable behaviour by an open source company!

Red Hat's "obfuscated" kernel source

Posted Mar 1, 2011 17:55 UTC (Tue) by jspaleta (subscriber, #50639) [Link] (4 responses)

I actually didn't state an opinion. I seldom state an opinion. I do tend to ask a lot of questions. My opinion ultimately does not really matter. What matters is the consensus opinion of the upstream project developers and the the larger consensus opinion of the ecosystem from which Red Hat draws partners and consumers. And that such a consensus opinion be applied fairly and broadly to all participants.

In this specific case, the underlying issue here is the attempt by other multi-vendors to "sync" their offering in some way. This wouldn't really have come up as a potential scandal if the effort to "sync" wasn't under way. No one pounds on Cisco/Linksys to make code available widely because the kernel they ship in their embedded junk isn't a cross-vendor "sync" target.

There is and there will always be a tension between standardization and differentiation between vendors in the marketplace. This round of "syncing" as mentioned in the original interview isn't the first such effort in the inherent tug of war of market interests. Anyone else remember the United Linux effort? I believe the current "syncing" effort at the kernel layer is similar in motivation if not in scope. It will be interesting if such cross-distro syncing becomes an important aspect of closing customer deals or not. The question remains as to whether the paying market values that cross-distro syncing effort. Time will tell. It's far from clear how important such standardization is in the final analysis.

-jef

Red Hat's "obfuscated" kernel source

Posted Mar 1, 2011 22:10 UTC (Tue) by jrn (subscriber, #64214) [Link] (3 responses)

> No one pounds on Cisco/Linksys to make code available widely

Really?

Red Hat's "obfuscated" kernel source

Posted Mar 1, 2011 22:16 UTC (Tue) by jspaleta (subscriber, #50639) [Link] (2 responses)

No they get pounded to make it available to customers...at all. A bar Red Hat already meets. Many embedded vendors have trouble even meeting the strictest definition of GPL compliance of getting the source code in the hands of their customers...let alone into the hands of competitors or the general public or any nuance discussion about the "preferred" form.

-jef

Red Hat's "obfuscated" kernel source

Posted Mar 1, 2011 22:34 UTC (Tue) by jrn (subscriber, #64214) [Link] (1 responses)

Yes, I guess I should have phrased it another way: Red Hat has successfully raised expectations. People like them and are disappointed when they create obstacles because it is currently possible to collaborate with them.

I don't think that has too much to do with standardization. To give another example, many people _are_ upset that Google does not make their work on Android public as it happens but only makes code drops now and then. That is for many reasons, including wanting to be able to take advantage of hardware support from that tree and to increase its code quality.

Red Hat's "obfuscated" kernel source

Posted Mar 1, 2011 22:51 UTC (Tue) by jspaleta (subscriber, #50639) [Link]

Sure be disappointed...express that honest disappointment. But be as fair an unbiased about expectations as you can. If this is going to hurt how people are already collaborating with Red Hat, then by all means those people should speak up and tell Red Hat that they valued that collaboration which the older kernel patch policy facilitated and try to engage them in a dialogue on how to structure things so that collaboration can continue to happen.

-jef

practical difficulties

Posted Feb 28, 2011 19:05 UTC (Mon) by mcoleman (guest, #70990) [Link] (2 responses)

Regardless of politics and licenses, this makes it more difficult for end users to debug kernel problems, as a practical matter. This is a not-insignificant minus in my book.

The snarky view

Posted Mar 3, 2011 22:47 UTC (Thu) by jmorris42 (guest, #2203) [Link] (1 responses)

> this makes it more difficult for end users to debug kernel problems

We here at LWN aren't RH's target customer. If you can debug kernel problems you don't need them and should be using a RHEL Rebuild or Debian. If you have a problem you are supposed to be competent enough to file a trouble ticket and wait but that is all. If you know more your employer is either overpaying you or you are working for less than you should be.

RHEL is normally for hosting commerical apps where you can't really see what is going on so any problem is sorted out by filing trouble tickets and eventually getting the software vendor and/or the OS vendor to fix it. And while things are smoking and business isn't happening it is all good, because you have a trouble ticket number which officially makes it an SEP (Someone Else's Problem). Admins in those settings are typically certification chasers, not real hackers.

The snarky view

Posted Mar 3, 2011 23:12 UTC (Thu) by mcoleman (guest, #70990) [Link]

That's a pleasant thought, to be sure. Unfortunately, I live in the sticks, technology-wise, and unfortunately have not yet been able to convince Google to open a branch here, or (say) Ubuntu to hire me. (I wonder how many of us there are stranded here in the slow zone.)

Waaah. Life goes on.

In the mean time, I still try to do the best work I can.

Is Red Hat in financial trouble?

Posted Feb 28, 2011 19:34 UTC (Mon) by NightMonkey (subscriber, #23051) [Link] (17 responses)

I'm trying to understand this. Is this change because Red Hat is in some serious financial trouble? By unscientifically looking at their stock price over the last few years, the answer would seem to be "no". But a move like this could threaten their customer relationships in a big way.

Would this really put a crimp in CentOS's style? Yeah, I see that doing big tree-to-tree diffs to extract changes in the RedHat source would be unfun, but still possible. At least bugs could be better pinned to non-vanilla kernel source with such a diff. Or am I missing the piece that really hurts CentOS and friends?

I hope that RedHat changes their hive-mind regarding this. I hope that even if they keep this new approach, they don't go all "talk to the hand" to LWN and other community news outlets regarding it... That's just really poor community relations, and it will bite them over time.

Is Red Hat in financial trouble?

Posted Feb 28, 2011 19:49 UTC (Mon) by hp (guest, #5220) [Link] (13 responses)

Something that's underappreciated in the open source world, I think, is that Red Hat's stock price basically assumes that they can somehow increase margins a fair bit. The stock is badly overpriced (in my opinion) if you assume that they cannot improve margins. (I'm not saying it's a bad company, I'm saying the present value of their future cash flows is not worth their market price, at current margins. It would be worth some lower market price. Lots of great companies aren't for sale at great prices.) There's some amount of acquisition-speculation with Red Hat stock as well, probably, in addition to future-margin-expansion speculation.

To date Red Hat has always grown revenue by growing costs also, and they just are not that profitable compared to a Microsoft or an Apple or other proprietary software companies.

I think Red Hat would say that this is because they're still investing in the business and don't want to just hoard cash when they can build the business instead. Whether you believe this is a key question if you are investing in Red Hat.

So what they have to do _eventually_ is somehow increase revenue without increasing costs. This could mean raising prices, or just using their resources more efficiently, or whatever it is.

But, you should expect Red Hat to feel pressure to expand margins and act accordingly. In this sense they are in "financial trouble" - it's not that they're going to go bankrupt, but unquestionably current investors in Red Hat expect them to become more profitable than they are today. And Red Hat's management has a fiduciary responsibility to try to maximize shareholder value.

Is Red Hat in financial trouble?

Posted Feb 28, 2011 21:38 UTC (Mon) by daglwn (guest, #65432) [Link] (11 responses)

> And Red Hat's management has a fiduciary responsibility to try to maximize
> shareholder value.

And right there is the failing of U.S.-style capitalism. Fiduciary responsibility is the only relevant factor. Moral responsibility doesn't even enter the equation for management.

We are just seeing the beginning of what we're going to reap from this highly warped value system we've built.

Is Red Hat in financial trouble?

Posted Feb 28, 2011 22:01 UTC (Mon) by hp (guest, #5220) [Link] (2 responses)

I don't think there's a moral problem with Red Hat raising their margins. After all right now they have very low margins relative to the industry. Raising them would be good for a lot of people, investors (anyone with an S&P500 fund), employees, and even customers in some ways (higher-margin companies usually can do more innovation and are more stable).

Practically speaking, though, the question is how much they _can_ raise the margins and how quickly.

Is Red Hat in financial trouble?

Posted Feb 28, 2011 22:19 UTC (Mon) by boog (subscriber, #30882) [Link] (1 responses)

A few responses to the discussion on business and ethics:

- a FOSS business is expected to have low margins;

- monopolies have high margins that should be undercut by FOSS companies;

- nothing is stopping RH taking a long-term view of shareholder value (growing the cake not their slice); does that charming American law mention a time limit?

As a non-FOSS example of the last point, take Apple, who happily and repeatedly make their own top-selling products obsolete with their breakneck pace of development; many companies really struggle not to rest on their laurels in that kind of situation.

Debian seems to be the tortoise in this race.

Is Red Hat in financial trouble?

Posted Feb 28, 2011 22:31 UTC (Mon) by hp (guest, #5220) [Link]

Not sure I agree that a FOSS business is expected to have low margins. The stock market does not currently expect Red Hat to have low margins. Investors appear to believe they will have high margins. Maybe there's an alternative explanation for the stock price, but in my opinion it's based on hopes for either an acquisition or higher margins.

I do agree that high margins will involve some competitive advantage, but I don't think it has to go so far as a monopoly. My view is that "monopolistic competition" as an economics textbook would say is a good balance between interests of the company and the consumer. These are the Cokes and Wrigleys, where they can't charge infinite amounts for sugar water and gum, but they do have some pricing power. Bob Young's vision for Red Hat in 1998 was a story about Heinz.

I think most people would say that management is supposed to focus on long-term value. Stocks are normally valued assuming perpetual duration.

But it's context-dependent; if a manager thinks the best outcome for shareholders is to liquidate the company and give them their money back, they're also supposed to do that. Some stocks obviously will not have perpetual duration.

In practice managers can do pretty much whatever they want, since there's no way to prove in court that such-and-such complex judgment was wrong. But managers who don't have investor confidence may not last very long.

If you were Red Hat management, you can't come out and say "oh, we'll have bad margins." The stock price would crater. In an interview a while ago, Red Hat's CEO said something like he'd compromised with analysts and agreed to increase margins 1% per year.

moral responsibility

Posted Feb 28, 2011 22:17 UTC (Mon) by dbruce (guest, #57948) [Link] (4 responses)

I don't think it is so black-and-white "money vs. morals". Red Hat's long term business plan and viability has apparently had everything to do with being a good FOSS citizen, "moral" if you will. So in the long run, it may be essential to the "fiduciary responsibility" to behave in a way that doesn't piss off the free software community.

Short term, sure, all the time we see companies doing dubious things to make the quarterly reports match up to market expectations. "Fiduciary responsibility" gets used as an excuse for almost any kind of trickery, but it doesn't mean the whole idea of investor-owned business is wrong.

Put it this way, if investors are in it for the long run, they are going to want management to do things that will win customers and keep them loyal for many years.

moral responsibility

Posted Mar 1, 2011 3:13 UTC (Tue) by allesfresser (subscriber, #216) [Link] (3 responses)

>if investors are in it for the long run

And therein lies the problem: most investors are not it in for the long run--that would require that they actually care about what the company does and why it does it. They are looking for essentially pump-and-dump results. When investors don't actually care about the company or its products, but only what money they can get out of it, it's not investing, but sociopathic gambling.

moral responsibility

Posted Mar 1, 2011 11:54 UTC (Tue) by dbruce (guest, #57948) [Link] (2 responses)

"And therein lies the problem: most investors are not it in for the long run-They are looking for essentially pump-and-dump results."

Do you have any data on that? My understanding is that the largest chunk of money in the stock market gets there via mutual funds. I don't think the typical fund manager has a "pump-and-dump" strategy. I know there is a popular image of the stock market as a place for wheeler-dealer day traders, and a lot of that activity certainly exists, but I thought that the bulk of stock investment actually is long-term buy-and-hold.

moral responsibility

Posted Mar 1, 2011 13:34 UTC (Tue) by nivola (guest, #5662) [Link] (1 responses)

Average stock hold time: 22 seconds.

Stock markets have changed pretty radically in the last 30 years, and not for the better. Hudson is talking about US markets here, but it's a similar story in Europe and elsewhere.

fishy statistics warning

Posted Mar 1, 2011 17:18 UTC (Tue) by jku (subscriber, #42379) [Link]

That figure is probably bogus and in any case not necessarily relevant: High frequency traders may do massive amounts of trades per day but large amounts of stock is still owned by long term investors. Trading the same stock thousands of times per day doesn't magically move the long term investments into the market.

It seems that the real mean duration of holding is still measured in months.

Is Red Hat in financial trouble?

Posted Mar 1, 2011 3:42 UTC (Tue) by tialaramex (subscriber, #21167) [Link] (1 responses)

Strictly speaking they're responsible for everything they sign up for. If a company says it's going to make boats and profit from that then yes, you can sue because the board made a decision that needlessly trims profits ("let's not charge Old Bill full price for these materials, he's a nice fellow") but you can also sue them for making a decision that interferes with the boat-building goal ("I don't even like boats, let's sell icecream")

The existence of the stock market does encourage some people to buy and sell stocks without knowing anything about the company (perhaps not even the name, the ticker symbol is enough to buy and sell) but the lack of interest by investors in non-financial goals is a failing of the investors and not of the businesses. In my experience the largest fraction of companies have a clear purpose stated in their paperwork, and many have a purpose that a layman would instantly understand like "sell people coffee" or "build skyscrapers" and thus investors do have the information to make ethical decisions if they choose to do so.

Red Hat, I think, says it makes Free Software operating systems (I won't swear what terms they use exactly). It cannot become a used furniture store without going through a process to change the paperwork or risking a lawsuit by investors. Until it does that, you can expect that producing Free Software will be a goal balanced with making money to keep the financial people happy. From time to time that will mean we don't get what we want, and we don't have to be happy about that (I think this change was stupid) but we shouldn't think its the end of the world.

Is Red Hat in financial trouble?

Posted Mar 1, 2011 16:12 UTC (Tue) by mpr22 (subscriber, #60784) [Link]

My understanding is that in England, the purpose of a company limited by shares is habitually stated in its paperwork to be "carrying out business". This avoids paperwork-wrangling when you decide that you'd like to carry out a kind of business you hadn't initially considered.

Is Red Hat in financial trouble?

Posted Mar 1, 2011 7:05 UTC (Tue) by paulj (subscriber, #341) [Link]

Moral responsibility can enter into things, if a company's constitutional documents say they should. Any shareholders who buy in can then not complain if the financial position is not maximised because of greater moral considerations.

Is Red Hat in financial trouble?

Posted Mar 1, 2011 5:16 UTC (Tue) by yuhong (guest, #57183) [Link]

FYI, see this: http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1013744

Is Red Hat in financial trouble?

Posted Mar 1, 2011 6:40 UTC (Tue) by rodgerd (guest, #58896) [Link] (2 responses)

They aren't in financial trouble, but they're pretty clearly Oracle's next target. Oracle have been trash-talking them very publicly and aggressively, and I know they're coming into RedHat shops with carrots ("We'll give you OEL for 80% less than RHEL") and sticks ("Oracle DB will be reducing RHEL to a second-class citizen, we don't support virtualisation on any platform except OEL and Solaris" are two). This is pretty much the strategy they follow with many of their aquisition - aggressive assaults to drive down market value, then picking up the company and migrating the customers to Oracle's preferred offerings.

One can argue whether *this* response is a good one or not, but RedHat would be complete idiots not to be ready to fight. And while those Linux users who are stuck in the 1999 /. "RedHat are the Microsoft of Linux" view of the universe, I invite folks to consider what Oracle have done to Sun, MySQL, and Java when they consider whether this is would be a desireable outcome.

Is Red Hat in financial trouble?

Posted Mar 1, 2011 17:04 UTC (Tue) by brunowolff (guest, #71160) [Link] (1 responses)

Maybe Red hat should work on getting Postgres certified to use to use with a variety of applications with support from whoever provides the application. There are a lot of people running Oracle's database that probably wouldn't need to if they could still get support using Postgres instead of Oracle in their stack.

Is Red Hat in financial trouble?

Posted Mar 1, 2011 17:16 UTC (Tue) by rodgerd (guest, #58896) [Link]

That would be great, and there are ex-RedHatters doing that in other companies, as it happens. Unfortunately the open source world appears hell-bent on MySQL. I see apps in our part of the software world dropping PostgreSQL as often as picking it up.

Red Hat's "obfuscated" kernel source

Posted Feb 28, 2011 20:16 UTC (Mon) by dps (guest, #5725) [Link]

I have tried, and failed, to built RH's kernel with a radically different configurations. Let it suffice to say this is a serious server configuration without any graphics support and the build bombed out with a compiler error.
I suspect RH's stock configurations work but mine did not.

I managed to build stock 2.6.32.9 with configuration any problem but I have no clue how close this is to the RH tar ball.

Red Hat's "obfuscated" kernel source

Posted Feb 28, 2011 20:58 UTC (Mon) by miguelzinho (guest, #40535) [Link] (2 responses)

I suppose distributing a tarball does not violate the GPL. If they decide to do the same with packages that would be the death sentence for CentOS.

Red Hat's "obfuscated" kernel source

Posted Feb 28, 2011 21:43 UTC (Mon) by lkundrak (subscriber, #43452) [Link]

How exactly does presence of patches make it any harder to rebuild the code? If they did that, they would do no bigger harm to CentOS than they would do to their customers.

Red Hat's "obfuscated" kernel source

Posted Mar 1, 2011 21:50 UTC (Tue) by daniel (guest, #3181) [Link]

<quote>I suppose distributing a tarball does not violate the GPL. If they decide to do the same with packages that would be the death sentence for CentOS.</quote>

More probably it would be a death sentence for Red Hat and a huge boost for Ubuntu.

Red Hat's "obfuscated" kernel source

Posted Feb 28, 2011 21:41 UTC (Mon) by lkundrak (subscriber, #43452) [Link] (3 responses)

This is rather unfortunate; the patch list has been helpful to me numerous times, both when hunting down regressions against stock kernel and to quickly inspect whether a backported feature or a fix is present.

Also, the snapshot kernels are gone, with an explanation from linville that it's Red Hat's policy now.

On the other hand, I've not paid for anything from Red Hat anyway, just am wondering whether paying customers are stripped off those rather valuable resources as well.

Red Hat's "obfuscated" kernel source

Posted Feb 28, 2011 22:01 UTC (Mon) by mmahut (guest, #45550) [Link] (2 responses)

On the other hand, I've not paid for anything from Red Hat anyway, just am wondering whether paying customers are stripped off those rather valuable resources as well.

I don't think they are. As a customer you have access to an interface that let you browse these sources with references to erratas, bugzillas, changelogs and patches now.

Red Hat's "obfuscated" kernel source

Posted Mar 1, 2011 13:52 UTC (Tue) by ixs (subscriber, #47170) [Link] (1 responses)

Where is that interface?

I have been looking around https://access.redhat.com and cannot see anything like a kernel source browser.

Any pointers? Thx.

Red Hat's "obfuscated" kernel source

Posted Mar 2, 2011 10:35 UTC (Wed) by lkundrak (subscriber, #43452) [Link]

Found it here: https://access.redhat.com/knowledge/sources/
(Customer Portal -> Knowledge -> Source)

Red Hat's "obfuscated" kernel source

Posted Feb 28, 2011 21:56 UTC (Mon) by mmahut (guest, #45550) [Link] (6 responses)

Red Hat customers will get more for their money? <sarcasm>Oh noes! What a foolish business move!</sarcasm>

Red Hat's "obfuscated" kernel source

Posted Feb 28, 2011 22:05 UTC (Mon) by lkundrak (subscriber, #43452) [Link] (5 responses)

So how exactly is merging the patches "more"?

It's the other way around

Posted Mar 1, 2011 6:42 UTC (Tue) by khim (subscriber, #9252) [Link] (4 responses)

Customers don't get merged patched. Everyone else get merged patches so customers indeed are getting more :-)

It's the other way around

Posted Mar 1, 2011 8:47 UTC (Tue) by gnufreex (guest, #70396) [Link] (3 responses)

No.

Everyone is getting less. Customers get same.

It's the other way around

Posted Mar 1, 2011 11:18 UTC (Tue) by mmahut (guest, #45550) [Link] (2 responses)

No.

As a customer I have now access to the "Source Browser" section in the Customer Portal that let me browse through the code (patches included). It looks similar to an opengrok instance.

It's the other way around

Posted Mar 2, 2011 6:11 UTC (Wed) by gdt (subscriber, #6284) [Link] (1 responses)

But as a customer I lose the ability to straight-forwardly rebuild a kernel dropping a problematic patch.

It's the other way around

Posted Mar 3, 2011 12:06 UTC (Thu) by mmahut (guest, #45550) [Link]

Well, not really - you can revert the patch you get from the source browser against the tarball during the build, you get the same effect. But I recommend you to ask Red Hat for a hot-fix in such case, as a kernel build by yourself won't be supported.

Red Hat's "obfuscated" kernel source

Posted Feb 28, 2011 22:12 UTC (Mon) by cyperpunks (subscriber, #39406) [Link] (10 responses)

In a perfect world this action by Red Hat should not be needed, however when a much larger company (with a popular database and awful open source history) is trying to kill you, some form of defence is okay.

Red Hat's "obfuscated" kernel source

Posted Feb 28, 2011 22:31 UTC (Mon) by lkundrak (subscriber, #43452) [Link] (9 responses)

What exactly prevents Oracle from buying a RHEL subscription and enjoying access to Red Hat's patch tracker (http://lwn.net/Articles/430173/)?

Red Hat's "obfuscated" kernel source

Posted Mar 1, 2011 6:34 UTC (Tue) by butlerm (subscriber, #13312) [Link] (8 responses)

Oracle could probably get away with doing that on the sly, but RedHat certainly has no obligation to enable them, and may very well have contractual terms that manage to restrict competitor-customers from doing that, as long as the contract is in force.

Red Hat's "obfuscated" kernel source

Posted Mar 1, 2011 9:14 UTC (Tue) by jamesh (guest, #1159) [Link] (6 responses)

Given that one of the reasons some people buy RHEL is to run Oracle's database software, it isn't clear that it is in Red Hat's best interest to limit Oracle's access to RHEL.

It was good idea before the "Unbreakable Linux"

Posted Mar 1, 2011 14:54 UTC (Tue) by khim (subscriber, #9252) [Link] (5 responses)

Well, these customers can easily switch to Oracle's Linux so in a sense they are already lost. It customers which need to run more then Oracle's DB that are at stake...

It was good idea before the "Unbreakable Linux"

Posted Mar 2, 2011 6:58 UTC (Wed) by jamesh (guest, #1159) [Link] (4 responses)

Just because they can switch to Oracle's Linux doesn't mean that it is in Red Hat's best interest to push them to that distro.

It is far from clear that the loss of customers would be offset by whatever gains they get from not letting Oracle certify their software on RH's platform.

Of course Oracle will be certified!

Posted Mar 2, 2011 14:28 UTC (Wed) by khim (subscriber, #9252) [Link] (3 responses)

Huh? Where the idea to not certify the Oracle comes from? It's actually backwards: Oracle gives certificate, not RedHat.

And this is the problem: if user only cares about Oracle certificate and has no interest in anything else then there are no realistic way to keep him/her. If, on the other hand, he/she cares about other kinds of certification then it's in RedHat's interest to make sure this certificate can not be easily obtained by Unbreakable Linux too. And for that it must make sure Oracle can not just use components of RHEL. It must build them from scratch and, more importantly, Unbreakable Linux certificate must be earned by each ISV, not added on the cheap.

CentOS is not a problem here: it carries no certificates and is not interested in carrying them. Unbreakable Linux does carry them - and this trend must be stopped or at least slowed down.

Of course Oracle will be certified!

Posted Mar 3, 2011 9:50 UTC (Thu) by jamesh (guest, #1159) [Link] (2 responses)

But in order for Oracle to certify their software running on RHEL, presumably they need access to RHEL.

If Red Hat cuts off Oracle's access to RHEL completely, then Oracle can't certify their software on that platform.

This is exactly why this license exist...

Posted Mar 3, 2011 10:46 UTC (Thu) by khim (subscriber, #9252) [Link] (1 responses)

Sure, but then Oracle is constrained by support contract and can not just lift patches from RHEL and land them in Unbreakable Linux.

This is not about the physical ability of doing something: of course the team which certifies RHEL can pass patches around to the team which polishes Unbreakable Linux - but then Oracle will be in very hot water and will be forced to pay sizable sum for damages incurred.

How well it'll work remains to be seen, but the idea is simple enough.

This is exactly why this license exist...

Posted Mar 3, 2011 11:18 UTC (Thu) by PaXTeam (guest, #24616) [Link]

> but then Oracle is constrained by support contract and can not just lift patches from RHEL and land them in Unbreakable Linux.

sure they can, otherwise RH would be violating GPL2 section 6 ("You may not impose any further restrictions on the recipients' exercise of the rights granted herein.")

whether they 'retaliate' by tearing up the support contract is a different matter, it has zero bearing on the legality of redistributing RH kernel patches.

Red Hat's "obfuscated" kernel source

Posted Mar 2, 2011 0:49 UTC (Wed) by mleu (guest, #73224) [Link]

Then Red Hat could sue them the same way Oracle sued SAP/TomorrowNow. ;-)

Red Hat's "obfuscated" kernel source

Posted Feb 28, 2011 22:18 UTC (Mon) by PaulWay (guest, #45600) [Link] (1 responses)

So how long until someone writes a tool to read the source blob and 'decompose' it into a bunch of patches based on the kernel git tree (and possibly RH's git tree)? Diff the code against the stock kernel, find sections of lines that have changed, see if those are in a git commit somewhere (a simple look at which files had changed in that commit would narrow it down substantially). Or take a list of git commits and find them in the source tree and decompose them into patches - it all depends on which is the larger list of changes, I suppose.

It's going to be interesting to see how RH spins this, especially if it's now public knowledge that most of their developers are unhappy with it.

Have fun,

Paul

Red Hat's "obfuscated" kernel source

Posted Feb 28, 2011 22:26 UTC (Mon) by lkundrak (subscriber, #43452) [Link]

Reportedly (http://lwn.net/Articles/430173/), subscribers have access to the patches; it should only take one of them pulling the patches and exposing the GIT tree to the community (CentOS, SL) users.

Red Hat's "obfuscated" kernel source

Posted Mar 1, 2011 2:06 UTC (Tue) by paravoid (subscriber, #32869) [Link] (8 responses)

Maximilian Attems (and Ben Hutchings, who has commented here) are both Debian Developers with significant contributions to the kernel, in Debian and upstream, over the years.

Debian's kernel tree, with all of its modifications (which *are* significant) remains availabe in a proper format for everyone to distribute, work on it, fork it or any other purpose with the only limitations being the ones that are mandated by the GPL.

This tree is not under any corporation's control and fulfills no agenda besides the one that serves Debian's (and its derivatives) users.

Please remember that and thank these people.

Red Hat's "obfuscated" kernel source

Posted Mar 1, 2011 8:54 UTC (Tue) by akurtakov (guest, #62232) [Link]

There is only one response. http://pkgs.fedoraproject.org/gitweb/?p=kernel.git;a=tree :)

Red Hat's "obfuscated" kernel source

Posted Mar 1, 2011 22:33 UTC (Tue) by dowdle (subscriber, #659) [Link] (6 responses)

I'm not trying to denigrate the contributions of Debian developers... and while they may have contributed significantly in the past and may continue to in the future... in comparison to how much Red Hat contributes... I've yet to see Debian or a Debian developer listed in the top 10 list.

It is possible I've overlooked one or two on a few releases and I haven't really been looking at it that hard... but Red Hat has been the #2 contributor to the kernel for some time.

Debian makes a fine distribution, makes it for a lot of arches, and packages up a lot of packages... but when it comes to original development work in core components, to the best of my knowledge, they do not stand out at all. On the other hand, Red Hat stands on a number of projects including the kernel, gcc, x.org, gnome, etc.

Trying to turn this into an opportunity to switch users to Debian seems a little too convenient. I hear some people tell me, because I'm an pro-Red Hat advocate, that they will never use Red Hat software... and my response is that no matter what Linux distro you use, you are using a lot of software Red Hat has developed. I don't think anyone who has actually look into it is willing to argue with me on that point.

Red Hat's "obfuscated" kernel source

Posted Mar 1, 2011 22:41 UTC (Tue) by paravoid (subscriber, #32869) [Link] (5 responses)

From Maximilian's interview:

Ben Hutchings is the Nr.1 contributor for 2.6.33. He also is top listed as author of patches on stable 2.6.32. Debian is not listed as organization as many send their linux-2.6 patches from their corporate or personal email address and thus it won’t be attributed to Debian. There is currently no means to see how many patches get forwarded for the stable tree, but I certainly forwarded more then fifty patches. I was very happy when Greg KH personally thanked me in the 2.6.32.12 release.

And this was not an attempt on switching users, but merely a give credit where credit is due attempt. Nor I disagree with you on RedHat's contributions.

Red Hat's "obfuscated" kernel source

Posted Mar 1, 2011 23:05 UTC (Tue) by dowdle (subscriber, #659) [Link] (4 responses)

Thank you for pointing that out.

When Jon Corbet first started doing his analysis of who made kernel X... and it became an ongoing feature... I emailed him to ask why Debian didn't show up... if it was because they are harder to identify... or if it was because they don't contribute as much to kernel development. It was a while ago and I'm not quoting... but I believe he said... as far as he could tell they weren't contributing to the things he was measuring.

I don't think the Debian development community cares as much about getting credit... but it wouldn't be a bad thing for them to make some effort to become more measurable in such surveys... if they are indeed contributing more than they are being credit with. I'm not sure what that would take but I'm guessing those doing the measuring could give some valuable clues.

I certainly would like to see the Debian developers get credit for the work they do.

Red Hat's "obfuscated" kernel source

Posted Mar 2, 2011 0:22 UTC (Wed) by neilbrown (subscriber, #359) [Link] (3 responses)

It seems to me that there is an apples-and-oranges comparison here.

Redhat are a software distributor and a development house and a support service (and probably other things).

Debian is a software distribution.

The kernel patches from "redhat" are almost certainly mostly from the "development house" side of redhat. There is no corresponding part of Debian.

I really don't expect 'Debian' to contribute much in the way of kernel patches (though I suspect they channel their fair share of bug reports, which are just as valuable). When individuals who happen to be Debian developers also happen to do kernel development I suspect they are not doing so as a "Debian developer" but in some other role (employee of some company, independent enthusiast or whatever).

As a software distributor you might expect Debian to appear in surveys such as "how widely used" or "user preference" or "number of packages" or "number of bug reports" or "frequency of releases", and I thing Debian does OK in most of those.

Red Hat's "obfuscated" kernel source

Posted Mar 2, 2011 5:36 UTC (Wed) by JoeBuck (subscriber, #2330) [Link] (1 responses)

Yes, and there is no organization called "Debian" paying developers so they can work full time on the kernel. There certainly are Debian developers making significant contributions all over the place, but the RHEL revenue is making it possible for many people to do nothing else but work on free software.

Red Hat's "obfuscated" kernel source

Posted Mar 4, 2011 8:07 UTC (Fri) by smurf (subscriber, #17840) [Link]

Your point being?

My point would be that they didn't invent the wheel (i..e the kernel) here. There got to where they are now because lots of others play by the rules and don't obfuscate their code, or its origins.

While Oracle doesn't play nice with Open Source, kowtowing to their level of "this is our code, whether the community likes it or not" boneheadedness and doing essentially the same thing is not the way forward: Oracle isn't going to change its business practice because of what Red Hat does or doesn't do with its kernel patches.

Summary: This step benefits nobody.

It may even hurt Red Hat directly, if a couple of their kernel people get disgusted enough about this attitude that they leave.

Red Hat's "obfuscated" kernel source

Posted Mar 5, 2011 15:32 UTC (Sat) by BenHutchings (subscriber, #37955) [Link]

When individuals who happen to be Debian developers also happen to do kernel development I suspect they are not doing so as a "Debian developer" but in some other role (employee of some company, independent enthusiast or whatever).

I work on the kernel as a Debian developer, fixing bugs where I can see how to and occasionally developing features that are important to Debian and its users. I also work on the kernel as an employee of Solarflare, but this is a pretty well separate role, as my employer does not use or claim to support Debian.

they will lose some customers over this

Posted Mar 1, 2011 2:15 UTC (Tue) by brouhaha (guest, #1698) [Link] (2 responses)

I've been considering buying RHEL 6 licenses for my servers, which currently run Fedora. I like Fedora but would prefer RHEL for longer-term stability. However, I have on multiple occasions had to debug kernels by rebuilding from RPMs with some patches disabled. The way past RHEL kernel RPMs worked (and Fedora kernel RPMS) made this very easy. I'm unwilling to switch to a distribution that flattens the patches into their distributed kernel sources, even if they have provided some separate mechanism for customers to get access to the individual patches.

they will lose some customers over this

Posted Mar 1, 2011 2:37 UTC (Tue) by jspaleta (subscriber, #50639) [Link] (1 responses)

You'd be in a much stronger position to argue the point if you were already a paying customer and you cancelled your subscriptions because of this policy change. Existing customers have the most leverage in influencing strategic business decisions for any for-profit business.

Those of us who are not paying customers(and I am not a paying Red Hat customer) can still have impact if we engage in reasoned debate on the merits of a policy and the actual harm it is causing to the ecosystem. As a Fedora community member and Fedora user this particular policy change does not directly nor does it indirectly impact me, so I don't have an authoritative voice in challenging the policy. The kernel in question is effectively dead to me. As a CentOS user it matters somewhat more, but I'm not yet sure how much more yet.

But what seldom works in coercing any business into changing its policy, is to suggest that you were thinking about being a customer and now you have been turned off because of a policy change. Even if its true, you haven't risked anything by saying it and you haven't guaranteed them any income if they revert the policy. Since you weren't a customer before the policy change there's no reasonable expectation that reverting the policy will in fact make you a new customer.

-jef

So true...

Posted Mar 1, 2011 6:47 UTC (Tue) by khim (subscriber, #9252) [Link]

Yup - that's exactly right. Business people are monitoring these things, you know. When such "stupid change" are introduced there are lots of talks about how "I will not support them because of X", but then adoption rate shows that very few people actually care.

When people really do care (think SONY's rootkit fiasco, for example) companies backpedal furiously. But I doubt it's the case here: people who are build the RHEL subscriptions and people who are hacking kernel in the same organizations are usually just totally different people so I doubt this change will affect adoption rate all that much.

Red Hat's "obfuscated" kernel source

Posted Mar 1, 2011 12:22 UTC (Tue) by lmb (subscriber, #39048) [Link]

Sad move.

SUSE uses a git tree internally too, and builds from the tarball (it speeds up the build considerably, relative to applying thousands of patches). However, the SUSE kernel git repository is mirrored publicly on gitorious.

Red Hat's "obfuscated" kernel source

Posted Mar 1, 2011 19:37 UTC (Tue) by kolyshkin (guest, #34342) [Link] (4 responses)

It's making a mountain out of a molehill. My guess is Red Hat is using one big tarball instead of a set of patches just because it's easier for them that way, not because they want others to stop modifying their kernels.

Red Hat's "obfuscated" kernel source

Posted Mar 1, 2011 21:15 UTC (Tue) by nix (subscriber, #2304) [Link]

If they were saying that they'd say that. They wouldn't direct all queries to a press contact who says 'no comment'. You don't do that unless you're doing something you think people will hate (people other than your own employees, who allegedly hate it too).

Red Hat's "obfuscated" kernel source

Posted Mar 2, 2011 2:31 UTC (Wed) by rriggs (guest, #11598) [Link] (2 responses)

Red Hat has been very clear with their customers for at least the last 6 months that something like this was going to happen because certain competitors were taking advantage of their openness, repackaging Red Hat's work as their own.

We were expecting something along these lines. It is unfortunate. But I don't know what I would do were I in Red Hat's shoes.

Red Hat's "obfuscated" kernel source

Posted Mar 2, 2011 14:10 UTC (Wed) by dskoll (subscriber, #1630) [Link] (1 responses)

Excuse me??? Isn't Red Hat's entire business built around taking advantage of the openness of thousands of Free Software developers and repackaging their work?

I'm not saying it's wrong of Red Hat to build a business around that. It clearly isn't; those thousands of Free Software authors have consented to allow this by licensing their works under the GPL. It's just a bit rich for Red Hat to complain that others are doing to its work exactly what Red Hat has been doing for 15+ years.

Red Hat's "obfuscated" kernel source

Posted Mar 3, 2011 0:32 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]

To give RH its due, it is also the largest contributor of code to many of the software packages found in every GNU/Linux distribution. Their work goes well beyond repackaging.

This "righteous indignation" would amuse me if it didn't sadden me.

Posted Mar 2, 2011 2:31 UTC (Wed) by linux.whiz (guest, #73256) [Link] (2 responses)

Red Hat spends, what, between $100 and $200 million a year improving F/OSS code. It contributes *everything* to the community via the Fedora Project. Red Hat has bought stacks of companies and then released once-proprietary code as F/OSS. Red Hat is the top commercial contributor to the kernel, glibc, X.org, GNOME, the list goes on and on. Red Hat gives more to the Linux community than any other commercial entity out there.

How do they do that? They hire the best and the brightest developers from the community, enabling them to work full time on Linux and related technologies. Then Red Hat charges a fair price for their work so they can pay those developers and support teams and documentation teams and so on.

That's completely reasonable - who doesn't want to be fairly compensated? But how is Red Hat rewarded? Oracle, CentOS and other respins take all their hard work but make sure Red Hat is not compensated. Where is all your righteous indignation when stuff that happens? Where is the hue and cry about the "Spirit of Free Software" there?

I don't recall anything in the Free Software manifesto saying "it's ok, when someone is asking to be fairly compensated, to take their work and make sure they don't get paid for it." I certainly don't imagine that was the goal. I know that it is within the *letter* of the law, but c'mon, we're talking about the *spirit* here, aren't we?

Please. Be honest, people. The vast majority of you are really saying "I'm pissed because I might not get my stuff for free anymore!!! WAAAAH!!!"

This "righteous indignation" would amuse me if it didn't sadden me.

Posted Mar 2, 2011 3:01 UTC (Wed) by foom (subscriber, #14868) [Link]

> The vast majority of you are really saying "I'm pissed because I might not get my stuff for free anymore!!! WAAAAH!!!"

No, not really. People can still get the stuff for free via CentOS no matter whether the patchset is broken out or not...all this move really seems to do is hurt collaboration with other distros on kernel maintenance.

This "righteous indignation" would amuse me if it didn't sadden me.

Posted Mar 3, 2011 22:36 UTC (Thu) by xilun (guest, #50638) [Link]

> Where is the hue and cry about the "Spirit of Free Software" there?

The spirit of free software is at a place you just demonstrated with your comment that you don't understand the begining of. The spirit of free software is the ability for anybody to help its neighbour without condition (with the precision that when a definition of "help" is needed, it's right to exclude the possibility to allow third parties to remove this ability for others, because the ability to harm others and/or refuse to help them would obviously not qualify for "help"), and you certainly are not in the spirit of free software when you voluntarily undermine / deteriorate the quality of what you provide to both your customer, upstream, and the linux community at large and when you ask your customers to chose between their freedom of helping themselves and third parties and other contractual relationship with RH (faced with such a choice, my hope is that as many as possible customers of RH will indeed chose to retain their ability to help others, so will terminate their relationship with a player gone rogue that tries to be harmful to the community by distributing their work in an deliberately obfuscated way in the displayed and recognised attempt to slow down customers and the community and make their work artificially more difficult). There are indeed lots of people who even think with good arguments that this RH move is indeed even against the _letter_ of the GPLv2 (on top of being obviously against the spirit of free software...)

Red Hat's "obfuscated" kernel source

Posted Mar 4, 2011 10:08 UTC (Fri) by psuresh (guest, #53229) [Link]

IMHO, shipping kernel source as one big tarball, without breaking out the patches is OK if it was patched against the upstream kernel.The issue is only the command used - patch or diff.But, there also some information is lost as to how they have landed upon the final patch via incremental patches. :(

OTH, if the future updates are restricted to paid subscribers only, it means non-subscribers have to resort to _other means_ for getting those patches and it is definitely against the principles and spirit of free software. :(

Red Hat's "obfuscated" kernel source

Posted Mar 5, 2011 0:33 UTC (Sat) by mgross (guest, #38112) [Link] (1 responses)

This is a good thing.

It will force more knock off distributions to align more closely with up stream as opposed to RH. There is too much waisted effort making yet another RH clone. We can do better things with our energies going into upstream projects than making RH knock-offs.

Red Hat's "obfuscated" kernel source

Posted Mar 6, 2011 22:30 UTC (Sun) by vonbrand (guest, #4458) [Link]

It is certainly not our call to make on what people "waste" their efforts... if somebody finds it useful, more power to the "wasters"; if not, it might just show bad judgement, in which case they'd better stay away ;-)

Red Hat's "obfuscated" kernel source

Posted Mar 6, 2011 9:31 UTC (Sun) by riteshsarraf (subscriber, #11138) [Link]

This is just competition. Trying to ensure your efforts pay you first.

The next round of actions would be to do one single, large, monolithic commit on the public git repository derived from finer commits off of a private git repository. This would still allow compliance with the GPL.

Red Hat's "obfuscated" kernel source

Posted Apr 4, 2011 20:43 UTC (Mon) by saucito (guest, #74064) [Link] (1 responses)

I wonder how this situation will impact RH-Oracle relation and if Oracle has any (future) intentions to put "stoppers" at their products supported on RH.

Red Hat's "obfuscated" kernel source

Posted Apr 7, 2011 4:58 UTC (Thu) by redbeard (guest, #74129) [Link]

you mean besides dropping support as of RHEL 6.1?