Commitment to Open (Red Hat News)

[Posted March 4, 2011 by ris]

Red Hat CTO Brian Stevens responds to criticism of Red Hat's decision to ship its RHEL 6 kernel source as one big tarball. "Recently, Jonathan Corbet, respected kernel community member and editor at LWN, commented on our change in kernel RPM packaging. When we released RHEL 6 approximately four months ago, we changed the release of the kernel package to have all our patches pre-applied. Why did we make this change? To speak bluntly, the competitive landscape has changed. Our competitors in the Enterprise Linux market have changed their commercial approach from building and competing on their own customized Linux distributions, to one where they directly approach our customers offering to support RHEL. Frankly, our response is to compete."

to post comments

Commitment to Open (Red Hat News)

Posted Mar 4, 2011 20:34 UTC (Fri) by cmorgan (guest, #71980) [Link] (32 responses)

Sounds like a reasonable action for a business to take. It can be difficult for some people involved with oss to separate the oss interests from the business ones but as long as RedHat is contributing to the community, and they do quite a bit from what I've read, I support them.

Commitment to Community(?)

Posted Mar 5, 2011 4:10 UTC (Sat) by coriordan (guest, #7544) [Link] (31 responses)

> Sounds like a reasonable action for a business to take

Correct, if we were evaluating just another dog-eat-dog business.

I have a higher opinion of Red Hat. I think they're a friend. As a friend, I'm disappointed they're making life difficult for upstream and for distros such as Debian.

Commitment to Community(?)

Posted Mar 5, 2011 6:51 UTC (Sat) by asherringham (guest, #33251) [Link] (27 responses)

I have a very high opinion of Redhat as well. They're one of the most, maybe *the* most, important Linux/Opensource companies. It takes a lot of work to build a business like this and contribute so much to the community - contributions that other distributions like Debian and Ubuntu happily benefit from.

But in what way does this make it "difficult" for Debian or upstream (the kernel upstream I assume)?

Commitment to Community(?)

Posted Mar 5, 2011 12:26 UTC (Sat) by coriordan (guest, #7544) [Link] (26 responses)

> in what way does this make it "difficult" [...]?

When you get a kernel from Debian, Ubuntu, OpenSuSe, etc. you can see the original source plus a few hundred patches. Each patch addresses a single change, and does so by modifying one or more files. Fictional example: power_management.c, power.h, and core.c.

If you want to see how they changed something in the power_management.c code, you can see which patch modifies this code, and you will also see the modifications to power.h and core.c that were part of this change.

If there were two unrelated changes made in the power_mangement.c code, you'll see two patches and you can choose the one you're interested in.

This makes it easy to make the same change to your distro, or to push the change upstream. Until recently, all distros did this.

Under Red Hat's new system, all changes are lumped together into a single patch. Their single patch will modify 1,000 files. If you see something useful in their power_management.c code, you've no way to see which of the other 1,000 modifications are part of this change (in our example: power.h and core.c), and there's nothing to indicate if two changes to power_management.c are related or not.

Commitment to Community(?)

Posted Mar 5, 2011 14:46 UTC (Sat) by msnitzer (guest, #57232) [Link] (25 responses)

The key piece here is that Red Hat does follow an "upstream first" policy. Red Hat is the biggest corporate contributor to upstream Linux.

The upstream community, downstream distros, and Red Hat benefit from later versions of upstream Linux having the fixes Red Hat (and others) identified as necessary. The benefit comes in the form of a guarantee that the next time an upstream Linux kernel is selected as the starting point for RHEL++, Fedora++, SLES++, etc. the previously required fixes will all be in place (eliminating most concerns about regression: performance, feature, etc).

So it is in Red Hat's interest to continue its strong commitment to "upstream first". As a Red Hat kernel developer I can tell you that "upstream first" isn't just some mantra -- it governs my development workflow. If a change isn't accepted upstream it has an _extremely_ difficult time of getting into RHEL.

Commitment to Community(?)

Posted Mar 5, 2011 22:59 UTC (Sat) by coriordan (guest, #7544) [Link] (24 responses)

There's something of a contradiction in Red Hat's official response.

On one hand, Red Hat says that by discontinuing the itemization of kernel patches, they can put other distros at a disadvantage and thus "compete" against rivals, and on the other hand they say that since all the important stuff is "upstream first" they're not really being unfreindly to the community.

Which is it? Are they being obstructive other distros or not? The Debian Linux package maintainer says they are.

So, the two unanswered questions are:
* Is Red Hat saying that the Debian Linux package maintainer is wrong (or exaggerating, or being blown out of proportion by the media)?
* Has Red Hat found a way to impede nasty rivals without being obstructive to the general kernel community?

Commitment to Community(?)

Posted Mar 6, 2011 1:36 UTC (Sun) by jmalcolm (subscriber, #8876) [Link] (6 responses)

I do not see a contradiction at all.

They are trying to be unfriendly to distributions that do not exist primarily as part of the "community" but rather as satellites of the RHEL universe. Think "Unbreakable Linux".

If all the Red Hat changes go into the upstream first then everything that Red Hat does contributes to the common pool of software. You can see all the patches that Red Hat does to the Linux kernel for example by tracking the mainline kernel itself. A true "community" distribution will have no problems.

However, if what you are really trying to do is piggy-back on Red Hat by pretending that you have assembled a simliar product from the available Open Source technologies then you have a tougher time knowing exactly what you are offering your customers. If you are just trying to poach support revenue away from businesses running RHEL then you have some more work to do.

If we want to have companies that behave a well as Red Hat does overall we are going to have to be somewhat more understanding about what it will take for them to survive. Should life be hardest on those that try the hardest?

Commitment to Community(?)

Posted Mar 6, 2011 1:41 UTC (Sun) by jrn (subscriber, #64214) [Link] (5 responses)

> You can see all the patches that Red Hat does to the Linux kernel for example by tracking the mainline kernel itself. A true "community" distribution will have no problems.
>
> However, if what you are really trying to do is piggy-back on Red Hat by pretending that you have assembled a simliar product from the available Open Source technologies then you have a tougher time knowing exactly what you are offering your customers.

What this analysis misses is that various people are working to maintain v2.6.32 as a longterm release. I don't see how that is less of a "true community" endeavor than tracking mainline.

Commitment to Community(?)

Posted Mar 6, 2011 2:01 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link] (4 responses)

Vanilla 2.6.32 is pretty different from what is included in RHEL 6 in so many ways. Not a very relevant platform for coordination for Red Hat.

Commitment to Community(?)

Posted Mar 6, 2011 10:36 UTC (Sun) by makomk (guest, #51493) [Link] (3 responses)

Except that as someone pointed out earlier, the maintainer of the official 2.6.32 long-term release has said that Red Hat's refusal to publish broken-out patches for their kernel has made maintaining it as a long-term release harder for them. In fact, if you recall the original LWN article, the only reason we found out about this in the first place is because it was obstructing the 2.6.32-series maintainers!

Commitment to Community(?)

Posted Mar 6, 2011 10:56 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

The fact that Red Hat picked 2.6.32 as a base kernel to build on for EL 6 doesn't seem to part of any coordinated effort. It just happens to fall in the right timeline. In the case of EL6, we are talking about 7 to 10 years with increased divergence over a period of time considering the enterprise model of backporting fixes or in some cases rewriting or creating new patches because upstream has moved ahead in a different way.

The decision to maintain 2.6.32 series for a longer term is a independent one and while there is a small level of intersection between them at this point, that won't last. It is unfortunate, certainly that stable release process is not made easier now but the individual patches get pushed upstream anyway and the fixes end up in the Linus tree and the benefits shared.

Commitment to Community(?)

Posted Mar 7, 2011 23:40 UTC (Mon) by rahvin (guest, #16953) [Link] (1 responses)

Blame Oracle. No one wants to say it but they are the problem. Redhat never had a major issue with CentOS, but when Oracle showed up, copied RHEL, renamed it and tried to start poaching Redhat's clients that created the problem. Obviously Redhat has lost some clients do to this and is going to make Oracle spend some cash to simply copy them.

It's too bad some companies are only interested in the revenue and not supporting the community. I'd personally like to see this hurt Oracles revenue to the point that the entire project is killed. This is the result of a bad community member and it would be better if they just went away.

Commitment to Community(?)

Posted Mar 8, 2011 0:32 UTC (Tue) by jmalcolm (subscriber, #8876) [Link]

I think that Novell had a hand in it too but yes, Oracle seems quite happy to be the tragedy in the commons.

Commitment to Community(?)

Posted Mar 6, 2011 20:19 UTC (Sun) by ceplm (subscriber, #41334) [Link] (16 responses)

We are trying to make it difficult to *support* RHEL, not to develop Linux kernel. And BTW, I have just checked (that's regarding concerns about making life difficult for Debian & other free distros development). In folder with unpacked src.rpm for Fedora Rawhide kernel:

bradford:kernel $ ls *.patch *.diff |wc -l
69
bradford:kernel $

All this is just about the RHEL kernel, not the Fedora one, IIUC.

This is partly a communication problem

Posted Mar 6, 2011 23:59 UTC (Sun) by coriordan (guest, #7544) [Link] (11 responses)

> We are trying to make it difficult to *support* RHEL, not to develop Linux kernel.

No one's questioning that, AFAICT.

What the community is asking is: what's Red Hat's response to the complaints of kernel maintainers Maximilian Attems and Greg Kroah-Hartman?

No one's questioning Red Hat's motives, their contributions, or their right to impede the business of parasites. I'm not anti-Red Hat, and I don't think that posing the above question is an attack on Red Hat. It's just a valid question, but so far, there's no answer.

This is partly a communication problem

Posted Mar 7, 2011 0:36 UTC (Mon) by msnitzer (guest, #57232) [Link] (1 responses)

Have you seen this answer?

This is partly a communication problem

Posted Mar 8, 2011 14:29 UTC (Tue) by coriordan (guest, #7544) [Link]

Your post makes the points that:
* RH pushes stuff upstream
* Porting patches from RH's kernel to stable is inherently difficult

I think the kernel developers already know this. They didn't question or complain about either of these things, they complained about the new Big Kernel Patch.

A sample good answer from RH would be "Ok, in future we'll set up a phone call between the relevant person here and the stable kernel maintainer before each release".

I'm not trying to embarrass RH by asking this question. On the contrary, I see them often as the role model for free software participation. So when they do something which shouldn't be copied by others, I think the question is worth asking: can this problem be fixed?

If this story was about Oracle, I wouldn't bother hoping for a fix.

This is partly a communication problem

Posted Mar 7, 2011 3:49 UTC (Mon) by ricwheeler (subscriber, #4980) [Link] (8 responses)

RHEL6 is *not* 2.6.32 stable based and never has been.

If you are a developer with a distro based on a stable series, you have to do your homework. When another upstream developer flags a patch as stable material, you need to understand if that patch is applicable to your kernel. That patch might - or might not - apply. It might be totally irrelevant.

Should Red Hat developers backport their fixes for other developers' branches? Why just .32 stable which Oracle and SLES use? Why not backport to the embedded stable series as well?

This is partly a communication problem

Posted Mar 7, 2011 4:50 UTC (Mon) by foom (subscriber, #14868) [Link] (4 responses)

I think you're being disingenuous. RHEL6 is 2.6.32-based. So it seems reasonable for maintainers of other distros based on 2.6.32 (like Maximilian for Debian, or GregKH for upstream-stable) to want be able to check RedHat's kernel source for patches which might be applicable to their kernels as well.

RedHat of course doesn't need to themselves backport fixes to other people's kernels (including 2.6.32-stable)...now, ideally, they *would* also participate in upstream stable branch maintenance themselves for whatever kernel they've based on (everyone else seems to be doing so...), but, it's okay if they don't. However, it's *not fine* to intentionally make it difficult for others to do that work. That's incredibly lame.

I hadn't seen this link referenced here before, so, here it is for anyone else that missed it:
http://lwn.net/Articles/430600/

This is partly a communication problem

Posted Mar 7, 2011 11:27 UTC (Mon) by ricwheeler (subscriber, #4980) [Link] (3 responses)

Strange, as someone directly involved in developing RHEL6, I thought that I would know more about how we did than you did.

Here are the facts:

RHEL6 is based on Fedora which was our point of forking when it had a 2.6.32 based kernel. Note I did not say 2.6.32 stable.

After forking from mainline, we continued to work on tip of upstream actively during the alpha and beta phases on key subsystems.

Our developers would post to upstream tip, flag patches for stable and provide a backport to RHEL6.

Before RHEL6 went out the door, many subsystems in the kernel were 2.6.34 or 2.6.35 based. At this point, some subsystems are much closer to 2.6.37 (specifically things like file systems that we have a very large and active upstream developer pool).

This is a key misconception - RHEL6 is not a 32 stable series product and never has been.

This is partly a communication problem

Posted Mar 7, 2011 13:09 UTC (Mon) by foom (subscriber, #14868) [Link] (1 responses)

> Strange, as someone directly involved in developing RHEL6, I thought that I would know more about how we did than you did.

I'm sure you do. However, you might note that *I* did not say it was 2.6.32-stable based either, only that it was 2.6.32 based...

> Our developers would post to upstream tip, flag patches for stable and provide a backport to RHEL6.

So you're saying Maximilian didn't actually need to look at the RHEL6 source at all, because all of the bugfix patches RHEL6's kernel includes have already been flagged for backport to upstream stable branches? I get the impression that he wouldn't agree with that statement, but for myself, I have no information for or against.

If that is true, that would certainly make it *much* less of a problem that it's difficult for other people to do the work of checking out the patches.

This is partly a communication problem

Posted Mar 8, 2011 11:33 UTC (Tue) by pbonzini (subscriber, #60935) [Link]

> So you're saying Maximilian didn't actually need to look at the RHEL6
> source at all, because all of the bugfix patches RHEL6's kernel includes
> have already been flagged for backport to upstream stable branches?

Only he can answer, but my hypothesis is that

- he spelunked the RHEL6 changelog to distinguish: 1) features, 2) bugfixes which were in stable, 3) bugfixes which were not in stable because the original author forgot to CC stable@kernel.org.

- he focused on the third group here, which may have included patches from both RH and non-RH authors. RH is _not_ actively hiding their stuff from stable@kernel.org.

- he then used the summary of the patches in the changelog to identify upstream commits

- he backported those

Assuming he selected patches whose backports were relatively easy, no, he didn't need to look at the RHEL6 source at all.

To be fair, he would have probably benefited from the full commit messages; these are part of the patch files so they are also not included in RHEL6.

This is partly a communication problem

Posted Mar 8, 2011 1:42 UTC (Tue) by riel (subscriber, #3142) [Link]

Several subsystems in the RHEL 6 kernel have been upgraded to be close to 2.6.33, 2.6.34 or newer. Fixes to that code may simply not apply to the 2.6.32-stable codebase.

People who use 2.6.32-stable may need to do their own backports, since many of ours won't apply anyway.

This is partly a communication problem

Posted Mar 7, 2011 13:54 UTC (Mon) by lmb (subscriber, #39048) [Link] (2 responses)

Hi Ric, yes, well, there is a point to that. But it is also common for partners and customers to report "works with kernel XY", and now one of the parties has made it much more difficult for other maintainers to look up why - while the others still publish their broken out series.

While I personally wish the whole enterprise distribution approach would go away (and people would instead pay us for supporting them on latest upstream - hey, a boy can dream), I also know that there's a pretty good cooperation between the engineering teams. I hope that is not affected.

This is partly a communication problem

Posted Mar 7, 2011 14:31 UTC (Mon) by ricwheeler (subscriber, #4980) [Link] (1 responses)

I don't see any reason that work upstream is impacted by how we package patches against the RHEL6 tree.

In addition, I fully expect our kernel team to continue to help any one on any distro understand, debug, etc just like we always do.

This is partly a communication problem

Posted Mar 7, 2011 20:30 UTC (Mon) by dlang (guest, #313) [Link]

how long can the engineers on the kernel team continue to help others when management is explicitly trying to make it harder for those same others?

customers also have to support the product

Posted Mar 7, 2011 14:34 UTC (Mon) by mcoleman (guest, #70990) [Link] (3 responses)

I'm sympathetic to RedHat's plight, but I'll point out that as an admin, I *also* have to support the kernel. It appears that this makes it more difficult for me to do so, and thus would seem to make RHEL a less attractive option.

(I don't really have a dog in this, since I'm currently not using RHEL anyway, but obviously it's something to mention if someone asks whether we should start.)

customers also have to support the product

Posted Mar 8, 2011 0:40 UTC (Tue) by jmalcolm (subscriber, #8876) [Link] (2 responses)

I think that if you are a 'paying' admin that you do have access to this information. It is the 'public' SRPM that is all rolled-up into one.

customers also have to support the product

Posted Mar 8, 2011 0:53 UTC (Tue) by makomk (guest, #51493) [Link] (1 responses)

Yes, except that you're not allowed to tell anyone else what patches Red Hat have applied to the kernel they gave you. So for example, if you encountered a problem with part of the kernel and managed to convince one of the upstream maintainers of that part of the kernel to help you diagnose it, you wouldn't be allowed to tell him or her what changes Red Hat had made that may affect his or her code. That could be an issue.

Red Hat's new policy essentially makes it impossible for third parties to help RHEL customers with any kernel problems they encounter, should Red Hat fail to deal with them itself.

customers also have to support the product

Posted Mar 8, 2011 12:05 UTC (Tue) by anselm (subscriber, #2796) [Link]

Red Hat can't prevent you (or anybody) from running diff against a (small number of) file(s) from the vanilla vs. RHEL kernel sources (from the SRPM). This is infeasible for all of the kernel, but if a problem can be localised to an individual driver or other manageable subsystem, this may be all that is needed for a third party to figure out what changes Red Hat has made to that particular part of the kernel.

Commitment to Community(?)

Posted Mar 5, 2011 19:35 UTC (Sat) by acme (subscriber, #2443) [Link]

We're upstream. We do it first upstream. Company policy. Want the breakdown patches? Look upstream. Something left? Work in progress.

Commitment to Community(?)

Posted Mar 6, 2011 12:30 UTC (Sun) by vblum (guest, #1151) [Link]

Hm, let's hope RH does not get eaten by the dogs. This move does not seem to be aimed at Debian.

Since I have no stake in the thing ... Caldera (back when they were "good") were heavily criticized for their attempt to license "per seat." A short time later RH did something very similar with RHEL and didn't create the same terrible reactions ... but some worries. Turns out those concerns were unfounded. The Enterprise distributions have greatly enhanced Linux' credibility in the wider world.

If this move reminds the rest of the world to work upstream a bit more, rather than waiting for RH to do the work, not bad.

Commitment to Community(?)

Posted Mar 7, 2011 1:52 UTC (Mon) by hofhansl (guest, #21652) [Link]

> I think they're a friend.

Me too, and like any friend I like them to stay around.
There are other distributions just copying RHEL, changing the name and few other things and then selling support for it. RedHat does the work and does not see a dime.

Also remember that this is RedHat *Enterprise* Linux. RedHat also produces a free distribution: Fedora.

Commitment to Open (Red Hat News)

Posted Mar 4, 2011 20:37 UTC (Fri) by jhubbard (guest, #5513) [Link] (9 responses)

He'd have been better off saying no comment. There wasn't much of anything in there that wasn't just a sound bite for a press release. Perhaps it's time to take seriously the idea of a meta distribution based on something like Puppet alluded to in a previous article.

I understand that Oracle has basically shown (not just recently but in the past as well) that they're a bunch of douche bags. Do you really want to to resort to being one yourself?

Sorry if the language is offensive, but...

Commitment to Open (Red Hat News)

Posted Mar 4, 2011 20:58 UTC (Fri) by drag (guest, #31333) [Link] (8 responses)

My understanding is that Redhat itself does quite a bit of development on code that ends up in Linus' kernel tree. They don't seem to be to afraid of implementing features their first that end up in their 'Enterprise kernels'.

Is that so horrible, is that so small, that you must slander them?

What Redhat did here is just kinda stupid and really isn't going to hinder Oracle in any substantive manner. In fact it just validates what Oracle has been saying all along about Redhat's business model. It's counter productive and may actaully give investors pause. The CTO/CEO or whoever is responsible really has not thought it out very well and He/They just need(s) to remember to trust his engineers. They have the best interests in company at heart.

Commitment to Open (Red Hat News)

Posted Mar 4, 2011 21:13 UTC (Fri) by sgros (guest, #36440) [Link] (2 responses)

I don't understand your comment about trusting engineers?

Engineers that RedHat has are probably the best. The problem (sort to speak) is that their job is to think about engineering problems, and they we'll indeed do everything to make what they do the best. But sometimes, doing best isn't also the best (or at least is too risky) for the survival of the company which, IMHO, requires another type of thinking... the one that has more to do with strategic decisions and includes more than just engineering stuff.

And, in the end, every engineer will certainly find a job somewhere else. It would be completely different story if the faith of employees would be bound to the faith of the company.

Commitment to Open (Red Hat News)

Posted Mar 4, 2011 23:24 UTC (Fri) by drag (guest, #31333) [Link] (1 responses)

> I don't understand your comment about trusting engineers?

From the previous article comments it makes it seem that Redhat engineers are not happy about the developments. Redhat management should listen to them and understand why they are unhappy.

Commitment to Open (Red Hat News)

Posted Mar 8, 2011 11:53 UTC (Tue) by pbonzini (subscriber, #60935) [Link]

> From the previous article comments it makes it seem that
> Redhat engineers are not happy about the developments.

If you are thinking of this, consider that the sample is necessarily biased. Whoever gave those data was effectively leaking internal information; employees that are okay or neutral about the decision would think twice about that.

Commitment to Open (Red Hat News)

Posted Mar 4, 2011 21:34 UTC (Fri) by jhubbard (guest, #5513) [Link] (4 responses)

I don't believe that my comment reached the level of slander. Slander implies that I'm lying about them. I'm commenting on their behavior. Perhaps in UK and other places this might be considered slander. Libel laws in the US are a lot more relaxed. We can actually call people out on their behavior and not get sued for slander/libel.

There are probably a lot of people that would agree that that Larry Ellison is an arrogant douche bag. (I'm sure he's a hero to lots of others.) Oracle and the way it runs seems to exude his personality/style. As a result Oracle as a company seems to be a bunch of douche bags. I think that the exodus of engineers from Sun kind of proves the style of company.

Bob Sutton's book "The No Asshole Rule" discusses the fact that assholes in leadership can result in asshole poisoning. People become assholes because of the environment generated by their leaders.

RedHat is a leader in the commercial opensource world and they didn't get that way by just buying a company with lots of OpenSource projects. As a result they help to set the tone and are able to call people out on bad behavior. If they become douche bags it doesn't bode well that others won't become as bad if not worse.

Let me make clear that I'm not calling the engineers or the general workers at either company douche bags. Unfortunately they have a duty to do what their mgmt wants unless it violates the law.

Commitment to Open (Red Hat News)

Posted Mar 4, 2011 23:27 UTC (Fri) by drag (guest, #31333) [Link]

> I don't believe that my comment reached the level of slander. Slander implies that I'm lying about them. I'm commenting on their behavior. Perhaps in UK and other places this might be considered slander. Libel laws in the US are a lot more relaxed. We can actually call people out on their behavior and not get sued for slander/libel.

My statement was not dependent on your level of liability in different jurisdictions. I think comparing them to Oracle is unfair.

>Bob Sutton's book "The No Asshole Rule" discusses the fact that assholes in leadership can result in asshole poisoning. People become assholes because of the environment generated by their leaders.

Yes. If a company fails it is because of management. This is obvious.

Commitment to Open (Red Hat News)

Posted Mar 7, 2011 13:30 UTC (Mon) by michel (guest, #10186) [Link] (2 responses)

The business world is littered with corpses of great engineering companies. Capitalism has a way of doing that.

Commitment to Open (Red Hat News)

Posted Mar 7, 2011 14:49 UTC (Mon) by clugstj (subscriber, #4020) [Link] (1 responses)

Failure is a required feature of any system that is to actually succeed. It is the height of hubris to think that any individual/group has all the right answers.

Commitment to Open (Red Hat News)

Posted Mar 7, 2011 15:29 UTC (Mon) by michel (guest, #10186) [Link]

I agree with both of those statements. I do not understand how those statements relate to my comment though.

Commitment to Open (Red Hat News)

Posted Mar 4, 2011 20:56 UTC (Fri) by ESRI (guest, #52806) [Link] (14 responses)

Red Hat is still providing SRPM's for everything, including the kernel, correct? So this shouldn't affect CentOS and/or SL. In fact, Oracle should still be able to do their rebuild as well albeit making it tougher to selectively include the patches they're interested in for any customization efforts.

Red Hat is also still contributing their changes upstream, so the Linux Kernel community shouldn't be hurt either, correct?

I'm probably missing something -- but how does this hurt OSS?

Commitment to Open (Red Hat News)

Posted Mar 4, 2011 21:06 UTC (Fri) by foom (subscriber, #14868) [Link] (13 responses)

Hm. Didn't oracle make a big deal about having a kernel that was a completely new not based on RHEL's kernel? Does this change actually even affect Oracle at all?

Commitment to Open (Red Hat News)

Posted Mar 4, 2011 21:19 UTC (Fri) by ESRI (guest, #52806) [Link] (5 responses)

Hmm, yes they did. You'd think Oracle would have the resources to roll their own kernels.

Or maybe they used a Fedora kernel :)

They used vanialla kernel

Posted Mar 4, 2011 21:38 UTC (Fri) by khim (subscriber, #9252) [Link] (4 responses)

Actually they explained what they did. They are rolling out their own kernel, but use userspace from RHEL - and of course they cherry-picked few changes needed to do that. Essentially they want to fix the "Solaris problem" by piggybacking on RHEL: Solaris had great kernel but poor userspace so it was really painfull to use so Oracle think they can avoid this problem by concentrating on kernel and enterprise (where the money are) and leaving userspace (where the support costs are) to RedHat. RedHat does not want this. It basically says: no problem, roll out your own kernel, if you wish, but then, please, support your userspace too.

They used vanialla kernel

Posted Mar 4, 2011 21:51 UTC (Fri) by foom (subscriber, #14868) [Link] (1 responses)

> RedHat does not want this. It basically says: no problem, roll out your own kernel, if you wish, but then, please, support your userspace too.

But wait...RedHat is going to do that by making it hard for Oracle to steal RedHat's kernel changes? Which Oracle wasn't doing anyways...Errrrrrr, what?

PS: what's up with Oracle's kernel, anyways? Their git tree doesn't seem to have been updated in ages:
http://oss.oracle.com/git/?p=linux-2.6-unbreakable.git;a=...

They used vanialla kernel

Posted Mar 4, 2011 22:23 UTC (Fri) by jengelh (subscriber, #33263) [Link]

>PS: what's up with Oracle's kernel, anyways? Their git tree doesn't seem to have been updated in ages:

Are you surprised? Ever since the acquisition thing, everything has practically come to a halt. Last entry of onnv (below) is just about the same timeframe unbreakable.git stopped being updated.

changeset: 13149:b23a4dab3d50
tag: tip
date: Wed Aug 18 15:52:48 2010 -0600
summary: 6973228 Cannot download firmware 2.103.x.x on Emulex FCoE HBAs

They used vanialla kernel

Posted Mar 4, 2011 22:11 UTC (Fri) by quotemstr (subscriber, #45331) [Link] (1 responses)

So why not just buy Nexenta? If you're right, it's much closer to what they're trying to do.

They used vanialla kernel

Posted Mar 4, 2011 23:23 UTC (Fri) by ESRI (guest, #52806) [Link]

This is what we're doing. Costs for running NexentaStor (not Nexenta) on non-Oracle hardware are compareable to what Oracle charges now.

The risk is whether or not Nexenta and the Illumos folks have the resources to support development of drivers for newer hardware going forward... and whether or not they can count on Oracle doing Solaris source code dumps periodically to either re-base or cherry pick...

Commitment to Open (Red Hat News)

Posted Mar 4, 2011 21:21 UTC (Fri) by mrshiny (guest, #4266) [Link] (1 responses)

If Oracle is customizing the vanilla kernel, then this means they can't easily cherry-pick the patches they like from RedHat's kernel.

Commitment to Open (Red Hat News)

Posted Mar 5, 2011 16:13 UTC (Sat) by msnitzer (guest, #57232) [Link]

Sure, but even if Oracle didn't modify their 2.6.32-stable based uek kernel they'd have a hard time cherry-picking RHEL's kernel patches.

Oracle aside, various other distro kernels are based on 2.6.32-stable too. RHEL6's kernel is _not_ based on 2.6.32-stable. That said, RHEL6's kernel does contain many of the same upstream linux-2.6's "stable@kernel.org" fixes that feed into 2.6.32-stable.

But due to the various 2.6.3[45678] backports that the RHEL6.x kernel has seen the code has diverged considerably from 2.6.32-stable. This divergence is to the point that most fixes made to RHEL6's kernel are either irrelevant to or do not apply cleanly to 2.6.32-stable. The fixes would be more suitable to apply to 2.6.36-stable, 2.6.37-stable, etc. Red Hat kernel developers do mark appropriate upstream linux-2.6 fixes with: "Cc: stable@kernel.org".

So Red Hat's fixes really do flow back to "stable@kernel.org" kernels -- unfortunately (for Oracle, Novell, Ubuntu, Debian, etc) those changes are not overly useful to 2.6.32-stable based distribution kernels. NOTE: all "stable@kernel.org" kernels do not allow new features whereas the RHEL6's kernel does.

It would require quite some surgery to backport the RHEL6.x kernel changes to 2.6.32-stable (because the implicit requisite feature surgery is _not_ possible in a "stable@kernel.org" kernel). The challenge associated with trying to backport RHEL6's changes to 2.6.32-stable will only grow over time.

Oh, yeah, it does.

Posted Mar 4, 2011 21:27 UTC (Fri) by khim (subscriber, #9252) [Link] (4 responses)

Oracle selectively pulls changes needed to make RHEL programs happy, then add it's own patches and packages the result. Now they will have a dilemma: either use pure RHEL source (and forget about "latest and greatest" claims) or start actually making its own distro.

Oh, yeah, it does.

Posted Mar 4, 2011 21:58 UTC (Fri) by foom (subscriber, #14868) [Link] (3 responses)

I'm having a hard time imagining that there's very much from RHEL5's 2.6.18 kernel which is even applicable to Oracle's 2.6.32-based kernel.

But I guess RedHat is concerned that now that they're *also* using the 2.6.32 kernel, Oracle might stop bothering to maintain their own kernel from scratch and just use RHEL's with some extra patches on top, or something.

Oh, yeah, it does.

Posted Mar 4, 2011 23:31 UTC (Fri) by ESRI (guest, #52806) [Link] (1 responses)

My question is -- does this mean Oracle Unbreakable Linux is gaining traction? Or is this a preemptive move from RH?

I never understood why, from a customer perspective, I'd want to use OEL instead of the "real thing" (RHEL). Plus, as big as Oracle is, RH has the bigger mindshare and expertise as far as kernel hackers and engineers (at least devoted to Linux) -- not to say Oracle doesn't have some quality people, just not as many.

I never thought OEL would really take off or be a threat to RHEL ...

Oh, yeah, it does.

Posted Mar 7, 2011 13:40 UTC (Mon) by michel (guest, #10186) [Link]

You would think that, except that Oracle can simply declare their own kernel the only one 'tested and supported' for their database. As a customer of their database, why wouldn't I use it?

Having said all that, I have no clue how Oracle is going to continue to support their kernel once they've undermined RH enough. I'm sure not many of the RH engineers want to work for oracle (apparently not many of the Sun engineers did either...). I have this impression that for Larry Ellison it's all about winning, regardless of whether he's a winner of a wasteland, rather than a large participant in a vibrant ecosystem.

Oh, yeah, it does.

Posted Mar 4, 2011 23:34 UTC (Fri) by SEJeff (guest, #51588) [Link]

This entire discussion is about RHEL6, not RHEL5.

Commitment to Open ?

Posted Mar 4, 2011 21:04 UTC (Fri) by pixelpapst (guest, #55301) [Link] (21 responses)

> The itemization of kernel patches that correlate with articles in our knowledge base is no longer available to our competitors, but rather only to our customers [...]
And this is where things really will start to suck. Not only for those triaging and tracking bugs across distributions, but also for the developers supposed to actually fix them - no matter where they are employed.

I find it interesting that he starts out with explaining their "upstream first" policy, but doesn't follow up on it - so at least to this confused reader it stays unclear whether RH will still be following it in the future.

It will be interesting to see how far Red Hat management is willing to battle their way down this blind alley. Then again, the FLOSS community has seen other big players turn much more rogue, so I'm not that worried. :-)

Commitment to Open ?

Posted Mar 4, 2011 21:09 UTC (Fri) by cmorgan (guest, #71980) [Link] (20 responses)

Huh? If the push their changes upstream, which they most certainly have been doing for dozens or hundreds of patches, then why not hold back the secret combination of patches found in their kernels? You've already gotten many of the RH fixes from upstream!

Commitment to Open ?

Posted Mar 5, 2011 1:27 UTC (Sat) by pixelpapst (guest, #55301) [Link] (19 responses)

Well, _if_ they will still be pushing everything they're doing "upstream first", then you are right, I have no use for their "secret patch combination" and they can keep it secret. But in that case it makes even less sense to keep stuff secret in the first place, because anybody with a specific interest can almost trivially reconstruct their patch combination.

As others have commented, this whole policy will only inconvenience CentOS and SL lightly, and maybe Oracle a little bit more. I'm concerned it will be quite annoying for Fedora-only devs, though.

Overall I have the feeling this will mostly inconvenience legitimate uses of the RHEL kernel sources, while not really making life harder for the "illegitimate" users (as RH management defines them). I'm open to be proven wrong, though.

Commitment to Open ?

Posted Mar 5, 2011 2:46 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link] (18 responses)

"I'm concerned it will be quite annoying for Fedora-only devs, though"

Fedora does not pick patches from RHEL since RHEL kernel is much older usually and Fedora is following the latest upstream. When RHEL is used in Fedora infrastructure, there is no kernel patching involved.

"Overall I have the feeling this will mostly inconvenience legitimate uses of the RHEL kernel source"

Legitimate users as in customers have access to a source browser.

Commitment to Open ?

Posted Mar 5, 2011 11:07 UTC (Sat) by ballombe (subscriber, #9523) [Link] (15 responses)

Every person that download the GPL linux kernel SRPMS is a legitimate user of that kernel. They should receive the preferred form for making modification. That is the whole point of the license.

It is sad to see that Oracle is finally starting to destroy RedHat as a FOSS company. RedHat should not take the bait.

What RedHat is doing is a (admittedly very limited) form of vendor locking. I doubt this will end well since they cannot do anything about leaks (which they might not even know about).

Commitment to Open ?

Posted Mar 5, 2011 12:40 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link] (14 responses)

"Every person that download the GPL linux kernel SRPMS is a legitimate user of that kernel. They should receive the preferred form for making modification. That is the whole point of the license."

Maybe it is. Unless a copyright holder makes the claim in court that a single tarball doesn't satisfy the license terms, it makes no difference. Arm chair lawyering in LWN serves no real purpose.

Commitment to Open ?

Posted Mar 5, 2011 15:24 UTC (Sat) by ewan (guest, #5533) [Link] (9 responses)

Bearing in mind that this move seems to be aimed at Oracle, and Oracle have quite a few kernel devs of their own with an interest in the code that Red Hat ships, they certainly have the standing to take this to court if they wanted.

There is no good outcome for Red Hat here; either this move pisses off community people and doesn't inconvenience Oracle at all, or it does inconvenience Oracle and they sue.

Really, aside from anything else, can you imagine how embarrassing it would be for Red Hat to defend, or even lose, a GPL enforcement case to Oracle?

It'll be interesting indeed...

Posted Mar 5, 2011 16:01 UTC (Sat) by khim (subscriber, #9252) [Link] (4 responses)

There is no good outcome for Red Hat here; either this move pisses off community people and doesn't inconvenience Oracle at all, or it does inconvenience Oracle and they sue.

Wow. Interesting theory we have here. Now, why will they sue? RedHat have not invented this "monolythic-patch-for-everyone, VCS access to selected few" scheme. This distinction belongs to other well-known organization: FSF. For quite a few years GCC, Emacs and other FSF-sponsored programs were developed behind the closed doors and only releases were dumped on FTP. Essentially what the RedHat is doing. To argue that RedHat treats GPL improperly you must argue that FSF treated GPL improperly for years - and this is not so easy to do, believe me.

P.S. It's interesting to note that community was pissed off back then too - but they fixed it introducing EGCS fork which was accepted by everyone, no by using courts to sue FSF.

It'll be interesting indeed...

Posted Mar 6, 2011 15:08 UTC (Sun) by ballombe (subscriber, #9523) [Link] (3 responses)

FSF require copyright assignement, so nobody had standing to sue anyway.

It'll be interesting indeed...

Posted Mar 6, 2011 20:13 UTC (Sun) by salimma (subscriber, #34460) [Link] (2 responses)

That's a completely orthogonal issue. Copyright assignment only restricts the merging of contributions to the upstream tree, and has nothing to do with the form in which that tree is made available to outsiders.

It'll be interesting indeed...

Posted Mar 7, 2011 19:14 UTC (Mon) by vonbrand (subscriber, #4458) [Link] (1 responses)

No, it isn't. FSF requires copyright assignment before they accept your changes. Once you have assigned copyright to them, they can well do as they please with your changes, i.e., distributing them (or not) in whatever form they desire. Nobody has any legal standing to sue them over what they do with their own stuff.

Once somebody else gets, say, GCC, from the FSF, they are bound to honor GPL. Saying that FSF usually has distributed their packages only as monolithic tarballs is sort of a red hering. But others have followed suit, and FSF didn't say a word. So, in a sense they have set an example by their own actions and what they have allowed historically. And this could presumably be important in case some court considers ruling on what GPL's meaning of "preferred form for modification" really means.

Also don't forget that for the most part of its history Linux itself was distributed as tarball + monolithic patches as the only format available, and later (in the bitkeeper days) that was still the canonical format. This does weight a lot against the "git trees are the preferred form" arguments.

Actually they do...

Posted Mar 8, 2011 8:11 UTC (Tue) by khim (subscriber, #9252) [Link]

Nobody has any legal standing to sue them over what they do with their own stuff.

Actually they do. FSF's copyright assignment includes promises to the contributor, but yes, it's not GPL, it's separate assignment. It includes words like "machine-readable source code", but does not include words like "preferred form", so it's more relevant to spirit discussion and less relevant to legal discussion.

But others have followed suit, and FSF didn't say a word.

Actually they said lots of words about Cygnus (which had roughly similar policy to today's RedHat) - and most of them were bad. But again, they were about moral responsibility, etc - and not about legality...

Commitment to Open ?

Posted Mar 5, 2011 23:36 UTC (Sat) by jzb (editor, #7867) [Link] (3 responses)

"or it does inconvenience Oracle and they sue."

Er, on what grounds? RHAT is perhaps doing the bare minimum required by the GPL - but they are doing it.

What this does does not prevent Oracle from recompiling the kernel and running it, nor does it thwart studying the kernel, etc. It just means that they have to do detective work to figure out what's changed and where. Unless I'm mistaken about the GPL, there is no requirement whatsoever to provide any commentary on changes or break changes out as patches from the original source - only that you have to supply the changes, which they've done, but as part of the overall kernel.

I can't see Oracle having any cause to sue, even if they are (I hope) inconvenienced by this.

Commitment to Open ?

Posted Mar 6, 2011 0:42 UTC (Sun) by vonbrand (subscriber, #4458) [Link] (2 responses)

Sorry, no. GPL talks about passing source code if you distribute a changed version, not original source code, changes, and running commentary. So here Red Hat has historically done much more than was asked for (distributing to all comers, distributing upstream source and individual patches), now they are still doing more than strictly required. Again the ages old discussion: If you distribute your stuff under $LICENSE, you can't then complain if somebody does what said $LICENSE allows.

Commitment to Open ?

Posted Mar 6, 2011 2:08 UTC (Sun) by jzb (editor, #7867) [Link] (1 responses)

"If you distribute your stuff under $LICENSE, you can't then complain if somebody does what said $LICENSE allows."

You can complain, you just can't sue.

I compare this to the recent Supreme Court decision about the WBC - the "church" has the right to do what they do under the First Amendment. They should not be jailed for it, nor barred from it. That doesn't mean that the rest of the society/community can't or shouldn't shun them.

I'd much rather see companies kept in compliance with the spirit of the license by people complaining than by trying to write licenses that dictate every community standard.

Commitment to Open ?

Posted Mar 6, 2011 2:35 UTC (Sun) by DOT (subscriber, #58786) [Link]

You can sue, you just can't win. ;) I also don't think complaining is going to win a whole lot. Companies are used to complainers.

Commitment to Open ?

Posted Mar 6, 2011 11:07 UTC (Sun) by jch (guest, #51929) [Link] (3 responses)

> Unless a copyright holder makes the claim in court...

What has that to do with anything?

RedHat are clearly not distributing the "preferred form of the work for making modifications to it". They're therefore violating the spirit of the license.

The community ought to work with them to help them amend that mistake. This has nothing to do with the legal system.

--jch

Commitment to Open ?

Posted Mar 6, 2011 11:37 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

You claim a violation of "spirit". Some people claim it is a violation of the license. I was addressing the latter and not the former.

Commitment to Open ?

Posted Mar 6, 2011 13:05 UTC (Sun) by jch (guest, #51929) [Link] (1 responses)

Let me correct myself, then.

RedHat are clearly not distributing the "preferred form of the work for making modifications to it". By failing to do so, they are violating both the spirit and the letter of the GPL.

Whether or not anyone intends to sue them is irrelevant -- they should fix what many of us see as a serious mistake, lest they loose much of the community's goodwill they have earned over the years.

Better?

--jch

Commitment to Open ?

Posted Mar 6, 2011 14:19 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]

It expresses your opinion and belief better however a claim of license violation is a legal one and considering that Red Hat has a well qualified legal team that would have certainly reviewed the legal validity of such actions before Red Hat made them, I am inclined to trust their judgement instead of a layperson interpretation of it. In the case of a alleged infringement, whether or not one is willing to take it to court is certainly relevant and the absence of it, I consider such claims spurious ones.

I have no qualms about people arguing about the "spirit" of the license since that is open to interpretation and one doesn't need to be a copyright expert to do so.

Commitment to Open ?

Posted Mar 5, 2011 14:34 UTC (Sat) by jubal (subscriber, #67202) [Link] (1 responses)

It's nice to see you admitting that non-customers are illegitimate users; is it the official RedHat's attitude now?

Commitment to Open ?

Posted Mar 5, 2011 14:44 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]

Official Red Hat communication is via press releases. I was talking about a subset of users aka customers that Red Hat serves. Calling others illegitimate is a extreme interpretation of that and certainly not one I intended.

Commitment to Open (Red Hat News)

Posted Mar 4, 2011 21:31 UTC (Fri) by dlang (guest, #313) [Link] (2 responses)

while I don't have a problem with the act of shipping the one large patch, I am very disappointed to see the reasoning for this move.

They are saying that their business is not about the bits, but is instead about the knowledge of what the bits are and why they are that way.

This seems to be exactly the opposite of the ideals of FOSS software where you try to spread the knowledge as widely as possible.

I fully expect that this will make them more profitable in the short run, but in the long run I think it is going to be bad for everyone.

at the risk of using an analogy, they are moving away from the approach of 'make the pie bigger' to the approach of 'give me a bigger piece of the pie'

Commitment to Open (Red Hat News)

Posted Mar 4, 2011 23:10 UTC (Fri) by sciurus (guest, #58832) [Link]

How can a FOSS business be about the bits, when anyone can get them at no cost?

Commitment to Open (Red Hat News)

Posted Mar 5, 2011 22:17 UTC (Sat) by dsommers (subscriber, #55274) [Link]

"""
They are saying that their business is not about the bits, but is instead about the knowledge of what the bits are and why they are that way.

This seems to be exactly the opposite of the ideals of FOSS software where you try to spread the knowledge as widely as possible.
"""

This might be quite accurate, if you do not consider the 'upstream first' commitment.

As acme said earlier on in this thread, if it is not accepted upstream it is not easy at all to get things into RHEL. Get the patches upstream, and the process into RHEL goes smoother.

And that is all about the bits and spreading knowledge to the FOSS communities.

It's not about Oracle

Posted Mar 4, 2011 22:11 UTC (Fri) by wzzrd (guest, #12309) [Link] (9 responses)

...directly approach our customers offering to support RHEL

The way I read that, it's not about Oracle at all. It's about unnamed others (IT support shops operating at a national level?) contacting Red Hat's customers and offering direct support on RHEL itself, not a derivative.

This makes sense: Oracle is way too big to take on directly and has a more than enough bright people to support the kernel package, with or without separate patches. IT support shops providing support directly on RHEL eat away at Red Hat's main cash cow and - contrary to Larry's boys - the IT support shops might have a hard(er) time with the pre-patched tarball.

It's not about Oracle

Posted Mar 4, 2011 23:26 UTC (Fri) by msnitzer (guest, #57232) [Link]

Um no.. Oracle is approaching RHEL customers offering to support RHEL. I'll let others speculate on what Larry (and his "boys") are hoping to achieve.

It's not about Oracle

Posted Mar 5, 2011 1:33 UTC (Sat) by marrusl (guest, #67123) [Link] (4 responses)

Novell also sells support contracts for RHEL.

It's not about Oracle

Posted Mar 5, 2011 14:28 UTC (Sat) by erwbgy (subscriber, #4104) [Link] (3 responses)

Correct. The supplier that the company I work for uses Novell because they are cheaper than Red Hat. From my side I haven't be too impressed with the results though.

It's not about Oracle

Posted Mar 6, 2011 0:30 UTC (Sun) by csamuel (✭ supporter ✭, #2624) [Link] (2 responses)

Heh, as someone who has had bug reports in on the RHEL kernel with RH I wouldn't bet they would do much better. Would be nice if they considered packets being delivered on the wrong 10GigE interface something they should fix sooner rather than when 5.7 (eventually) comes out (reported prior to 5.6 release, but apparently too late to be considered)..

It's not about Oracle

Posted Mar 6, 2011 4:56 UTC (Sun) by airlied (subscriber, #9104) [Link] (1 responses)

did you ask support for a hotfix or Z stream fix?

It's not about Oracle

Posted Mar 6, 2011 7:18 UTC (Sun) by csamuel (✭ supporter ✭, #2624) [Link]

We are lucky enough to be able to work around the bug by bonding the interfaces together, tagging them and then passing both VLAN's down both interfaces so it no longer matters which interface packets are delivered on (plus we get some redundancy into the bargain). Others might not be so fortunate (and I've found at least one bugzilla entry [1] that indicates that a large US HPC lab has stumbled across the same issue that "upsets" their Lustre filesystem).

On the other hand our support contact at Red Hat seems to have trouble getting any info out of the RH kernel folks. We've determined ourselves that the fix is a newer version of the Mellanox driver and fed that back to them and I suspect that's what they are planning for RHEL 5.7. I hope.

[1] - https://bugzilla.redhat.com/show_bug.cgi?id=545530

It's not about Oracle

Posted Mar 5, 2011 17:25 UTC (Sat) by sciurus (guest, #58832) [Link] (1 responses)

I'm pretty sure that is a dig at Oracle. Another company can't offer "direct" support on RHEL, since you can't access Red Hat's yum repositories without paying.

$ sudo yum check-update
Loaded plugins: rhnplugin
There was an error communicating with RHN.
RHN support will be disabled.

Error Message:
Service not enabled for system profile: "example.com"
Error Class Code: 31
Error Class Info:
This system does not have a valid entitlement for Red Hat Network.
Please visit https://rhn.redhat.com/rhn/systems/SystemEntitlements.do
or login at https://rhn.redhat.com, and from the "Your RHN" tab,
select "Subscription Management" to enable RHN service for this system.

However, they can rebuild Red Hat from the source RPMs and sell support for it. Even better, they can disable some features of other software they produce (e.g. database smart flash cache, see http://download.oracle.com/docs/cd/E11882_01/server.112/e...) unless it's running on their derivative.

It's not about Oracle

Posted Mar 9, 2011 0:21 UTC (Wed) by tmassey (guest, #52228) [Link]

That Oracle link is potentially scary.

I've always thought the endgame for Oracle was to leverage the database support all the way down to OS and now hardware. Companies are already used to writing big checks to Oracle for database support: why not a little more and let Oracle own the stack? You might even get a better value. No finger-pointing: Oracle owns *everything*.

In fact, one of Oracle's biggest competitors is in the same position: IBM. With DB2 and AIX on POWER, IBM owns the whole stack, too. IBM leverages this.

If Oracle is now adding database features that specifically check kernel provenance, that's real ugly for shops using Oracle. How could you use anything *but* their kernel?

But what is Oracle's strategy if they succeed in killing Red Hat? Solaris?

It's not about Oracle

Posted Mar 6, 2011 16:14 UTC (Sun) by ballombe (subscriber, #9523) [Link]

They can just ask a future customer to make a local copy of the source browser before resigning their RedHat subscription.

Or they can just buy a single subscription from RedHat to get access to the source browser.

Commitment to Open (Red Hat News)

Posted Mar 4, 2011 22:14 UTC (Fri) by jonabbey (guest, #2736) [Link]

I respect Stevens for confirming the change they made and the real reason behind it. Red Hat making a change like this and refusing to admit to it I'd have more of a problem with.

Commitment to Open (Red Hat News)

Posted Mar 4, 2011 22:24 UTC (Fri) by Otus (subscriber, #67685) [Link] (4 responses)

I'm not going to take a moral stand on this matter, but I fear this decision isn't necessarily free of side effects. If developers for other distros (Oracle or e.g. Debian) can't look up bug fixes in Red Hat as easily, they'll have less time to actually be productive and fix unfixed bugs. That's work that would also have helped Red Hat and their customers.

If they are going to actively hinder their competitors, getting rid of "upstream first" would be just a difference of degree.

Commitment to Open (Red Hat News)

Posted Mar 4, 2011 23:35 UTC (Fri) by ESRI (guest, #52806) [Link]

I would think there won't be that much lost here. RH's developers will still be very active in upstream projects, participating in mailing lists and doing work publicly via Red Hat's own bugzilla (not to mention Fedora's development is extremely transparent).

I'd question that that was more how it worked before anyways rather then Debian and other developers picking through RH's SRPM files...

Commitment to Open (Red Hat News)

Posted Mar 5, 2011 0:05 UTC (Sat) by nix (subscriber, #2304) [Link] (1 responses)

Well, developers for other distros preferentially look up bugfixes in the upstream tree anyway. This does remove a large source of extra fixes that haven't got upstreamed yet, alas, but a lot of the devs working on that maintain their own git trees anyway, which are often a lot more useful than the RHEL kernel tree because they're not as ancient. (One would hope they haven't been banned from doing *that*.)

The only thing the RHEL tree is useful for is tracking people who want such a degree of stability that they're unwilling to upgrade their kernels for donkey's years. If it's only a matter of a year or two. a long-term-support -stable kernel will suffice. You only really want an RHEL tree if you want the backports and incredibly long lifecycle that RH provide...

Commitment to Open (Red Hat News)

Posted Mar 6, 2011 10:44 UTC (Sun) by makomk (guest, #51493) [Link]

Like, for example, the 2.6.32 long-term stable kernel whose maintainers are being inconvenienced by Red Hat's new refusal to publish information about their kernel patches?

Commitment to Open (Red Hat News)

Posted Mar 5, 2011 14:35 UTC (Sat) by erwbgy (subscriber, #4104) [Link]

RHEL uses such old kernel versions that I don't think this change will make much of a difference to most distributions other than those that are RHEL-based. For Centos it won't make any difference as they don't change the kernel package and I doubt Scientific Linux do either.

As long as Red Hat continue to work on the upstream kernel along with everyone else I don't see that this changes things for them or anyone else that matters.

Back in the days of the dinosaurs...

Posted Mar 5, 2011 0:48 UTC (Sat) by dskoll (subscriber, #1630) [Link]

... I went to a talk by Bob Young who was describing the Red Hat business model. He kept saying that Red Hat's strategy was to build a brand and use that as the selling point. He almost seemed to welcome the idea of competition, so certain was he that Red Hat's brand would give it the edge.

And he was right. Red Hat had (and still has) an incredible brand. It's sad to see the change in their strategy, though when you're up against Oracle, I guess it's difficult to stay true to Young's initial philosophy.

Commitment to Open (Red Hat News)

Posted Mar 5, 2011 4:35 UTC (Sat) by RogerOdle (guest, #60791) [Link] (1 responses)

How many distros out there are rebranded RHEL. Some of them offer little more than configuration support from a help desk and never contribute changes back. They have relied on RedHat forums for technical support.

At least with ScientificLinux, there is a narrowly defined purpose. It can focus attention on the applications that the select group of users need. They can contribute by improving the quality and usefulness of those applications.

But then what exacly is the CentOS business model?

As for Oracle, I don't remember ever seeing a patch report on the Linux kernel credited to Oracle. If they have done anything then I do not know what it is.

Red Hat has a point in their reasoning. Technical support cost money. However, I see the risk of fragmenting increasing. At the moment, Suse is in a questionable state. The productization of Linux is now primarily driven by Red Hat (RHEL and Fedora), Ubuntu, and Google Android.

Commitment to Open (Red Hat News)

Posted Mar 5, 2011 5:34 UTC (Sat) by foom (subscriber, #14868) [Link]

> I don't remember ever seeing a patch report on the Linux kernel credited to Oracle

Oh come on! I have no particular love for Oracle either, but that's just a *completely* wrong accusation.

Just check back a couple days to the recent lwn.net article "Who wrote 2.6.38" -- Oracle shows up in the top 20 by changesets and lines changed!

Or maybe you wanted to only know about bugs reported by oracle, not code authored by them? Okay, go run

git log --grep="Reported-by.*oracle"

in your kernel tree for a start...

Commitment to Open (Red Hat News)

Posted Mar 5, 2011 10:56 UTC (Sat) by lmb (subscriber, #39048) [Link] (13 responses)

What about the "preferred form for modification" clause in the GPL? Is that available to customers, since I'd assume the source code browser doesn't quite match that definition, does it?

If so, it'd take only one leak, which seems a pretty weak form of protection.

I can totally understand competing on the enterprise distribution market (despite my belief that the whole concept is terribly flawed and debilitated, it rolls in good money), but I'd have thought the competition ought to be on the services & consulting side more than on the code.

Commitment to Open (Red Hat News)

Posted Mar 5, 2011 12:06 UTC (Sat) by chithanh (guest, #52801) [Link] (11 responses)

I don't see how GPL requires access to more than the source code. After all, GPL-2 exists since 1991, and OpenBSD which pioneered anonymous CVS was not started until 1995. Prior to that, releasing code as one big tarball was the norm.

Commitment to Open (Red Hat News)

Posted Mar 5, 2011 15:28 UTC (Sat) by ewan (guest, #5533) [Link] (10 responses)

The GPL requires the 'preferred form', and that may change over time. Unless you can make a case that the 'one big patch' is preferable to the 'lots of small patches' form, then it is simply not the preferred form.

The GPL doesn't require a form that is 'good enough' or 'workable'; it requires whatever is preferred.

Preferred form

Posted Mar 5, 2011 15:46 UTC (Sat) by corbet (editor, #1) [Link] (9 responses)

I always interpreted "preferred form" to be the original source, rather than, say, object files or preprocessor output. The actual text is:

The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable.

The idea being that you can modify and rebuild the program. As nice as it might be, I think stretching "preferred form" to "the form that would be most convenient for you" goes beyond what the license is trying to say.

One could say that Red Hat's distribution violates this little provision:

You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.

That requirement has been mostly ignored for many years, though, and I'm not sure anybody really wants to bring it back now.

Preferred form

Posted Mar 5, 2011 17:14 UTC (Sat) by ewan (guest, #5533) [Link] (1 responses)

rather than, say, object files or preprocessor output

I think in practice it's usually a bit stronger than that; the 'preferred form' is the actual source, excluding machine generated files. That excludes preprocessor output, as you say, but also plain C code generated from other things, and, I think it's at least arguable, a big single patch that's been generated from something else.

The idea being that you can modify and rebuild the program.

Again, I think it's a bit stronger than that - you could, after all, rebuild something from pre-processor output too, it would just be hard work. It seems to me that it's generally taken to mean that you should have access to the same source as the person distributing the code - if they've written machine code directly with a hex editor, that's the source, if they've generated it from assember, then that's the source, and if it came from a big block of C, then that's the source. And if it came from a VCS, a big set of patches, and scripts to assemble the whole lot, then that is the source.

This is interesting idea, but...

Posted Mar 5, 2011 20:39 UTC (Sat) by khim (subscriber, #9252) [Link]

as I've already noted before Oracle (or anyone else) will have any hope to prevail in court they should answer one simple question: 20 years ago it was perfectly Ok to keep sources in private VCS and only present tarballs to the world (FSF did that, Cygnus did that, etc - it was normal M.O. back then). If, as you assert, times changed and now it's not Ok then you must explain what exactly happened between then and now to change the equation. VCS is not a new idea, you know: SCCS was released 38 years ago.

Preferred form

Posted Mar 5, 2011 17:56 UTC (Sat) by pboddie (guest, #50784) [Link] (2 responses)

I always interpreted "preferred form" to be the original source, rather than, say, object files or preprocessor output. [...] The idea being that you can modify and rebuild the program.

Yes, the intention is surely that you get precisely the source code for the code that is being run, not just a set of patches against some other archive that you have to track down.

After reading an LWN news item a few weeks ago, I ended up on a site which offered patches for a selection of packages to be obtained from their upstream locations for the software suite mentioned in the news item. Since some of the packages were LGPL- and GPL-licensed, I sent a question to the person responsible for licence compliance at the organisation concerned, noting that this links-plus-patches page probably wouldn't be good enough to comply with those licences, but also noting that this wouldn't matter unless the site in question were the primary means of giving the sources to those who had received binaries from that organisation. It turned out that the links-plus-patches page was merely for everybody else on the Internet, as I suspected.

So in fact, as myself and the representative of the organisation concerned agreed, offering separate patches is a convenience, but it probably isn't suitable as a means of complying with copyleft licences, as indeed the GPL FAQ notes.

Preferred form

Posted Mar 6, 2011 0:53 UTC (Sun) by vonbrand (subscriber, #4458) [Link] (1 responses)

That is quite different. An SRPM contains the upstream, unmodified source; (optionally) some patches against the above; a set of instructions on how to create and build the binaries from the preceding; and some ancilliary stuff. So there isn't any question of "distributing patches without original source". You might argue SRPMs fail the GPL because they don't give you the modified sources... ;-)

Preferred form

Posted Mar 7, 2011 17:07 UTC (Mon) by pboddie (guest, #50784) [Link]

I don't want to mention any names, but I wasn't talking about SRPMs exclusively, although this is obviously Red Hat's preferred mechanism for distribution. Nevertheless, you make a good point: Debian source packaging is done with upstream archives, patch archives, and some stuff which lets you combine them. I imagine that the GPL permits such distribution practices because all the different parts come from the same place and involve widely-available technologies for putting everything together.

Preferred form

Posted Mar 5, 2011 18:19 UTC (Sat) by ballombe (subscriber, #9523) [Link] (1 responses)

> One could say that Red Hat's distribution violates this little provision:

> You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.

I do not think this apply to patches, and as a consequence to the RedHat kernel and more generally SRPMS and Debian source packages: the point of this requirement is to prevent a modified version to pass for the original version, but source packages provide the unmodified source tarball (so no file is actually modified, so the requirement is void) and some patches (which in any case include the lists of files which are modified) and even a changelog that list changes with the date.

Preferred form

Posted Mar 5, 2011 18:33 UTC (Sat) by corbet (editor, #1) [Link]

The RHEL kernel SRPM is not packaged that way - there is only the (modified) source tarball.

Preferred form

Posted Mar 6, 2011 4:40 UTC (Sun) by branden (guest, #7029) [Link] (1 responses)

"As nice as it might be, I think stretching "preferred form" to "the form that would be most convenient for you" goes beyond what the license is trying to say."

It's not about what's most convenient for *you*, the downstream guy. It's about what was the preferred form for modification *by the upstream provider who modified it*.

This shift in perspective is critical.

The whole philosophy of the GNU GPL is to create a community of users for works of software wherein all are co-equal (within the limits of individual aptitude, of course).

That the one-big-monolith kernel SRPMs are a modifiable form of the work is not the point. As you implied, object files and preprocessor output are perfectly modifiable as well, but are seldom the preferred form for modification under the GNU GPL. These monolithic-patch SRPMS are not, by all accounts, the preferred form of the work for modification by those developing and distributing them--Red Hat's kernel engineers.

Congratulations are in order, I suppose, to Red Hat's management, who look poised to pull off what Larry McVoy could not--lock up a significant chunk of Linux kernel development behind a paywall without ominous notes of caution from the preeminent journalist in the field.

Preferred form

Posted Mar 6, 2011 5:15 UTC (Sun) by corbet (editor, #1) [Link]

Remember that my first post on the subject included an expressed hope that this whole thing was an accident.

Those interested in my opinion on this move are likely to get their chance to read it. Until that happens, let me just say that "I believe it complies with the letter of the GPL" is not equivalent to saying "I believe this is a good thing."

Commitment to Open (Red Hat News)

Posted Mar 5, 2011 22:08 UTC (Sat) by sgros (guest, #36440) [Link]

Extrapolating this 'preferable form' and what's said about RedHat's kernel one could conclude that whoever forked any source has to always provide the source in the original form and all the modifications have to be distributed as patches.

What RedHat does in a way is a fork. It takes some kernel release and backports patches.

Also, I don't understand what's exactly the problem with this RH's decision?! It seems to me like there is lot of FUD, and in the end it'll turn that actually nothing special has happened.... It's completely other thing if this move will help RH accomplish the goal it wanted to achieve...

Bad sign to mix business and technical decisions

Posted Mar 6, 2011 7:30 UTC (Sun) by laroche (guest, #24463) [Link]

There was another note that Red Hat might not continue to
provide newer kernels via http://people.redhat.com/. This was done very
successful in the past to e.g. maintain the RHEL5 kernel and get a good
and stable collection of patches together. That alone sign that it is
best to buy support contracts from Red Hat.

As market leader Red Hat could in the past work on further technical
improvements to improve the customer base. If they now experiment on
how to put technical limits into their distribution to gain further
income or limit either Oracle or other competitors, then this is a very
bad sign or just a management hickup.

best regards,

Florian La Roche

Commitment to Open (Red Hat News)

Posted Mar 6, 2011 15:02 UTC (Sun) by anshulajain (guest, #70172) [Link]

I wonder what the reaction would've been, if Canonical had done this for their Lucid LTS release.

Commitment to Open (Red Hat News)

Posted Mar 6, 2011 15:13 UTC (Sun) by nhippi (subscriber, #34640) [Link]

"...where they directly approach our customers offering to support RHEL"

It is hard to imagine companies falling for that. If your business depends on your RHEL servers working perfectly, you really want to get the best support. Nobody else has even near the amount of developers working on all core Linux kernel/RHEL userspace features than what RedHat has. Anyone else as support provider, and it is completly upon your luck the "anyone else" has employed anyone who can actually fix your problem.

Saving $100 a month by switching imposer support, and you are just risking your business. RedHat can validly point that out instead of resorting to the "patch-flattening" trick they did.

OTOH if you don't really need support, why pay someone else either? Just go with Centos/fedora/debian/whatever and support yourself internally. Chances are that you can find fixes with google and git just as fast as the imposer-support can.

Commitment to Open (Red Hat News)

Posted Mar 6, 2011 23:22 UTC (Sun) by lieb (guest, #42749) [Link]

Having very recently worked for a company that was/is trying to evaluate a reasonable support strategy which included Novell, CentOS, and OEL, I can see what and why RHAT has done what they have done. It both makes sense and does not cause the sky to fall.

This does not affect either CentOS/SL or Fedora. CentOS makes it a point to only rebuild RH SRPMs to be *exactly* binary compatible. They do some patches but only on top of that base and rarely. I just checked the Fedora git and, in fact, things are better now that they have migrated fully to git. We even still get patches that are still swimming upstream.

We have to remember that this applies to these weird things called "enterprise kernels" and to little else. OEL offered a .32 kernel for RHEL5 for good reason. Soon, any new server will only have Intel's Sandybridge parts and backporting full support to a 2.6.18 (RHEL5) kernel would be a nightmare. RH is only offering limited support in RHEL5. The whole "stable" thing is a fig leaf over a basic conflict between an enterprise customer's wanting nothing to change *forever* while at the same time wanting to use the very lastest hardware and have access to *all* its cool features. In the end, this is a "you can't get there from here" and someday, the corporate CIOs (will|may) figure it out. In the meantime, it is hard slogging to keep maintaining ancient "stable" kernels. It makes much more sense to rebase (as OEL has done for 5) but CIOs want the fig leaf of a "stable" RHEL5 kernel (with it's 5000+ patches). BTW, GKH has ranted on this very topic from time to time. Why should RH enable the commercial support under-bidders who leach off them?

If your h/w refresh cycle is measured in small numbers of units over 3-5 years, this is all a non-problem. If you are a large enterprise and have *lots* of machines and the constant refresh cycle that implies, stay closer to mainline kernels and allocate the resources to do it. There ain't no free lunch even if it is GPL.

Reasoning behind the "preferred form" language in the GPL

Posted Mar 7, 2011 5:10 UTC (Mon) by tomcatsdb (guest, #73351) [Link] (16 responses)

There's something that was brought up once regarding those people saying RH is in violation of the GPL due to them not providing a public git tree, but it's buried pretty deep, and not fully explained in a historical context:

Nothing RH is doing here is violating either the spirit or the actual terms of the GPL.

RH provides the source tarball including required makefiles and configuration files for the source to build the binary as shipped. That's all that's required by the GPL.

The language in the license was added to prevent someone from shipping a printed version of the source or other forms of distributing the source that amount to useless for an end user. Sure it's the source all right, but not machine readable nor editable or usable to make a modified distribution from. The language of the license protects us, the end users, from these kinds of actions by distributors of GPL applications.

Remember that GPL (v2 and earlier) was crafted long before wide spread network access. If a user needs source, it has to be supplied in a form the user can access so they can make changes, recompile, etc. So a tape, or other machine-readable media would need to be supplied by the vendor, and it needs to be in a reasonable format. Wide spread network access makes this easy, as a vendor can put the source of the binary available for download as RH has done. The GPL is about protecting the four freedoms outlined by RMS / the FSF, nothing more, nothing less.

The lack of a public git tree or multiple patch sets may make some workflows difficult for people outside of RedHat's immediate area of concern, but it isn't a GPL violation. It may make some people in the community irked, but that's a completely different matter than anything the GPL addresses.

Reasoning behind the "preferred form" language in the GPL

Posted Mar 7, 2011 5:44 UTC (Mon) by dlang (guest, #313) [Link] (4 responses)

I agree that the lack of a git tree is not an issue.

I also agree that just releasing one modified tree instead of a series of patches is not an issue

where I have an issue is with them releasing source code to some people, but only under the condition that they don't share it with anyone else. yes, the source that's available as patches to customers is available in other forms (as part of the modified tree), but the very idea of giving source code to someone and having a limitation that restricts that person from distributing the source code is at least against the spirit of the GPL, and may very well be against the letter as well

Reasoning behind the "preferred form" language in the GPL

Posted Mar 7, 2011 5:50 UTC (Mon) by foom (subscriber, #14868) [Link] (2 responses)

> I also agree that just releasing one modified tree instead of a series of patches is not an issue

Well..I think really that *is* the main issue. That's what started this whole conversation after all.

It may not be illegal or "against the spirit of the GPL" to just release the modified source rather than a git repo or set of patches, but it's not very nice. The legality or spirit-of-gplness of releasing those broken out patches to customers only is actually kind of a distraction from that main issue...

Reasoning behind the "preferred form" language in the GPL

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

I disagree. i don't think there is any problem with having the SRPMs not take the time to apply patches when used.

I also think that going down the road of requiring access to version control repositories that are used internally is a very bad idea.

think about the case where the source is distributed along with the binaries instead of being available for download separately. is the supplier requried to include a complete version control repository? what if that repository is using proprietary software? you could get into the situation where the source is being provided in the manner that the devlopers prefer to work with it, but the resulting files are completely useless to anyone who isn't willing to spend the money (and agree to the terms of service) of some proprietary software package. and to make things even more interesting, what if that VCS system only runs on windows?

you can't have it both ways. either the GPL does not require access to the VCS (in which case releasing one big patch, or a modified tree is not a problem), or it does (in which case the problems above can apply)

Reasoning behind the "preferred form" language in the GPL

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

Well, I don't really believe the GPL requires it, but I still think it's quite poor for RH to do this. Just because something isn't litigable doesn't mean you have to like it.

I think it's a problem because other kernel developers are complaining about it making their life more difficult, and the reason for the change was indeed to make other people's life more difficult.

Reasoning behind the "preferred form" language in the GPL

Posted Mar 7, 2011 13:54 UTC (Mon) by tomcatsdb (guest, #73351) [Link]

I think the issues you raise are more on point here if we're going to discuss GPL things.

To be honest, I'm a bit on the fence myself here, but I think we're looking at it from the wrong angle, or at least we should consider what RH is doing with their terms. The areas of their terms of use you're mentioning here is basically "don't ape our service" language. Without it, someone could literally buy a single RHEL subscription, get the system updates, and mirror said updates for a charge to others w/o RH having any recourse against said organization.

Put another way, RH is saying that in order to continue to use their service (RHN updates + support), you can't compete with them by using their own work product. Technically, you're free to do with the code as you wish, but certain actions may result in you not having access to RH provided services in the future.

Does the GPL state that no matter what someone does with GPL based code, once a vendor ships it to an entity, the vendor is forced to continue a business relationship with the entity? Keep in mind the source for the GPL'd code is still available as SRPMS IIRC, so RH is still distributing source for anyone, including said entity, to download and compile for themselves. The entity just looses access to the value added services RH provides.

As I said, I'm a bit on the fence myself, but this is another perspective to consider,

Reasoning behind the "preferred form" language in the GPL

Posted Mar 7, 2011 8:28 UTC (Mon) by PaXTeam (guest, #24616) [Link] (10 responses)

> RH provides the source tarball including required makefiles and configuration files for the source to build the binary as shipped. That's all that's required by the GPL.

so are you saying that breaking up each translation unit into individual files of a single line then #include'ing them back would still satisfy the GPL? after all, that'd produce the same binary, be machine readable, etc. and according to you, it'd also be the preferred form for modification ;).

Reasoning behind the "preferred form" language in the GPL

Posted Mar 7, 2011 19:46 UTC (Mon) by vonbrand (subscriber, #4458) [Link] (3 responses)

Clearly not, as nobody in their sane mind writes C code as a set on one-line files to be #included. But GPL also isn't meant to force anyone to (re)distribute each and every dead end, fixed bug, rewrite, and failed experiment in the code's history either (thanks $DEITY!).

Reasoning behind the "preferred form" language in the GPL

Posted Mar 8, 2011 10:38 UTC (Tue) by PaXTeam (guest, #24616) [Link] (2 responses)

> Clearly not, as nobody in their sane mind writes C code as a set on one-line files to be #included.

what does a sane mind have to do with the GPL and its 'preferred form for modification' clause? as the creator of a derived work, i can pretty much do 'whatever' i want to the 'source code'. say, i can split up all the files into one-liners, or i can go the other way as well, it's all within my rights to change the 'source code' any way i want (obviously i can't remove the GPL itself or anything else the GPL says). what we're talking about here is the form this changed work has to be distributed in. you (well, tomcatsdb) said that original sources + patches were not mandated by the GPL because (in his reading) the only requirement of the GPL here is the ability to build the distributed binary. my example derived work satisfies that criterion. if it doesn't, then you'll have to change your reading of this GPL clause. so which is it? ;)

Reasoning behind the "preferred form" language in the GPL

Posted Mar 8, 2011 15:19 UTC (Tue) by vonbrand (subscriber, #4458) [Link] (1 responses)

If a bunch of #included oneliners is the preferred source form for you, you are wellcome to distribute that way. But you'll have to be able to prove the above when challenged...

Note that GPL asks for you to distribute full source, and mark any changes you did. If you distribute original source and patches, you are complying with GPL with respect to the original source. As you don't distribute any patched stuff, that is all you need to do. GPL allows to patch the original (via your patches or by hand), so anyone who gets the package from you is in the clear too.

Reasoning behind the "preferred form" language in the GPL

Posted Mar 8, 2011 16:34 UTC (Tue) by PaXTeam (guest, #24616) [Link]

> If a bunch of #included oneliners is the preferred source form for you,
> you are wellcome to distribute that way.

so are you saying that RH's (their software developers') preferred form for modification is a single monolithic tree with no track of changes? because we know it's not the case therefore according to your own criteria they'd be violating the GPL when they distribute the monolithic tree.

> If you distribute original source and patches, you are complying with
> GPL with respect to the original source.

this is what i thought too but RHEL6 doesn't have this in the srpm so if you think RH is in the clear when they're distributing a monolithic tree for RHEL6's kernel then so would i be with my one liners *regardless* of what form i use myself for development. so you see something doesn't compute here, you're basically contradicting yourself: you want me to justify my development method when i distribute one liners but you accept RH's monolithic tree even if that's not how they develop RHEL's kernel.

> As you don't distribute any patched stuff, that is all you need to do.

i lost you here. we're talking about someone (like RH) who took a GPL'd work and created a derivative ('patched' it) and distributed it in binary form and therefore has to provide the 'source code'. if the work is original and not derivative, there's nothing to talk about, the author does whatever he wants with his work.

> GPL allows to patch the original (via your patches or by hand),
> so anyone who gets the package from you is in the clear too.

i don't understand how this came up here, there is no question that you can patch a GPL licensed work (i.e., create derivatives of it) and there's no question that you can distribute the derivative work (per the GPL's conditions). what is in question is the *form* of the derivative work, in particular what the 'preferred form for modification' means. but you already established that it's the form that the author(s) of the derivative work themselves use, from which it follows that RH is in violation according to you as well.

Reasoning behind the "preferred form" language in the GPL

Posted Mar 7, 2011 23:32 UTC (Mon) by tomcatsdb (guest, #73351) [Link] (5 responses)

vonbrand pretty much stated the obvious here, but I'll go ahead and bite for a bit, and explain why you're off base in your hypothetical situation.

So, let's say someone did try to do this, how does the GPL protect us? Well, the only feasible way this could be done would be with an automated script.

In this case, someone went from human-readable code -> "meta-c" code (using automated script) -> C compiler -> binary. The "source" chain still starts at the original unmangled C files. You could also argue that the organization that did this would have to release their mangling script too, since it's part of the required build materials. In short, it'd blow up on them in a bad way.

Reasoning behind the "preferred form" language in the GPL

Posted Mar 8, 2011 10:59 UTC (Tue) by PaXTeam (guest, #24616) [Link] (4 responses)

> vonbrand pretty much stated the obvious here

no, he didn't, read my reply to him please ;).

> Well, the only feasible way this could be done would be with an automated script.

for my specific example yes, very likely, but i can imagine other transformations that i can pull off by hand and would still irk the casual programmer when looking at it. also, what if my transformations were done within an IDE? no scripts to distribute would exist then...

> In this case, someone went from human-readable code -> "meta-c" code (using automated script) -> C compiler -> binary

hold that right there. first, what exactly makes your "meta-c" code not human-readable (it's not 'meta', it's normal C btw)? second, the GPL has exactly zero mention of 'human', let alone 'human-readable'. where did that requirement come in?

> The "source" chain still starts at the original unmangled C files.

and? what does that have to do with the GPL's 'source code' distribution clause? not to mention that following your logic, RHEL6's source chain most likely started with some git tree (for the sake of discussion let's assume 2.6.32) and then it got mangled over time. yet we don't see the 'original unmangled C files' released. so as i said to vonbrand already, you either accept my proposed one-liner files or you don't accept RHEL6's current form of distribution. which is it? ;)

> You could also argue that the organization that did this would have to
> release their mangling script too, since it's part of the required build
> materials.

first, the mangling script wouldn't help you much if you only had its output (i.e., what you'd want is a reverse script but the GPL doesn't require you to even create it). second, the mangling script, for all you know, is *not* part of the build process (you don't know what i do in my own environment, i may or may not use the mangled form for modifications myself, much like you're saying that we shouldn't care what form RH developers use as long as the released 'source code' compiles), the mangled files are perfectly compilable.

> In short, it'd blow up on them in a bad way.

much like it did for RH, on that we agree ;).

Reasoning behind the "preferred form" language in the GPL

Posted Mar 9, 2011 23:59 UTC (Wed) by tomcatsdb (guest, #73351) [Link] (3 responses)

Related section from the GPL:

"The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable."

When someone checks out code from whatever revision control system they have, you end up with directories that have source files + project files for the IDE (if applicable), and other related files. You don't directly edit git, cvs, svn, or whatever, you work directly with source files in a directory structure. You modify those files. Even with something like clearcase's dynamic views, to the compiler and programmer, it's still a filesystem (source files + directories). A tarball of that file system contains the source code in the format (C / headers / makefiles, etc) that is used for making modifications and preparing derivative works.

"for my specific example yes, very likely, but i can imagine other transformations that i can pull off by hand and would still irk the casual programmer when looking at it. also, what if my transformations were done within an IDE? no scripts to distribute would exist then..."

Fine, if your coding style is such than ok, I have no problem if that's how you work internally. But be prepared to show that you're not obfuscating the code prior to releasing the source. So, if someone sues you for a GPL violation and during discovery it's shown through your revision control system that you work in a normal fashion then proceed to obfuscate the code then release source, you'll be in trouble. You went through a step to transform the source from it's preferred form for modifications to something useless for the recipient of your source. As far as the IDE goes, it'd be the same thing. One of two things happens in the IDE case:

1) The IDE writes screwy source files but presents them to the programmer in an understandable format (in which case a receiver of the source could just use the same IDE).

2) The IDE has an obfuscate function which translates the source away from anything understandable so its no longer the preferred form for making modifications, which is in direct violation of the GPL section quoted above.

By the way, since RH is _NOT_ obfuscating their source, you've created a strawman here.

The thing you're failing to address is that there is a difference between version control and the actual sources. git, svn, cvs, etc are _not_ source code. They are repositories _for_ source code. Let me turn this around and present you with an argument:

To justify _your_ position, you need to prove than I can't download a kernel release (in source tar ball format) and make modifications to that source. Keep in mind that this is the method kernel.org used for years prior to git. Were they violating the GPL? If not, then how can RH be in violation for doing the exact same thing?

"hold that right there. first, what exactly makes your "meta-c" code not human-readable"

Ok, so remember way back when C++ code was translated to C code then that code was compiled (there were quite a few compilers that did this)? You, being the programmer, started and worked on the normal C++ code. The machine took over after this point doing the translations to C and went on from there. I'm not going to pretend that I can understand that C code, and I surely can;t ship that and claim it's the "source" fo rthe program. Your example is similar in nature. There is a starting point in the process that a person edits and works with source files (C / C++ / IDL files, project settings, etc). Past that point is where the source code ends. That's the clear line in the sand. Sure the translated C is readable in one way (I can see the characters), but it's not readable in terms of comprehension and all but useless for modifying.

I realize full well it's still C code, but in your example, it went from a normal format that people can read and follow to a syntactically correct (for C), but incomprehensible format, thus my "meta" term.

"second, the GPL has exactly zero mention of 'human', let alone 'human-readable'. where did that requirement come in?"

That's exactly why the "preferred form of the work for making modifications to it" language in the GPL exists. To modify the code, you need to be able to read and understand it. Deliberately obfuscated code fails this requirement and is thus against the GPL. This requirement also protects against the application vendors sending downstream users printed hard-copies, screen captures of an IDE, or other methods of source distribution that can't be worked with for the purposes of modifying and preparing derivative works. The GPL was very well crafted in this regard.

"and? what does that have to do with the GPL's 'source code' distribution clause? not to mention that following your logic, RHEL6's source chain most likely started with some git tree (for the sake of discussion let's assume 2.6.32) and then it got mangled over time."

Wrong. RHEL6's kernel source started as exactly that: source code. It might have come out of a version control system, but it's _NOT_ the version control itself. Modifications to source files happen over time, versions get committed back to a control system, but the _source code_ that's being modified is still the C and associated files. You keep trying to tie the versioning system and source code together and that's where your logic fails.

"so as i said to vonbrand already, you either accept my proposed one-liner files or you don't accept RHEL6's current form of distribution. which is it? ;)"

Your logic is flawed for the reasons outlined above, so I can both reject your proposed one-liner files as being against the GPL and accept RH's current distribution as being GPL compliant.

"i may or may not use the mangled form for modifications myself, much like you're saying that we shouldn't care what form RH developers use as long as the released 'source code' compiles), the mangled files are perfectly compilable."

Wrong again. Version control != source code. The RHEL folks probably edit in emacs or vi... who knows, but they're modifying files (C, headers, makefiles, etc), not directly editing git. Once you appreciate the difference, you'll see that the hypothetical situation you're describing and what RH is doing is completely different. RH provides the tarball for their kernel just like a full source download from kernel.org. They aren't obfuscating the source or coming anywhere near that, which is what your hypothetical situation is all about. What RH _is_ doing is restricting access to the version control system. These are two different things, one of which is prohibited by the GPL, one of which is not. Show me anywhere in the GPL where revision control system is mentioned. At best, there is the language which says to illustrate the changes. Since, IIRC, there is a single large patch that is released along with the complete tarball for their kernel versions, RH meets this obligation as well.

Yes this is a PR nightmare, but no, it's not a GPL violation.

If someone wants to be angry over the policy change, then fine. But let's at least be reasonable about what there is to be angry over. Let's discuss real issues (effects on the community, transparency in the development process or whatever) rather than fabricating scenarios that just aren't there.

Reasoning behind the "preferred form" language in the GPL

Posted Mar 10, 2011 23:37 UTC (Thu) by PaXTeam (guest, #24616) [Link] (2 responses)

> A tarball of that file system contains the source code in the format
> (C / headers / makefiles, etc) that is used for making modifications and
> preparing derivative works.

this is where you are wrong. you consider *only one* kind of modification (one where you add your own original work to create a derived work, although in reality even in this case one prefers to see the history leading up to the work you're modifying, but let's not digress), whereas there are *other kinds* of modifications where said format is *not* the preferred form. think of simple things as reverting a specific change (you need to know what that change was, why it was done, etc), or fixing a bug introduced in a specific change (again, you need to know what change was, why it was done, etc) or extracting a specific change because you want to study it for whatever reason, or you want to port it to another kernel tree, etc (again, you need to know what the change was, etc).

> Fine, if your coding style is such than ok, I have no problem if that's how you work internally.

great, so you agree that whatever the author of the work uses is prime candidate for 'preferred form for modification'. then you must agree that what RH distributes in the RHEL6 sprm is *not* the preferred form since they're not sending such monolithic tarballs around when their own developers communicate with each other during development.

> You went through a step to transform the source from it's preferred form
> for modifications to something useless for the recipient of your source.

and now you're contradicting yourself. you have to make up your mind and decide *whose* preferred form is the one meant by the GPL. seemingly the author and the recipient of the derived work can have wildly contradicting ideas about what 'preferred' means and you've now argued both views so it's time to settle on one. so, does the author or the recipient dictate the 'preferred form for modification'? if it's the author then you can't call my one-liner (or whatever) transformation useless, since it's what i use. if it's the recipient then you can't call the RHEL6 srpm preferred as seemingly it doesn't satisfy many people. so which is it?

> By the way, since RH is _NOT_ obfuscating their source, you've created a strawman here.

they're obfuscating what i and many other people consider 'preferred form for modification'. you're still trying to cling to some 'common sense' definition of 'source code' whereas for good reasons the GPL gives a definition of it for its use in the license, you cannot arbitrarily reinterpret it. you must instead interpret 'preferred form for modification' and *everyone* agrees that the RHEL6 srpm is *not* the preferred form for modification, exactly because the details of their changes are completely lost. and whatever explanation you come up for this you'll also have to explain why the RHEL5 srpm has a different 'preferred form for modification' than RHEL6. after all you and they can't have it both ways.

> The thing you're failing to address is that there is a difference between version control and the actual sources.

i never once mentioned version control.

> To justify _your_ position, you need to prove than I can't download a
> kernel release (in source tar ball format) and make modifications to
> that source.

easy. please extract all the fixes for all the CVEs they have in RHEL6.

> Keep in mind that this is the method kernel.org used for years prior to
> git.

prior to git there was bitkeeper, and the patches sent to the mailing lists. but it's all irrelevant, see next.

> Were they violating the GPL? If not, then how can RH be in violation for doing the exact same thing?

you're mixing up the rights of the authors of the original work (Linus has the copyright on the collective work and individuals have copyrights on their respective contributions) vs. those of the derived work (RH's modifications to some state of the Linus tree). authors of the original work can pretty much do whatever they want, authors of the derived work are bound by the GPL.

> Wrong. RHEL6's kernel source started as exactly that: source code. It
> might have come out of a version control system, but it's _NOT_ the
> version control itself.

you make no sense here. what is the 'version control itself'? i never said anything related in fact, i said that the RHEL6 kernel started its life as some specific point in the Linus git tree (i recall it's 2.6.32, give or take). that specific point means a set of files/directories obviously. but *that* set of files/directories is *not* distributed in the RHEL6 sprm, only its mangled version, contrary to your own expectation.

> You, being the programmer, started and worked on the normal C++ code.
> The machine took over after this point doing the translations to C and
> went on from there. I'm not going to pretend that I can understand that
> C code, and I surely can;t ship that and claim it's the "source" for the
> program.

so if i can understand the cfront output then what? am i in the clear? since when does skill level enter the GPL? right, it does not.

> Your example is similar in nature. There is a starting point in the
> process that a person edits and works with source files (C / C++ / IDL
> files, project settings, etc). Past that point is where the source code
> ends. That's the clear line in the sand.

yeah, clear as mud. 'source code' is not defined that way in the GPL. it's defined as 'preferred form for modification'. there's *no* mention of anything like 'starting point', 'person edits X', 'works with source files' (did you just make it a recursive definition now?), etc. please stick to what the license says, not what you wish it said.

> Sure the translated C is readable in one way (I can see the characters),
> but it's not readable in terms of comprehension and all but useless for
> modifying.

not readable by whom? remember the choice above you have to make. *whose* preferred form are you arguing for here? it looks like again that you're trying to take the recipient's view as 'preferred form' but then RH is in trouble as the RHEL6 srpm is anything but the preferred form according to many people (also 'comprehension' and stuff is not part of the GPL, you just made it up).

> That's exactly why the "preferred form of the work for making
> modifications to it" language in the GPL exists.

that language does exist in the GPL indeed, 'human-readable' does *not*. your point being?

> To modify the code, you need to be able to read and understand it.

this is the crucial part. *whose* ability to read/understand 'source code' defines what the acceptable form is? it seems that you argued once for the author and many times for the recipients, so i take it the latter is what you're really trying to defend (but then RH is violation for the RHEL6 kernel, so you're in a bind here). but even if we accept this stand there's still trouble: *which* recipient? people have different skill levels, people have different agendas (one can deliberately keep complaining until *his* demands are met, etc), so what now? do we need to take a poll or something to decide what 'preferred' means?

> Deliberately obfuscated code fails this requirement and is thus against the GPL.

define obfuscation. make sure it doesn't require a world-wide poll to decide.

> This requirement also protects against the application vendors sending
> downstream users printed hard-copies, screen captures of an IDE, or
> other methods of source distribution that can't be worked with for the
> purposes of modifying and preparing derivative works. The GPL was very
> well crafted in this regard.

you're wrong, the paragraph about the 'source code' and its 'preferred form for modification' has nothing whatsoever to do with the medium for distribution. what does talk about this are 3.a and 3.b in that they mandate a machine-readable form, but that's not under discussion here as RH is in the clear, they do provide a machine-readable form.

> Your logic is flawed for the reasons outlined above, so I can both
> reject your proposed one-liner files as being against the GPL and accept
> RH's current distribution as being GPL compliant.

you have yet to give a single valid reason, so no, you haven't proved my statement wrong yet.

> Wrong again. Version control != source code.

i don't know where this strawman came from, i wasn't talking about version control at all.

> The RHEL folks probably edit in emacs or vi... who knows, but they're
> modifying files (C, headers, makefiles, etc), not directly editing git.

for derived works and distribution it's irrelevant what an individual does in his privacy. what matters is what happens when he *communicates* (well, distributes) his derived work. RH developers don't send around entire linux tarballs but mere patches instead when they do development, therefore that pretty much defines *their* preferred form for modification. now of course you still have to make up your mind whether the modus operandi of the authors of the derived work matters or not, but whatever way i look at it, patches are preferred by both authors and recipients.

> RH provides the tarball for their kernel just like a full source
> download from kernel.org.

RH distributes a derived work, kernel.org does not (well, speaking of the Linus tree). not to mention that kernel.org distributes not only a tarball but a git tree with full history of the kernel. what did you try to say here again?

> They aren't obfuscating the source or coming anywhere near that, which
> is what your hypothetical situation is all about.

they're obfuscating their changes in the derived work.

> What RH _is_ doing is restricting access to the version control system.

another strawman? i never once mentioned access to their internal version control system. as you noted, the GPL doesn't even mention such.

> Since, IIRC, there is a single large patch that is released along with
> the complete tarball for their kernel versions, RH meets this obligation
> as well.

then you should download the RHEL6 sprm and look at it yourself. there is no such thing as a 'single large patch' in it. according to you then they're in violation.

Reasoning behind the "preferred form" language in the GPL

Posted Mar 12, 2011 4:52 UTC (Sat) by tomcatsdb (guest, #73351) [Link] (1 responses)

"this is where you are wrong. you consider *only one* kind of modification (one where you add your own original work to create a derived work, although in reality even in this case one prefers to see the history leading up to the work you're modifying, but let's not digress), "

The act of adding a new file, removing a file, changing a line of code, regardless of the purpose, is a modification. Viewing extraneous information, historical or otherwise, is not modifying the source, hence it is out of scope of the GPL. The history is data about the work you're modifying, not the work itself. Note that when people distribute a compiled GPL application + source in tarball format on the same media, this has historically satisfied the conditions of the GPL. Your assertions would make every one of these distributions against the GPL. In addition, distributing the changesets or diffs from a previous version are not sufficient, however the complete source to the binaries as shipped is. From the GPL V2 FAQ (See: http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html)

---

Q: I want to distribute binaries, but distributing complete source is inconvenient. Is it ok if I give users the diffs from the standard version along with the binaries?

A: This is a well-meaning request, but this method of providing the source doesn't really do the job.

A user that wants the source a year from now may be unable to get the proper version from another site at that time. The standard distribution site may have a newer version, but the same diffs probably won't work with that version.

So you need to provide complete sources, not just diffs, with the binaries.

----

Other relevant quotes:

----

... No, you must supply the source code that corresponds to the binary. Corresponding source means the source from which users can rebuild the same binary.

... No matter how you distribute the source, the sources you provide must correspond exactly to the binaries. In particular, you must make sure they are for the same version of the programnot an older version and not a newer version.

---

Note that in all cases, historical data is not required, just the source to the binary as shipped. If you still wish to debate this point, pick it up with the FSF. They are the authoritative voice on what the GPL requires and their FAQ spells it out in exactly the terms I originally used.

Now then, this does lead back to the question of your test case of obfuscated code. Others have discussed this in various places (google "gpl obfuscated code"), and the answer most agreed on is what I stated: The purpose of the GPL is to allow recipients to distribute the application (plus source) in original and/or modified form. Going through a GPL work and obfuscating the source to make it useless to a recipient goes against the purpose of the license. The reason why I stated that it does matter how you code i simple: badly written code / poorly documented code is not against the GPL. So if you did work in that fashion, ie you aren't intentionally attempting to make the code unreadable to the recipient, you'd be in the clear. Automating a obfuscation step prior to the release is translating it from the preferred form for modifications to a bunch of files useless for the recipient aside from running make on. Thus your example is not GPL compliant.

The rest of your paragraph details the reasons why someone would want to modify a file, but this is irrelevant as far as GPL compliance goes. Again, you are attempting to combine the source code with the history of that code. These are two different things as supported by the wording of the GPL as well as the FSF's GPL FAQ. If you can find an authoritative source to support your position, feel free to post it here.

"great, so you agree that whatever the author of the work uses is prime candidate for 'preferred form for modification'. then you must agree that what RH distributes in the RHEL6 sprm is *not* the preferred form since they're not sending such monolithic tarballs around when their own developers communicate with each other during development"

... Really? Here you equate the internal method for a developer obtaining the source to the source itself. You keep doing these kinds of things and its still as wrong as it was the first time. Your example hypothetical situation deals with modifications to the source files themselves. It makes no mention of how those files are passed around internally. That is the difference between the real world situation of what RH is doing and your example. Internal communications have absolutely _NOTHING_ to do with GPL compliance.

"and now you're contradicting yourself. you have to make up your mind and decide *whose* preferred form is the one meant by the GPL."

No, I haven't. My position has been clear. It's supported by the FSF's FAQ. The only thing that I could not find with a few seconds of googling was the FSF providing an official position on obfuscated code. There is a difference between poor programming and willful, or in your case, automated obfuscation which I think would be relevant to a GPL violation lawsuit... Regardless, since RH is _NOT_ obfuscating the "source code" (as defined by the FSF), interesting as this side discussion is, it's irrelevant to the situation at hand. The rest of your paragraph builds on the false assertion that I've contradicted myself, fails to take into account the qualifications I've clearly made, and attempts to equate source code obfuscation to not shipping historical data.

"hey're obfuscating what i and many other people consider 'preferred form for modification'. you're still trying to cling to some 'common sense' definition of 'source code' whereas for good reasons the GPL gives a definition of it for its use in the license, you cannot arbitrarily reinterpret it."

I'm reinterpreting the GPL? Your idea of what "source code" constitutes goes far beyond anything the GPL states. But don't take my assertion for it, go back and read the FSF GPLv2 FAQ. Diffs are not sufficient for GPL compliance, but complete source for the binary is. "source code" is defined _explicitly_ as "not an older version and not a newer version" but the exact version used to make the executable. Historical development data is _NOT_ relevant to GPL compliance. Period. If it was, then CDs with just the binary and tarball of the source would be against the GPL. Those forms of distribution have been cleared by the FSF numerous times.

Yes people may be unhappy, as they no longer have a convenience provided by RH. Historically RH went well above and beyond what was required by the GPL. They're cutting that back. In either case, what matters here are the sources / scripts etc used to build the binary, which is what is defined by the GPL as the corresponding source code. Regardless of how the sources were packaged, the recipient got a source tree that they can make, and no, the files are not obfuscated. In the end, both RHEL5 and RHEL6 srpms provided a kernel source tree for the binary kernel RH shipped. If the RHEL 5 srpms had extra info, so be it. You keep trying to stretch the GPL to cover areas beyond the actual source code. That is the failure in your position. The RHEL5 srpms went beyond what the GPL requires, the RHEL6 srpms trimmed it back. Both are in compliance with the GPL.

"i never once mentioned version control."

But you keep saying RH needs to provide data that can only come out of a version control system.

"easy. please extract all the fixes for all the CVEs they have in RHEL6."

From the GPL v2 FAQ, previous or newer versions are not relevant to GPL compliance. Aside from that, you're asking for a specific modification that relates to historical data, on a binary that when built by you, was never distributed by RH. Hence they have absolutely zero obligation to support the request you're asking for. As an additional thing, you didn't address my point: Prove I can't open a C file from the kernel tree, change it, and build the resulting modified work. Prove I can't add a new module. Is it machine readable code that can be compiled? Why yes it is. Is it the complete source to the version as shipped by RH, well yes, it is. Do these conditions satisfy the GPL, according the the FSF FAQ, yes they do.

"you're mixing up the rights of the authors of the original work (Linus has the copyright on the collective work and individuals have copyrights on their respective contributions) vs. those of the derived work (RH's modifications to some state of the Linus tree). authors of the original work can pretty much do whatever they want, authors of the derived work are bound by the GPL."

Now this is an easy one. There is no magical divide here. Guess what: RH is in the same boat as any other contributor or distributor. Anyone who distributes a binary build of the kernel is bound by the GPL. This is the key component. RH is not under any obligation to provide sources for a binary they did not distribute.

RH plays the role of both contributor (the employees that RH pays to do the kernel work are making the contributions on behalf of RH) and distributor. The obligations for a distributor are to ship the source for the binary they distributed. RH does this. Now then, as a developer, RH internally builds, tests, and works on numerous bugs, but unless they distribute those binaries to an external entity, they are not bound by the GPL for those versions. They can expose that information or not, it's their choice, but not a GPL requirement.

"you make no sense here. what is the 'version control itself'? i never said anything related in fact,"

The version control system would be git, or bitkeeper, or whatever. The historical development data for a code base comes from a version control system. You keep saying stretching the definition of source code to include historical development data based on a completely twisted reading of the "preferred form" phrase in the GPL which contradicts the GPLv2 FAQ, as well as contradicting the simple fact that the GPL is triggered for a specific binary released. The development history behind the code is irrelevant to the terms of the GPL as explicitly stated by the FSF. Sure it's nice to have, but not required.

"that specific point means a set of files/directories obviously. but *that* set of files/directories is *not* distributed in the RHEL6 sprm, only its mangled version, contrary to your own expectation."

I never said RH had to distribute vanilla kernel sources, now did I. The only thing I stated regarding historical data, was that I think RH does provide a bulk "here's all the changes" patch, but I could be wrong on that point. Its a moot point though.

"so if i can understand the cfront output then what? am i in the clear? since when does skill level enter the GPL? right, it does not."

No, because that wasn't where you, being the programmer, made your changes. But you're illustrating my point. Obviously delivering the C code version of the C++ wouldn't satisfy the GPL. It's the same reasoning I'm using to justify why your (completely irrelevant to the situation RH is in) hypothetical code obfuscation example fails GPL compliance.

"yeah, clear as mud. 'source code' is not defined that way in the GPL. it's defined as 'preferred form for modification'. "

Omission of the next sentence in the GPL is your downfall: "For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable." By the way, the kernel is an executable, hence this clarification applies. Oddly enough, it's exactly what I've been saying. You can't selectively quote a single sentence out of the GPL and twist it all to heck to fit your personal agenda or worldview. You accuse me of reinterpreting the GPL when your own ideas about what a single sentence means goes against the FSF GPL FAQ and the very next sentence in the GPL itself.

"please stick to what the license says, not what you wish it said."

Please read more than one sentence of the license.

Your next paragraph is more of the same flawed logic. Read the license again as it applies to executables. Oh, thats right, it fits exactly what I said. You keep trying to wedge in a division between what the recipient of the code and the author expects based on your non-applicable hypothetical situation. No such division exists. People are crying foul about the RH policy change and trying to argue every possible negative against what RH is doing. I'm fine with that so long as those arguments are based on something real, not an imaginary GPL violation.

"you're wrong, the paragraph about the 'source code' and its 'preferred form for modification' has nothing whatsoever to do with the medium for distribution. what does talk about this are 3.a and 3.b in that they mandate a machine-readable form, but that's not under discussion here as RH is in the clear, they do provide a machine-readable form. "

So you're arguing a PNG screen cap is fine then? It's machine readable, but not the preferred form for modifications. People have tried to pull stunts like that in the past, hence the language in the GPL to prevent such nonsense. Aside from that, source code as defined for an executable is stated directly after the preferred form language, which, again supports what I've been saying.

"i don't know where this strawman came from, i wasn't talking about version control at all."

Because the data you are asking RH to provide comes out of their revision control system. The source code and its history are two different things. Your entire argument against RH boils down to a lack of that history.

The next few paragraphs equate internal distribution methods to making modifications on the source. But one thing you stated:

"or derived works and distribution it's irrelevant what an individual does in his privacy. "

I agree with this 100%. Guess what: RH developers are part of the same corporate entity. They can pass whatever they want around however they want around and it matters absolutely zero to RH's obligations under the GPL. See the GPL and the GPL FAQ for support of this.

"RH distributes a derived work, kernel.org does not (well, speaking of the Linus tree). not to mention that kernel.org distributes not only a tarball but a git tree with full history of the kernel. what did you try to say here again?"

This is wrong. Linus, kernel.org, or anyone really, is technically distributing a derived work from someone else at this stage, since the copyrights aren't assigned to a central entity. There is no central owner of the Linux source tree's copyrights.

"they're obfuscating their changes in the derived work."

No, they aren't. The C is as readable as the next bit of code in the kernel. You equate no internal revision history to source obfuscation which is yet another failure in your position.

I had read somewhere that they were doing monolithic patches, rather than individual patch sets. If it's the full source to the binary w/o patches in there, then according to the authoritative voice (FSF) RH is still fine. As I said, it was the only thing that may matter, and based on the clarifications provided by the FSF in their FAQ, seems to be a non-issue.

With this post, I'm bowing out of this topic. I think we're both fairly set in our positions on this one. While I don't agree with your logic, the debate did raise an important point that AFAIK isn't directly addressed in FLOSS licensing: obfuscated code in a Open Source project.

Reasoning behind the "preferred form" language in the GPL

Posted Mar 13, 2011 11:40 UTC (Sun) by PaXTeam (guest, #24616) [Link]

i think the crux of the matter is that when the GPL grants one the right to modify the distributed work, it doesn't say anything about what those modifications may be (as in, what kind of modifications the distributed 'source code' must allow). and clearly, there's a disconnect between what the RHEL6 srpm allows vs. what many people would like to be able to do as 'modification' (and what earlier RHEL kernel srpms allowed). so as you can read it in the followup post from Bradley Kuhn, the language of the GPLv2 is not what it should be, but that's too late now of course. that also means that my one-liner files would satisfy his 'tar x; make -C' criterion and therefore be compliant (and of course many other forms would also be compliant). sad or not, that's what we have to live with.

one last comment, as you seem to keep misreading the GPL: 'source code' != 'complete source code'. the sentence using the second term does *not* define 'source code', it defines 'complete source code' using the definition of 'source code' given in the previous sentence and i didn't mention it because it's irrevelant for the discussion: before we can talk about 'complete source code' we have to know what 'source code' is. apparently anything that compiles and a human can read in a normal text editor is good enough for 'source code'.

Commitment to Open (Red Hat News)

Posted Mar 7, 2011 10:56 UTC (Mon) by nim-nim (subscriber, #34454) [Link] (1 responses)

Red Hat has painstakingly built over the years a brand that basically meant "we do not play customer-hostile games" (and yes locking the customer in a support website like Oracle or SAP like to do is a customer-hostile game).

This brand meant RHEL sold well even though Red Hat salespeople (that were used to proprietary offerings) messed things up more often than less. Because the engineering departments rooted for Red Hat. Here we see those clueless salespeople winning a round and eroding this brand.

If Red Hat lowers itself to the level of vendors such as Oracle, I fear it will find out over time that on the "who sucks less" playing field others are better organised to win contracts (yay for "educational" conferences the other side of the world).

What an incredibly stupid waste of goodwill.

Commitment to Open (Red Hat News)

Posted Mar 7, 2011 20:27 UTC (Mon) by dlang (guest, #313) [Link]

one of the benifits of opensource software is supposed to be the lack of lock-in. If you don't like one vendor (for any reason, including support), you can just start paying someone else.

for RedHat to now take that attitude that you should not be able to buy support for RHEL from anyone other than RedHat does a great deal to undermine this benifit.

Commitment to Open (Red Hat News)

Posted Mar 7, 2011 13:33 UTC (Mon) by boniek (guest, #45061) [Link] (3 responses)

I thought the whole idea of GPL was so that no anyone could provide support to the same code - increased competition benefits customers. So seeing people calling Oracle parasites is not honest and goes against GPL spirit. If Red Hat wants to compete with Oracle it should do it on the grounds of better support not by using such, dare I say, underhanded tricks. It absolutely does not matter if Red Hat did all the work. If you don't agree with GPL and its effets maybe you should not use it to licence your code.

Welcome to Singularity :-)

Posted Mar 7, 2011 15:31 UTC (Mon) by khim (subscriber, #9252) [Link] (2 responses)

I thought the whole idea of GPL was so that no anyone could provide support to the same code.

Well, yes. The idea was that anyone can hack on the same code but author naturally will know it better then anyone and so can charge extra. But as we are moving closer and closer singularitywe find out that author does not keep the knowleadge in his head - it's delegated more and more to the computers (RedHat does not provide customers with just series of raw patches - there are bugs history, discussions, etc; all kept on RedHat's servers). The question about "how much of this precious and valuable knowleadge should be given to competitors?" is an interesting one. Certainly sources must be given for GPL requires that. But what about patch sequences? What about engineer's notes? The question is not as simple as it looks on first glance.

If you don't agree with GPL and its effets maybe you should not use it to licence your code.

But RedHat does agree with GPL. It provides all things GPL requests (source code used to compile binary) but if you want extra - there are price and conditions.

Welcome to Singularity :-)

Posted Mar 7, 2011 16:27 UTC (Mon) by lmb (subscriber, #39048) [Link] (1 responses)

But little of this is relevant for competitors. (SUSE at least maintains their own tree, anyway.)

The fact that a patch is present might be (saves the effort to identify the upstream commit for a relevant issue) - but that could be deduced by matching the (inter)diff of RHEL kernels against upstream commits with a heuristic matching algorithm. It is certainly not infeasible to do, should anyone's business really depend on it.

So I'm not quite sure what the real goal is, and I don't like the trend (because, you know, humans are herd animals and pick up on each other's ideas ;-), but I don't think it has much impact for anyone who really cares in practice. The message that it sends may or may not be desirable, though. (What, again, was the downfall of the old Unices?)

Well, it's always about $$

Posted Mar 8, 2011 8:01 UTC (Tue) by khim (subscriber, #9252) [Link]

The message that it sends may or may not be desirable, though. (What, again, was the downfall of the old Unices?)

They were expensive. Fragmentation didn't help, that's true, but Windows won because Intel systems were cheaper, not because they were better. And on Intel Windows was cheaper because "full-blown Unixes" needed more expensive PCs.

The fact that a patch is present might be (saves the effort to identify the upstream commit for a relevant issue) - but that could be deduced by matching the (inter)diff of RHEL kernels against upstream commits with a heuristic matching algorithm. It is certainly not infeasible to do, should anyone's business really depend on it.

You can easily identify large patches, but it's much harder to spot small patches which were created to accomodate 2.6.37 patches in 2.6.32. And this is exactly the patches which are interesting for support: they are less discussed and less tested then upstream patches, so they are more likely to contain bugs. They, too, can be identified, but it becomes closer and closer to "real" kernel work... Easier to ask customer to switch to some other kernel... but then RedHat can righfully point out that all problems are related to the switch and not to RHEL.

This is risky game: RedHat bet is that their kernel is better then what Oracle or Novell can offer for RHEL-compatible (==years old) distribution. This may be so, but I'm not sure Oracle and Novell can not do better. If they'll do RedHat's plan may backfire.

Commitment to Open (Red Hat News)

Posted Mar 7, 2011 14:57 UTC (Mon) by avr (guest, #27673) [Link] (1 responses)

It's likely Oracle is strategically salting the earth here. Normally it would be foolish to try and disrupt a business on which your own depends to some degree, but with their latest aquisition they now have two enterprise operating systems on offer. Judging by Oracle's corporate personality, it's not hard to see which one is going to become the red-hatted stepchild, and which one the much celebrated sun.

"Unbreakable" might become nothing more than a crowbar to pry customers from redhat folowing the formula, lure them in with lower prices, provide sub-par support and blame it on the uncontrolled nature of 'upstream', 'upgrade' to controlled Solaris.

If it sounds farfetched, consider that the most profitable thing for Oracle regarding their operating system or 'integrated stack' business would be for redhat to stop existing in their current form; not to replace the void with their own support and GNU/Linux offering, but to replace it with what would be marketed as a *real* in-house OS instead.

The bottom line:
Redhat is, as the expression goes, worth more dead than alive to Oracle since the aquisition of Solaris.

The insidious part here is that it's more effective to slowly sabotage from the inside.

It's not so simple, again...

Posted Mar 7, 2011 15:38 UTC (Mon) by khim (subscriber, #9252) [Link]

"Unbreakable" might become nothing more than a crowbar to pry customers from redhat folowing the formula, lure them in with lower prices, provide sub-par support and blame it on the uncontrolled nature of 'upstream', 'upgrade' to controlled Solaris.

Right. But Oracle found that it's not so easy to switch everyone to OEL so they inroduced intermediate step: they offer support for RHEL! And this is where RedHat wants to draw the line: if wants to make it perfectly clear that crappy Oracle support is problem of not 'uncontrolled nature of upstream' but the property of quite controlled upstream where only RedHat customers have access to the vital information needed to support RHEL. Thus people will know from the onset that Oracle's support is not equal to RedHat's support.

Will it work? Who knowx. But the situation where RedHat develops RHEL and then Oracle and Novel get the money for support is clearly not a viable long-term solution...

Commitment to Open (Red Hat News)

Posted Mar 7, 2011 15:13 UTC (Mon) by clugstj (subscriber, #4020) [Link] (1 responses)

The whole "GPL Violation" argument is just silly. The preferred format for making changes to the kernel code (actual new work, not just cherry-picking) is the full source. Who makes edits by creating patch files?

Commitment to Open (Red Hat News)

Posted Mar 7, 2011 20:33 UTC (Mon) by dlang (guest, #313) [Link]

I agree that there is no requirement to release patches.

however, if you _do_ release patches, I believe it is against the GPL to place additional restrictions on the distribution of those patches.

Commitment to Open (Red Hat News)

Posted Mar 7, 2011 15:23 UTC (Mon) by moffit (guest, #71153) [Link] (1 responses)

Seems to me RHEL is taking lots of steps backward in this release.

What about all these system-config-* GUIs that were removed, in favor of manual edits to the configuration files? http://bit.ly/haO7Mr

Commitment to Open (Red Hat News)

Posted Mar 7, 2011 19:50 UTC (Mon) by vonbrand (subscriber, #4458) [Link]

As a longtime Red Hat and now Fedora user I've used them rarely, if at all (and never for "servers"), so for me this is a non-issue.