It's not so simple [LWN.net]

It's not so simple

Posted Feb 28, 2011 21:00 UTC (Mon) by jmorris42 (guest, #2203)
In reply to: It's not so simple by khim
Parent article: Red Hat's "obfuscated" kernel source

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

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

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

to post comments

It's not so simple

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

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

It's not so simple

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

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

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

It's not so simple

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

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

It's not so simple

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

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

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

It's not so simple

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

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

It's not so simple

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

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

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

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

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

It's not so simple

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

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

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

It's not so simple

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

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

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

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

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

It's not so simple

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

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

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

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

It's not so simple

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

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

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

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

It's not so simple

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

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

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

It's not so simple

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

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

It's not so simple

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

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

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

It's not so simple

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

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

It's not so simple

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

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

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

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

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

It's not so simple

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

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

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

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

It's not so simple

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

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

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

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

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

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

It's not so simple

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

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

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

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

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

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

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

It's not so simple

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

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

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

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

It's not so simple

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

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

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