![[image of the Head of a GNU]](/graphics/gnu-head-sm.jpg)
(jpeg 7k)
(jpeg 21k)
no gifs due to patent problems
Hello everybody, I am glad to present the fourth issue of the Brave GNU World. I'll begin this month's column by picking up some reaction I received after the first issue.
Commercial GPL Software?
After my article about the renaming of the LGPL I got some email complaining about my favoring the GPL over the LGPL. As an example let me quote an email by Marcel Ruff (note: the author translated this quote into English so you would understand it; the original quote can be found in the German version): "I think that all free Software should be released under the LGPL because it is of utmost importance for mixtures of commercial and free Software." This argument appears logical but it is based on a flawed assumption - let me elaborate.
What exactly is the difference between the LGPL and the GPL? The GNU General Public License grants each user the right to use, modify and copy software however he or she desires. To protect this right, code licensed by the GPL may never be used within proprietary programs. This is not the case with the LGPL. Even if the license of the code may never be changed, it explicitly allows use in all (even proprietary) programs. Proprietary means that a person or firm demands to be the only authority regarding who may possess or use a certain piece of software. But we have been talking about commercial software, which is software people or firms earn money with. This raises the main question, which is whether commercial software needs to be proprietary. The GNU Project has been saying for a long time that this is not the case, and the success of GNU/Linux has proven it.
There are a lot of reasons to release software as Free Software. The attempt to explain this to the managers has kept a lot of people busy for years, the most prominent example of these attempts being the "Open Source" movement.
But this is not about the advantages of Free Software, it is about the question whether the GPL or LGPL should be preferred. It certainly makes more sense to release some software under the LGPL, though this should be decided on a case by case basis. In general the GNU Project thinks the GPL should be preferred. One of the reasons for this is to give commercial Free Software an extra edge in competition. This extra edge combined with the advantages of Free Software may just be what a small firm needs to succeed.
That's theory for this month. My next topic will certainly be of interest to commercial software producers because choosing the right organisation for maintaining source code in a software project can be crucial. Even in projects with just one developer, a good structure can save many hours of work, and for distributed projects with multiple developers it can be almost life-saving. For this reason, I'd like to introduce
Aegis
Aegis [4] by Peter Miller is a tool which runs on almost all UNIX platforms, providing a system for project coordination and sourcecode maintenance. Since it is based on GNU Autoconf, installation is quick and easy. Like similar projects, Aegis has one central archive, the so-called repository. The repository contains all versions of the project since its start so one can easily go back to older versions or simultaneously develop two different branches of the project.
The repository is never changed directly. Developers create local source trees to work on. Changes made to the sourcecode are put into "Change Sets" where all changes during a work-cycle are being collected. Aegis is built around keeping the current versions running and as bug free as possible, so each Change Set incorporates at least one test. These tests become a part of the repository when the Change Set is being implemented into the repository; this makes it possible to assert that new code didn't break any old routines by running "historic" tests. By also tracking dependencies of source files in the repository, Aegis can suggest test programs that make sense with the new Change Set. A Change Set is accepted only if the included tests and a build succeed. In order to finally become part of the repository it needs to be reviewed and signed off once.
This may sound a tad complicated but it does have certain advantages. With other systems it sometimes becomes a major problem that the system locks a file as soon as a developer announces he might be thinking about changing something in this file. This creates a bottleneck with popular files that is avoided by Change Sets. Aegis also integrates part of the quality assurance work within the development process without slowing it down noticeably. Signing off the changes could, for instance, be done by each developer, a central group of developers, an external committee or a project leader; whatever fits the project's needs best. In each case you have someone who authorized the changes. This system also ensures that the development process directly produces tested and running versions. This can be extremely valuable to firms because they are able to give a current version to their customers at any time.
What I personally liked a lot is the fact that local versions do not need to be insulated from the repository. Aegis supports push and pull updates, so a change in the repository can be transferred to the working directories automatically.
Without going into details too much let me just mention that Aegis supports multiple, distributed repositories, allows Change Sets to be transported by email or HTTP and has been written with regard to security aspects.
But now I'd like to talk about two projects that should be of interest to "normal" users, too. The maintainer of GNU Enscript, Markku Rossi, asked me to write a little bit about the status and plans of his project.
GNU Enscript
GNU Enscript is a program to convert ASCII into PostScript, ANSI (terminal escape-sequences), HTML, Overstrike (nroff escape-sequences as in the manpages) or RTF.
Although the code for it is being rewritten at the moment, GNU Encript does support language sensitive highlighting since version 1.5.1. This is somewhat similar to the "font lock modes" of Emacs. The type of file is recognised and certain parts of the text (for instance the comments in a C program) are highlighted in a user-defined way. One use, for example, would be publishing source code on the web by just running it through enscript once. If you are missing styles in your installation, the GNU Enscript homepage by Markku Rossi [5] is probably the place to go; Enscript currently supports 42 different languages and filetypes.
The new highlighting engine is much faster and easier to configure than the previous one because it defines highlighting rules, styles and output languages in separate layers that can be changed without affecting each other. If you are interested in taking a look, the betaversion [6] is already using this new engine.
In this context I'd like to introduce another interesting project.
Ted
Ted [7] is a simple rich text processor by Mark de Does. It allows the user to simply type away on an email or letter in wysiwyg style. Since RTF is being used as the native file format, exchanging documents with Microsoft Word or Wordpad is not a problem. Ted can also be used as the RTF viewer for Netscape. The goal of the project is to get an easy to use application for maximum portability with the "Windows-Sphere".
Although the author would prefer GTK+ by now, Ted is Motif based; getting the relations between screen and printer right and implementing other alphabets than Latin1 are paramount at the moment, though. Help on these tasks is welcome.
I'd like to end this issue with another idea of mine. When setting up a web page lately I wasn't able to find any "We run GNU" icons for webpages. Thinking about it I realized I have never seen such an icon. Please feel free to send design ideas as well as questions, comments and ideas regarding the column via email [1].
| Info |
|
[1] Send ideas, comments and questions to Brave GNU World <column@gnu.org>
|
Return to previous issue / Brave GNU World home page
Return to GNU's home page.
Please send FSF & GNU inquiries & questions to gnu@gnu.org. There are also other ways to contact the FSF.
Please send comments on the Brave GNU World column to column@gnu.org, send comments on these web pages to webmasters@www.gnu.org, send other questions to gnu@gnu.org.
Copyright (C) 1999 Georg C. F. Greve, German version published in the Linux-Magazin
Permission is granted to make and distribute verbatim copies of this transcript as long as the copyright and this permission notice appear.
Updated: 10 Jul 1999 greve