Much software is now available under Open Source licences, which apply to the public availability of source code. There are many Open Source licenses, with a variety of conditions to cover different circumstances. However, there are many other types of information covered by copyright, and there are Open Content licenses for these. This paper discusses these licenses
The Open Source movement has crystallised a number of ideas about the public availability of source code that have been practised both formally and informally for a number of years [1]. The GNU Public License has represented one extreme of this, as it guarantees that not only must the source covered by this license be public, but all derivative works must be covered by this license and also be public. There are other Open Source licenses such as the Berkeley license, which simply make the source code available, with no restrictions on further use.
Source code is ``creative content'' that is subject to copyright, and so may have an open copyright license applied to it. The concept of copyright covers a much wider range of material, such as images, novels, computer documentation and various types of performances. Licenses such as the GNU Public License are not always applicable to such material, and a number of different licenses have been proposed to deal with these in an ``open'' manner.
Of particular importance to the computing community is documentation material for computer systems, or indeed, any written material. Some of the ``open'' licenses refer specifically to written materials.
This paper surveys some of the different Open Content licenses, which can cover copyright materials other than computer source code.
Copyright law is a complex area, which varies across countries. In Australia, copyright may be applied to literary works (including computer program source), dramatic works, musical works, artistic works, films, sound recordings, broadcasts, published editions and certain types of performances [3]. This is much wider than the simple domain of computer source code.
There is a wider category, too: that of Intellectual Property. This includes patents, copyright, trade marks, designs, trade secrets and many other areas. There seems to be little attempt as yet to apply Open Content principles to these, although some areas of this (in particular, computer patents) would seem to be worthy of attention.
There are a large number of licenses that can be branded ``open''. The OpenSource Web site contains definitions of Open Source, and also contains a list of licenses which conform to this definition [2]. The definition includes
The Berkeley license was originally devised for the BSD Unix distributions. It changed over the years, following some court actions.
It is a very simple license, that allows redistribution in source or binary form, as long as the copyright notice is retained. It also contains a disclaimer of liability which looks sufficiently legalistic to have been framed by lawyers and perhaps to have good legal meaning. It does not place any requirements on derived software.
The Perl Artistic License is one of the possible licenses for Perl distributions, or for perl packages. It is fairly flexible in that it allows choices on distribution and modification.
If a package is modified so that it changes from a ``Standard Version'', then these changes must be posted in some way
Distribution of the software can be done in a variety of ways, too
You can charge a reasonable copying fee and charge for support of the package. But you cannot charge a fee for the package itself. But if you use the package to create programs, then you own the copyright on these programs, and are allowed to sell them commercially, or give them away - they are yours.
The GNU General Public License (GPL) comes from the Free Software Foundation (FSF), which is responsible for a huge range of software tools such as emacs, gcc, Unix utilities, compiler-compilers, and so on. The GPL is possibly the best known Open Source license. Since it is unlikely that Linux would ever have been produced without use of the GNU tools, the FSF claims that Linux should be properly known as GNU/Linux.
The GPL is a very purist license, which works from the philosophical basis that software should be free, and that once software is free the license should protect this freedom. Note that ``freedom'' refers to freedom of access to source code, not free as in costing nothing. A distributor of software covered by the GPL is free to charge a reasonable distribution fee, to charge for support and to charge for instructional material about the software. If this was not the case, Red Hat and other Linux vendors would not be able to charge for their distributions, and O'Reilly would be unable to sell books about GNU tools.
The GPL covers the activities of copying, distribution and modification. Copying and distribution requires you to maintain and publish the copyright notices on the software. Like other licenses, this ensures that authorship can never be removed, so that the intellectual property ownership remains with the originators. If the software is modified, then it may be redistributed in source or binary form. However, even if it is in binary form, there must be reasonable access to both the original and to your changes. In other words, you cannot make changes to the software and hide them if you make the executables available to others.
There is often confusion about products created using software covered by GPL. The most common case is a program in C/C++ that is compiled by a GNU compiler. The result of running the compiler is not covered by the GPL. That is, the executable produced from your source code belongs to you, and is not covered by the GPL. You are free to place whatever copyright license you want on your executables. You do not have to make your intellectual property publically available, although the open community would of course prefer you to do so.
The GNU Lesser Publication License (formerly the Library Public License) is known as the LGPL. The LGPL is a weaker form of the GPL, and is mainly intended for use with libraries of code. If a library is covered by the GPL and is linked into a program, then that program is considered to be a derivative of the library and so it must be covered by the GPL. From a purist viewpoint this is good: it forces everyone into making their software GPL'ed if they use your library.
However, purism can have the effect of killing use of the library. For example, the GNU libc is linked into every C program. If this was under the GPL, then every program compiled and linked with GNU libc would have to be GPL'ed. No commercial vendor would be likely to use the library.
The LGPL thus distinguishes between distribution and modification of the library itself, and distribution of programs which just ``use'' the library. Modifications to the library are dealt with in a similar manner to the GPL, but programs linked with the library are called ``a work that uses the library'' and are not covered by the LGPL. That is, they can be sold, given away, and can be covered by the GPL or any other license.
the Sun Community Spurce License is not an open license [4]. It represents an attempt to combiine elements of the Open Source licensing with ``commercial reality''. It allows you to distribute, modify and use software as long as you make no commercial gain directly from the software. As soon as you do - and this includes using it as a library - then you have to start paying fees to the copyright owner.
At present this license mainly refers to various Java libraries. Nobody yet knows if this is helping (source code availability) or hindering (pay later) software development using these libraries.
The Open Content License (confusingly called the OPL) is intended to cover any copyrightable material that is digitally available [5]. It covers digital images, documentation, educational materials, digital videos, etc. Essentially, it is based on the GNU GPL, with specific reference to software removed and replaced by ``content'', or simply eliminated.
The Open Content License allows free use of content, while maintaining copyright ownership by the author(s). Modifications are allowed, but if you redistribute the changed version, then the nature of the changes must be made public. The license does not make clear how this is to be done. For example, for documentation a list of changes can be added, or change-bars inserted in the document, etc. However, if an image is modified, then it may be necessary to add the information in as metadata. This can be done for some file formats such as PNP, but not for all.
The Open Publication License [5] was derived from the Open Content License after a sufficient number of authors began publishing works under this license, and the more traditional book publishers (such as O'Reilly!) found problems with this license. The Open Publication License has no formal acronym - while it should be called the OPL, this has already been used by the Open Content License.
The Open Publication License covers documents, such as online tutorials, books, letters and program documentation. Since it deals with text documents, it is able to give a definition of what comprises a ``modified work''. This includes translations, anthologies, compilations and extracts of the document. This differs from the meaning of ``modified/derived work'' for software.
A major difference between this license and others lies in two optional restrictions that may be added by authors. The first is to ban ``substantial modifications'' without explicit permission. This is true for ``traditional'' copyright notices as found in books. Since the Open Publication License allows modifications, this brings it back in line with these notices. one could imagine Shakepeare (or any author) using this to forbid the Reader's Digest condensed versions of their work!
The other optional rider is to forbid publication in paper format without explicit permission from the copyright holder. This gives traditional print publishers the confidence they need to print books without fear that someone else can simply take their editorial and publication work and use it for free.
The Linux Documentation Project [6] is an attempt to document all features of Linux, especially for configuration issues for various pieces of hardware and software. This involves ``HOWTO's'' and ``Guides'', along with manual pages, info docs, etc. Collections of these are often made into books such as the ``Linux Bible'' or ``Linux Encyclopedia''.
The existing HOWTO's have been covered by a variety of licenses. For example, the 1996 version of the Linux Encyclopedia contains these copyright notices
Due to this variation, the Linux Documentation Project currently includes a ``boilerplate'' license that can be used as-is, or modified as desired. This allows anyone to freely copy or distribute (sell or give away) the document in any format. The document can be modified or a derivative work created, as long as the derivative uses the same license or the GNU GPL. The derivative must also be made available on the Internet in some manner, such as by sending it to the Linux Documentation Project.
This license ensures that derivative works are also Open Documentation works, and that changes must be made public. It does not include waivers of liability, and may be problematic in litigous countries. In the future, it may change the reference to the GNU GPL to the GNU Free Documentation License.
The GNU Free Documentation License preserves the spirit of the GNU GPL, adapting the details to open documentation. It preserve the rights to copy the material, to distribute it freely and to modify it. A key distinction made for documents is the difference between ``transparent'' and ``opaque'' documents. This distinction is made for purposes of modification.
A document can be distributed or modified and the version passed along in transparent form. If it has been made into an opaque form, then it must be possible to get the transparent form, either from the network or by including the transparent copy.
Some material in a document should not be changed: such as the background of the authors, legal disclaimers, etc. These can be marked as ``invariant'' matter and cannot be modified.
A document may have ``cover texts'' either front or back. If the document is printed in bulk, then these covers must form part of each printed copy. This allows an author to specify a cover for non-trivial print-runs.
I have authored two books, published by international publishers. The first was an awful experience, with the publisher leading changes based on a reviewer who really wanted to write a different book, and saw my book as means of getting someone else to do it. The publisher enforced these changes until this reviewer dropped out. The current version of the book, with the original book proposal was sent to a new reviewer, who suggested I throw out all the changes and revert to the original. At which point I became upset (!-) and insisted on publication as it was then.
The second publisher was much more reasonable (Addison-Wesley), and gave me lots of valuable and timely advice. However, since I had approached them, they still maintained control of the project, and I had to make some changes against my preferences. On the whole, their changes were good, and I would not mind working with that particular group of staff at Addison-Wesley again.
I did not make money out of these two books. The first sold 2,000 copies, the second sold 8,000 copies. The first was in a relatively obscure area (parallel Prolog) and was mainly of academic interest. The second was on X-Windows and Motif, and could have sold better if it was promoted more by the publisher. These two experiences led to the conclusion that if I wanted to write books, I should do it for my own reasons: fun and interest, rather than to make money.
At the beginning of 1999, I knew nothing about Jini, and neither did anyone else. There were a couple of short tutorials and examples, and a difficult-to-read formal specification [8]. So I began to write a book about it: as I discovered things, I wrote another chapter. The traditional way is to do all this in your closet, late at night when no-one is watching. After my previous experiences, I went the Open Content way, and published the material on the Web from the beginning, using the Open Content license [9]. It started at 10 pages, and is currently at 350 pages.
Open publishing has had many benefits. I have had feedback from the beginning, which still continues. Links to my tutorial/book have been made from many sites, including the Jini FAQ [10]. Sites which rate Jini materials place my site in the top ten. Eventually, a publisher approached me, offering to publish the book in hard-copy. Negotiations took place - but in this I had the upper-hand, since I was quite happy to continue working without a publisher, whereas he needed authors to survive. My concession was to change the license to the Open Publication license, with that publisher having sole rights to printed copies.
I have no idea if I will make money from this book. It doesn't matter, since I have regular employment, and have used this as a base to contribute Open Source for many years. This has just changed to an Open Content project, which is just as much fun, and avoids the hassles of dealing with regular publication systems which tend to make it hard for authors.
This paper has discussed some of the ways on which the original Open Source licenses have been extended to deal with other types of Open Content. Even for particular types of content, there are often many different licenses, based on different philosophical backgrounds. This allows an Open Content author to choose a license that suits their requirements.