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

Red Hat's "obfuscated" kernel source

Posted Mar 1, 2011 0:07 UTC (Tue) by jspaleta (subscriber, #50639)
In reply to: Red Hat's "obfuscated" kernel source by daniels
Parent article: Red Hat's "obfuscated" kernel source

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

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

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

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

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

-jef

to post comments

Red Hat's "obfuscated" kernel source

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

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

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

Red Hat's "obfuscated" kernel source

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

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

Red Hat's "obfuscated" kernel source

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

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

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

Red Hat's "obfuscated" kernel source

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

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

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

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

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

Red Hat's "obfuscated" kernel source

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

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

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

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

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

Red Hat's "obfuscated" kernel source

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

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

Red Hat's "obfuscated" kernel source

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

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

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

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

-jef

Red Hat's "obfuscated" kernel source

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

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

Really?

Red Hat's "obfuscated" kernel source

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

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

-jef

Red Hat's "obfuscated" kernel source

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

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

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

Red Hat's "obfuscated" kernel source

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

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

-jef