Open Source

What exactly is Free Software? Perens discusses the Open Source Definition and provides an overview of the various licenses under which software is released.

Lauren Ling

Free Software programmers often cooperate to produce something greater than they
could create alone. Our software licenses define and control the ways in which we can collaborate.
That’s one of the reasons that licenses are so important to the free software community. In this
article, I’ll present an overview of free software licensing and discuss some of the features of the
various licenses as well as the differences between them. This article is an overview; an exhaustive
analysis of free software licenses would require an entire book.

Software licenses exist because the government grants you, the author,the
“copyright”, or the right
to control how your work is copied. Software you write is automatically copyrighted, with the
default license being “All Rights Reserved”. That’s a legal way of saying no copying allowed, this
means you! An author can sell his or her copyright, or a subset of rights under that copyright, and
this is the main way that literary and software authors earn an income. An author’s copyright
restricts others from copying a program, but not from doing other things with it. For example, a
program can be used for any purpose. Users can, however, give up other rights voluntarily when they
agree to comply with a software license.

One common form of commercial license is the “tear-open” license. It’s called that because some
versions are printed on the outside of an envelope, and when you tear open the envelope, that is
taken as your voluntary agreement to abide by the terms of the license. More recently, licenses are
displayed during the installation of a program, and the user clicks an “I Agree” button to accept
the license. The program won’t install unless you agree with the license. Thus, most users have
little choice but to agree with any license that comes with their commercial software.

The essence of Free Software is that you have many more rights than are granted by the average
commercial software license. The generally-accepted list of rights necessary for a program to be
called Free Software or Open Source is the Open Source Definition (the OSD), originally called the
Debian Free Software Guidelines (DFSG). The complete text of the OSD is reprinted on pp. 78 and 79.

The terms Open Source and Free Software were intended to mean the same thing — Open Source was
supposed to be simply a marketing name for Free Software. We coined the name Open Source to reduce
the confusion stemming from the dual meaning of Free in the English language: we mean liberty, but
the more common English usage refers to price. However, the Open Source Initiative, the organization
behind Open Source,has not been universally perceived as an asset to the Free Software movement. Thus
many developers still prefer to call it Free Software, eschewing the Open Source label.

Much Free Software created in the ’70s and early ’80s was public domain, which is the simplest
way of making a program Open Source. Public domain isn’t really a license. When an author places a
program in the public domain, he surrenders his copyright and gives the general public unlimited
rights regarding his work. People can do anything they want with a public-domain program, they can
even erase the real author’s name and say that they wrote the program. Most software authors want to
have just a little more control than that over their creations, and thus they resort to software

There are a number of software licenses that have already been deemed compliant with the Open
Source Definition. These include the X License (which was originally applied to the X Window System
when it was developed at MIT), and its derivatives the BSD (Berkeley Software Distribution — the
license applied to Berkeley UNIX) and Apache licenses, the GPL (General Public License) and LGPL
(Library GPL) of the Free Software Foundation, the Artistic License originally produced for Perl,
the NPL and MPL licenses (Netscape and Mozilla Public Licenses) written by Netscape, and the QPL (Qt
Public License) version 2.0, written by Troll Tech for the Qt toolkit used by the KDE GUI for Linux.
The original Qt license was not compliant with the Open Source Definition, but version 2.0 is.

Licenses that do not comply with the Open Source Definition include the Sun Community Source
License, (SCSL), IBM’s original Jikes license (IBM might have changed their license to be fully Open
Source by the time this article is published), the Alladin license used on GhostScript, and the Non
Consultant’s License, an experimental license that allows a royalty fee for software distribution.

The major inspiration for the Open Source Definition is Richard Stallman’s GNU General Public
License, also known as the GPL or Copyleft. Stallman elucidated the tenets of the Free Software
movement in 1984, when he first announced the GNU Project to create a free version of AT&T’s
pioneering Unix system. Ten years after Stallman’s announcement, Linus Torvalds’ contribution of the
Linux kernel provided the last component necessary to create an entirely free system.

