Er, Linux?!?

I mentioned Linux. Kernel is under GPL v2 with the rumored module exception (can someone clear this up for me?) but if you want to make an OS, you need other things, which aren't GPL. That's all - I'm not trying to detract from Linux or any users of GPL, but just trying to point out that it's not as clear cut as Marten makes it out to be.

-geir

Samba, GIMP, most of GNOME, KDE, most of the "GNU" tools e.g. GCC, coreutils, bash, blah. I'm not aware of any code in the Linux kernel which uses a modifed GPL, it's all GPLv2 with some bits of BSD-licensed code.

Here's some lies and statistics, FWIW, from the Fedora source package archive, looking at the license tag on each package:

5593 total source packages
4184 with license tags including the string "GPL" somewhere, audited or not
505 with audited license tags that claim pure GPLvN
500 with unaudited license tags that claim pure GPL
131 with license tags that match (Apache|ASL), audited or not

We have been doing a license tag audit recently, so audited numbers are more reliable than unaudited; take it all with a pinch of salt of course. By "pure" above I mean with all code under that single license.

Someone else also noted GCC, and I think that is a good example of probably the *most* successful free software project. However, IIRC, there is an exception somewhere, isn't there? I thought that when GCC creates an executable, it links the boostrap code into your binary?

-geir

From Debian /usr/share/doc/gcc-4.1/copyright:

gcc/libgcc2.c (source for libgcc) has the following addition:

In addition to the permissions in the GNU General Public License, the Free Software Foundation gives you unlimited permission to link the compiled version of this file into combinations with other programs, and to distribute those combinations without any restriction coming from the use of this file. (The General Public License restrictions do apply in other respects; for example, they cover modification of the file, and distribution when not linked into a combine executable.)

So, one file has an exception such that it can be copied into things without being considered a "derivative work". This is a clumsy mechanism; that file should just be public domain and forget it. Would this change your point that it's not "just" the GPL? No, probably not.

But this whole argument misses the point, I feel. Ultimately, the GPL is the clearest expression of our freedoms, and it is suitably compelling that most projects use it, with exceptions or without. No non-copyleft license *can* offer that, whether it's "just" ASL, "just" BSD, or anything else. It's not like people are saying "This project is released under the GPL with the further exception that you needn't distribute source with executables." I would argue that even if a large proportion of successful free software projects are licensing in this way, *and* even if this is significant rather than just an artifact of projects' size or political climate, the conclusion to draw is only that the GPL is somewhat clumsy in its definition of derivative work, and errs on the side of caution. Still, the majority of successful free software projects use the GPL, and in my opinion, this is a useful datum.

Ethan

I probably should have made it clearer that this isn't an attack on the GPL, but really what I thought was an interesting observation about some of the most visible and common projects that do use the GPL.

Maybe a better question to ask is "What would be different if they used only the GPL?"

And regarding AL, BSD, EPL, MPL-licensed projects, I can't actually think of any projects that require an exception or alteration of the terms of their respective licenses. If you know of any, let me know, as I find the whole topic interesting.

-geir

Good point re libgcc being GPL+exception.

It's certainly true that AL-licensed software is not always purely AL-licensed; e.g. there are five different BSD/MIT variants tacked onto the APR LICENSE file at the moment, alongside the AL 2.0.

These impose different sets of restrictions on redistribution, just as the GPL variants (be that GPL+exception or LGPL or whatever) impose different sets of restrictions on redistribution.

But for cases like the Apache License that is used for APR, (and this is true of many, many projects at the ASF, especially Java projects), the fact that there are portions under licenses such as BSD, MIT, etc isn't a modification or alteration of the Apache License in order to limit, relax or change the Apache License's requirements or limitations on licensees, but simply rather just a required accounting of software written by others and released under other licenses that are included in the project.

There's a big difference.

Sure. The same is true in many of the cases where GPL software includes BSD/MIT-licensed portions (e.g. the Linux kernel).

You've somewhat of a point. The "Most Open Source is GPL" line is always overstretched by:

a) History; it's one of the oldest licenses
b) A large long tail of very niche/weak applications on SourceForge

I don't think it gets away form the "Most" still being true, but it changes things from 85% to 55% etc.

Even at that 55%, if you ask yourself which ones developers are actually interested in; as opposed to which ones developers as users are interested in; the numbers shift even more. Throw out the GUI applications for users, and the numbers drop significanly I suspect. So much so that really the only GPL of note is Linux and its accompanying libraries - most of which you wouldn't use off of Linux.

I suspect what Mr Mickos means is that most successful Open Source businesses are using GPL ;) and that's because he defines success as hoarding IP.

Licenses should be for the *developer*. To say *code* is free is utter non-sense. Code is nothing. What matters is what programmers do with code - that is, the freedom of the *individual* to use that code.

All stats based on collecting data on licenses are flawed. Yes, there are many GPL products, but how many are mature products? Most are immature, buggy pet projects that will never be finished.

All top open-source projects, with the exception of the Linux kernel and GNU toolchain are business-friendly and contain either exceptions or LPGL, Apache, or BSD code libraries: Firefox, GWT, Apache, KDE, GNOME, etc, fall in this category.

Once you move outside linux to the average (think 95%+) of users using a PC, you will not likly find a single GPL program, but plenty of open free software (firefox being probably the most likly). GPL is basically by GNU for GNU.

I think your rumoured Linux module linking exception is entirely fictitious - see http://www.kroah.com/log/linux/ols_2006_keynote.html which states "Closed source Linux kernel modules are illegal"

There is no "rumored" Linux module exception, Linus has made his stand very clear for 8 years (paragraphs reorders, from an email from Linus posted at http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html ):

"Well, there really is no exception. However, copyright law obviously hinges on the definition of 'derived work', and as such anything can always be argued on that point.

"I personally consider anything a 'derived work' that needs special hooks in the kernel to function with Linux (i.e., it is not acceptable to make a small piece of GPL-code as a hook for the larger piece), as that obviously implies that the bigger module needs 'help' from the main kernel.

"Similarly, I consider anything that has intimate knowledge about kernel internals to be a derived work.

"What is left in the gray area tends to be clearly separate modules: code that had a life outside Linux from the beginning, and that do something self-contained that doesn't really have any impact on the rest of the kernel. A device driver that was originally written for something else, and that doesn't need any but the standard UNIX read/write kind of interfaces, for example. ...

"Well, it really boils down to the equivalent of 'all derived modules have to be GPLd'. An external module doesn't really change the GPL in that respect.

"There are (mainly historical) examples of UNIX device drivers and some UNIX filesystems that were pre-existing pieces of work, and that had fairly well-defined and clear interfaces and that I personally could not really consider any kind of "derived work" at all, and that were thus acceptable. The clearest example of this is probably the AFS (the Andrew Filesystem), but there have been various device drivers ported from SCO too."

Don't you have it in the reverse order?

It seems like the GPL has been added on to software that was originally licensed otherwise. For example, Firefox was solely under the MPL, but now is dual-licensed. Qt has been GPL'd. Java was under the Sun community license, but has been GPL'd.

It seems to me that the GPL provides the most protection, being what some call the most restrictive. It also seems to be the most community-oriented, since it forces(!!) community orientation. So other projects eventually cede to the GPL.

So the question is: when will Apache and its sub-projects be dual-licensed?