Slashdot

It is difficult to spend a week on Slashdot without colliding with a GPL advocate. Eager to spread their philosophy, they proselytize to anyone willing to listen, and to many who are not. When they collide with a BSD advocate, such as myself, a heated flamewar usually erupts with each side repeating the same arguments over and over, failing to understand how the other party can be so stupid as to not see the points that appear so obvious and right. These disagreements, as I wish to show in this article, are as much linguistic as they are philosophical, and while the latter side can not be reconciled, the former certainly can, hopefully resulting in a more civil and logical discource over the matter.

The first disagreement I wish to address concerns the statement "BSD projects are free, but GPL projects stay free". GPL advocates can not understand why the BSD advocates are not getting this point, and BSD advocates make accusations of communism, which are then argued to death by both parties. The problem with the statement above is the different interpretation of the word "project". I, and I suspect many other BSD advocates, generally separate the concept of "project" from "code". While code is what projects are made of, I do not see it as valuable as the useful product a project provides. When I write a program, be it a site scraper, or a todo program, or a UI framework, I think of my project as the entity that matters. The fact that I may have copied some code from one to another is of no concern to me.

A GPL advocate sees an entirely different situation. To him, it is the code that comes first, and the applications built from that code are a secondary consideration. Even a single line of code is precious, whether it contains a complex spline formula or i += 2;. As an aside, I would expect this mindset to be more prone to reusing other people's code instead of reimplementing it. Where I would scoff at a piece of code, call it utter garbage, and rewrite the damn thing from scratch, a GPL advocate would probably wrap the garbage in another API that he find more palatable. In my opinion, this leads to bloat from wrappers, instability from the garbage that is still there, and loss of skills. What programmer from the current generation is up to the challenge of reimplementing libjpeg? But, I digress. I am here to explain, not bash, so please excuse this little rant.

The two different viewpoints outlined above lead to different interpretation of the expression "stay free". To a BSD advocate, his project will always "stay free", and to assert otherwise is ridiculous. Once it is published, what could possibly make it go away? I have projects that I wrote fifteen years ago which are still hosted on ibiblio.org ftp site and mirrored around the world. I no longer maintain them and think them useless, but they'll persist forever, and anyone at all who wants to download them still can download them. The fact that some company can take it, write a little bit on top of it, and sell it, does not in any way affect my project.

To a GPL advocate, the project is not important; the code is important. So he looks not just at the project distributions he has made, but also of other projects that may incorporate any line of code he ever wrote. In his mind there is no distinction between his original work and its encapsulation in a derived work. He still thinks of both as "his code", and as an entity that must stay free. Naturally, any non-free derived work will anger him, because his code in it will no longer be free, even though his own copy of that code and his entire project will still be free.

The code/project distinction also leads to a different view of what it means to "use" a project, although this point is seldom argued explicitly. A GPL advocate makes a rather arbitrary and vague distinction between a human using his code and a computer using his code. Consider a situation where a user has a GPL-licensed program that converts a JPEG image to a GIF image and his own program (which he sells, or distributes under some other incompatible license) that can only view GIF images. It is legal for him and his customers to call the GPL program from the command line to convert JPEG images and then view them with his program. Suppose he gets fed up with this sequence and writes a shell script to do both operations in sequence. Is this legal? Probably. But what if he cuts out the conversion part of the GPL program and embeds it in his viewer? That would make his viewer a derived work, and so illegal to distribute under anything but GPL.

From the GPL advocate's view, this is perfectly logical. It is his code, and he wants all instances of his code to be free. The instance can not be free if it is embedded in another executable that is not free, since it can not be easily modified, which was Stallman's gripe and reason for GPL's existence. From the BSD advocate's view, the situation is absurd. His project is still free, and he does not really care how a user wants to use it. A shell script calling the converter is no different than a closed source program embedding it. They are simply different ways for a human to use the program. Whether the object code for the project stays hackable is also irrelevant, since the human's use of the project through a derived work project is just another way of use.

These different views of derived works are another bitter point of contention. GPL code can only be legally embedded in GPL projects, and if a non-GPL project wants to use GPL code, it must either not do that, or become a GPL project. This is why BSD advocates call the license viral, and thus elicit vehement denials from GPL advocates, who retort that nobody is forced to use GPL code, which lead to useless arguments over the meaning of "forced" or "viral" with no meaningful result. It must be reiterated that the GPL advocates look at code, while the BSD advocates look at projects, and the "viral" debate can only be resolved by examining both viewpoints. A GPL advocate sees a derived work as "his code" combined with some "other code" in a package, and his concern is that the package always be openable. "His code" always remains his code, and he sees any use or distribution of the whole package as a kind of use or distribution of his code. As a result, he feels justified in placing restrictions on how a user may use or distribute the derived work, even though he "owns" only a small part of the whole package. This is following the philosophy of copyright and intellectual property, which, curiously, is a favorite target of derision of these same people. A copyrighted work can never be wholly owned by the user, it is only rented, and so subject to control by the original creator.

A BSD advocate sees a derived work as his project being used by another project. The derived project is wholly owned by whoever wrote it, even if it uses other people's code. This is similar to the property laws of the real world. For example, suppose I sit on the curb and give away free lemons. A kid next door might get the bright idea to get my lemons, make lemonade, and sell it. The lemonade is clearly a "derived work", since it is made from my lemons, but it is absurd to suggest I have any right to tell him what price to put on his lemonade or how much sugar he can use in it. By the laws of private property in the real world, my ownership was relinquished at the time when I handed him my lemons. Just as I do not own his lemonade, neither do I own the derived works he makes from my BSD-licensed software.

These distinctive views of ownership combine with considerations of money, and GPL's anti-business mindset, resulting in accusations of Communism, and worse. But I'll save explaining that for another article. For now I will simply suggest that GPL advocates should change their language a bit, to make themselves more easily understood by people who do not subscribe to their philosophy. Specifically:

"BSD code is free, but GPL code stays free"

It would be better to instead say:

"BSD code is free, but the GPL ensures all derived works are also free"

or

"The GPL ensures your code will never be used by a closed-source application"

These alternatives clarify that you are talking about derived works, rather than the original project, which, of course, will always stay free anyhow. Also, do keep in mind the other points brought up in this article and make at least some effort to ensure you are speaking the same language before becoming too upset. I will never agree with your philosophy, but at least you'll know you were understood.