If there are two things we notice about public licenses today, the first is the confusion surrounding them and the second is the abundance of these licenses. Because of this abundance, free software licensing has become a difficult and obscure topic, a no man's land of pits and landmines. But it is the method of licensing that is one of the distinctive and important things about Linux.
The abundance of licenses raises the same question as open source development itself: is this duplication of effort fruitful or wasteful? Some people say that there is no need, as in commerce, to compete; therefore there should only be cooperation. Yet there are over a dozen free licenses in the hands of the public today. Why is this? How did we get there?
Today we're going to take a wide look at the free software licenses and ask whether they are legal, spend some time on the GNU General Public license, and then compare commercial and non-commercial modes of licensing. We'll move on to licensing purposes and dependencies, and finally we'll take up the question of forking. We are not going to go into the licenses in detail—they’re rather boring--we will concentrate on what these licenses are trying to do and what are their results.
Are they legal?
The truth is that free licenses are enforceable only under the current copyright laws. The pending UCC 2B changes, however, would help such licenses, because the changes are intended to enforce the terms of any shrink-wrap license (contrary to usual business practices today, which generally regard their terms as absurd). The changes would therefore tend to enforce any other wild license. In any case, a well-written free license should have a clause like No. 4 in the GNU GPL, which says that violating the license terms voids the license, leaving further distribution, etc. open to copyright violation enforcement. But software developers and vendors need to remember that only a copyright holder who has code in the project in question has standing to bring a suit, and that although their work is considered copyrighted with no action on their part, the copyright must be registered before a suit can be brought. Lawyers tell me that the copyright can be registered after infringement occurs, provided registration occurs within three months of publication. Nevertheless, many software vendors and developers do not register their copyrights.
A greater problem with the free licenses and their enforceability is that of binding persons down the distribution chain from the original parties to the license. This is an area in which contract law, which binds only the actual parties to the contract, borrows from real estate law, which binds successive parties who were not part of the original agreement. Free licenses might appear to be working satisfactorily right now, while there is not much interest in the products, and everyone who uses them is in the potlatch culture, but there are people out there ready to test the limits. You probably remember the man who trademarked the Linux name; you have also seen the abortive Linux Standards Association--others will be sure to follow.
The Granddaddy—GNU General Public License or GPL
One way to look at free licenses is to regard them as tweaks on the GPL. Because the GPL underlies Linux, it is a good place to start.
The GNU General Public License or GPL (often called the GNU Public License) gives the user three rights: 1) to copy the software, and to give it away, 2) to change the software, 3) to have access to the source code. The key requirement is that the user pass on these rights, unimpaired, to other users. This automatically means that any changes passed on by the user must be distributed in source code form as well. If passing along the source code is an inconvenience, you don't have to do it with every copy, but you must say with every copy that source code is available, and tell how to obtain it. You can charge for the distribution costs of the program and source code--free refers to liberty, not to cost.
The whole process is commonly called
"copylefting;" anyone can use the General Public License, and a copy of
it must go with each copy of the distributed program. The smart software
developer will register the copyright for his program; this simple and
inexpensive procedure guarantees maximum legal leverage to controlling
the distribution rights for the software. The copyrighted program
can be distributed in any way the copyright holder chooses: he can
OEM license it to IBM, sell it through Egghead, and still distribute it
under Copyleft. If the developer were to place the program in the
public domain, free for all comers, anyone would be free to take it, modify
it, and copyright and sell the result, thus returning the software to proprietary
ways. In theoretical terms, Copyleft eliminates the middleman who
takes away the user's freedom.
Proprietary products that simply link to GPL software are allowed to remain proprietary; only derivative products need be placed under the GPL. The GPL notice must be displayed on start-up. And finally, the injunction that displays the legal mind at work: no copying, distribution, or modification may take place except under the terms of the GPL.
The logical, happy, but somehow unexpected result of many people following this license is that much of the free software floating over the Internet, and all of the software in the Linux kernel, has the same licensing terms, greatly simplifying compound distributions. There are other free licenses besides the GPL; these include the Open Group X License and the other BSD-style licenses, the Perl Artistic License (none insists on source code distribution).
There is a loophole for commercial (i.e., proprietary) software: the Library GPL a) protects GNU libraries from being incorporated into proprietary software b) also protects proprietary libraries from the "tainting" of the GPL.
The big issue surrounding the GPL is the "tainting" ("viral" or "contaminating") effect, which is actually a liberating effect. The principle is that any code combined with GPL 'd code must be issued under the GPL. This is a means of pulling more and more code under the GPL license. Some people regard this effect of the GPL as a “tainting” effect, and it is a reason frequently given by persons unwilling to use the GPL.
The reaction of the business world is particularly strong here: some are put off by the manifesto at the front of the license and some by the tainting question. It is difficult to comply with the GPL in some cases, especially when dealing with the operating system. Thus "the GPL divides the world into the Free and non-Free" (what Richard Stallman actually said was the "rights and no-rights" world).
Commercial vs. Non-Commercial Modes
The BSD license offers a counter to the anti-proprietary effects of the GPL. As to what constitutes the BSD license, forget the "advertising/copyright line requirement;” that condition is practically obsolete nowadays. The essence of the BSD license is that it allows you to take the source code proprietary (that is, binary); once you've modified it there is no obligation to return code, but some people do contribute to the source tree. Thus derivative works forbidden by the GPL are allowed by the BSD license. The downside of this I'll save for later; it is, of course, forking.
So far we see the coexistence, but not the intersection, of the GPL and BSD-type licenses. You can't put GPL code into a BSD binary, although you can distribute both packages on a single desk. Anyone looking at free licenses ends up with sets of polarities, dichotomies, bifurcations. It is these polarities that cause a lot of the confusion in free software licensing. We can proceed from cases.
If you are looking for a Big Problem in the Linux licensing world, it's the Qt library from Troll Tech. The library is a toolkit: the user is free to use and distribute it and his derivative application--unless it's a commercial application. That is, the application must be given away with source code and permit further distribution and modification. Qt, on the other hand, may not be modified in any way when it is distributed. Therefore, commercial applications don't fit the
Free Edition License from Qt
The Qt Free Edition License is like
the GPL, except that
1) no modifications are permitted to the Qt library
2) no commercial distribution is permitted.
Commercial users must buy the Qt toolkit under the Professional Edition License; the developer pays a handsome sum for the Qt toolkit and the right to distribute unlimited runtimes. Let's look first at the license details: under the Free Edition License, a developer may a) write his own free (or open source) license, allowing free distribution and modifications, or b) use the GPL, or the LGPL.
Leaving the commercial vs. free problem aside, there is an immediate problem with the Free Edition License: under the GPL, you can't distribute Qt library with your application, because it is itself not under the GPL, so you can't combine the code.
You can, however, use the LGPL. The suggestion of the GPL by Troll Tech is a little careless. Troll Tech says you can distribute your free application under the BSD as well, but this is not correct either, since the BSD-type license allows you to distribute your code in binary-only form, clearly not allowed by the Qt Free Edition License. There are obvious (and subtle) problems of writing your own license and not getting it right, and in encouraging people to write their own licenses—all this is a little less than cautious.
The practical effect of these licenses is that commercial developers need to buy Professional Edition and distribute their applications under the Professional Edition License. Note that you can never use the Free Edition license on anything but some sort of UNIX platform (basically Linux), and that Windows (and the Mac) are reserved for the Professional Edition.
The motives are clear: Troll Tech wants to control the toolkit, and to prevent forking; therefore, no modifications are permitted. The firm makes the product free on Linux in hope of collecting improvements from users, and wants to reserve the Windows and Macintosh platforms for their revenue product. Troll Tech wants to use the Free Edition to promote their technology, spread its use and familiarity, and lure people (some will say trick them) to the Professional Edition.
Qt is important enough to KDE and thus to Linux, and thus to many users around the world, that Qt tries to allay fears that it is not really an Open Source product by promising to put Qt source code in a foundation controlled by both Qt and KDE representatives in the event that Troll Tech has some sort of business failure. That's one complication in the license. Further, the Foundation would license the Qt code to the world under a BSD-type license. More complication. I won't go into yet another document; just notice that the Foundation was announced as imminent in April 1998 and that nothing has happened since. This makes some developers uneasy.
What's going on?
The Qt Free Edition License is what some people call a Checkerboard License: you are trapped on your square. The checkerboard is just one way of interpreting the Commercial/non-Commercial split. Under this metaphor, you can contrast the Checkerboard License with the Layered License. With the Layered License you can divide the world in a number of ways. Aladdin divides the world by time slices: you can have the cutting-edge software for money, or the slower-moving software for free. Scriptics divides the world into those who care about free licensing and those who don't care about free licensing. Scriptics has noticed that those who don't care about free licensing are also willing to pay money.
Using another metaphor, you could call the Free Edition License a “Change-of-State” License; if your application changes its status from free to commercial, it needs a different license. This is like going what the INS calls “out-of-status;” in the case of Troll Tech you suddenly owe them money for what you casually assumed was a free product; in the case of the INS, you are liable to be deported. And who decides the status?
If this were just a carelessly-drawn license, it would just be a curiosity. But this particular license carries a large practical consequence: KDE, a free desktop, uses Qt. This is fine as long as Linux is a hobbyist tool. But as it becomes more mainstream, that is, more commercial, anyone distributing commercial apps based on KDE suddenly wakes up to find he owes Troll Tech money for Qt.
This is an issue of license dependencies; it can be a problem as bad as software dependencies.
We encounter another Duality in the form of Split Opinions: Some people think Qt is such great technology that Troll Tech will be able to get what they want—KDE is so great it will save Linux and UNIX from Microsoft (and don’t forget that business people are used to paying money for software).
Some people are so horrified by this problem that we have forking in what had seemed to be a common Linux desktop.
On the one hand, we have Linus’s view: Qt, like everyone else, is free to do as they choose. Don’t whine about it; read the directions. Grow up; there’s lots of stuff out there. And SuSe is distributing Qt and KDE on their CD.
On the other hand, Red Hat has decided not to distribute Qt or KDE any longer; they feel that the development software on the CD should all have the same terms (essentially GPL or LGPL). Marc Ewing is worried about confusion caused by the “change-of-state” license. Additionally, Debian has dropped KDE from its distribution and has posted an explanation of the licensing issues on their site.
Finally, resentment about Qt’s licensing has caused movements to spring up to clone Qt. Harmony, a project to clone a Free Qt is still active, I’ve been told, and the GNOME movement has sprung up to put out a rival toolkit that will be distributed under the GPL, just like Linux. There are desktop projects based on GNOME, and Red Hat is working on one of them.
So far we’ve looked at these splits:
One the one hand we have the GPL/LGPL and dynamic linking (not always doable); on the other, the BSD-style license allowing binary-only distribution and derivative works, and entailing no obligation to contribute changes back to the source tree.
Aladdin’s Ghostscript splits itself into different free/commercial versions using different licenses: a separate enterprise distributes a commercial version called Aladdin Ghostscript, and there are free versions under the Aladdin Free Public License and GNU Ghostscript. The Aladdin Free Public License resembles the GPL and has additional restrictions. You can’t accept money for the free program except for cost of disks and copying, you can’t put the free version on a disk with any paid-for software; the bundling restriction helps kill commercial distribution of the free product. On the other hand, the licensed commercial user can use Ghostscript in his application and also get interim updates to the code; free users wait for the annual update.
Thus one dimension of Aladdin’s free/commercial split is Core/Newest.
Tcl/Tk is a toolkit; this very popular scripting language claims a million users. Scriptics is a new firm founded by the developer to commercialize Tcl/Tk. While keeping the core material and its improvements free, the firm will develop niche applications for money. This plan drew a strong reaction at Open Source Developer Day, raising the question of how badly free software supporters will resent the paying side of the house. John Osterhout recognizes the potential for forking here, and knows that he has to keep the free side happy. He intends to do this by keeping the toolkit good enough so that the free side attracts new users. In turn the Scriptics Web site aims to be the principal online resource for Tcl/Tk, attracting prospects and converting them to users. Profits from the commercial side of the operation will pay for the in-house developers working on Open Source Tcl/Tk.
Thus one dimension of Scriptics’ free/commercial split is Core/Niche.
The Apache license is hidden inside the source code. It says there is 1) no source code distribution requirement and 2) you can combine Apache code with other code. The developers took public domain code originating in NCSA (which they acknowledge), and copyrighted their improvements, putting out the result under a BSD-type license. The terms grant permission to distribute the code and combinations of it under the Apache name, but not for resale; distribution under another name is forbidden.
Free distribution and modification of Apache has made it a widely-used product; IBM is joining the Apache effort with a large crew of developers. Because the Apache copyright holders can license their software as they please, that is, under licenses other than the usual Apache license, we now have a secure server version from C2Net called Stronghold that demonstrates the co-existence of free and commercial software based on the same source tree.
Finally, there is the result of putting a lot of effort, Open Source people, and lawyers together: The Mozilla Public License.
Mozilla Public License (MPL)
The MPL divides a software work into files, which are separated into a) the Open Source part (called “Covered”) and b) anything the user adds. The arrangement allows the developer to add his own files and distribute them with the Covered files, provided he does not modify the Covered files. If he does modify the Covered files, then he must distribute those modifid files under Open Source MPL rules. The license is very neat, and makes it easy for proprietary and Open Source software to work together. If, for instance, the developer uses the published API to call the Open Source files, he can keep his own code proprietary. If he wants to add some API calls to the Covered files, that is fine, too; he just has to share that part of his code. That way other developers get a look at what else might be done with the API. The license shows its affinity to commercial software licenses by including standard language covering such topics as liability and arbitration.
The MPL recognizes the speckled nature of the free software world by requiring that a file called legal.txt accompany all distributions. The recipient of the Mozilla code must keep his eyes open and look in this file for a listing of included software that is under dispute, or under patent (although minimal use of the included patented software is allowed), or has some other limiting license. For instance, a developer could put some Qt material in his distribution, and point out that it couldn't be distributed in any commercial products. This is exactly the approach that some vendors back away from as too confusing; it is interesting that the MPL specifically provides for these problems.
PART TWO: LICENSING PURPOSES AND DEPENDENCIES
Faced with the confusion in free
licenses, the free software community is taking steps to simplify things,
such as the actions regarding the Qt Free Edition License, for instance.
Here is a simple scheme of purposes and dependencies:
Base Layer – Operating System – GPL
Operating systems stand to benefit the most from the GPL because they are the broadest-base software; the users of an operating system will always outnumber the users of any particular application on that system. There is more choice in applications than in operating systems. The GPL may do its best work at this level, forcing a standardization of all licenses, and aggressively keeping it open and free of all closed material. Openness is highly important for operating systems; applications can get away with the BSD-type licenses because their usage is more limited.
In this Base Layer of the OS, vendors can earn money on source code distribution, and they can earn money on binary distribution (so long as source code goes out with it). Linux distributions using the GPL are more or less successful businesses
Second Layer, Part A: Toolkits
At the next level, software may be either free or commercial, but it is essential that there be a firewall here (the vertical red division); the same toolkit can't be capable of changing state. This is the reason the Open Source Definition forbids licenses that discriminate against groups (e.g., for students or against businessfolk). The firewall represents not a separation of products for free/commercial, but clear licenses for those products. Scriptics, for instance, lets you use it for commercial products or for free products.
Second Layer, Part B: Extensions and Libraries for Toolkits
At this next higher level, extensions and libraries need to adopt the same licensing (either free or commercial) as the toolkits they serve. Otherwise we're back in the "checkerboard" or "change-of-state" license. Although the MPL provides for it, businesses don't really want to hire more people to check all their licensing to keep ahead of the SPA raiders. Nevertheless, you must watch licensing dependency as closely as you watch software dependencies.
Third Layer: Tools and Applications
Of the applications which are not tools, we can expect a larger proportion of these to be binary or proprietary. The proprietary applications can build upon both proprietary and free foundations, provided they respect the licensing of the layers upon which they are built.
Tools, however, need to follow the same choice as toolkits, being either on the Free side or the Proprietary side, so that their products likewise have unambiguous licenses.
At this third level, vendors have a strong desire for proprietary code to protect their development investment, and distribution in binaries is common for many products. The LGPL is often not enough to allow for use of proprietary code, and so BSD-style licenses fit here, as do products like the Apache-based Stronghold. The Aladdin Free Public License operates at this level in the Free category, while the Perl Artistic License, which is useable for closed, embedded commercial work fits into the Free and Proprietary category (we might ask whether this license would work as well for an application as it does for a language/script).
PART THREE: FORKING
The F-word: What Causes Forking?
There are a couple of basic reasons for forking; the simplest is the license itself. This is to say, forking occurs Because You Can Do It. For instance, the BSD license enables developers to take code private and not make improvements public. The UNIX tradition of forking originates in hardware tweaks and commercial competition. We must ask then, whether forking is needed in a cooperative world. The incentive for BSDi to keep distinctive is its need to generate sales of its BSD OS; there are no free versions.
Politics is the other basic cause of forking, but this is also a way of saying, Because You Can Do It. Some say forking results from a bad personality that everyone deserts; it is more likely that developers are deserting an unresponsive leader of a development effort. A need that is not being met can result in forking, as when glibc ignored Intel graphics needs. But LibC eventually got together again with glibc2. BSD is still split, and it is possible to go down a trail far enough that the divisions can’t get back together.
But do licenses encourage or discourage forking? Does GPL software have less forking tendency? BSD more? Is there, in short, a
Unified Field Theory of Forking?
On this diagram licenses are roughly arranged on a scale of Free vs. Proprietary and with a greater or lesser tendency to fork. If we begin at the right of the chart, we see that proprietary software is not likely to fork because the source code is not available to modify. Shareware, of course, is freely distributable, but unmodifiable; hardly a situation for forking. The Not for Commercial Use software is likewise unlikely to fork because Ghostscript source, although available, is controlled by Peter Deutsch; all modifications go back to him, not onward.
In the center of the diagram we have High Forking Likelihood (or Experience) existing on the borderline between Free and Proprietary. Here we find BSD, which allows binary-only distribution, with no obligation to pass on source code or modifications; derivative works are allowed, and there is a financial incentive to fork.
Likewise, Java is a standard, “open” and published; the choices for implementation are a) write your own code and pay nothing, or b) use Sun’s code and pay a large licensing fee. As a result some developers, like HP, decide to write their own code, and change it, and (naturally), Microsoft pays for the code and changes it.
The lesson here is that there is a benefit in requiring modifications to be open-source.
On the Free side, with a large tendency toward and some experience of forking, we have the Artistic License. Larry Wall didn’t want to get into legal hassles; he originally just wanted to clarify his view of the GPL. He found that businessfolk did not find the GPL reassuring, nor his clarifications of it. Consequently he wrote the Artistic License not so much as legally binding, as a statement to encourage the good people. You can modify the source code and take it private if you also supply the standard version of Perl with yours; OR, if you are careful to rename modified files so that the standard version still works. Unlike the strict GPL, input/output data is exempted from the license. The only real fork experienced by Perl was over several different Windows ports, and the One Perl campaign has talked everybody back together again. The Artistic License rates high on this chart not from experience, but from potential: there are no binding requirements on the party who receives the second-hand version.
Coming closer to the Free and non-Forking ideal, we have the Mozilla Public License. Basic Mozilla is protected by GPL-like Open Source requirements for received code and changes to it; proprietary additions outside it may be secret. Forking is possible if the project leader is not responsive, but is probably no more likely than with the GPL. Official Mozilla source code can come only from a single vendor.
Closer still to the ideal is GNU Emacs. Although enjoying the GNU GPL that discourages forking, there has been an important fork here in the form of XEmacs, a split based on the desire for a GUI version which GNU Emacs did not satisfy.
Linux can serve as an example of the anti-forking properties of the GNU GPL. It is the Open Source requirement—for the received code and all changes to it—that makes forking less likely. If we look at the condition of BSD,
we see that at any time a developer may take the source code, modify it, and distribute it in a closed version. There is an absolute tendency to fork here, demonstrated by the record. On the other hand, the GPL source tree shows a tendency to pull the branches together.
The official version may at
any point in time not be quite as good as the variant, but it can catch
up by taking the necessary code from the variant. It is possible,
for instance, to have an official source that is authoritative, but not
good at deliverables; this supplies an opportunity for another team to
work on that aspect.
It will be interesting to watch the free licensing space and see whether we are moving from abundance and chaos to fewer forms, or perhaps to more appropriate use of existing forms. Is the market giving any direction? I think it is still too early to tell. Wise developers will to give careful consideration to the type of license they choose. The license form should be picked earlier rather than later, and should reflect the intended use of the software.
Finally, keep an eye open for signs
of potential threats. At present these are conjectural, but, what
if someone claimed there was patented material in Linux, or copyrighted
Return to Top of Evaluating Public Licenses
Open Source Software Licensing
Stromian's Guide to OEM Software Licensing
Other Software Marketing Resources
Stromian Technologies Home Page
20 Feb 99
Contents except decorative graphics Copyright © 1998 by Stromian Technologies. All rights reserved.