Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
GNU is Not Unix Operating Systems BSD

Linguistic Problems of GPL Advocacy 633

Reader Chemisor advances a theory in his journal that a linguistic misunderstanding is at the root of many disagreements over different licensing philosophies, in particular BSD vs. GPL. The argument is that GPL adherents desire the freedom of their code, while those on the BSD side want freedom for their projects. "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 discourse over the matter." Click below for Chemisor's analysis of the linguistic chasm.


The first disagreement I wish to address concerns the statement "BSD projects are free, but GPL projects stay free." GPL advocates cannot 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 finds 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 the reason for the 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 instead to 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.
This discussion has been archived. No new comments can be posted.

Linguistic Problems of GPL Advocacy

Comments Filter:
  • Hey, now! (Score:1, Informative)

    by Anonymous Coward on Wednesday July 09, 2008 @01:11AM (#24112073)

    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.

    Give a little credit to the Apple-worshipers.

  • Runtime GPL (Score:3, Informative)

    by bazald ( 886779 ) <bazald@z[ ]pex.com ['eni' in gap]> on Wednesday July 09, 2008 @01:23AM (#24112201) Homepage

    I just want to mention a variant of the GPL that is often used and rarely noticed. All those standard header files included when compiling with GCC are Runtime GPL. If you take the point of view that the GPL is viral, you can think of the Runtime GPL as the completely non-viral GPL.

    Using some variants of the GPL linking exception, it becomes possible to release code that must stay Free (as in Libre) in derived works without requiring every last bit of the derived work to be Free.

    It as close as you can get to a compromise between the BSD and GPL licenses as far as I am aware. The biggest downside is that neither side believes the license to be trustworthy. It is too GPL for the BSD folks, and not GPL enough for the GPL advocates.

  • by h4rr4r ( 612664 ) on Wednesday July 09, 2008 @01:25AM (#24112227)
    Then don't use it, and deal with it. It is also impractical for me to build a Ferrari, I don't steal them.
  • Re:Probably Not (Score:3, Informative)

    by setagllib ( 753300 ) on Wednesday July 09, 2008 @01:30AM (#24112263)

    Wait, what? Isn't that completely backwards? GPL limits redistribution of aggregated and derivative works, which are things that a recipient would be doing.

  • Re:There is a reason (Score:5, Informative)

    by walshy007 ( 906710 ) on Wednesday July 09, 2008 @01:34AM (#24112313)

    you'd think that, maybe, but copying and improving the improvements to linux to the os x kernel is no trivial task, take a look at the exec proc bench on this http://www.anandtech.com/mac/showdoc.aspx?i=2436&p=8 [anandtech.com]

    mac os x took on average a bit over four times as long to create new processes, if os x were always ahead of linux shouldn't they be at least equal, if not slightly more efficient?

    as much resources as apple has, there is no way they'd have collectively as much resources going into kernel development as the linux kernel would have in total, and the quality is reflected in that.

  • by MoHaG ( 1002926 ) on Wednesday July 09, 2008 @01:39AM (#24112357) Homepage
    The LGPL still has conditions to use of the code. You may, for example, not forbid disassembly of code linked to LGPL code... The "GPL with linking exception [wikipedia.org]" is better if you want no restrictions on code linking to your code.
  • by qbwiz ( 87077 ) <(moc.ylimafnamuab) (ta) (nhoj)> on Wednesday July 09, 2008 @01:50AM (#24112425) Homepage

    It has happened, [kerneltrap.org] although the case is slightly more complicated than that.

  • by Drantin ( 569921 ) * on Wednesday July 09, 2008 @02:00AM (#24112503)

    However, small companies can take, modify and sell media players based on mplayer if they like, the only stipulation being that they have to follow the terms of the GPL when doing so...

  • Misses the point (Score:3, Informative)

    by Tord ( 5801 ) <tord,jansson&gmail,com> on Wednesday July 09, 2008 @03:06AM (#24113067) Homepage

    As far as I'm concerned the author totally misses the point with the GPL.

    I don't care about "my code being free" the way he expresses it. What I care about is to create a level playing field between free and proprietary software and nurture the existence and proliferation of free software. With BSD-style licenses the proprietary software developers always have an upper hand in the race for consumer mindshare and userbase since they can take any BSD code but doesn't need to (and most often doesn't) contribute anything back. They can always stand on our shoulders but we can't stand on theirs so they will always be a head higher.

    For free software to proliferate, which is a personal goal for me for many good reasons (freedom to tinker, freedom and savings for enduser, privacy protection, establishing of standards, sharing of wealth, better for developing nations, faster inovation etc) we need a bigger userbase which currently is occupied by proprietary software.

    We will not achieve that by remaining upstream providers for proprietary projects, which BSD-licensed projects often become.

    The BSD-licenses have their place in certain projects where it is more important to advance the technical field for both proprietary and free software than advancing the marketshare of free software.

    Without marketshare we are always bound to play catch-up with standards, hardware support etc. and as a community remain marginalized. The GPL, with it's restrictions against inclusion in closed projects, helps us to gain marketshare.

  • by Rix ( 54095 ) on Wednesday July 09, 2008 @03:17AM (#24113151)

    But I won't code for free. That's the real difference.

    I'm happy to let you use things I've written, but if you're not willing to reciprocate with what you do with it, you'll need to cut me a cheque.

  • Re:There is a reason (Score:3, Informative)

    by Hes Nikke ( 237581 ) on Wednesday July 09, 2008 @03:33AM (#24113269) Journal

    First: the linked article is 3 years old and isn't even using the same hardware architecture.

    Second: Apple has by no means been resting on it's laurels. In Snow Leopard there is a new thread management system called Grand Central. GS seems like it would be a kernel level feature, which means that it just might be open sourced in Darwin 10. Read up on GS (and other features) at http://www.roughlydrafted.com/2008/06/12/wwdc-2008-new-in-mac-os-x-snow-leopard/ [roughlydrafted.com]

    Chances are pretty good that your entire argument will be void next year, if not already. Have a nice day. :P

  • Mozilla is in fact under a triple license at the choice of the licensee. You can pick whether you want to reuse its code under the LGPL, the LGPL-like MPL (weak copyleft, allowing proprietary derivatives as long as modifications to the MPL code is published with source and under the same license) and the GPL (strong copyleft, no proprietary derivatives). In any case, all three of those licenses have some form of copyleft.

  • by Per Abrahamsen ( 1397 ) on Wednesday July 09, 2008 @03:55AM (#24113405) Homepage

    The whole "linguistic" discussion (free, viral, stays free, whatever) is missing the point. You shouldn't choose license from which has the best sound-bites, but from which best supports your goals. Here is a seven year old article about how to choose a free software license [dina.kvl.dk] that should be much more useful. The specific choice of licenses may have changed, but the reasoning hasn't.

  • Re:Probably Not (Score:3, Informative)

    by mcvos ( 645701 ) on Wednesday July 09, 2008 @07:03AM (#24114453)

    - BSD ensures freedom of the *producer* of the code to do what they want.
    - GPL ensures freedom of the *recipient* of the code to do what they want.

    Almost;
    - BSD ensures the freedom of the producer of derived code to do what they want.
    - GPL ensures the freedom of the recipient of derived code to do what they want.

  • by coats ( 1068 ) on Wednesday July 09, 2008 @07:34AM (#24114603) Homepage
    It's a license: permission to reproduce and distribute a work is a uniloateral action on the part of the author. Without a license, the Berne Treaty (of which your nation is a signatory) says you have no right to reproduce and distribute.

    Contracts are bi- or multi-lateral actions in which every party gives up something in exchange for something else. Copyright license is not contract.

  • by jedidiah ( 1196 ) on Wednesday July 09, 2008 @02:28PM (#24121325) Homepage

    You are essentially whining about the nature of free market compeititon.
    It is the nature of the market to make EVERYTHING a commodity. Even if
    it is tied up in patents and copyrights, eventually even those are meant
    to expire. Someone will build a better mousetrap. Someone else will do it
    cheaper. You don't even have to worry about a bunch of STUDENTS replicating
    your idea and giving it away.

    The fact that Apple can't stagnate or it will become irrelevant is what
    causes Apple to continue trying to push the state of the art. The fact
    that they are driven by external forced to improve is HOW IT SHOULD BE.

    Yeah, if what Apple wants to sell you can already be cobbled together by
    a bunch of freshman CIS students then they shouldn't have "some god given
    right" to be able to base their business off it. They need to move on andprovide genuine innovation.

    This situation where programmers can make money selling you this years
    rehashed version of a 20 year old idea with no real improvements is
    what the problem is. Hopefully Free Software will help kill that.

Work continues in this area. -- DEC's SPR-Answering-Automaton

Working...