The GPL guarantees that no one will be able to take away various rights and freedoms that all
programmers should be entitled to. For example, it guarantees that the source code for any program
released under the GPL must be redistributed with the binaries. You are permitted to make any
modifications that you wish to the source code, but you must then make those modifications available
under the terms of the GPL. Although you are free to sell your software to others, You are
prohibited from charging a royalty for the right to distribute the program or its source code. You
also may not restrict any other party from redistributing the code. When added together, the terms
of the GPL insure that software released under its protection will always remain free (not
necessarily in terms of price, but in terms of freedom of use).

Many consider the GPL itself to be as important a contribution to the Free Software community as
any of the software that has been placed under the license. Programmers use the GPL when they want
their software, and any variations that others might produce, to always remain free. Examples of
important GPL’ed software are the Linux operating system kernel, the GNU C Compiler, and the Emacs
text editor.

Some programmers would simply not write Free Software unless they were assured of the protection
that comes with a license like the GPL. As one programmer described: “With the GPL, anyone can add
new features to my software and I’ll be sure to get the changes back if I want them. I don’t mind if
Red Hat sells my program and makes some money, as long as Red Hat’s competitors and I are all free
to sell the same software or just give it away. We can circumvent Red Hat if we want to; because of
the GPL, they can’t corner the market. If there wasn’t a level playing field for everyone, if I had
to let companies run away with my work without returning anything, I’d not want to write Free
Software, because I’d feel like an unpaid employee being taken advantage of by someone else who made
all of the money: I’d just feel stupid. The GPL assures me that my contribution will be used fairly,
and thus it creates a climate in which I will contribute.”

Aside from the GPL, the other widely used Open Source licenses are the X license (with its
variants the BSD and Apache licenses). The main difference between the GPL and the X-derived
licenses involves their policies on whether or not software can be taken private. A Free Software
program is taken private when someone makes useful modifications and then doesn’t contribute those
modifications back to the public as Free Software. Such programs are called non-Open-Source,
Non-Free, and Proprietary. Proprietary programs are usually sold under restrictive licenses that
allow no copying, and the source code for them is rarely released. A person who takes Free Software
private is taking advantage of the original software author’s generosity without being equally
generous about his own work. If a developer doesn’t want their work taken private, they choose a
license like the GPL. If they want to encourage others to take their work private, they use an X
license (or BSD or Apache) or some other licenses we’ll discuss later.

Open Source Tree 1
All In The Family: The origins and evolutions of a sample of software licenses.

X might be the ultimate example of a “do anything you want with it” license. It basically says
you can do anything you wish to do with the software, or even with the license itself. You can
release binary-only distributions of the software, and you can make modifications that you do not
need to re-distribute or make available as source code. You can even write a new license and make
the original software available under the terms of that license (incidentally the GPL does not allow
you to remove the GPL from the software it is attached to, and you are not permitted to modify the
GPL itself). The BSD and Apache licenses are almost the same as the X license except that they also
contain what many consider to be an obnoxious “advertising clause”.Basically, you can do anything
you want with the software, as long as you give credit to the Regents of the University of
California (or the Apache Group) any time you advertise your program.

Why would anyone ever create one of these “do anything you want with it” licenses? Well, In the
case of the BSD license, the software for which it was originally used was funded by monetary grants
of the U.S. government. Since the taxpayers had already paid for the software, it made sense for
those taxpayers to be allowed to do as much as possible with it, including take it private. The
grants were made at least in part for the purpose of stimulating the computer industry in the United
States, and thus licenses that prevented companies from making proprietary offshoots of the software
would probably not have been accepted by the granting authority.

In the case of the X license, the X Window System for which it was first used was funded by a
consortium of corporations (and perhaps some government grants), and again, the people who paid for
the software expected to have the right to take it private. Although most Free Software producers
today do not get government or corporate funding, many of them do not mind seeing their work taken
private, and thus they have adopted the X, BSD, and Apache licenses.

