Some more thoughts on the results of GPL enforcement

Just a small personal note: Yes, this blog is currently seeing close to no updates. This is because I'm literally working every minute that I'm awake, with no time for anything else.

But to get to the main point of this entry: The results we see from GPL enforcement. I don't want to write about the legal results, since they have always been successful, in 100+ violations that I've been dealing with so far.

I'd rather want to talk about other results. They mainly fall into two categories:

Structural results, how I like to call them, show that the vendors / "the industry" now understand the GPL [better] and thus adopt policies and business practises that are more likely to be GPL compliant from now on. This is good, since it has the potential to prevent further GPL violations down the road, presuming license compliance is something that we value and strive for.

But how does Free Software actually benefit from GPL enforcement? I'm talking about the actual software, and not the movement, the community, the advocates, etc.

How many times have you seen some code coming out of a "GPL code release" from one of the many (mostly embedded) vendors that was actually useful to be contributed back to an existing Free Software project, or even that spawned a new Free Software project? I for my part am certain to say: Zero. The actual number might be close to zero, but very small anyways.

The next logical question is to ask ourselves, why it is like that. First of all, the code quality is usually extremely bad. Looking at kernel patches from the various vendors, I'd say the code quality is _by far_ off any scale that would ever even remotely be considered to be suitable for upstream inclusion. Not only do those vendors not care about any CodingStyle (which could be easily fixed), but they ignore any existing standard API's (why use them if we can reinvent our own?), don't ever spend a single second on portability issues such as SMP, DMA safe allocations, endian issues, 32/64bit, etc. This code is "throw-away software". Fire and forget. The complete opposite of the long-term maintainability goals of about any FOSS project I know.

I would be the most embarrassed man if I ever was involved with any such software. Having your name associated with such poor quality would be like a stigma. Any technical person would laugh. And yet, the managers of those respective companies proudly announce the availability of their so-called "GPL code releases". If they only understood how ridiculous they make themselves in the technical community. It's like if they were proudly presenting a drawing from a three-year-old kid as the new Picasso. They just don't notice because the number of people with a taste of art is apparently larger than the number of people with a taste of source code quality and aesthetics.

The next big problem is the perpetual preference of vendors, even in a market with only six month product life-cycles, to use ages old software to base their code on. Of what use is e.g. an obscure netfilter patch that was developed against kernel 2.4.18, something that is many years old and of no relevance to current stable kernels or even current development?

Now you might argue "What about projects like OpenWRT?". While they are no doubt very useful, it is quite simple. Those projects mainly benefit only the customers of the (probably formerly GPL infringing) embedded devices. Therefore, they benefit specific customers, and not Free Software Users in general. Even if OpenWRT or others invest huge amounts of work and manage to clean up / re-implement some of the awkward sources released by embedded manufacturer X, and push it into the upstream project (e.g. Linux kernel), it is something that most often only a very specific user base that benefits from it. All the really interesting bits, if there are any at all, are kept proprietary by the respective manufacturers, using legally extremely questionable practises such as binary-only kernel modules.

If one thinks a bit more, this whole sad process could have envisioned before. It's a myth to believe that Linux and other FOSS is so popular in the embedded market because vendors think it is more reliable, or secure, or even because of the maintainability, audit-ability, or even the benefits that users and developers get from being able to run modified versions of the software. If they were, we would see clean code and regular security updates. In reality almost every product is one gaping security nightmare. None of those potential benefits are of any interest to embedded vendors.

The response to the 'why' question is quite simple: They use GNU/Linux because this way they can avoid per-unit royalties that are very popular with alternative (proprietary) embedded OS's. It's a cheap commodity. Thus, it's not surprising how they treat GPL compliance. Disgruntled, not understanding the issues behind, releasing only the most incomplete non-building source code snippets that make any reasonable developer vomit at first sight. And since they themselves lack the skilled developers internally (they're not cheap!), their management goes ahead and releases something that is embarrassing. If I wanted to evaluate the technical skill-set of a company before making large-scale business with them, I'd [have somebody] look at their source code releases. It can tell a lot about technical expertise and corporate style :)

Please don't get me wrong. I'm not complaining that there is any legal shortcoming in those "GPL Code Releases" though there often is, but that is not the point of this article). But if somebody asks me, how much the actual Free Software source code benefits from the code that was released by the vendors, my honest reply would be simple and sad: None.

While this whole post might sound bitter and resignated, and like I wanted to give up GPL enforcement since it's not worth it: This is not the message that I want to put out. GPL enforcement remains important. I never assumed that there would be a lot of actual mainline-mergeable source code coming out of it, so I'm not disappointed with the enforcement. I just have the constant feeling that many people are driven by misconceptions, and nobody outside the hacker community really knows what's going on on a technical level.