The crux of the GPL problem

Last Friday, I wrote a piece describing why I wouldn't use GPLv3 software. As some pointed out, most of my complaints centered around the fact that I would never use a GPLv3 product as part of a development project, as I mostly opposed two things: a) that I can't control the software that runs on custom hardware when using GPLv3 code, and b) that I can't static or dynamic link to pure GPL code (version 2 or 3, a restriction that doesn't apply to LGPL code of either license version). Given that I am a programmer and thus am more likely to want to program against the software products I use, and given that at least some of the resulting code is likely to be proprietary (I work for Microsoft, a clear reflection of the fact that I am not instinctively opposed to proprietary software), that means I am unlikely to USE GPLv3 software for that reason (or much pure GPLv2 software, either).

But, so what? If I don't like the license, don't use it, as I noted in my last blog and am noting again here. I have every right to choose my software poison, as it were, just as much as free software advocates have the right to choose the recipe of theirs.

That, however, doesn't change the fact that I find a position which actively tries to discourage proprietary software to be wrong, both from a practical and MORAL standpoint (hey, if Stallman can use the language of morality, so can I). I posed the following scenario in the Talkbacks to my previous blog. Say a borough or neighborhood decides they want to build a park. Since parks involve both allocations of land and resources to buy park equipment, they aren't cheap, so the community must decide how to build something that suits everyone in the neighborhood.

Now, assume there is a group in that neighborhood who is vegetarian. Further, this group isn't just vegetarian, but has a strong dislike for those who aren't vegetarian. Therefore, they insist that no one be allowed to eat meat while in the park (they managed to get those who insisted that no one who eats meat anywhere, in the park or otherwise, to back down). If the neighborhood doesn't agree to these terms, they will go off and build a park that is exclusively vegetarian, cost inefficiencies and wasted space be damned.

They have a right to do that, as it is their money they will spend on the park. Why, however, does the fact that others eat meat affect the decision not to eat meat among vegetarians? Further, however many ways you slice it, an exclusivity stance is wasteful of human effort, as now the neighborhood will have two parks.

That has parallels to software development. Let's pretend that I am building a hardware device that will enable VoIP communications. SIP is the chosen protocol for that device, and a great GPLv3 library covered under a pure GPLv3 license has been found which provides SIP functionality (let's also assume that I WANT this device to be user modifiable, so that takes item a) off the table). According to the rules of GPLv3, however, if I merely link to that library in my own product, the product MUST be released under a GPLv3 license.

There are good foundation principles underlying the GPL. I agree with the power of community development, and I think it's important for a GPL license to require that true modifications be returned to the community (clearly, a linked product doesn't qualify). That ensures that the product continues to be advanced as a community development project. I also agree with the GPL's attempts to ensure that patents are not likely to hold up development, or bind users to unexpected fees from third parties. Community developed projects have a harder time amassing patent arsenals, and besides, patents in most cases ARE a hindrance to the software development process (in my opinion, of course).

What I fail to understand, however, is why the FSF feels it necessary to make it so that proprietary software CANNOT use the GPLed code. As I described previously, that's just bad-tempered wall building on the part of people who believe that proprietary software is evil and a form of enslavement. MOST reading this blog don't believe that. However, MOST with an appreciation for open source software seem perfectly willing to allow an organization that claims to speak for the combined forces of community development speak as if that is the case.

As I've noted in the past, if you added up the use value (a term used by Eric Raymond, and yes, I know he is part of the open source camp, not the free software camp) of all the software ever created, MOST of it would have been derived from proprietary software. How much of the typical software stack is proprietary, if you had to add it up? That's a lot of bang for the software buck.

I've described in a past series of articles why proprietary software has certain advantages, but suffice to say, proprietary software HAS been a tremendous source of innovation, driven by the incentives created by the proprietary software model.

Why, then, is it so important to create a code stream that is, to proprietary software, like touching the third rail in a subway system? To my mind, the more proprietary software that uses a FREE and OPEN base, the more of the software stack that becomes truly open. Likewise, all that innovation ATOP an open base creates new ideas as to how to extend the open base. Leverage those financial incentives as opposed to trying to stamp them out completely, in other words.

If I had to distill my discomfort with the GPLv3, it would be that it fails to fix problems with GPLv2 (the linking problem for pure GPL code, which I don't think should EVER be the case), even as it creates some new ones. The FSF encourages people to use the pure GPL license, and let's not pretend that sizable numbers won't use it. I've seen a number of products which use open source subcomponents, some of which use an LGPL license, others that use a pure GPL license. It's a simple fact, however, that, practically speaking, the product as a whole MUST conform to the pure GPL restrictions...unless someone is willing to rewrite the GPL portions and release them under an LGPL license (which has its own pitfalls...how do you prove you didn't use knowledge from the original product?).

I believe in the power of a software commons. Pure GPLv3 software doesn't add to that commons, as it creates a common infrastructure that is beyond the use of a demonstrated driver of innovation in the software arts.

So, to reiterate, I won't USE GPLv3 software, at least if I can avoid it, simply because I don't agree with a principle designed simply to divide the forces of software innovation into incompatible camps.

Not that such a position will amount to a hill of beans with most free software advocates, many of whom will stop at the point where they realize I am a Microsoft employee (I guess the mind control chip HR installed on my hire date doesn't quite function properly). But, that's what I think, and since I write a blog on ZDNet, you get to see my reasons here.