Red Hat's "obfuscated" kernel source
One of the key points behind the RPM and Debian package formats is that
source is shipped in its upstream form, with patches shipped separately and
applied at build time. Red Hat has always followed this convention; the
failure to do so with the RHEL 6 kernel is a new and discouraging
change of behavior. Distribution in this form should satisfy the GPL, but
it makes life hard for anybody else wanting to see what has been done with
this kernel. Hopefully it is simply a mistake which will be
corrected soon.
(Log in to post comments)
Red Hat's "obfuscated" kernel source
Posted Feb 28, 2011 18:01 UTC (Mon) by BenHutchings (subscriber, #37955) [Link]
Red Hat's "obfuscated" kernel source
Posted Feb 28, 2011 18:04 UTC (Mon) by Rubberman (guest, #70320) [Link]
Red Hat's "obfuscated" kernel source
Posted Feb 28, 2011 18:08 UTC (Mon) by daney (guest, #24551) [Link]
Which points to a possible motivation for the change.
Red Hat's "obfuscated" kernel source
Posted Feb 28, 2011 18:17 UTC (Mon) by smoogen (subscriber, #97) [Link]
Red Hat's "obfuscated" kernel source
Posted Feb 28, 2011 19:08 UTC (Mon) by jebba (guest, #4439) [Link]
This has the makings of a short term mistake on Red Hat, Inc.'s part which is going to continually bite them for the next decade (think: old gcc patch, that *still* gets brought up)....
Red Hat's "obfuscated" kernel source
Posted Feb 28, 2011 21:37 UTC (Mon) by lolando (guest, #7139) [Link]
Red Hat's "obfuscated" kernel source
Posted Mar 1, 2011 4:40 UTC (Tue) by jmalcolm (subscriber, #8876) [Link]
Oracle might have to spend some money understanding what it is they are supporting in order to get those support contracts.
Red Hat's "obfuscated" kernel source
Posted Mar 9, 2017 18:15 UTC (Thu) by phred14 (guest, #60633) [Link]
Red Hat's "obfuscated" kernel source
Posted Mar 9, 2017 18:19 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
https://lwn.net/Articles/579551/
So they work together fine.
Red Hat's "obfuscated" kernel source
Posted Mar 1, 2011 4:37 UTC (Tue) by jmalcolm (subscriber, #8876) [Link]
Am I wrong?
Red Hat's "obfuscated" kernel source
Posted Feb 28, 2011 18:18 UTC (Mon) by jonabbey (guest, #2736) [Link]
Red Hat's "obfuscated" kernel source
Posted Feb 28, 2011 19:44 UTC (Mon) by riel (subscriber, #3142) [Link]
As a result, the number of kernel patches from one RHEL update to the next has grown from a few hundred large patches, to a few thousand tiny patches.
I suspect this trend will continue.
That is just not a practical amount to comb through, and it was getting to the point where applying the patches took almost as much time as compiling the kernel on some systems.
Red Hat's "obfuscated" kernel source
Posted Mar 1, 2011 2:02 UTC (Tue) by brouhaha (subscriber, #1698) [Link]
and it was getting to the point where applying the patches took almost as much time as compiling the kernel on some systems.So? Computers are also twice as fast as they were ten years ago.
I have a hard time believing that Red Hat's kernel developers can effectively manage kernel development WITHOUT keeping a set of patches against the stock kernel. It seems likely to me that they are just flattening it somewhere in the process downstream from where the actual maintenance occurs.
Red Hat's "obfuscated" kernel source
Posted Mar 1, 2011 4:47 UTC (Tue) by jzbiciak (guest, #5246) [Link]
So? Computers are also twice as fast as they were ten years ago.
I'm glad I don't buy computers where you buy computers.
Red Hat's "obfuscated" kernel source
Posted Mar 1, 2011 9:49 UTC (Tue) by dgm (subscriber, #49227) [Link]
Red Hat's "obfuscated" kernel source
Posted Mar 1, 2011 17:02 UTC (Tue) by jengelh (subscriber, #33263) [Link]
And yet you win nothing. Your double computing power is again eaten by double-optimizing compilers and a larger set of files to deal with.
(Remember the day when an operating system was just the 100-or-so files in C:\DOS.)
Red Hat's "obfuscated" kernel source
Posted Aug 8, 2012 19:22 UTC (Wed) by hummassa (guest, #307) [Link]
Twenty. There were roughly twenty files. DIR C:\DOS did not scroll, nor paused, nor "more"'d or "less"'ed. It just showed less then twenty files, and a little bit less than 120K bytes free space (in a 160k disk).
*sigh* the follies of youth...
Red Hat's "obfuscated" kernel source
Posted Aug 11, 2012 11:03 UTC (Sat) by Jonno (subscriber, #49613) [Link]
Red Hat's "obfuscated" kernel source
Posted Aug 11, 2012 17:24 UTC (Sat) by hummassa (guest, #307) [Link]
Red Hat's "obfuscated" kernel source
Posted Aug 11, 2012 21:50 UTC (Sat) by Jonno (subscriber, #49613) [Link]
msdos.sys, on the other hand, was auxiliary kernel functionality loaded by io.sys. The closest things in the Linux world would be loadable kernel modules in /lib/modules. In MS-DOS 7 (only sold bundled with the Windows 9x Desktop Environment) all code from msdos.sys has been merged into io.sys, and in FreeDOS the combination has been renamed kernel.sys.
config.sys was a text file parsed by msdos.sys (or io.sys in MS-DOS 7). Essentially it was the DOS equivalent of the Linux cmdline (on modern x86 systems usually specified in the Grub configuration file). It also allowed loading additional kernel modules and specifying parameters to them (eg replacing the modprobe utility). While not strictly required, still definitely part of the OS.
command.com was the entry point for userspace code. Not part of the kernel, but still part of the OS. In GNU/Linux terms it would be a merge of /sbin/init and /bin/sh as well as most of coreutils. While replaceable, replacing it would pretty much make a different OS with the same kernel (think Android vs GNU/Linux).
I didn't mention autoexec.bat, it was not part of the OS, but a way to autostart non-os stuff on your computer, essentially the DOS equivalent of /etc/rc.local.
Red Hat's "obfuscated" kernel source
Posted Feb 28, 2011 18:22 UTC (Mon) by clugstj (subscriber, #4020) [Link]
Red Hat's "obfuscated" kernel source
Posted Feb 28, 2011 23:33 UTC (Mon) by jerub (guest, #73225) [Link]
- It is not about Centos.
- The primary motivation was to make it harder for Oracle Enterprise Linux to repackage the work that Red Hat do.
- The kernel tarball inside the srpm is created from a git tree that is only accessible to Red Hat engineers.
- This change to the way that kernels are dealt with inside Red Hat has angered and frustrated engineers who work on the product. Employees of the company are Not Happy.
- The orders to do this, to make it harder to rebuild the kernel with and without patches, and to make it harder to extract specific patches from the Red Hat kernel came from the top. This is with the knowledge of, and by the order of, the CEO: Jim Whitehurst.
- There is a web interface (somewhere!) that is available that will allow you to specifically omit specific patches and download a new kernel. This is a clunky web front end to the git tree.
- An Oracle engineer I interviewed on this matter greeted this news with in-credulousness, and quickly got out his notebook so he could provide me with links to the various public git trees that oracle maintains of their kernels, and showed me where I could download them from.
Red Hat's "obfuscated" kernel source
Posted Mar 1, 2011 11:20 UTC (Tue) by nix (subscriber, #2304) [Link]
- There is a web interface (somewhere!) that is available that will allow you to specifically omit specific patches and download a new kernel. This is a clunky web front end to the git tree.Well, that makes the whole thing completely pointless, doesn't it? One bit of automation, a pile of rather slow downloading and bingo, the patches are split out again. Only effect: lots of extra bandwidth cost for RH.
Red Hat's "obfuscated" kernel source
Posted Mar 2, 2011 17:10 UTC (Wed) by jnh (subscriber, #69758) [Link]
> Linux to repackage the work that Red Hat do.
This makes me ache. For the past several years, I'd been fighting an
on-again-off-again argument with the lead DBA at my (mercifully former)
place of employment about OEL vs. RHEL. We'd run all our Oracle DB and
grid infrastructure systems on RHEL from day 1, and we used RHEL everywhere
we needed support contracts to back up proprietary software installations.
The sysadmins didn't want to add a distro migration to their TODO list,
particularly one with no obvious benefits to the other applications we ran
on RHEL. The DBAs argument was invariably "we probably wouldn't have
problem $foo if we ran OEL, and even if we did Oracle would owe us an
explanation becuase we have a support contract." (This is ignoring that
we obviously had a RHEL contract too, our DBA didn't like to leave his
little world of all-things-Oracle.) During the last argument of this
nature, which was centered around the kernel's swap behavior, I visisted
both Oracle and RedHat's archives, pulled down the kernel patches, and
compared them to see if there was *any* way the OEL kernel would behave
differently. At the time there was only one patch that was even close to
being relevant in the mm subsystem and there was no way it was going to
make a difference in the behavior we were trying to figure out. I used
that information to *quickly* shutdown the argument and bring the focus
off of switching to OEL and back to actually figuring out the root cause.
While I could have still made the comparison by grabbing the patches from
rhn (which I assume is where this web UI lives) it would have been an
inconvenience. Assuming that OEL really is the primary motivation behind
this, I'm embarrassed for RedHat. It's far easier to inconvenience your
customers than it is to inconvenience somebody like Oracle.
Red Hat's "obfuscated" kernel source
Posted Mar 3, 2011 0:05 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]
Red Hat's "obfuscated" kernel source
Posted Mar 5, 2011 16:15 UTC (Sat) by BenHutchings (subscriber, #37955) [Link]
Red Hat's "obfuscated" kernel source
Posted Aug 8, 2012 11:58 UTC (Wed) by xz (subscriber, #86176) [Link]
Red Hat's "obfuscated" kernel source
Posted Mar 5, 2011 16:18 UTC (Sat) by BenHutchings (subscriber, #37955) [Link]
Red Hat's "obfuscated" kernel source
Posted Mar 5, 2011 16:20 UTC (Sat) by BenHutchings (subscriber, #37955) [Link]
Red Hat's "obfuscated" kernel source
Posted Mar 5, 2011 16:36 UTC (Sat) by BenHutchings (subscriber, #37955) [Link]
Red Hat's "obfuscated" kernel source
Posted Aug 8, 2012 13:18 UTC (Wed) by nix (subscriber, #2304) [Link]
Red Hat's "obfuscated" kernel source
Posted Feb 28, 2011 18:31 UTC (Mon) by patrick_g (subscriber, #44470) [Link]
I contacted Matthew Garrett about this kernel issue and he said he can't comment. He gave me the advice to contact RH press people.I'm waiting for an official answer from Kerri Catallozzi.
I wrote a little text about this on linuxfr and one of the reader said he was a former RH employee and, according to him, this policy is deliberate. He said that a lot of RH devs are not happy with this new kernel policy. Patches are only visible for RH subscribers (through a web interface).
Red Hat's "obfuscated" kernel source
Posted Feb 28, 2011 19:16 UTC (Mon) by pkern (subscriber, #32883) [Link]
Patches are only visible for RH subscribers (through a web interface).
Especially annoying as this means that every RH subscriber can just leak them to the world, because they're obviously derivative works of a GPL'ed code base.
Red Hat's "obfuscated" kernel source
Posted Feb 28, 2011 19:22 UTC (Mon) by patrick_g (subscriber, #44470) [Link]
>>> this means that every RH subscriber can just leak them to the worldRead part 6 of this text : https://access.redhat.com/site/help/terms_conditions.html
Red Hat's "obfuscated" kernel source
Posted Feb 28, 2011 19:47 UTC (Mon) by azaghal (subscriber, #47042) [Link]
----%----
In the event of a conflict, inconsistency or difference between this Section 6 and the terms of a License or Customer Agreement, the License or Customer Agreement will control (for example, for Red Hat Content licensed under a Creative Commons License, you will have the rights set forth in the applicable Creative Commons License).
----%----
Even if the agreement didn't acknowledge it, GPL is _very_ precise on the fact that you cannot further limit the derivative work (from part 6 of GPLv2 license):
----%----
You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
----%----
It's not so simple
Posted Feb 28, 2011 20:51 UTC (Mon) by khim (subscriber, #9252) [Link]
RedHat can not restrict you, that's true, but they can (and probably would) refuse to support your RHEL installations and terminate access to subscriber-only area.
It's not so simple
Posted Feb 28, 2011 20:58 UTC (Mon) by dskoll (subscriber, #1630) [Link]
On what basis could they do that? If you've paid money and not violated the license, RH couldn't unilaterally decide to shut you off.
(Well, I suppose they could do whatever they wanted, but they'd be sued within an inch of their life if they tried, I suspect.)
It's not so simple
Posted Feb 28, 2011 21:24 UTC (Mon) by pzb (guest, #656) [Link]
Because support is not covered under the GPL, but under the Subscription Services appendix of the Red Hat Enterprise Agreement. It says:Distributing the Software or any portion of the Subscription Services to a third party or using any of the Subscription Services for the benefit of a third party is a material breach of the Agreement even though the open source license applicable to individual software packages may give you the right to distribute those packagesSo you breach the agreement if you distribute the packages. If you are in breach, they do not provide services (support or further updates) to you.
It's not so simple
Posted Feb 28, 2011 21:50 UTC (Mon) by jonabbey (guest, #2736) [Link]
It's not so simple
Posted Feb 28, 2011 23:16 UTC (Mon) by pzb (guest, #656) [Link]
No, the nasty bit is:Any unauthorized use of the Subscription Services is a material breach of the Agreement, such as (a) only purchasing or renewing Subscription Services based on some, but not all, of the total number of Units of Red Hat Software or other Red Hat Product that you deploy, install, use or execute [...] For the purposes of this paragraph (for example, in calculating the total number of Units of Software), Software would include versions or copies that have the Red Hat trademark(s) and/or logo file(s) removed.This would suggest that RHEL customers have to pay Red Hat for a subscription for each of their CentOS, Scientific Linux, etc systems in addition to their RHEL systems.
It's not so simple
Posted Mar 1, 2011 0:27 UTC (Tue) by ESRI (guest, #52806) [Link]
It's not so simple
Posted Mar 1, 2011 0:40 UTC (Tue) by jspaleta (subscriber, #50639) [Link]
Basically the idea is.. if you are going to install RHEL then the deal is you will be paying subscriptions for all the RHEL you run in-house. If you decide the subscription isn't a good value, then you can stop paying it and still run the RHEL system..but you have to stop paying it for _all_ the RHEL systems you have. You can't drop half your system...its all systems or none...no in-between. In for a penny, in for a pound.
I do not believe that the clause is intended to nor can be can be used to enforce payment to count CentOS or Scientific installs..or even Oracle installs. None of these are Red Hat branded products at any point. None of these products were ever eligible for services from Red Hat under the service agreement. They are distinctly different products from distinctly different vendors.
-jef
It's not so simple
Posted Mar 1, 2011 0:45 UTC (Tue) by foom (subscriber, #14868) [Link]
I'm having a bit of trouble figuring how you came by your interpretation. "Software would include versions or copies that have the Red Hat trademark(s) and/or logo file(s) removed." sounds to me like an exact description of CentOS.You say that clause only applies if I remove RedHat's trademarks, but not if the CentOS project does so?
It's not so simple
Posted Mar 1, 2011 0:55 UTC (Tue) by jspaleta (subscriber, #50639) [Link]
I'm saying that the act of rebuilding from source is different _product_. CentOS is not a Red Hat product offering in any form. It's not certified by Red Hat and does not get access to subscription services Red Hat sales you when you get RHEL.
An installed RHEL system with with binaries built and certified by Red Hat that has been modified post-install to hide the fact that it was originally installed on the system as a branded Red Hat product. Those are the systems at issue here in this clause. These situations are absolutely most definitely distinctly different than choosing to install CentOS.
-jef
It's not so simple
Posted Mar 1, 2011 0:26 UTC (Tue) by dskoll (subscriber, #1630) [Link]
Distributing the Software or any portion of the Subscription Services to a third party or using any of the Subscription Services for the benefit of a third party is a material breach of the Agreement even though the open source license applicable to individual software packages may give you the right to distribute those packages.
If that isn't against the letter of the GPL, it's certainly against the spirit. The GPL specifically says "You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License." You'd have to be a very creative lawyer to argue that terminating a support contract is not imposing "further restrictions" on the exercise of GPL-granted rights.
It's not so simple
Posted Mar 1, 2011 1:37 UTC (Tue) by JoeBuck (subscriber, #2330) [Link]
If your support contract is terminated, you can continue to use, modify, and distribute the code, and you can continue to ask for source from Red Hat to what you have good for up to three years. What you can't do is expect Red Hat Support to do something about your bugs or provide you with help.
It's not so simple
Posted Mar 1, 2011 14:27 UTC (Tue) by AndreE (guest, #60148) [Link]
It's not so simple
Posted Mar 1, 2011 16:49 UTC (Tue) by dskoll (subscriber, #1630) [Link]
So it's ok to sell a support contract and say "By the way, if you exercise rights granted by the GPL, we will unilaterally terminate this contract and not refund your money?"
It's not so simple
Posted Mar 1, 2011 19:52 UTC (Tue) by jthill (subscriber, #56558) [Link]
The GPL license terms also ask you to give up rights. Substantially more valuable rights, imo. If you don't like the terms you're free to not accept them, but if you do accept, what's your complaint?
What's the complaint?
Posted Mar 1, 2011 20:40 UTC (Tue) by dskoll (subscriber, #1630) [Link]
Since I'm not a Red Hat customer, I don't really have a complaint for myself. (I am most certainly never going to be a Red Hat customer while this policy is in place.)
My complaint is that Red Hat seems to feel that it's fine to benefit from the GPL (they've built a billion-dollar business on GPL'd software), but are now imposing restrictions that make it harder for others to benefit from the GPL.
Even if this is legal, it's unethical. It's completely contrary to the intent of the GPL. I do not admire Red Hat's cleverness at finding a legal way to add restrictions to the GPL.
What's the complaint?
Posted Mar 1, 2011 21:55 UTC (Tue) by AndreE (guest, #60148) [Link]
What's the complaint?
Posted Mar 1, 2011 21:56 UTC (Tue) by dlang (guest, #313) [Link]
What's the complaint?
Posted Mar 2, 2011 5:35 UTC (Wed) by AndreE (guest, #60148) [Link]
What's the complaint?
Posted Mar 2, 2011 5:37 UTC (Wed) by AndreE (guest, #60148) [Link]
What's the complaint?
Posted Mar 2, 2011 5:43 UTC (Wed) by dlang (guest, #313) [Link]
at what point does the cost become 'prohibiting'?
What's the complaint?
Posted Mar 2, 2011 5:50 UTC (Wed) by AndreE (guest, #60148) [Link]
What's the complaint?
Posted Mar 2, 2011 5:54 UTC (Wed) by dlang (guest, #313) [Link]
once you start eroding this, where can you draw the line?
"all animals are equal, but some are more equal than others"
What's the complaint?
Posted Mar 2, 2011 6:09 UTC (Wed) by AndreE (guest, #60148) [Link]
I mean the question of whether you are prohibited is trickier to determine than I originally considered. I'm not agreeing that this service agreement means you ARE prohibited from redistribution, but I'm backing down from my position that you certainly are not prohibited
What's the complaint?
Posted Mar 1, 2011 22:07 UTC (Tue) by dskoll (subscriber, #1630) [Link]
The GPL allows you to redistribute derived works under the GPL. Red Hat claims that doing that is a breach of their subscription agreement.
What's the complaint?
Posted Mar 2, 2011 5:44 UTC (Wed) by AndreE (guest, #60148) [Link]
Nothing.
You are still free to distribute the code under GPL, modify it under the terms of the GPL, and utilize the precise freedoms the GPL gives you.
If Red Hat said that you could only distribute the code if you were a subscriber, then THAT would be an additional condition. But that is not what they are saying at all.
What's the complaint?
Posted Mar 2, 2011 5:49 UTC (Wed) by dlang (guest, #313) [Link]
that sounds very similar to the microsoft 'viewable' source the difference being that microsoft can sue you for damages while RedHat can only stop supplying you with updates and support, potentially shutting your business down while you transition to a different distro
What's the complaint?
Posted Mar 2, 2011 5:59 UTC (Wed) by AndreE (guest, #60148) [Link]
What's the complaint?
Posted Mar 2, 2011 9:12 UTC (Wed) by airlied (subscriber, #9104) [Link]
all the source code + all the files needed to rebuild are in the srpms.
What's the complaint?
Posted Mar 3, 2011 16:43 UTC (Thu) by smurf (subscriber, #17840) [Link]
"Source", in this context, is "a kernel and a heap of patches, as embodied in a git archive". Granted that if you drop the archive and flatten the patches into 200+ patch files, that still counts, because people still customarily edit patches.
A humungous diff, however, is not a patch. It's the source equivalent of a core dump. Nobody uses that for software development.
Therefore, Red Hat is breaking the spirit of the GPL by doing that.
What's the complaint?
Posted Mar 3, 2011 22:29 UTC (Thu) by airlied (subscriber, #9104) [Link]
I'm sure lawyers can define Source == source code, in that context you have the source code to the kernel.
Its easy to make up definitions and then base arguments on them, its harder to prove the definition you made up is backed by the law.
What's the complaint?
Posted Mar 4, 2011 7:56 UTC (Fri) by smurf (subscriber, #17840) [Link]
The source code for a work means the preferred form of the work for
making modifications to it.
Whether combining lots of patches into one large patch constitutes a change in "form" would be an argument for the lawyers if this ever goes to court, which I very much doubt.
In my opinion, however, the case is pretty clear -- you simply do not modify that large a patch file. Therefore it's not a "preferred form". Therefore Red Hat is, ideally if not materially, in breach of the GPL.
Disclaimer: I am not a lawyer, not do I play one on TV.
What's the complaint?
Posted Mar 4, 2011 17:28 UTC (Fri) by dlang (guest, #313) [Link]
What's the complaint?
Posted Mar 7, 2011 22:26 UTC (Mon) by paulj (subscriber, #341) [Link]
E.g. if the patches are of no import to making modifications to a source code, then why have RedHat decided to try get a competitive advantage by withholding them? Clearly RedHat feel having the split-out patches helps them to maintain and modify the kernel they ship. My experience is that having patches (more precisely, access to the history) can be *very* important to making further modifications (finding recently introduced bugs particularly, and modifying them).
I know RedHat is "Good", I know they put in lots of resources into Linux and free software. I really want them to be able to succeed in their business. However, let's be careful to remain dispassionate about this - do any GPL copyright holders involved really want to concede that it's perfectly fine for distributors to deliberately withhold fairly important source-related information? (Obviously some of those copyright holders also have a strong interest in the continuing success of RedHat).
What's the complaint?
Posted Mar 7, 2011 22:41 UTC (Mon) by foom (subscriber, #14868) [Link]
What's the complaint?
Posted Mar 7, 2011 23:25 UTC (Mon) by dlang (guest, #313) [Link]
that doesn't mean that I think what they are doing is good in this area, just that it is within the letter of the rules. I think that them making this change erodes their moral position, but the GPL isn't dependant on people making good decisions for moral reasons, it's only dependant on people making the decisions to comply with the letter of the license (or if it requires more than just compliance with the letter of the license, there may be a need for a license change, but I don't believe that there is)
the only piece I have a legalistic problem is with them releasing code in some form to users, but only under the condition that those users don't redistribute the code (and if the users violate this condition, penalties kick in)
What's the complaint?
Posted Mar 8, 2011 7:38 UTC (Tue) by paulj (subscriber, #341) [Link]
1. RedHat work on the source in form A
2. Form B is auto-generated from A
3. Form B is distributed to comply with the GPL.
A is the src.rpm with the split patches: the format they've preferred for donkey's years and, I'm presuming to be a dead certainty, are continuing to use internally, and B is the src.rpm with the patches deliberately collapsed. Talking about email or conversations is a misdirection - binaries never get machine-built from such. The patches *are* a source input to the process that builds the distributed src.rpms though, and the reason they are an input is because that's RedHats' preferred means of making modifications.
Look at the flow above again, form B *clearly* is covered by the GPL through the text in which explains what "preferred form" is meant to cover. It's pretty explicit that intermediate transformations of the sources are *not* sufficient, that *all* the files required for input to the build process are required.
Just because an auto-generated file is still human-readable and editable does not take-away from the fact it's not the original source.
What's the complaint?
Posted Mar 2, 2011 12:46 UTC (Wed) by dskoll (subscriber, #1630) [Link]
Yes and what does the GPL say about Red Hat's license agreement? Nothing.
Maybe. Maybe not. The GPL says you are not allowed to add "additional restrictions" on the redistribution of GPL'd works.
Red Hat and others argue that their subscription agreement is not an additional restriction. I argue that it is. I'd like a legal judgement or at least an opinion from the FSF, because it's not clear-cut to me.
What's the complaint?
Posted Mar 4, 2011 1:06 UTC (Fri) by jthill (subscriber, #56558) [Link]
By signing that agreement, you did not bind them, and by signing that agreement, they did not bind you.
The defining characteristic of a coercive offer is that if you refuse it, you're worse off than you were before they made it.
That's not the case here. It's a perfectly good offer. They did not bind you by authority, they did not bind you by coercion, they did not bind you by any means.
You bound yourself, for gain, in a completely voluntary and fully informed choice.
What's the complaint?
Posted Mar 1, 2011 21:57 UTC (Tue) by dowdle (subscriber, #659) [Link]
Red Hat did NOT have to release the sources the way they originally did... that breaks it into the original source and patches. They could have originally "obfuscated" the source but they did not.
What they are doing now is "obfuscated" one package... the kernel. They are still releasing the source so they aren't hiding anything... and that source is publicly available to all. They are in compliance with the GPL.
What Red Hat has done is just change one package, the kernel source release format. They have not broken the GPL and the added restrictions they have put on their original release format for that package, as far as I can tell, are not a violation of the GPL. They do not have to make the source available in multiple formats, or any one format in particular... as long as the offer the source... which they are.
I'm guessing this won't really help them much technically... and it will anger the community more than it will restrict access to the targeted competition... and they will eventually switch back to the way they were originally doing things... but they have to try it to see how it works out. Now to see how it works out.
GPL does not ask you to give up rights.
Posted Mar 1, 2011 20:43 UTC (Tue) by dskoll (subscriber, #1630) [Link]
The GPL license terms also ask you to give up rights.
That's completely wrong. The GPL grants you rights. If you don't accept the GPL, you have no right to redistribute software it covers. If you do accept the GPL, then you have some rights.
What rights does the GPL ask you to "give up"?
GPL does not ask you to give up rights.
Posted Mar 1, 2011 22:06 UTC (Tue) by jthill (subscriber, #56558) [Link]
You have the right to charge a fee for a license to distribute your copyrighted works, for instance. The GPL asks you to give up that right in exchange for distribution rights on any combined work. So long as value received exceeds value surrendered, that's a win — and it's plainly a huge win, nothing exceptionable about it.
To get excruciatingly correct, the license doesn't actually ask people to surrender those rights, it only offers something on condition that they not exercise them. What the GPL does to people who violate its terms is exactly what Red Hat does to people who violate theirs: it terminates their license.
GPL does not ask you to give up rights.
Posted Mar 1, 2011 22:14 UTC (Tue) by dskoll (subscriber, #1630) [Link]
The GPL asks you to give up that right in exchange for distribution rights on any combined work.
Wrong. You give up that right in exchange for distribution rights on any derived work. There's a huge difference between "derived" and "combined".
To get excruciatingly correct, the license doesn't actually ask people to surrender those rights, it only offers something on condition that they not exercise them.
Wrong again. If a copyrighted work gets dropped into your lap, you have no rights whatsoever to redistribute it. So the GPL cannot offer something on condition you "not exercise certain rights" because you don't have any rights not to exercise in the first place! Again: the GPL grants you rights if you obey certain conditions. It does not remove rights.
Red Hat is removing rights. Their kernel patches are works derived from a GPL'd product and therefore anyone receiving the kernel patch has the rights granted under the GPL. Even Red Hat does not dispute that. However, Red Hat is punishing those customers who exercise rights they have already been granted by terminating their support contracts. While that may or may not be legal, it is certainly unethical.
GPL does not ask you to give up rights.
Posted Mar 1, 2011 23:45 UTC (Tue) by jthill (subscriber, #56558) [Link]
You give up that right [...]So we agree, then, on the substance: the GPL asks you to give up rights, just as Red Hat does. All that's left is discussing how best to describe the details and whether they're fair offers.
Red Hat asks you not, under particular circumstances, to give away their work. The GPL asks you not, under particular circumstances, to charge for distribution rights on your own. Both offer something valuable in return for your not doing what you have a license or even the right to do.
--
I think if you check you'll see the GPL v2 does not use "combine" at all, the GPL v3 does not use "derive". Either way, I rejected "derived" because I wanted to highlight the continued existence of your own separate interest in the result.
GPL does not ask you to give up rights.
Posted Mar 2, 2011 4:14 UTC (Wed) by JesseW (subscriber, #41816) [Link]
It is important to clarify something here: If you create, let alone distribute, a derivative work without a license from the copyright holder of the work (or works) it is derived from, that is illegal.You have no right to sell (or even give away) a license for the derived work unless you already possess a license to do the deriving. What the GPL says is that you can have a license to create a derivative work merely by following certain conditions, which do not include payment or notification to anyone, but do include licensing the derivative work under the GPL.
If the derivative work you want to create has components that are not derivative (i.e. that were written only by you), the GPL has nothing to say about them, and puts no restrictions on what you do with them. You are free to sell licenses for them, or do anything else that is legal.
While you do, in some sense, have a "right to charge a fee for a license to distribute your copyrighted works", you have no right to do so without the consent of all the copyright holders for a work. Derivative works have multiple copyright holders, all of whom need to consent before a license can be granted. All the GPL does is clarify the terms in which the other copyright holders will grant their necessary permissions. It takes nothing away from you.
GPL does not ask you to give up rights.
Posted Mar 2, 2011 8:30 UTC (Wed) by jthill (subscriber, #56558) [Link]
If you create, let alone distribute, a derivative work without a license from the copyright holder of the work (or works) it is derived from, that is illegalTaken at face value, you've just asserted it's illegal to sing in the shower, and to keep scrapbooks. Perhaps if you clarify your clarification it'll also become clear how it's relevant at all in a discussion of the exercise of distribution licenses.
I don't see the value here in insisting that copyright on derived work is on the work as a whole: to the extent that you have copyright on the result, it's due to your contribution. I say po-tay-to, and we're discussing tays.
And when the reason you may not charge for a distribution license on the resulting work is only that the GPL says you may not, claiming that the GPL takes nothing away is at best pure equivocation.
GPL does not ask you to give up rights.
Posted Mar 2, 2011 15:56 UTC (Wed) by JesseW (subscriber, #41816) [Link]
I'm not sure what "to the extent that you have copyright on the result, it's due to your contribution" even means. What "result" -- the derivative work? What "contribution", exactly? The specific lines of code that were not present before? What about lines that were modified (say by changing a "==" to "!=")? Whose "contribution" are they?
The reason you can't charge for a distribution license on the derivative (not "resulting" -- it's a work derived from the existing work, which you were allowed to derive from (and copy, and distribute, etc.) by following the terms of the GPL) work is that you are not the sole copyright holder for it. If you get the agreement of all the copyright holders, you all can certainly refuse to grant additional licenses without payment.
GPL does not ask you to give up rights.
Posted Mar 2, 2011 23:52 UTC (Wed) by jthill (subscriber, #56558) [Link]
you know as well as I what the clarification that makes the examples you listed legalIf you check back you'll see I didn't ask for a clarification that would explain why those examples are legal. I asked for a clarification that explains how an assertion about requirements on private derivation is relevant in a discussion about exercising licensed public distribution. The rebuke for the gratuitous overreach on private use stands.
I'm not sure what "to the extent that you have copyright on the result, it's due to your contribution" even means.Well, I kind of took it as read that copyright in GPL'd works is almost entirely due to application of authors' patches, and that reverting an author's changes means that author has no copyright on the resulting work. Patches are contributions in any sense of the word, contributions in other forms are generally also revertible, "contributor" is the word v3 uses, and the exact extent of the changes necessary to excise an author's copyright interest is irrelevant here. That all seemed so obvious it needed no more than acknowledgment.
If you get the agreement of all the copyright holders, you all can certainly refuse to grant additional licenses without payment.I think you might have missed that that makes my point: with unrestricted copyright authority, one can demand money for a distribution license. Authors employing the GPL ask that you (as they do) not exercise that and other rights in exchange for the GPL's benefits. You have to give up either the rights or the license to get the other.
To finish bringing it back on topic, Red Hat offers timely, warranted service in exchange for your not exercising the GPL the instant you receive it. You have to give up either the right or the service to get the other.
Don't forget that you (as Red Hat does) still get the software courtesy of the GPL, nor that Red Hat also makes sure no one loses what I think most people regard as its main benefit: they also distribute their work freely. They do so after a delay that takes it out of the realm of service, i.e. current work for which it's ethical to charge the people who want it right now, and into the realm of adequately compensated work that can be distributed at no cost. That they do so completes the GPL's positive-feedback loop.
Publishing a repo is on its way to being the standard way to distribute GPL'd and other free software, but it seems in Red Hat's experience it's only possible to distribute their complete set in a way a little more like software was ordinarily distributed when the GPL was written -- mostly tarballs as I recall, but I wasn't tracking then -- if they want to execute their business model. OK. That feedback loop is what I care about.
GPL does not ask you to give up rights.
Posted Mar 3, 2011 3:23 UTC (Thu) by JesseW (subscriber, #41816) [Link]
OK, I think we are coming to more of an understanding here. You are pointing out differences between two situations:
- Distributing software while relying on (one or more) GPL grants by other copyright holders (whether or not you also have some copyright interest in the software), and
- Distributing software for which you are the sole copyright holder.
You are claiming (correctly) that you can demand payment for permission to further distribute the software only in the 2nd case, not in the 1st. I agree.
You are claiming that demanding payment for further distribution is a "right" in both cases, which the GPL demands you "give up" in the 1st case. I disagree. I claim that, in the 1st case, you have no right (except for fair use) to distribute the software or permit further distribution (with or without payment). The GPL provides you the ability to distribute the software, but does not provide you the ability to prevent further distribution. You are giving up no right.
As for the Red Hat situation, I don't have a strong opinion one way or another. I tend to agree with the your analysis, since, as you pointed out, a RH subscriber loses nothing if they distribute the materials after their subscription expires.
GPL does not ask you to give up rights.
Posted Mar 3, 2011 6:03 UTC (Thu) by jthill (subscriber, #56558) [Link]
You're presenting a false dichotomy between the GPL and no license at all, and confusing a license to distribute with the right to dictate terms.
The only reason you are constrained at all is that the other copyright holders have the right to dictate license terms. If you create a derived work, you are one of those copyright holders, and you also have the right to dictate terms. If you can't all arrive at a compatible set of terms for a license to distribute, then none of you can distribute — but only because you and they have the right to dictate terms.
Two of the infinite myriad of possible sets of terms you and the other copyright holders may offer are
BSD: you retain, you may exercise, your right to offer any terms at all for a license to your own work, your own copyright interest, in any derived work. You may stipulate any restrictions and charge any fee.
GPL: you give up, you may not exercise, that right: if you distribute at all you must offer specific permissions at no charge.
GPL does not ask you to give up rights.
Posted Mar 4, 2011 23:58 UTC (Fri) by cas (guest, #52554) [Link]
without permission being granted, you have no right to distribute works derived from other people's copyrighted works.
i suspect that what is confusing you on this issue is that BSD and GPL have different conditions on that grant of permission, but (in the context of this argument) that is irrelevant.
BSD code is not public domain, any more than GPL code is.
GPL does not ask you to give up rights.
Posted Mar 5, 2011 2:27 UTC (Sat) by jthill (subscriber, #56558) [Link]
Hi, no, please find (at least) all uses of the phrase "the right to" in the history of this conversation. I certainly didn't make that mistake.
GPL does not ask you to give up rights.
Posted Mar 2, 2011 12:41 UTC (Wed) by dskoll (subscriber, #1630) [Link]
So we agree, then, on the substance: the GPL asks you to give up rights
No, we do not. My original phrasing was wrong. Let me spell it out: The GPL only grants you rights. It does not ask you to give up any rights because in the absence of the GPL, you have no rights anyway.
Huh?
Posted Mar 2, 2011 14:42 UTC (Wed) by khim (subscriber, #9252) [Link]
The GPL only grants you rights. It does not ask you to give up any rights because in the absence of the GPL, you have no rights anyway.
Sorry, but this is not true. Just a recent example. GPL asks you to surrender your rights in exchange for a bunch of code. Again: If you want to use said code you must give up the rights copyright gives you. RedHat does the same in reverse: in order to enjoy the support you must give up the rights GPL gives you. In both cases it's up to you to decide if you want to agree to the terms or not.
Huh?
Posted Mar 2, 2011 15:10 UTC (Wed) by dskoll (subscriber, #1630) [Link]
The example you gave with libreadline does not in any way show how the GPL forces you to give up rights. In the absence of the GPL, you would have no right whatsoever to link libreadline against your app, nor could you distribute it. The GPL grants you rights under certain conditions.
RedHat does the same in reverse: in order to enjoy the support you must give up the rights GPL gives you. In both cases it's up to you to decide if you want to agree to the terms or not.
And I think that may be illegal. Red Hat is adding additional restrictions to the GPL. Red Hat's patches that it distributes to paying customers are clearly GPLd and can be distributed under the terms of the GPL. But you can't get the patches unless you agree to the subscription agreement. Therefore, Red Hat is adding restrictions to the GPL.
Heh...
Posted Mar 2, 2011 15:41 UTC (Wed) by khim (subscriber, #9252) [Link]
In the absence of the GPL, you would have no right whatsoever to link libreadline against your app, nor could you distribute it.
Right. But you have the right to demand per-copy royalties, etc. All these privileges given to you by copyright law, you know. For your program, not for readline.
The GPL grants you rights under certain conditions.
Yes. But these conditions are quite interesting: surrender the privileges you usually have - then enjoy the benefits. That's the point of copyleft.
Red Hat's patches that it distributes to paying customers are clearly GPLd and can be distributed under the terms of the GPL.
Sure.
But you can't get the patches unless you agree to the subscription agreement.
Exactly: service agreement gives you rights under certain conditions. Without service agreement you can not even look on patches, let alone distribute them.
Therefore, Red Hat is adding restrictions to the GPL.
How come? You can distribute patches using the GPL - noone disputes this right. Just like nobody disputes your privilege for per-copy royalties. But if you want to enjoy benefits of service agreement (access to the patchlist, for example) you must agree not to exercise your privileges. Actually it's even more generous then GPL: GPL forces you to give up your privileges forever, while service agreement will only bind you temporarily.
Heh...
Posted Mar 2, 2011 16:41 UTC (Wed) by dskoll (subscriber, #1630) [Link]
The difference between the GPL's granting of rights and Red Hat's subscription service is this: The GPL is a license, not a contract. Red Hat's subscription agreement is a contract. You pay Red Hat for support, and in return they give you support. But they also include a landmine in the contract: You are forced to give up rights you'd normally have even in the absence of the support contract. (For example, if Red Hat's segregated kernel patches magically landed in my mailbox, it would be perfectly legal for me to redistribute them under the GPL even though I'm not a Red Hat customer.)
Red Hat's contract adds additional restrictions to the GPL which IMO is a GPL violation. Try this thought experiment:
If Red Hat's contract said: "If you take advantage of the rights under the GPL to redistribute our patches, you agree to pay Red Hat software one billion dollars", then that would clearly be a severe restriction on redistribution.
All that's in dispute is the degree of restriction (which is basically the money you've spent on the support contract.) The existence of an additional restriction cannot be disputed and this violates the GPL.
What rights?
Posted Mar 2, 2011 19:54 UTC (Wed) by khim (subscriber, #9252) [Link]
You are forced to give up rights you'd normally have even in the absence of the support contract.
In the absence of the support contract you have no access to patches in question so you can not distribute them.
For example, if Red Hat's segregated kernel patches magically landed in my mailbox, it would be perfectly legal for me to redistribute them under the GPL even though I'm not a Red Hat customer.
If you can prove that patches arrived in your mailbox from source other then RedHat's site (for example from kernel.org site) you are still free to distribute them.
If Red Hat's contract said: "If you take advantage of the rights under the GPL to redistribute our patches, you agree to pay Red Hat software one billion dollars", then that would clearly be a severe restriction on redistribution.
Sure. This will be like patent license: no matter how you've gotten the patches you are forbidden to excercise your rights. RedHat's agreement only restricts distribution of meta-information. You are free to strip meta-information and distribute raw source/patches. In fact if the meta-information comes from third-party source and not from RedHat you are free to distribute that too - but you must prove that it indeed come from different source.
The existence of an additional restriction cannot be disputed and this violates the GPL.
Sorry, but no. It's said quite explicitly: this Appendix is not intended to interfere with your rights under those individual licenses. If you can prove that you had the right to distribute something under terms of GPL then you are in the free. Just remember that while software included in patches is GPL-licensed different commit messages, ACKs and NAKs are not. And they may even be peceived as trade secrets.
You will need pretty good lawer to properly cleanup the patches from RedHat's web site, but you can distribute the source code itself - RedHat does not interfere with that.
What rights?
Posted Mar 2, 2011 20:18 UTC (Wed) by dskoll (subscriber, #1630) [Link]
In the absence of the support contract you have no access to patches in question so you can not distribute them.
No, that's untrue. Someone with a support contract could (legally) mail me the patches, and I could redistribute them in the absence of a support contract with Red Hat. The person who sent me the patches might be in hot water with Red Hat, but I wouldn't be.
If you can prove that patches arrived in your mailbox from source other then RedHat's site (for example from kernel.org site) you are still free to distribute them.
Nope. Even if I obtained the patches from Red Hat, I can still distribute them because they are GPL'd (being derived products created from a GPL'd work.)
RedHat's agreement only restricts distribution of meta-information.
Are you claiming that Red Hat's patches are not derived from a GPL'd work? I don't think even Red Hat claims that.
Sorry, but no. It's said quite explicitly: this Appendix is not intended to interfere with your rights under those individual licenses.
But it absolutely does interfere with those rights. How can you claim it does not?
You will need pretty good lawer to properly cleanup the patches from RedHat's web site
Why do you think that? Are you claiming that the patches Red Hat distributes to its customers are not derived from a GPL'd work?
Just remember that while software included in patches is GPL-licensed different commit messages, ACKs and NAKs are not. And they may even be peceived as trade secrets.
I am not talking about commit messages. I am referring to the individual kernel patches that Red Hat does make available (only) to its customers (supposedly) under the GPL.
Once again...
Posted Mar 3, 2011 10:39 UTC (Thu) by khim (subscriber, #9252) [Link]
But it absolutely does interfere with those rights. How can you claim it does not?
I'm not claiming that. RedHat does.
I don't think you've read the whole thing. Basically RedHat says the following:
1. You have no right to distribute anything you are downloading from our servers.
2. But if you know that some open-source license gives you such right and can prove that then you are in the clear.
3. Our lawyers are always ready to discuss your proof in the court of law.
See? It does not interfere with your GPL rights - but it shifts the separation issue on your side. You must prove that you have the right to distribute anything - and if you'll do a single error... well, your support contract is no longer valid and that's that.
Why do you think that? Are you claiming that the patches Red Hat distributes to its customers are not derived from a GPL'd work?
They contain mix of the GPLed code and non-GPLed code. For example a lot of files in Documentation subdirectory are not derived works of kernel (even if they are distributed in the same tarball - see "mere aggregation" clause). This means that the fact that patch applies to Linux kernel is not enough to clear you: you must review each and every patch and decide what parts of it are GPL-derived and what parts are not GPL-derived. This is quite non-trivial amount of work.
Once again...
Posted Mar 3, 2011 12:02 UTC (Thu) by dskoll (subscriber, #1630) [Link]
I'm not claiming that. RedHat does.
Red Hat is full of crap if it claims that.
If you think Red Hat is using the threat of lawyers to stop people from distributing the patches ("Our lawyers are always ready to discuss your proof in the court of law."), then that's even worse. That throws a huge chill over collaborative kernel development. Even I don't think Red Hat is that bad; I believe they won't actually sue anyone for distributing the patches.
This means that the fact that patch applies to Linux kernel is not enough to clear you: you must review each and every patch and decide what parts of it are GPL-derived and what parts are not GPL-derived.
If you believe that's what Red Hat is doing, then it's even worse that what I'm claiming it's doing. If what you say is true, then Red Hat is deliberately blocking collaborative kernel development and adding legal threats to its arsenal against anyone using its patches. Do you think that's in the spirit of the GPL?
RedHat had not invented anything
Posted Mar 4, 2011 17:52 UTC (Fri) by khim (subscriber, #9252) [Link]
If you think Red Hat is using the threat of lawyers to stop people from distributing the patches ("Our lawyers are always ready to discuss your proof in the court of law."), then that's even worse. That throws a huge chill over collaborative kernel development. Even I don't think Red Hat is that bad; I believe they won't actually sue anyone for distributing the patches.
If they'll sue or not remains to be seen. But they reserve the right to do so - like Microsoft reserves the right to do so (WRT Mono).
If you believe that's what Red Hat is doing, then it's even worse that what I'm claiming it's doing. If what you say is true, then Red Hat is deliberately blocking collaborative kernel development and adding legal threats to its arsenal against anyone using its patches. Do you think that's in the spirit of the GPL?
Well, it's good question. Probably not. But... FSF itself developed GNU programs (like emacs or gcc) behind the closed doors for years. When the programs were released they were released as tarballs only - access to the VCS was restricted even fater that. Of course they have not threatened you with lawers and when EGCS project decided to fork GCC they they allowed them to take patches from private tree, but it happened when developers convinced RMS to conduct this experiment, not when they decided that they have unalienable right to publish them...
GPL does not ask you to give up rights.
Posted Mar 2, 2011 16:15 UTC (Wed) by jthill (subscriber, #56558) [Link]
I think if you consider the right to relicense you'll find a misstep in your reasoning.
GPL does not ask you to give up rights.
Posted Mar 3, 2011 9:26 UTC (Thu) by jthill (subscriber, #56558) [Link]
http://lwn.net/Articles/430809/
It's not so simple
Posted Mar 1, 2011 21:48 UTC (Tue) by AndreE (guest, #60148) [Link]
It's not so simple
Posted Mar 1, 2011 22:18 UTC (Tue) by dskoll (subscriber, #1630) [Link]
That is not the issue. The issue is that Red Hat's kernel patches are works derived from a GPL-licensed work. They must, therefore, be GPL-licensed. This means that Red Hat customers can redistribute the patches under the GPL. Red Hat does not dispute this.
Instead, Red Hat works around the GPL by saying "If you exercise your rights, then we will punish you." This means Red Hat customers effectively cannot exercise their rights (or if they do, they need to do it anonymously to avoid retribution). That's unethical, even if it's legal, and I hope that Red Hat is suitably punished in the marketplace.
It's not so simple
Posted Mar 2, 2011 5:57 UTC (Wed) by AndreE (guest, #60148) [Link]
We can both come up with extreme cases supporting the legitimacy or illegitimacy of this decision. I might suggest that Red Hat has no obligation to provide support to entities that just repackage their efforts under different logos, although they DO have obligations to respect the GPL when distributing code to all subscribers.
It's not so simple
Posted Mar 2, 2011 6:11 UTC (Wed) by dlang (guest, #313) [Link]
this obligation is based on the fact that most of 'their code' is not actually theirs, it's code from other people who let them use it on the condition that they let others use it (and derived works) as well.
RedHat has traditionally made it easy for people to make rebranded distros by keeping all their branding fairly nicely isolated.
they would be perfectly within their rights to stop doing so, no longer provide broken out patches for anything, and start including trademarked logos embedded in the source files to make it harder for people to strip the trademarked branding out.
and there may even be technical arguments for doing exactly this in the final build code version (and no, I don't buy the argument that a series of patches is the "preferred means of modification" patches aren't edited by humans, they are a way of transmitting changes from one entity to another).
If that is what they were doing, I would be silent, or supporting their right to do so (while not necessarily agreeing that it's a good idea to do so)
It's not so simple
Posted Mar 2, 2011 6:41 UTC (Wed) by paulj (subscriber, #341) [Link]
Think very carefully about defending RedHat here. While RedHat generally get Free Software and are reasonably trust-worthy[1], and we might feel like cutting them slack, there are plenty of other Linux distributors who don't. Particularly in the embedded world, if you can even get (all) the source, it's usually a giant tarball. To the extent such distributors keep patches separated out internally, users who buy such devices *should* be able to get at those patches. It's not a massive issue yet, because usually the changes they make are small enough that diffing is still tractable - but that need not always remain the case.
1. Even if they've apparently acquired some amount of middle-management that doesn't and may not be, according to daniel (which, if correct, makes for a long-term worry the community should have for RedHat: some of those middle-managers may progress to top-level management one day).
It's not so simple
Posted Mar 2, 2011 7:33 UTC (Wed) by dlang (guest, #313) [Link]
yes, I know that there are people who edit and write patch files directly. I also know a person who taught himself C from the K&R book by compiling the examples and then reading the machine code that resulted (a long time mainframe systems guy), such people are very much the exception and are not what we base expectations on :-)
I wouldn't expect to require patches, or git trees any more than I would require a someone who used a proprietary compiler to compile GPL source code into a binary provide me with a copy of the compiler because that is what I would need to recreate the binary I got from that person.
so I have no problem with someone just providing one tarball of the result instead of broken out patches (I may have concerns about why someone is doing this, especially if they used to do something more useful, but that's not concerns over what is being done, but rather why they are doing it)
while I think it would be nice to get a git tree of the patches, deciding that such a thing is a requirement gets very ugly very quickly (what if they use a proprietary version control system instead of git? for example?)
It's not so simple
Posted Mar 2, 2011 7:59 UTC (Wed) by paulj (subscriber, #341) [Link]
I actually agree with you in your caution about drawing firm lines. However, I'd argue such caution should go /both/ ways. Not only should be cautious about concluding that publishing changesets is a GPL requirement, but we should also be cautious about concluding that only publishing the aggregated-together sources and NOT the changesets is sufficient to comply with the GPL. I'm not sure myself where the line is, or what principle can be drawn other than "decide on a case-by-case basis", but I do think that in cases where there clearly is such a large amount of information contained in the deltas that /not/ publishing them effectively frustrates anyone trying to replicate the work, and that the publisher retains a significant advantage by having its own internal work-flow still be based on those deltas, that then there is a strong case to be made that the published source no longer is in preferred form...
It's not so simple
Posted Mar 2, 2011 9:06 UTC (Wed) by airlied (subscriber, #9104) [Link]
just because there is a git tree somewhere I can access if I want it doesn't change the fact that I was given a tarball which wasn't in what you are calling the preferred form.
It's not so simple
Posted Mar 2, 2011 10:24 UTC (Wed) by maks (guest, #32426) [Link]
> violating the GPL?
The point beeing that linus doesn't really hide his git tree on kernel.org, whereas RH does. I'm pretty sure that you know that they didn't before, as up to RH 6.0 beta all patches are visible.
Wow. Talk about fogetting history.
Posted Mar 2, 2011 15:17 UTC (Wed) by khim (subscriber, #9252) [Link]
The point beeing that linus doesn't really hide his git tree on kernel.org, whereas RH does.
Well, Linus did that for a few years. It was not possible to get meta-information from bikeeper.com without agreeing to pretty onerous terms. Note that some developers refused to accept such terms - but none tried to imply that what Linus and other were doing is breach of the GPL!
Sorry, but this ship sailed long ago.
Wow. Talk about fogetting history.
Posted Mar 2, 2011 16:59 UTC (Wed) by paulj (subscriber, #341) [Link]
It's not so simple
Posted Mar 2, 2011 10:41 UTC (Wed) by pboddie (subscriber, #50784) [Link]
You may say it's a punishment, I might suggest it's protecting their business. And I still don't see where in the GPL this is prevented, although I will admit reading yours and some other points have made me think of things differently.
I don't care about Red Hat's business, but I do care about GPL compliance, so let's look at that aspect. To those who receive binaries (as part of their subscription), Red Hat also make the corresponding sources available, albeit in a form that others (who additionally have access to that software) may not prefer. In addition, Red Hat also appear to make the patches available on the condition that these are not redistributed, with the penalty for breaking this condition being that the offending subscriber's subscription is terminated and that they will receive no more patches.
Now, in the context of upholding the terms of the GPL, Red Hat appear to provide the corresponding sources to the binaries being distributed, so they aren't violating the GPL in this respect. Meanwhile, the patches distributed separately, whilst potentially being considered derived works of GPL-licensed work by other authors, still presumably come with all the privileges conferred by the GPL: you may still redistribute them, but Red Hat may then decide not to share any further patches with you.
Clearly, the GPL doesn't make anyone promise that they will continue to share new updates and revisions to a piece of software that has already been shared, so Red Hat can probably get away with making such continued sharing conditional on the "good behaviour" of subscribers. You can even turn this on its head and say that Red Hat only promises to share one revision's worth of patches but may continue to do so on the basis of such "good behaviour".
Having said all this, the divisive and isolating effect such policies might have, disempowering recipients of software and making them mere consumers, arguably work against the spirit of Free Software.
It's not so simple
Posted Mar 2, 2011 15:36 UTC (Wed) by nevyn (subscriber, #33129) [Link]
You have the _right_ to buy a single support contract, and then sell support contracts yourself for CentOS/SL/OEL and log all your problems against RH. Red Hat have the right to refuse your business.
You may feel RH is being "mean" for not letting you screw them over, and you are free to have that opinion (but that doesn't mean others will agree with you).
It's not so simple
Posted Feb 28, 2011 21:00 UTC (Mon) by jmorris42 (guest, #2203) [Link]
No, don't think they even do that. But that doesn't matter. What they did was blow enough FUD into the question that no corporate type will want to allow an employee to repost the patches.
I do feel for RH on the patchsets being unwieldy but think they crossed the line to naughty on this one. Hopefully saner heads will prevail.
It's not so simple
Posted Mar 1, 2011 0:29 UTC (Tue) by ESRI (guest, #52806) [Link]
It's not so simple
Posted Mar 1, 2011 1:03 UTC (Tue) by dskoll (subscriber, #1630) [Link]
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]
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]
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]
It's not so simple
Posted Mar 1, 2011 14:39 UTC (Tue) by AndreE (guest, #60148) [Link]
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]
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]
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]
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]
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]
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]
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]
<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]
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]
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]
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]
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]
(The more I think about a tool to do automatic patch composition like this, the more useful it seems, and not just for this application either. After all, it's not RHEL-kernel-specific: it's a generalized way of turning giant third-party code drops against git-maintained projects into 'this came from git: this did not: of those, these bits look like they are unrelated'.)
Red Hat's "obfuscated" kernel source
Posted Mar 1, 2011 6:05 UTC (Tue) by patrick_g (subscriber, #44470) [Link]
>>> I'm waiting for an official answer from Kerri Catallozzi.Official (and disappointing) answer from RH press service :
Hi Patrick
We have no comment.
thanks,
Kerri
Red Hat's "obfuscated" kernel source
Posted Mar 1, 2011 15:38 UTC (Tue) by daniel (guest, #3181) [Link]
Red Hat's "obfuscated" kernel source
Posted Mar 1, 2011 16:20 UTC (Tue) by nix (subscriber, #2304) [Link]
Red Hat's "obfuscated" kernel source
Posted Mar 1, 2011 21:20 UTC (Tue) by daniel (guest, #3181) [Link]
Red Hat's "obfuscated" kernel source
Posted Mar 4, 2011 23:06 UTC (Fri) by yuhong (guest, #57183) [Link]
Red Hat's "obfuscated" kernel source
Posted Mar 4, 2011 23:09 UTC (Fri) by yuhong (guest, #57183) [Link]
daniel: Do you know?
Red Hat's "obfuscated" kernel source
Posted Mar 8, 2011 7:33 UTC (Tue) by daniel (guest, #3181) [Link]
Some of the worst offenders are still there. From what I have seen, more competent people have left Red Hat than incompetent. I do not think that is because Red Hat has a surplus of competent people.
Then there are some gems who have arrived, like Ric Wheeler. But does Red Hat management realize how lucky they are and are they willing to give him real power, or will they just abuse him and spit him out as I saw happen to a number of good people when I was there? Let's see.
Red Hat's "obfuscated" kernel source
Posted Mar 1, 2011 18:36 UTC (Tue) by bronson (subscriber, #4806) [Link]
Red Hat's "obfuscated" kernel source
Posted Mar 1, 2011 21:27 UTC (Tue) by daniel (guest, #3181) [Link]
Red Hat's "obfuscated" kernel source
Posted Mar 3, 2011 17:46 UTC (Thu) by vonbrand (guest, #4458) [Link]
Red Hat's Linux offerings do include certain parts that you aren't allowed to freely redistribute. That they sit on the same DVDs (or even inside the same RPMs) with stuff that you can redistribute freely doesn't allow you to redistribute them.
Red Hat's "obfuscated" kernel source
Posted Mar 4, 2011 15:55 UTC (Fri) by Tet (subscriber, #5433) [Link]
Red Hat's Linux offerings do include certain parts that you aren't allowed to freely redistribute[citation needed] There used to be an extras disc that contained various non-free apps. I don't know if that still exists. But in the main RHEL, I'm not aware of anything that isn't redistributable. The artwork and logos have restrictions on use, but not on distribution AFAIK. And the various bits of firmware in the kernel have passed the scrutiny of Red Hat's legal team, so although some may claim they're not distributable, it would seem that they are in the real world.
So what are you claiming they are shipping that can't be freely redistributed?
Red Hat's "obfuscated" kernel source
Posted Mar 5, 2011 20:27 UTC (Sat) by vonbrand (guest, #4458) [Link]
I'm talking about the logos and the whole branding as Red Hat. It is on the media you get from Red Hat, and you can't redistribute that freely, extra conditions apply. Same as with the Fedora branding, and (presumably) even Debian.
The "extra software" CD that came with early Red Hat distributions (and wasn't on their website) is something entirely different.
Red Hat's "obfuscated" kernel source
Posted Feb 28, 2011 18:27 UTC (Mon) by criswell (guest, #40091) [Link]
I used to work at Progeny, making customized RPM-based distributions derived from RHEL sources, and I actually found the RHEL kernels to be quite sane to work with and customize back then (this was 4+ years ago).
Kernel SRPMs used to contain basically stock kernels from kernel.org along with a large number of patches to be applied in a systematic way by the rpm build process. It still required a fair bit of esoteric knowledge and understanding to be able to grok the process, but it was possible and you could de-couple the patches and modify the kernels as needed (it was part of our bread-and-butter at the the time :-) The fact that they are now just a blob of patched work is pretty disheartening.
Part of me wonders if this is more laziness than anything else on behalf of the RHEL kernel maintainers, because creating the SRPM kernels that way is likely more difficult in the short term (but with the extra added benefit of maintainability in the long term). I can't imagine that this was a result of some serious debate internally as to how they could do some sort of "value add" to the product, or a "lock-in"... because it seems like it's just going to cause more headaches for the RHEL kernel maintainers than it's probably worth.
How come?
Posted Feb 28, 2011 20:55 UTC (Mon) by khim (subscriber, #9252) [Link]
I'm pretty sure internally all changes are kept in git and they can track anything (probably better then they were able before). But when .src.rpm is generated they just dump current state of their git repository.
Makes life easier for in-house developers and harder for out-of-house developers. Win-win situation as far as management is concerned.
How come?
Posted Feb 28, 2011 21:21 UTC (Mon) by abartlet (subscriber, #3928) [Link]
How come?
Posted Mar 1, 2011 6:48 UTC (Tue) by jamesh (guest, #1159) [Link]
If they want to send the changes upstream, presumably they would be working on them in a separate branch, in isolation of unrelated RH kernel changes.
Whether those changes are integrated into the RH kernel by merging them into another git tree or producing patches would only really effect the tail end of that work.
Red Hat's "obfuscated" kernel source
Posted Feb 28, 2011 21:22 UTC (Mon) by aristeu (subscriber, #35826) [Link]
assure I'm not lazy! :)
Red Hat's "obfuscated" kernel source - a git repository anywhere?
Posted Feb 28, 2011 18:37 UTC (Mon) by grantma (subscriber, #5225) [Link]
It comes down to what is easier to ship - a ball of C out of a git repository, vs a handmade package manually pieced together from thousand's of patches. They could just be moving to a more saner release model given the technology available.
Let's keep our eyes peeled for this repo, and pressure them to make it available if it can't be found.
Red Hat's "obfuscated" kernel source - a git repository anywhere?
Posted Feb 28, 2011 19:00 UTC (Mon) by mbanck (guest, #9035) [Link]
Red Hat's "obfuscated" kernel source
Posted Feb 28, 2011 18:49 UTC (Mon) by branden (guest, #7029) [Link]
This means that their SRPM does not contain the kernel sources in the "preferred form ... for making modifications to it." (GNU GPLv2)
That means they are violating the GPL.
Red Hat's "obfuscated" kernel source
Posted Feb 28, 2011 19:06 UTC (Mon) by hp (guest, #5220) [Link]
I don't think an SRPM with hundreds of patches is really the preferred form for modification ... surely a git tree is the actual way work happens
Red Hat's "obfuscated" kernel source
Posted Feb 28, 2011 19:22 UTC (Mon) by branden (guest, #7029) [Link]
Ordinarily this wouldn't be a very interesting question, and I'd be inclined to view Red Hat's packaging decisions with latitude.
However, in the instant case, the act which brought this matter to the attention of LWN's readership was an act of obfuscation of the source.
Wherever the boundary line of the GPLv2's definition of source code is drawn, this decision has moved Red Hat's kernel SRPMS away from its uncontroversial center.
"Preferred form for modification" in GPL
Posted Mar 1, 2011 13:12 UTC (Tue) by vonbrand (guest, #4458) [Link]
Sorry, but in what way I (as a very minor contributor to Linux) would like to define "prefered form for modifying" of whatever I added is probably totally irrelevant, a court of law would have to sort that out.
Red Hat's "obfuscated" kernel source
Posted Mar 1, 2011 14:46 UTC (Tue) by AndreE (guest, #60148) [Link]
It's also debatable which is why it is silly to declare so simply that they are violating the GPL
Red Hat's "obfuscated" kernel source
Posted Mar 1, 2011 23:34 UTC (Tue) by branden (guest, #7029) [Link]
The purpose of GNU GPL is, in part, to keep end users from having to jump through ridiculous or high-cost hoops to make a work of software operate as they desire.
If the Red Hat kernel engineers don't work with a giant monolithic patch, then they are imposing a tax on the rest of the community by forcing everyone else to swallow one.
If I were a copyright holder in the kernel, I'd be talking to the SFLC right about now.
Maybe no copyright holders in the kernel share my interpretation. That's fine; it's their prerogative. My view is that Red Hat is doing the Wrong Thing(tm) here, and if the GNU GPL is a sufficiently long lever to get them to revert their decision, good. If it's not, the perhaps the weight of public opinion will be.
They've clearly made a choice that no sane and educated person can regard as friendly to the community. Part of the solution is to shine light and attention on this hostile decision until they find a better way to solve whatever problem it is they're trying to solve.
Telling the world what that problem is, exactly, would be a great first step.
Red Hat's "obfuscated" kernel source
Posted Feb 28, 2011 19:50 UTC (Mon) by jspaleta (subscriber, #50639) [Link]
-jef
Red Hat's "obfuscated" kernel source
Posted Feb 28, 2011 20:05 UTC (Mon) by zlynx (guest, #2285) [Link]
Red Hat's "obfuscated" kernel source
Posted Feb 28, 2011 20:20 UTC (Mon) by jspaleta (subscriber, #50639) [Link]
-jef
Red Hat's "obfuscated" kernel source
Posted Feb 28, 2011 21:19 UTC (Mon) by dskoll (subscriber, #1630) [Link]
This was proposed for the Debian source format too, and I think was implemented.
In their FAQ, they have a Q/A pair about archive bloat.
Red Hat's "obfuscated" kernel source
Posted Feb 28, 2011 21:23 UTC (Mon) by jspaleta (subscriber, #50639) [Link]
-jef
Red Hat's "obfuscated" kernel source
Posted Feb 28, 2011 21:39 UTC (Mon) by pkern (subscriber, #32883) [Link]
Red Hat's "obfuscated" kernel source
Posted Feb 28, 2011 22:58 UTC (Mon) by daniels (subscriber, #16193) [Link]
Red Hat's "obfuscated" kernel source
Posted Mar 1, 2011 0:07 UTC (Tue) by jspaleta (subscriber, #50639) [Link]
Red Hat already goes beyond what is strictly required by the GPL by making the source public to anyone..instead of just to their customers. Is that enough?
Are the Fedora kernels which Red Hat manpower helps maintain as part of a community distribution using the large tarball dump yet? A check of the SRPM collection for rawhide says Fedora is still doing things with patchsets. Is that enough?
Have the upstream maintainers of the kernel project delineated what _all_ distributors are meant to do to provide as a preferred corresponding source? _all_ distributors including those who produce linux embedded devices such as my home router and what not. So far we have heard from one peer distributor...a community based project that competes with Red Hat in the server space. Now of course competitors certainly have a voice in helping to keep standards for interaction high, but they are not the...canonical...voice. What is the standard of behaviour expected from the upstream project, the linux kernel project, in terms of being able to pull and merge patches from corresponding source as shipped by _all_ vendors that distribute the linux kernel.
If we are going to have this conversation then the upstream project needs to set the guidance as to what _all_ distributors should be providing so we can measure conformance equitably for _all_ distributors to the preferences of the upstream project. If a public git tree is what is expected from a good downstream citizen, than that needs to be documented somewhere by the upstream project and then we can all go poke our fav vendors in the eye to conform to that..whether that be one of the new-breed android tablet vendors...whether that be Cisco for distributing embedded linux in my router whom I have to contact for the sourcecode...or whether its stodgy old Red Hat and their tarball distribution based packaging.
-jef
Red Hat's "obfuscated" kernel source
Posted Mar 1, 2011 10:44 UTC (Tue) by ekj (guest, #1524) [Link]
Thus I don't consider "source to everyone" some sort of huge gift over "source to the customers" -- the former is a lot simpler and cheaper than the latter. (bandwith is -also- cheap these days - *especially* for Open Source software where it's generally easy to get mirrors for free)
Red Hat's "obfuscated" kernel source
Posted Mar 1, 2011 13:19 UTC (Tue) by vonbrand (guest, #4458) [Link]
Not really. You can just give the customer the binaries and the source in the same deal. I.e., you get binaries + source, even if you don't ask for source. Ditto for any updates. No need to keep track of anything extra this way.
Red Hat's "obfuscated" kernel source
Posted Mar 3, 2011 1:28 UTC (Thu) by dag- (guest, #30207) [Link]
I guess we can drop that from the list of conspiracies :-)
Red Hat's "obfuscated" kernel source
Posted Mar 3, 2011 7:09 UTC (Thu) by ekj (guest, #1524) [Link]
The observation was, that online, the extra work involved in offering sourcecode to everyone - over offering it only to customers, is typically very little, and it can even be easier to offer it to everyone.
Thus, very little gratitude is required for going "above and beyond" the duties by giving sourcecode to everyone, rather than just customers. Yeah it's an advantage, but it's a tiny contribution. (even if they -did- give the source only to customers, free-for-all mirrors of these source-packages would spring up in a matter of days automagically.)
RedHat does however do many things that are significant positive contributions to the Open Source community, for example several paid employees of theirs are regular contributors to central projects.
Red Hat's "obfuscated" kernel source
Posted Mar 3, 2011 10:16 UTC (Thu) by dag- (guest, #30207) [Link]
And my response was that they now are already offering it "only to customers" through RHN. So there's no cost for them to stop offering it to everyone, if they wanted to. Of course, Red Hat has generally benefited from the RHEL-rebuild scene and the wide availability of RHEL-rebuilds in markets Red Hat is not targeting is making RHEL very attractive. That's why I always described the Red Hat/CentOS relation as a symbiosis.
> (even if they -did- give the source only to customers, free-for-all mirrors of these source-packages would spring up in a matter of days automagically.)
Then one can only wonder why this never happened for Novell, which did only offer source-packages to customers. No free-for-all mirrors ever appeared, despite a demand from the community, and hence no community SLES project.
Red Hat's "obfuscated" kernel source
Posted Mar 1, 2011 10:49 UTC (Tue) by daniels (subscriber, #16193) [Link]
Red Hat's "obfuscated" kernel source
Posted Mar 1, 2011 17:55 UTC (Tue) by jspaleta (subscriber, #50639) [Link]
In this specific case, the underlying issue here is the attempt by other multi-vendors to "sync" their offering in some way. This wouldn't really have come up as a potential scandal if the effort to "sync" wasn't under way. No one pounds on Cisco/Linksys to make code available widely because the kernel they ship in their embedded junk isn't a cross-vendor "sync" target.
There is and there will always be a tension between standardization and differentiation between vendors in the marketplace. This round of "syncing" as mentioned in the original interview isn't the first such effort in the inherent tug of war of market interests. Anyone else remember the United Linux effort? I believe the current "syncing" effort at the kernel layer is similar in motivation if not in scope. It will be interesting if such cross-distro syncing becomes an important aspect of closing customer deals or not. The question remains as to whether the paying market values that cross-distro syncing effort. Time will tell. It's far from clear how important such standardization is in the final analysis.
-jef
Red Hat's "obfuscated" kernel source
Posted Mar 1, 2011 22:10 UTC (Tue) by jrn (subscriber, #64214) [Link]
Really?
Red Hat's "obfuscated" kernel source
Posted Mar 1, 2011 22:16 UTC (Tue) by jspaleta (subscriber, #50639) [Link]
-jef
Red Hat's "obfuscated" kernel source
Posted Mar 1, 2011 22:34 UTC (Tue) by jrn (subscriber, #64214) [Link]
I don't think that has too much to do with standardization. To give another example, many people _are_ upset that Google does not make their work on Android public as it happens but only makes code drops now and then. That is for many reasons, including wanting to be able to take advantage of hardware support from that tree and to increase its code quality.
Red Hat's "obfuscated" kernel source
Posted Mar 1, 2011 22:51 UTC (Tue) by jspaleta (subscriber, #50639) [Link]
-jef
practical difficulties
Posted Feb 28, 2011 19:05 UTC (Mon) by mcoleman (guest, #70990) [Link]
The snarky view
Posted Mar 3, 2011 22:47 UTC (Thu) by jmorris42 (guest, #2203) [Link]
We here at LWN aren't RH's target customer. If you can debug kernel problems you don't need them and should be using a RHEL Rebuild or Debian. If you have a problem you are supposed to be competent enough to file a trouble ticket and wait but that is all. If you know more your employer is either overpaying you or you are working for less than you should be.
RHEL is normally for hosting commerical apps where you can't really see what is going on so any problem is sorted out by filing trouble tickets and eventually getting the software vendor and/or the OS vendor to fix it. And while things are smoking and business isn't happening it is all good, because you have a trouble ticket number which officially makes it an SEP (Someone Else's Problem). Admins in those settings are typically certification chasers, not real hackers.
The snarky view
Posted Mar 3, 2011 23:12 UTC (Thu) by mcoleman (guest, #70990) [Link]
Waaah. Life goes on.
In the mean time, I still try to do the best work I can.
Is Red Hat in financial trouble?
Posted Feb 28, 2011 19:34 UTC (Mon) by NightMonkey (subscriber, #23051) [Link]
Would this really put a crimp in CentOS's style? Yeah, I see that doing big tree-to-tree diffs to extract changes in the RedHat source would be unfun, but still possible. At least bugs could be better pinned to non-vanilla kernel source with such a diff. Or am I missing the piece that really hurts CentOS and friends?
I hope that RedHat changes their hive-mind regarding this. I hope that even if they keep this new approach, they don't go all "talk to the hand" to LWN and other community news outlets regarding it... That's just really poor community relations, and it will bite them over time.
Is Red Hat in financial trouble?
Posted Feb 28, 2011 19:49 UTC (Mon) by hp (guest, #5220) [Link]
To date Red Hat has always grown revenue by growing costs also, and they just are not that profitable compared to a Microsoft or an Apple or other proprietary software companies.
I think Red Hat would say that this is because they're still investing in the business and don't want to just hoard cash when they can build the business instead. Whether you believe this is a key question if you are investing in Red Hat.
So what they have to do _eventually_ is somehow increase revenue without increasing costs. This could mean raising prices, or just using their resources more efficiently, or whatever it is.
But, you should expect Red Hat to feel pressure to expand margins and act accordingly. In this sense they are in "financial trouble" - it's not that they're going to go bankrupt, but unquestionably current investors in Red Hat expect them to become more profitable than they are today. And Red Hat's management has a fiduciary responsibility to try to maximize shareholder value.
Is Red Hat in financial trouble?
Posted Feb 28, 2011 21:38 UTC (Mon) by daglwn (guest, #65432) [Link]
> shareholder value.
And right there is the failing of U.S.-style capitalism. Fiduciary responsibility is the only relevant factor. Moral responsibility doesn't even enter the equation for management.
We are just seeing the beginning of what we're going to reap from this highly warped value system we've built.
Is Red Hat in financial trouble?
Posted Feb 28, 2011 22:01 UTC (Mon) by hp (guest, #5220) [Link]
Practically speaking, though, the question is how much they _can_ raise the margins and how quickly.
Is Red Hat in financial trouble?
Posted Feb 28, 2011 22:19 UTC (Mon) by boog (subscriber, #30882) [Link]
- a FOSS business is expected to have low margins;
- monopolies have high margins that should be undercut by FOSS companies;
- nothing is stopping RH taking a long-term view of shareholder value (growing the cake not their slice); does that charming American law mention a time limit?
As a non-FOSS example of the last point, take Apple, who happily and repeatedly make their own top-selling products obsolete with their breakneck pace of development; many companies really struggle not to rest on their laurels in that kind of situation.
Debian seems to be the tortoise in this race.
Is Red Hat in financial trouble?
Posted Feb 28, 2011 22:31 UTC (Mon) by hp (guest, #5220) [Link]
I do agree that high margins will involve some competitive advantage, but I don't think it has to go so far as a monopoly. My view is that "monopolistic competition" as an economics textbook would say is a good balance between interests of the company and the consumer. These are the Cokes and Wrigleys, where they can't charge infinite amounts for sugar water and gum, but they do have some pricing power. Bob Young's vision for Red Hat in 1998 was a story about Heinz.
I think most people would say that management is supposed to focus on long-term value. Stocks are normally valued assuming perpetual duration.
But it's context-dependent; if a manager thinks the best outcome for shareholders is to liquidate the company and give them their money back, they're also supposed to do that. Some stocks obviously will not have perpetual duration.
In practice managers can do pretty much whatever they want, since there's no way to prove in court that such-and-such complex judgment was wrong. But managers who don't have investor confidence may not last very long.
If you were Red Hat management, you can't come out and say "oh, we'll have bad margins." The stock price would crater. In an interview a while ago, Red Hat's CEO said something like he'd compromised with analysts and agreed to increase margins 1% per year.
moral responsibility
Posted Feb 28, 2011 22:17 UTC (Mon) by dbruce (guest, #57948) [Link]
Short term, sure, all the time we see companies doing dubious things to make the quarterly reports match up to market expectations. "Fiduciary responsibility" gets used as an excuse for almost any kind of trickery, but it doesn't mean the whole idea of investor-owned business is wrong.
Put it this way, if investors are in it for the long run, they are going to want management to do things that will win customers and keep them loyal for many years.
moral responsibility
Posted Mar 1, 2011 3:13 UTC (Tue) by allesfresser (guest, #216) [Link]
And therein lies the problem: most investors are not it in for the long run--that would require that they actually care about what the company does and why it does it. They are looking for essentially pump-and-dump results. When investors don't actually care about the company or its products, but only what money they can get out of it, it's not investing, but sociopathic gambling.
moral responsibility
Posted Mar 1, 2011 11:54 UTC (Tue) by dbruce (guest, #57948) [Link]
Do you have any data on that? My understanding is that the largest chunk of money in the stock market gets there via mutual funds. I don't think the typical fund manager has a "pump-and-dump" strategy. I know there is a popular image of the stock market as a place for wheeler-dealer day traders, and a lot of that activity certainly exists, but I thought that the bulk of stock investment actually is long-term buy-and-hold.
moral responsibility
Posted Mar 1, 2011 13:34 UTC (Tue) by nivola (guest, #5662) [Link]
Average stock hold time: 22 seconds.
Stock markets have changed pretty radically in the last 30 years, and not for the better. Hudson is talking about US markets here, but it's a similar story in Europe and elsewhere.
fishy statistics warning
Posted Mar 1, 2011 17:18 UTC (Tue) by jku (subscriber, #42379) [Link]
That figure is probably bogus and in any case not necessarily relevant: High frequency traders may do massive amounts of trades per day but large amounts of stock is still owned by long term investors. Trading the same stock thousands of times per day doesn't magically move the long term investments into the market.
It seems that the real mean duration of holding is still measured in months.
Is Red Hat in financial trouble?
Posted Mar 1, 2011 3:42 UTC (Tue) by tialaramex (subscriber, #21167) [Link]
The existence of the stock market does encourage some people to buy and sell stocks without knowing anything about the company (perhaps not even the name, the ticker symbol is enough to buy and sell) but the lack of interest by investors in non-financial goals is a failing of the investors and not of the businesses. In my experience the largest fraction of companies have a clear purpose stated in their paperwork, and many have a purpose that a layman would instantly understand like "sell people coffee" or "build skyscrapers" and thus investors do have the information to make ethical decisions if they choose to do so.
Red Hat, I think, says it makes Free Software operating systems (I won't swear what terms they use exactly). It cannot become a used furniture store without going through a process to change the paperwork or risking a lawsuit by investors. Until it does that, you can expect that producing Free Software will be a goal balanced with making money to keep the financial people happy. From time to time that will mean we don't get what we want, and we don't have to be happy about that (I think this change was stupid) but we shouldn't think its the end of the world.
Is Red Hat in financial trouble?
Posted Mar 1, 2011 16:12 UTC (Tue) by mpr22 (subscriber, #60784) [Link]
My understanding is that in England, the purpose of a company limited by shares is habitually stated in its paperwork to be "carrying out business". This avoids paperwork-wrangling when you decide that you'd like to carry out a kind of business you hadn't initially considered.
Is Red Hat in financial trouble?
Posted Mar 1, 2011 7:05 UTC (Tue) by paulj (subscriber, #341) [Link]
Is Red Hat in financial trouble?
Posted Mar 1, 2011 5:16 UTC (Tue) by yuhong (guest, #57183) [Link]
FYI, see this: http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1013744
Is Red Hat in financial trouble?
Posted Mar 1, 2011 6:40 UTC (Tue) by rodgerd (guest, #58896) [Link]
One can argue whether *this* response is a good one or not, but RedHat would be complete idiots not to be ready to fight. And while those Linux users who are stuck in the 1999 /. "RedHat are the Microsoft of Linux" view of the universe, I invite folks to consider what Oracle have done to Sun, MySQL, and Java when they consider whether this is would be a desireable outcome.
Is Red Hat in financial trouble?
Posted Mar 1, 2011 17:04 UTC (Tue) by brunowolff (guest, #71160) [Link]
Is Red Hat in financial trouble?
Posted Mar 1, 2011 17:16 UTC (Tue) by rodgerd (guest, #58896) [Link]
Red Hat's "obfuscated" kernel source
Posted Feb 28, 2011 20:16 UTC (Mon) by dps (guest, #5725) [Link]
I suspect RH's stock configurations work but mine did not.
I managed to build stock 2.6.32.9 with configuration any problem but I have no clue how close this is to the RH tar ball.
Red Hat's "obfuscated" kernel source
Posted Feb 28, 2011 20:58 UTC (Mon) by miguelzinho (guest, #40535) [Link]
Red Hat's "obfuscated" kernel source
Posted Feb 28, 2011 21:43 UTC (Mon) by lkundrak (subscriber, #43452) [Link]
Red Hat's "obfuscated" kernel source
Posted Mar 1, 2011 21:50 UTC (Tue) by daniel (guest, #3181) [Link]
More probably it would be a death sentence for Red Hat and a huge boost for Ubuntu.
Red Hat's "obfuscated" kernel source
Posted Feb 28, 2011 21:41 UTC (Mon) by lkundrak (subscriber, #43452) [Link]
This is rather unfortunate; the patch list has been helpful to me numerous times, both when hunting down regressions against stock kernel and to quickly inspect whether a backported feature or a fix is present.Also, the snapshot kernels are gone, with an explanation from linville that it's Red Hat's policy now.
On the other hand, I've not paid for anything from Red Hat anyway, just am wondering whether paying customers are stripped off those rather valuable resources as well.
Red Hat's "obfuscated" kernel source
Posted Feb 28, 2011 22:01 UTC (Mon) by mmahut (guest, #45550) [Link]
On the other hand, I've not paid for anything from Red Hat anyway, just am wondering whether paying customers are stripped off those rather valuable resources as well.I don't think they are. As a customer you have access to an interface that let you browse these sources with references to erratas, bugzillas, changelogs and patches now.
Red Hat's "obfuscated" kernel source
Posted Mar 1, 2011 13:52 UTC (Tue) by ixs (subscriber, #47170) [Link]
I have been looking around https://access.redhat.com and cannot see anything like a kernel source browser.
Any pointers? Thx.
Red Hat's "obfuscated" kernel source
Posted Mar 2, 2011 10:35 UTC (Wed) by lkundrak (subscriber, #43452) [Link]
(Customer Portal -> Knowledge -> Source)
Red Hat's "obfuscated" kernel source
Posted Feb 28, 2011 21:56 UTC (Mon) by mmahut (guest, #45550) [Link]
Red Hat's "obfuscated" kernel source
Posted Feb 28, 2011 22:05 UTC (Mon) by lkundrak (subscriber, #43452) [Link]
It's the other way around
Posted Mar 1, 2011 6:42 UTC (Tue) by khim (subscriber, #9252) [Link]
Customers don't get merged patched. Everyone else get merged patches so customers indeed are getting more :-)
It's the other way around
Posted Mar 1, 2011 8:47 UTC (Tue) by gnufreex (guest, #70396) [Link]
Everyone is getting less. Customers get same.
It's the other way around
Posted Mar 1, 2011 11:18 UTC (Tue) by mmahut (guest, #45550) [Link]
As a customer I have now access to the "Source Browser" section in the Customer Portal that let me browse through the code (patches included). It looks similar to an opengrok instance.
It's the other way around
Posted Mar 2, 2011 6:11 UTC (Wed) by gdt (subscriber, #6284) [Link]
But as a customer I lose the ability to straight-forwardly rebuild a kernel dropping a problematic patch.
It's the other way around
Posted Mar 3, 2011 12:06 UTC (Thu) by mmahut (guest, #45550) [Link]
Red Hat's "obfuscated" kernel source
Posted Feb 28, 2011 22:12 UTC (Mon) by cyperpunks (subscriber, #39406) [Link]
Red Hat's "obfuscated" kernel source
Posted Feb 28, 2011 22:31 UTC (Mon) by lkundrak (subscriber, #43452) [Link]
Red Hat's "obfuscated" kernel source
Posted Mar 1, 2011 6:34 UTC (Tue) by butlerm (subscriber, #13312) [Link]
Red Hat's "obfuscated" kernel source
Posted Mar 1, 2011 9:14 UTC (Tue) by jamesh (guest, #1159) [Link]
It was good idea before the "Unbreakable Linux"
Posted Mar 1, 2011 14:54 UTC (Tue) by khim (subscriber, #9252) [Link]
Well, these customers can easily switch to Oracle's Linux so in a sense they are already lost. It customers which need to run more then Oracle's DB that are at stake...
It was good idea before the "Unbreakable Linux"
Posted Mar 2, 2011 6:58 UTC (Wed) by jamesh (guest, #1159) [Link]
It is far from clear that the loss of customers would be offset by whatever gains they get from not letting Oracle certify their software on RH's platform.
Of course Oracle will be certified!
Posted Mar 2, 2011 14:28 UTC (Wed) by khim (subscriber, #9252) [Link]
Huh? Where the idea to not certify the Oracle comes from? It's actually backwards: Oracle gives certificate, not RedHat.
And this is the problem: if user only cares about Oracle certificate and has no interest in anything else then there are no realistic way to keep him/her. If, on the other hand, he/she cares about other kinds of certification then it's in RedHat's interest to make sure this certificate can not be easily obtained by Unbreakable Linux too. And for that it must make sure Oracle can not just use components of RHEL. It must build them from scratch and, more importantly, Unbreakable Linux certificate must be earned by each ISV, not added on the cheap.
CentOS is not a problem here: it carries no certificates and is not interested in carrying them. Unbreakable Linux does carry them - and this trend must be stopped or at least slowed down.
Of course Oracle will be certified!
Posted Mar 3, 2011 9:50 UTC (Thu) by jamesh (guest, #1159) [Link]
If Red Hat cuts off Oracle's access to RHEL completely, then Oracle can't certify their software on that platform.
This is exactly why this license exist...
Posted Mar 3, 2011 10:46 UTC (Thu) by khim (subscriber, #9252) [Link]
Sure, but then Oracle is constrained by support contract and can not just lift patches from RHEL and land them in Unbreakable Linux.
This is not about the physical ability of doing something: of course the team which certifies RHEL can pass patches around to the team which polishes Unbreakable Linux - but then Oracle will be in very hot water and will be forced to pay sizable sum for damages incurred.
How well it'll work remains to be seen, but the idea is simple enough.
This is exactly why this license exist...
Posted Mar 3, 2011 11:18 UTC (Thu) by PaXTeam (guest, #24616) [Link]
sure they can, otherwise RH would be violating GPL2 section 6 ("You may not impose any further restrictions on the recipients' exercise of the rights granted herein.")
whether they 'retaliate' by tearing up the support contract is a different matter, it has zero bearing on the legality of redistributing RH kernel patches.
Red Hat's "obfuscated" kernel source
Posted Mar 2, 2011 0:49 UTC (Wed) by mleu (guest, #73224) [Link]
Red Hat's "obfuscated" kernel source
Posted Feb 28, 2011 22:18 UTC (Mon) by PaulWay (guest, #45600) [Link]
It's going to be interesting to see how RH spins this, especially if it's now public knowledge that most of their developers are unhappy with it.
Have fun,
Paul
Red Hat's "obfuscated" kernel source
Posted Feb 28, 2011 22:26 UTC (Mon) by lkundrak (subscriber, #43452) [Link]
Red Hat's "obfuscated" kernel source
Posted Mar 1, 2011 2:06 UTC (Tue) by paravoid (subscriber, #32869) [Link]
Debian's kernel tree, with all of its modifications (which *are* significant) remains availabe in a proper format for everyone to distribute, work on it, fork it or any other purpose with the only limitations being the ones that are mandated by the GPL.
This tree is not under any corporation's control and fulfills no agenda besides the one that serves Debian's (and its derivatives) users.
Please remember that and thank these people.
Red Hat's "obfuscated" kernel source
Posted Mar 1, 2011 8:54 UTC (Tue) by akurtakov (guest, #62232) [Link]
Red Hat's "obfuscated" kernel source
Posted Mar 1, 2011 22:33 UTC (Tue) by dowdle (subscriber, #659) [Link]
It is possible I've overlooked one or two on a few releases and I haven't really been looking at it that hard... but Red Hat has been the #2 contributor to the kernel for some time.
Debian makes a fine distribution, makes it for a lot of arches, and packages up a lot of packages... but when it comes to original development work in core components, to the best of my knowledge, they do not stand out at all. On the other hand, Red Hat stands on a number of projects including the kernel, gcc, x.org, gnome, etc.
Trying to turn this into an opportunity to switch users to Debian seems a little too convenient. I hear some people tell me, because I'm an pro-Red Hat advocate, that they will never use Red Hat software... and my response is that no matter what Linux distro you use, you are using a lot of software Red Hat has developed. I don't think anyone who has actually look into it is willing to argue with me on that point.
Red Hat's "obfuscated" kernel source
Posted Mar 1, 2011 22:41 UTC (Tue) by paravoid (subscriber, #32869) [Link]
From Maximilian's interview:
Ben Hutchings is the Nr.1 contributor for 2.6.33. He also is top listed as author of patches on stable 2.6.32. Debian is not listed as organization as many send their linux-2.6 patches from their corporate or personal email address and thus it won’t be attributed to Debian. There is currently no means to see how many patches get forwarded for the stable tree, but I certainly forwarded more then fifty patches. I was very happy when Greg KH personally thanked me in the 2.6.32.12 release.
And this was not an attempt on switching users, but merely a give credit where credit is due attempt. Nor I disagree with you on RedHat's contributions.
Red Hat's "obfuscated" kernel source
Posted Mar 1, 2011 23:05 UTC (Tue) by dowdle (subscriber, #659) [Link]
When Jon Corbet first started doing his analysis of who made kernel X... and it became an ongoing feature... I emailed him to ask why Debian didn't show up... if it was because they are harder to identify... or if it was because they don't contribute as much to kernel development. It was a while ago and I'm not quoting... but I believe he said... as far as he could tell they weren't contributing to the things he was measuring.
I don't think the Debian development community cares as much about getting credit... but it wouldn't be a bad thing for them to make some effort to become more measurable in such surveys... if they are indeed contributing more than they are being credit with. I'm not sure what that would take but I'm guessing those doing the measuring could give some valuable clues.
I certainly would like to see the Debian developers get credit for the work they do.
Red Hat's "obfuscated" kernel source
Posted Mar 2, 2011 0:22 UTC (Wed) by neilbrown (subscriber, #359) [Link]
Redhat are a software distributor and a development house and a support service (and probably other things).
Debian is a software distribution.
The kernel patches from "redhat" are almost certainly mostly from the "development house" side of redhat. There is no corresponding part of Debian.
I really don't expect 'Debian' to contribute much in the way of kernel patches (though I suspect they channel their fair share of bug reports, which are just as valuable). When individuals who happen to be Debian developers also happen to do kernel development I suspect they are not doing so as a "Debian developer" but in some other role (employee of some company, independent enthusiast or whatever).
As a software distributor you might expect Debian to appear in surveys such as "how widely used" or "user preference" or "number of packages" or "number of bug reports" or "frequency of releases", and I thing Debian does OK in most of those.
Red Hat's "obfuscated" kernel source
Posted Mar 2, 2011 5:36 UTC (Wed) by JoeBuck (subscriber, #2330) [Link]
Yes, and there is no organization called "Debian" paying developers so they can work full time on the kernel. There certainly are Debian developers making significant contributions all over the place, but the RHEL revenue is making it possible for many people to do nothing else but work on free software.
Red Hat's "obfuscated" kernel source
Posted Mar 4, 2011 8:07 UTC (Fri) by smurf (subscriber, #17840) [Link]
My point would be that they didn't invent the wheel (i..e the kernel) here. There got to where they are now because lots of others play by the rules and don't obfuscate their code, or its origins.
While Oracle doesn't play nice with Open Source, kowtowing to their level of "this is our code, whether the community likes it or not" boneheadedness and doing essentially the same thing is not the way forward: Oracle isn't going to change its business practice because of what Red Hat does or doesn't do with its kernel patches.
Summary: This step benefits nobody.
It may even hurt Red Hat directly, if a couple of their kernel people get disgusted enough about this attitude that they leave.
Red Hat's "obfuscated" kernel source
Posted Mar 5, 2011 15:32 UTC (Sat) by BenHutchings (subscriber, #37955) [Link]
When individuals who happen to be Debian developers also happen to do kernel development I suspect they are not doing so as a "Debian developer" but in some other role (employee of some company, independent enthusiast or whatever).
I work on the kernel as a Debian developer, fixing bugs where I can see how to and occasionally developing features that are important to Debian and its users. I also work on the kernel as an employee of Solarflare, but this is a pretty well separate role, as my employer does not use or claim to support Debian.
they will lose some customers over this
Posted Mar 1, 2011 2:15 UTC (Tue) by brouhaha (subscriber, #1698) [Link]
I've been considering buying RHEL 6 licenses for my servers, which currently run Fedora. I like Fedora but would prefer RHEL for longer-term stability. However, I have on multiple occasions had to debug kernels by rebuilding from RPMs with some patches disabled. The way past RHEL kernel RPMs worked (and Fedora kernel RPMS) made this very easy. I'm unwilling to switch to a distribution that flattens the patches into their distributed kernel sources, even if they have provided some separate mechanism for customers to get access to the individual patches.
they will lose some customers over this
Posted Mar 1, 2011 2:37 UTC (Tue) by jspaleta (subscriber, #50639) [Link]
Those of us who are not paying customers(and I am not a paying Red Hat customer) can still have impact if we engage in reasoned debate on the merits of a policy and the actual harm it is causing to the ecosystem. As a Fedora community member and Fedora user this particular policy change does not directly nor does it indirectly impact me, so I don't have an authoritative voice in challenging the policy. The kernel in question is effectively dead to me. As a CentOS user it matters somewhat more, but I'm not yet sure how much more yet.
But what seldom works in coercing any business into changing its policy, is to suggest that you were thinking about being a customer and now you have been turned off because of a policy change. Even if its true, you haven't risked anything by saying it and you haven't guaranteed them any income if they revert the policy. Since you weren't a customer before the policy change there's no reasonable expectation that reverting the policy will in fact make you a new customer.
-jef
So true...
Posted Mar 1, 2011 6:47 UTC (Tue) by khim (subscriber, #9252) [Link]
Yup - that's exactly right. Business people are monitoring these things, you know. When such "stupid change" are introduced there are lots of talks about how "I will not support them because of X", but then adoption rate shows that very few people actually care.
When people really do care (think SONY's rootkit fiasco, for example) companies backpedal furiously. But I doubt it's the case here: people who are build the RHEL subscriptions and people who are hacking kernel in the same organizations are usually just totally different people so I doubt this change will affect adoption rate all that much.
Red Hat's "obfuscated" kernel source
Posted Mar 1, 2011 12:22 UTC (Tue) by lmb (subscriber, #39048) [Link]
SUSE uses a git tree internally too, and builds from the tarball (it speeds up the build considerably, relative to applying thousands of patches). However, the SUSE kernel git repository is mirrored publicly on gitorious.
Red Hat's "obfuscated" kernel source
Posted Mar 1, 2011 19:37 UTC (Tue) by kolyshkin (guest, #34342) [Link]
Red Hat's "obfuscated" kernel source
Posted Mar 1, 2011 21:15 UTC (Tue) by nix (subscriber, #2304) [Link]
Red Hat's "obfuscated" kernel source
Posted Mar 2, 2011 2:31 UTC (Wed) by rriggs (guest, #11598) [Link]
We were expecting something along these lines. It is unfortunate. But I don't know what I would do were I in Red Hat's shoes.
Red Hat's "obfuscated" kernel source
Posted Mar 2, 2011 14:10 UTC (Wed) by dskoll (subscriber, #1630) [Link]
Red Hat has been very clear with their customers for at least the last 6 months that something like this was going to happen because certain competitors were taking advantage of their openness, repackaging Red Hat's work as their own.
Excuse me??? Isn't Red Hat's entire business built around taking advantage of the openness of thousands of Free Software developers and repackaging their work?
I'm not saying it's wrong of Red Hat to build a business around that. It clearly isn't; those thousands of Free Software authors have consented to allow this by licensing their works under the GPL. It's just a bit rich for Red Hat to complain that others are doing to its work exactly what Red Hat has been doing for 15+ years.
Red Hat's "obfuscated" kernel source
Posted Mar 3, 2011 0:32 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]
This "righteous indignation" would amuse me if it didn't sadden me.
Posted Mar 2, 2011 2:31 UTC (Wed) by linux.whiz (guest, #73256) [Link]
How do they do that? They hire the best and the brightest developers from the community, enabling them to work full time on Linux and related technologies. Then Red Hat charges a fair price for their work so they can pay those developers and support teams and documentation teams and so on.
That's completely reasonable - who doesn't want to be fairly compensated? But how is Red Hat rewarded? Oracle, CentOS and other respins take all their hard work but make sure Red Hat is not compensated. Where is all your righteous indignation when stuff that happens? Where is the hue and cry about the "Spirit of Free Software" there?
I don't recall anything in the Free Software manifesto saying "it's ok, when someone is asking to be fairly compensated, to take their work and make sure they don't get paid for it." I certainly don't imagine that was the goal. I know that it is within the *letter* of the law, but c'mon, we're talking about the *spirit* here, aren't we?
Please. Be honest, people. The vast majority of you are really saying "I'm pissed because I might not get my stuff for free anymore!!! WAAAAH!!!"
This "righteous indignation" would amuse me if it didn't sadden me.
Posted Mar 2, 2011 3:01 UTC (Wed) by foom (subscriber, #14868) [Link]
No, not really. People can still get the stuff for free via CentOS no matter whether the patchset is broken out or not...all this move really seems to do is hurt collaboration with other distros on kernel maintenance.
This "righteous indignation" would amuse me if it didn't sadden me.
Posted Mar 3, 2011 22:36 UTC (Thu) by xilun (guest, #50638) [Link]
The spirit of free software is at a place you just demonstrated with your comment that you don't understand the begining of. The spirit of free software is the ability for anybody to help its neighbour without condition (with the precision that when a definition of "help" is needed, it's right to exclude the possibility to allow third parties to remove this ability for others, because the ability to harm others and/or refuse to help them would obviously not qualify for "help"), and you certainly are not in the spirit of free software when you voluntarily undermine / deteriorate the quality of what you provide to both your customer, upstream, and the linux community at large and when you ask your customers to chose between their freedom of helping themselves and third parties and other contractual relationship with RH (faced with such a choice, my hope is that as many as possible customers of RH will indeed chose to retain their ability to help others, so will terminate their relationship with a player gone rogue that tries to be harmful to the community by distributing their work in an deliberately obfuscated way in the displayed and recognised attempt to slow down customers and the community and make their work artificially more difficult). There are indeed lots of people who even think with good arguments that this RH move is indeed even against the _letter_ of the GPLv2 (on top of being obviously against the spirit of free software...)
Red Hat's "obfuscated" kernel source
Posted Mar 4, 2011 10:08 UTC (Fri) by psuresh (guest, #53229) [Link]
OTH, if the future updates are restricted to paid subscribers only, it means non-subscribers have to resort to _other means_ for getting those patches and it is definitely against the principles and spirit of free software. :(
Red Hat's "obfuscated" kernel source
Posted Mar 5, 2011 0:33 UTC (Sat) by mgross (guest, #38112) [Link]
It will force more knock off distributions to align more closely with up stream as opposed to RH. There is too much waisted effort making yet another RH clone. We can do better things with our energies going into upstream projects than making RH knock-offs.
Red Hat's "obfuscated" kernel source
Posted Mar 6, 2011 22:30 UTC (Sun) by vonbrand (guest, #4458) [Link]
It is certainly not our call to make on what people "waste" their efforts... if somebody finds it useful, more power to the "wasters"; if not, it might just show bad judgement, in which case they'd better stay away ;-)
Red Hat's "obfuscated" kernel source
Posted Mar 6, 2011 9:31 UTC (Sun) by riteshsarraf (subscriber, #11138) [Link]
The next round of actions would be to do one single, large, monolithic commit on the public git repository derived from finer commits off of a private git repository. This would still allow compliance with the GPL.
Red Hat's "obfuscated" kernel source
Posted Apr 4, 2011 20:43 UTC (Mon) by saucito (guest, #74064) [Link]
Red Hat's "obfuscated" kernel source
Posted Apr 7, 2011 4:58 UTC (Thu) by redbeard (guest, #74129) [Link]