The NPL or Netscape Public License had nothing to do with government funding, but was inspired
by the success of Apache. Thus, Netscape created a license that allowed others to take parts of
their Mozilla Web browser private. Netscape wanted Mozilla to become a standard for Web browsers,
and they felt that many software producers would not accept the program as a standard if they were
not allowed to build Non-Free Web browsers on top of it. Other details of the NPL relate to
Netscape’s existing commitments at the time — they had contracted to provide other companies with
software under a different license, and thus they had to add a provision to the NPL so that when
modifications are contributed by others, Netscape may distribute them under any license it chooses.
The MPL, or Mozilla Public License, is a variation of the NPL without this provision.

One example of a program that was successfully taken private is Microsoft Internet Explorer.
Both IE and Netscape Navigator started out as a free program called Mosaic. Mosaic was developed in
an academic environment. Its producers wanted to bootstrap the Web but had no interest in turning a
profit. Its early license deliberately allowed (in fact, preferred) commercial, proprietary
development as a means of encouraging companies to develop software for the Web. Microsoft and
Netscape each took the program and made hit commercial products with restrictive licenses and no
source-code releases. Their final products, which were derived from Free Software, facilitated
Netscape’s multi-billion-dollar stock offering, and propelled Microsoft’s already-astronomical stock
issue to even greater heights. Netscape eventually released Mozilla, their improved version of
Mosaic, as Free Software, while Microsoft’s Internet Explorer has remained proprietary.

Mosaic spawned products that are employed by virtually all Internet users. Think about how
different the world might be today if Mosaic had been under the GPL: today, Microsoft is attempting
to dominate the Web through their “embrace and enhance” strategy, by adding so many
Microsoft-specific features that users are compelled to employ a Microsoft Web browser to view them.
This strategy has propelled Internet Explorer to the point that it is now the choice of more than
50% of Internet users. This embrace and enhance strategy might have been less successful if Mosaic’s
authors had used the GPL, as that license would have prevented Microsoft from making proprietary
changes to Mosaic without releasing the source code. To avoid the requirement to release source code,
Microsoft might have taken the time to write their own Web browser from scratch. Mosaic and its Free
Software derivatives might have held onto the Web browser market if Microsoft had been unable to
enter the market so quickly. But Mosaic’s license made it easy for Microsoft to run away with the
product, making whatever changes it wished and releasing no source code. This example should be
considered carefully by the producers of future “bootstrap” products like Mosaic: a poor choice of
license could give an entire industry away to the most ruthless competitor.

