Commentary: Concerns over UnitedLinux forking Free Software projects

I would like to say that I was ecstatic when I first read the speculation about UnitedLinux when the news was first leaked. I completely support any initiative that companies use to work together and collaborate on the creation of their products.
Also, I’d like to take this moment to applaud Caldera, SuSE, Conectiva, and Turbolinux for creating UnitedLinux with the LSB, FHS, and many other standards in mind. This is certainly a wise choice and one that will help the community a great deal as the GNU/Linux landscape becomes more diverse and Free Software itself becomes more important.

One thing continues to bother me about UnitedLinux: Why?

Why are they doing this? The obvious answer is “Well, duh. They want to cut down on their individual costs and distribute their labor.” But that’s already what they do. When you contribute to any given Free Software project, this is precisely what you’re doing. You’re cutting down on your own initial labor to get a product that you need by sharing the work of creating it. Every single component of UnitedLinux comes from a project of this type. The infrastructure for collaboration already exists and has been functioning quite well for a long time.

So, the stock argument doesn’t quite make sense. This has been knocking at the back of my mind ever since this announcement came out. UnitedLinux doesn’t actually solve the problem.

First, we must define the problem. The problem is that many GNU/Linux distributions download Free Software and, pursuant to the rights given to them in Free Software licenses, modify the code and distribute their “enhanced” products. Because the GNU GPL protects the community by requiring these providers to also distribute the source code, these Free Software projects have been able to take from the enhanced work, and many providers have had the ethical decency to submit their changes to the Free Software projects that they are modifying.

Again, this is all provided for and is an inherent right given by Free Software licenses. The same concept that allows this problem to occur also allows UnitedLinux to exist. UnitedLinux doesn’t solve the supposed “GNU/Linux fragmentation problem.” What it does is make sure that a group of member distributions can maintain compatibility with one another.

If they wanted to solve the problem, the best way to do it would be to feed their changes back into the projects directly. If they all agreed to use the projects as they were distributed by their official maintainer, then the entire reason for UnitedLinux ceases to exist.

In thinking about this, I may have stumbled upon the real reason that UnitedLinux exists. Each one of these companies feels that its products must differentiate from the competition on key levels in order to succeed. This is true to some degree, but in a Free Software world, this is dubious when you’re discussing core components. Fragmentation in the core components could cause various problems and has done so in the past. We’ve seen this in changes to GCC and the GLIBC that deviated from the form of the official projects.

The real differentiation must occur in the applications and services that each company provides to their customer. UnitedLinux’s existence is a nod to this fact. Interoperability is really important for everyone involved in this community. However, UnitedLinux is not quite ready for complete interoperability. Its companies want to provide interoperable differentiation of the core components solely to those willing to become a member of UnitedLinux.

This leads me to a very problematic conclusion. If UnitedLinux functions by taking Free Software code produced by Free Software projects, modifies that code and then calls that code standard, is that an attempt to circumvent the original project? Again, this is within UnitedLinux’s rights; however, are we being fed a diet of “interoperability for all” when the real intent is to replace the projects that are the sole source of production for these distribution vendors?

Surely, the Free Software project members can take from the UnitedLinux code base and add the changes to their projects, right? Yes, but that changes the social relationship. And further, if the two groups don’t agree on the changes that were made, we’re back to square one. In this scenario, interoperability is not served because the original project and its UnitedLinux fork are themselves incompatible. Therefore, anyone seeking compatibility with UnitedLinux must use UnitedLinux’s code base and thus contribute to UnitedLinux’s fork. Assuming that many people will not do this, but rather continue to use the original project’s source and binaries, it may even compound the problem.

In the above scenario, both code bases will achieve significant marketshare, and we’ll essentially split down the middle on our core components. This would be devastating. The only way to avoid this is if UnitedLinux seeks to provide its changes back to the projects on a timely basis. Is UnitedLinux willing to do this? I’ve scoured the site looking for the answer and have not found anything except for a statement in a UnitedLinux white paper indicating that code will be available in the fourth quarter of this year. This does not qualify as “timely.” Therefore, this question must be addressed factually by somebody from UnitedLinux.

Are these distribution providers trying to take control of the Free Software projects that they use? Only time and the actions of UnitedLinux will tell. However, if the above question is not answered satisfactorily, meaning that UnitedLinux will feed its changes back to the original projects with those projects in mind, then we should be suspect of their motives. I applaud collaboration; but if it comes at the expense of the community, then we all lose.

About the author: Barry Fitzgerald is a member of the Free Software community from somewhere in New England. In his spare time he is a member of the DotGNU Steering Committee and works with Free Software in general. The content of this commentary is of a personal nature and does not in any way reflect the position of the DotGNU Steering Committee, nor anyone that the author knows unless they happen to agree and he doesn’t yet know about it. He has previously been a member of the LinuxFromScratch community and has built GNU/Linux systems from source code using almost all of the components UnitedLinux seeks to use.

“Commentary” articles, which usually run on weekends, are contributed by Linux.com and NewsForge.com readers. The opinions they contain are strictly those held by their authors, and may not be the same as those held by OSDN management. We welcome “Commentary” contributions from anyone who deals with Linux and Open Source at any level, whether as a corporate officer; as a programmer or sysadmin; or as a home/office desktop user. If you would like to write one, please email editors@newsforge.com with “Commentary” in the subject line.