The criteria used refer to four kinds of freedom for the users of the software:
This is from RichardStallman, who created the GnuProject when his model for collaborative computing--the MitAiLab (cf. IncompatibleTimesharingSystem)--lost its best programmers to industry, and "unfixable" closed systems began replacing "fixable" open systems.
The FreeSoftwareFoundation maintains an interesting list of software licenses, including comments:
The relationship between FreeSoftware and OpenSource is not always clear. Superficially -- on legal terms -- they are the same. Fundamentally -- on philosophical terms -- they are not. The proponents of FreeSoftware feel very strongly about the philosophical issues.
Contributors: SunirShah, CliffordAdams, AlexSchroeder.
There is certainly a distinction between the two groups, and it is not just Stallman and FSF on the "pure" FreeSoftware side.
The current BSD license, is almost certainly FreeSoftware. In Stallman's view, it doesn't strongly protect the freedoms like the GPL does, but it is certainly free in the pure BSD form. The problem that some people have with the BSD license is that it allows non-free descendants and variants of the original free code. For instance, a vendor could take one of the BSD-licensed Unix systems, change it slightly, and rerelease it under a completely closed and proprietary license (ie. no CopyLeft). An even bigger concern to some is that people could contribute extensions and new features under semi-closed or unclear licenses, leading to more and more restrictions on the code.
On the other hand, sometimes the "purity" of Stallman's views (and the FSF policy which is usually in agreement with them) causes problems with more "pragmatic" people willing to accept less-than-totally "free" systems. Recent conflicts have included ones over the KDE desktop project and the Python language license. The Python example is a good one--the only GPL-conflict is that the license says that any legal action over Python must be taken in the context of Virginia (USA) law. For most people, that is a perfectly acceptable interpretation, which could possibly avoid problems like the authors being sued under Russian, Chinese, or South-African legal systems. To the FSF the Python license would set a bad precedent, possibly leading to many other seemingly-harmless restrictions, and finally to more substantial restrictions.
A few years ago I was briefly involved in one of these conflicts: the RIPEM/GMP/free-MP arguments. The author of the RIPEM email encryption system released his code with the only restriction being that the user must agree to abide by the export control laws (which were taken far more seriously in the 1990s). His program used the GNU Multi-Precision integer library to greatly speed up the large-number calculations required by the program. To compress a long argument, the FSF believed (and still believes) that the principles of free software are more important than the actual availability of cryptographic software. (This seemed more important back in the days of proposals like the ClipperChip? or even government regulation of all cryptography. The battles aren't quite over yet.) This was where I disagreed with the FSF.
Even today I still have very mixed feelings about the GPL and the FSF's means of securing free software. In many ways the FSF has provided a great service, especially by rationalizing a huge mishmash of competing "free" licenses. For instance, in the late 1980s and early 1990s there were many programs released under "anti-commercial" licenses, which allowed free use, but forbade any "commercial" use (or profit from) the program. I worked on the "rn/trn/strn" UseNet newsreader family which was burdened with such a license. Even today it is not included in the main "free" Unix distributions (by default), partially because of its non-free license. In other cases the actions of the FSF have been important in opening up large amounts of code that would have been closed if not for the GPL.
On the other hand, I only reluctantly licensed UseModWiki under the GPL. (I even tried to use the less-restrictive LGPL, but the LGPL license doesn't fit very well with "scripting" languages that aren't linked libraries.) My preference would be to dual-license UseModWiki, with a GPL main version and a BSD-like alternative for any worthwhile exceptions. Since the derivatives of GPL'ed legacy code are less than 10% of UseModWiki, I may even rewrite those sections someday. --CliffordAdams
People taking BSD licensed code and turning it into proprietary products is not just a theoretical - it happens regularly. People doing just that ask questions on the OpenBSD mailing list quite regularly. Whether you think that is wrong, or some other benefits outweigh problems it causes is the reason to choose one license over the other. I think Theo and the rest of the OpenBSD team want to see secure software everywhere possible - and think that making theirs available as a building block for closed, commercial systems is a good way to do that. Other people might be upset if they saw their code (which they essentially donated) being used to make someone else lots of money (frequently without any sort of attribution). Personally I have a preference for GPL - if I'm make something "open", I'd like it to stay that way. However, the LGPL seems to offer that, without being quite so "sticky". Probably all depends on exactly what sort of software you're dealing with. --ErikDeBill
In the context of FreeSoftware, one often hears the statement, "Think of free as in Free Speech, not FreeBeer!" This, however, implies an understanding of what FreeSpeech is, which is not as obvious as it seems.
The expression is an entrenched shorthand amongst the software freedom community to draw out the distinction:
The term "free beer" owes something, perhaps, to the joke about the band that named itself "Free Beer" for the marquee appeal of the name. I've certainly been at parties where the beer was free to at least *some* of the people attending--I filled plastic Dixie cups, wrestled kegs, and changed the taps at a few, even.
The kicker of this term is that, though it's OK to sweeten the offer a little, you don't want to attract people who are only there for free drinks (or canapes, for the more highbrow). Conversely, if you are going to an event just because they are handing out goodies, then you're interest is otherwise shallow to non-existent.
For a quantitative analysis of the advantages of open-source software by an exhaustive review of published studies, analyses, and news stories refer to David Wheeler's [Why Open Source Software / Free Software (OSS/FS)? Look at the Numbers!].
"The continued freedom to create and use free software is always in danger. Unfortunately, some interests seem to use the tragic events of September 11, 2001 as an excuse for wide-ranging infringement on civil liberties, some of which may threaten the very ability to create free software at all." - from http://kernel.org