Some programmers strike a compromise between Free and Non-Free Software by using the LGPL, the
“library” (or sometimes referred to as the “lesser” GPL, which allows Free Software to be put
together with proprietary software into one program. The LGPL is good to use with software libraries
because those libraries can remain Free, yet they can be used by Non-Free Software. Since the
libraries that Linux comes with are available under the terms of the LGPL,Linux systems can support
proprietary software. However, the LGPL isn’t limited to libraries — it can be used for any
software. The LGPL requires that the source code be distributed for the LGPL’ed part of a program,
and it mandates that you be able to recompile the LGPL’ed part of a program and re-assemble it with
the non-LGPL components into a complete program. Another interesting feature of the LGPL is that you
can convert an LGPL-ed program into a GPL’ed program at any time, but you can’t convert GPL to LGPL
unless you’re the copyright owner. Thus, anyone can start a GPL’ed “thread” of an LGPL’ed program
that may not be merged back into the LGPL’ed version.

As Open Source has become more popular, we’ve seen the entry of huge corporations like IBM and
Apple into the field, and these corporations have formulated licenses that address their own unique
needs. This has introduced the concept of deep-pockets liability protection to Free Software. “Deep
pockets” is a way of saying that a company or an individual has a lot of money. Individual
developers do what they can to protect themselves from liability in their licenses without
compromising the goals of the Free Software movement. They do not have to worry about liability as
much as a corporation does, because it takes a lot of money to make an appetizing target for a
lawsuit. In contrast, a suit against IBM, with its deep pockets, might net a sum of several million,
enough to entice a lawyer to participate solely for the prospect of a large fee. IBM’s lawyers must
do their best to protect their company and its stockholders against lawsuits. Combined with the problems of
the U.S. software patent system, this means big trouble for the Free Software movement.

Professional patent-buster Gregory Aharonian estimates that 95 percent of software patents
issued in the United States are not inventions at all, either because they cover prior art, which
means an invention that someone else has previously created, or because they are trivial in that a
competent software engineer could be expected to think of them when faced with the same problem.
Unfortunately, the government doesn’t examine patents very carefully, and leaves it to the courts to
decide whether or not they are inventions when the owner of a patent makes a claim of infringement.
So, there are many opportunities for a Free Software author to be sued for patent infringement, and
it might easily take that author hundreds of thousands of dollars of legal fees to fight an invalid
patent. Obviously, corporations that release Free Software don’t want to have to pay for the
privilege, and thus they write an escape-hatch from a lawsuit into their licenses, a termination
clause. In the case that a corporation is sued for patent infringement, it will withdraw your right
to have or use a copy of their Free Software that infringes on the patent, removing most of the
cause of the lawsuit. This is a serious problem for Free Software users — if a license is
terminated, they may suddenly lose the right to use software that they depend on. IBM’s first
version of its Jikes license does so much to protect its patent rights and to provide IBM with
liability protection that it falls somewhat short of the Open Source Definition. However, IBM has
recently released a license that lacks a termination clause, but it’s for a different product, not
Jikes. They seem to still be developing licenses, and there is hope that the Jikes license will
eventually be replaced by one that is entirely compliant with the Open Source Definition.

A few months ago, Apple released the Apple Public Source License. Their first version only
ambiguously met the OSD, but their version 1.1, released a month later, is much improved in its OSD
compliance. As I write this, the Open Source Initiative is still deciding whether to accept that
license as Open Source. It is unclear whether license termination clauses, a feature of the APSL and
several other licenses, are compatible with Open Source licensing.

The Sun Community Source License, or SCSL is not an Open Source license. Sun released this
license when they decided to publicly disclose the source code of the JDK, their Java software
Developer’s Kit. The license contains provisions that require modifications to pass a regression
test, and that allow Sun to charge a royalty to commercial distributors of modified source code.
This royalty fee means that Sun is relying on direct revenue capture — being paid directly for
their software, which would immediately disqualify the license as being Open Source. Section 1 of
the OSD prohibits a royalty fee. Most Open Source producers make their money indirectly, from
selling services, support, or peripheral items of Non-Free Software that work with their Free
Software. Sun feels that their Community Source license addresses what they consider disadvantages
of the Open Source model: A lack of centralized development controls, and their own belief that
without a financial incentive, there is little reason for anyone to improve that software. However,
these objections are belied by the success of Linux. Although Linus Torvalds effectively exercises
central control over the development of Linux, nobody is compelled to cede him that control by the
terms of the GPL. And although you don’t have to pay for Linux, there seems to be a tremendous
incentive for people to improve it — Linux is growing at a rate of one line of debugged code every
two minutes.

Java is another case where the GPL might have been more appropriate. Sun’s plans to make Java an
international standard continue to be attacked as Sun, wishing to maintain control, has recently
waffled on the issue of turning Java over the International Standards Organization (ISO). Sun should
realize that it will not attain worldwide acceptance of closed, proprietary standards, and that Open
Source Software provides the best way to promote an open standard. Licenses like the GPL are the
only insurance Open Source has against the “embrace and enhance” strategy used by Microsoft and its
ilk. The requirement that all modifications be made public prevents any one company from getting a
“lock” on a piece of software by taking it private.

The Alladin GhostScript License is another non-Open-Source license. The Alladin license
prohibits distribution of the software for profit, but allows the software to be downloaded from an
FTP site for free and allows some forms of non-profit distribution. This forces distributors to
negotiate separate licenses, paying fees for the right to distribute the software for profit. Linux
distributions which contain a current version of Alladin GhostScript have probably paid the fee, but
the majority of the fees for this software have been paid by printer manufacturers who embed the
software in their products. Two-year-old versions of GhostScript are released under the GPL, so
GhostScript’s developer is being paid for his software and is eventually making that same software
freely available. This is a viable strategy for those who must be paid for their software, if they
can find a market for it. This strategy has worked best with embedded systems (like the printers in
which GhostScript is used), while the Free Software version goes into a secondary market.

However, there is some evidence that direct revenue-capture licenses discourage the
collaboration that has given us the rapid development and power of systems (like Linux) developed
under true Open Source licenses. In an e-mail discussion some time ago, I offered the following
rationale against this form of licensing:

This form of licensing strategy can be classified as mandatory direct revenue-capture for the
initial developer. It disregards the role of the unpaid collaborator who would add features to your
program, because the initial developer has an advantage that the unpaid collaborator can neither
obtain nor circumvent. This is a disincentive to the unpaid collaborator, because instead of
contributing work to the community they are now contributing work that someone else will be paid for
no matter what they do. Contrast this to indirect revenue methods. If I don’t like Red Hat, I can
circumvent them and make my own Linux distribution, obtaining what would have been their profit for
myself for some (possibly small) number of customers. Consider this in the case of a product like
Linux, where the initial developer (Linus) contributed a small amount of the total work and his
services as an architect and coordinator, while the lion’s share of the work was done by others.

It makes collaborative development unwieldy. If every developer insists on their own revenue
capture, you would soon have a too-expensive product or a paperwork and procedural mess. Who decides
how much each developer gets? Who decides who is worthy as a developer? Do they all make that
decision for themselves and then compete with each other in some way?

Developer Matthew Parry has created the Non-Consultant’s License, another non-Open-Source
license, in an effort to encourage collaboration by providing for contributors to be paid for their
work. Parry attempts to address my objections to direct revenue-capture licenses using a scheme
through which an elected arbitrator determines the contribution of each programmer and splits up the
money accordingly. The Non-Consultant’s License has not yet been tested (Parry has only applied the
license to one product, and is the sole developer). Only when he can attract a good number of
additional developers can the money-splitting features of the license be demonstrated. Parry
contends that the OSD’s prohibition on a royalty fee for software distribution is ill-considered.
However, that prohibition was taken from the concept of free redistribution in the GPL. We have had
lots of time to consider that, as the GPL was created in 1984.

As the number of licenses grows, license incompatibility has become a problem. It’s sometimes useful to combine pieces of two programs to produce a third, but this is
impossible when the license terms of the two programs conflict with each other. For this reason, I
recommend that a developer use an existing license if it’s possible to achieve his goals with it.
Creating a new license forces Free Software developers to read and understand yet another license,
and will lead to more license incompatibility.

The past year has seen a tremendous increase in acceptance of Free Software and Open Source, and
a corresponding increase in the number of licenses we must deal with. Because of this, the Open
Source Definition has become much more important than it was previously as a tool against which
licenses must be measured. The tremendous mind-share it has accumulated is illustrated by the fact
that huge corporations have made a point of complying with it. We haven’t seen the last Free
Software license released by a new entrant into Open Source. But hopefully we will eventually see
some consolidation, as we find common elements in these documents and arrive at a few licenses that
we can all live with.

Bruce Perens is the primary author of the “Open Source Definition”. He co-founded the Open
Source Initiative with Eric Raymond, and was the project leader for the Debian GNU/Linux
Distribution. He can be reached at bruce@perens.com.


<< prev   page 1 2 3       


Linux Magazine /
July 1999 / FEATURES
The State of Free Software Licensing

Comments are closed.