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

Red Hat's "obfuscated" kernel source

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

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

Red Hat's "obfuscated" kernel source

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

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

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

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

Red Hat's "obfuscated" kernel source

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

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

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

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

Red Hat's "obfuscated" kernel source

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

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

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

Red Hat's "obfuscated" kernel source

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

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

Red Hat's "obfuscated" kernel source

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

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

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

Red Hat's "obfuscated" kernel source

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

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

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

*sigh* the follies of youth...

Red Hat's "obfuscated" kernel source

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

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

Red Hat's "obfuscated" kernel source

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

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

Red Hat's "obfuscated" kernel source

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

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

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

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

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

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

Red Hat's "obfuscated" kernel source

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

Did you ask them why they made this change?

Red Hat's "obfuscated" kernel source

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

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

- It is not about Centos.

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

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

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

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

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

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

Red Hat's "obfuscated" kernel source

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

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

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

Red Hat's "obfuscated" kernel source

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

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

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

Red Hat's "obfuscated" kernel source

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

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

Red Hat's "obfuscated" kernel source

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

Test comment with Iceweasel 4.0; please ignore.

Red Hat's "obfuscated" kernel source

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

Test comment; please ignore.

Red Hat's "obfuscated" kernel source

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

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

Red Hat's "obfuscated" kernel source

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

And one final test comment.

Red Hat's "obfuscated" kernel source

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

Sorry, one more test required.

Red Hat's "obfuscated" kernel source

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

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

Red Hat's "obfuscated" kernel source

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

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

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

Red Hat's "obfuscated" kernel source

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

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

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

Red Hat's "obfuscated" kernel source

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

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

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

Red Hat's "obfuscated" kernel source

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

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

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

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

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

It's not so simple

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

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

It's not so simple

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

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

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

It's not so simple

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

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

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

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

It's not so simple

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

Oh, that's a nasty bit of business.

It's not so simple

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

No, the nasty bit is:

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

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

It's not so simple

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

Wow, that is sneaky. When was that added?

It's not so simple

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

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

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

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

-jef

It's not so simple

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

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

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

It's not so simple

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

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

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

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

-jef

It's not so simple

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

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

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

It's not so simple

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

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

It's not so simple

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

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

It's not so simple

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

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

It's not so simple

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

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

What's the complaint?

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

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

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

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

What's the complaint?

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

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

What's the complaint?

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

distributing source code to others

What's the complaint?

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

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

What's the complaint?

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

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

What's the complaint?

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

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

at what point does the cost become 'prohibiting'?

What's the complaint?

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

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

What's the complaint?

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

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

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

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

What's the complaint?

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

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

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

What's the complaint?

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

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

What's the complaint?

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

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

Nothing.

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

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

What's the complaint?

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

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

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

What's the complaint?

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

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

What's the complaint?

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

they are on the ftp site.

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

What's the complaint?

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

Yeah, but they're not in source form.

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

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

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

What's the complaint?

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

You have a definition of source that suits your argument.

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

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

What's the complaint?

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

The GPL says quite plainly:

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

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

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

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

What's the complaint?

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

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

What's the complaint?

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

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

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

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

What's the complaint?

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

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

What's the complaint?

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

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

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

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

What's the complaint?

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

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

1. RedHat work on the source in form A

2. Form B is auto-generated from A

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

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

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

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

What's the complaint?

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

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

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

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

What's the complaint?

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

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

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

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

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

What's the complaint?

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

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

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

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

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

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

GPL does not ask you to give up rights.

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

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

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

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

GPL does not ask you to give up rights.

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

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

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

GPL does not ask you to give up rights.

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

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

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

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

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

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

GPL does not ask you to give up rights.

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

You give up that right [...]

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

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

--

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

GPL does not ask you to give up rights.

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

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

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

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

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

GPL does not ask you to give up rights.

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

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

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

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

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

GPL does not ask you to give up rights.

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

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

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

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

GPL does not ask you to give up rights.

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

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

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

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

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

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

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

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

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

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

GPL does not ask you to give up rights.

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

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

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

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

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

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

GPL does not ask you to give up rights.

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

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

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

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

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

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

GPL does not ask you to give up rights.

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

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

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

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

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

GPL does not ask you to give up rights.

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

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

GPL does not ask you to give up rights.

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

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

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

Huh?

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

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

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

Huh?

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

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

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

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

Heh...

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

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

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

The GPL grants you rights under certain conditions.

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

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

Sure.

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

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

Therefore, Red Hat is adding restrictions to the GPL.

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

Heh...

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

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

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

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

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

What rights?

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

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

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

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

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

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

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

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

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

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

What rights?

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

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

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

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

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

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

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

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

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

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

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

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

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

Once again...

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

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

I'm not claiming that. RedHat does.

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

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

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

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

Once again...

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

I'm not claiming that. RedHat does.

Red Hat is full of crap if it claims that.

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

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

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

RedHat had not invented anything

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

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

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

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

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

GPL does not ask you to give up rights.

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

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

GPL does not ask you to give up rights.

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

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

It's not so simple

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

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

It's not so simple

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

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

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

It's not so simple

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

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

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

It's not so simple

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

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

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

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

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

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

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

It's not so simple

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

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

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

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

It's not so simple

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

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

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

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

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

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

It's not so simple

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

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

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

It's not so simple

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

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

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

It's not so simple

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

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

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

Wow. Talk about fogetting history.

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

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

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

Sorry, but this ship sailed long ago.

Wow. Talk about fogetting history.

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

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

It's not so simple

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

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

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

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

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

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

It's not so simple

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

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

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

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

It's not so simple

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

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

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

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

It's not so simple

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

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

It's not so simple

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

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

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

It's not so simple

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

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

It's not so simple

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

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

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

It's not so simple

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

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

It's not so simple

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

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

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

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

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

It's not so simple

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

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

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

It's not so simple

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

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

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

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

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

It's not so simple

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

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

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

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

It's not so simple

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

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

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

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

It's not so simple

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

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

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

It's not so simple

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

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

It's not so simple

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

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

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

It's not so simple

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

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

It's not so simple

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

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

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

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

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

It's not so simple

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

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

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

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

It's not so simple

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

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

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

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

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

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

It's not so simple

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

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

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

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

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

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

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

It's not so simple

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

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

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

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

It's not so simple

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

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

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

Red Hat's "obfuscated" kernel source

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

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

Official (and disappointing) answer from RH press service :

Hi Patrick
We have no comment.

thanks,
Kerri

Red Hat's "obfuscated" kernel source

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

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

Red Hat's "obfuscated" kernel source

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

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

Red Hat's "obfuscated" kernel source

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

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

Red Hat's "obfuscated" kernel source

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

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

Red Hat's "obfuscated" kernel source

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

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

Red Hat's "obfuscated" kernel source

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

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

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

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

Red Hat's "obfuscated" kernel source

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

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

http://gpl-violations.org/

Red Hat's "obfuscated" kernel source

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

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

Red Hat's "obfuscated" kernel source

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

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

Red Hat's "obfuscated" kernel source

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

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

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

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

Red Hat's "obfuscated" kernel source

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

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

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