The Olliance Group has announced
the availability of a white paper entitled "Open Source Intellectual
Property and Licensing Compliance: A Survey and Analysis of Industry Best
Practices." The paper is available
for free download
to those willing to fill in a registration form.
The press release includes a recommendation from the president of the Free
Standards Group, and the paper itself includes a foreward by OSDL head
Stuart Cohen. So one might conclude that it would be a relatively
high-clue work on how to interpret and comply with free software licenses.
The sad truth, however, is that it appears to have been thrown together
quickly (it contains a number of grammatical errors, for example), and the
ultimate goals of its authors are unclear at best.
The purpose of the paper seems to be to help companies figure out how to
avoid "open source risk." But that risk is not defined or justified
anywhere in the paper. The closest it gets is toward the end, where we
The best defense against the risk of losing proprietary IP to
certain open source licenses such as the GPL or Mozilla is through
a sound compliance program that minimizes the risk of inadvertent
commingling of open source code and proprietary code.
In other words, we have the same old "the GPL can cause you to lose your
intellectual property" argument. This line has been debunked numerous
times: there is nothing in the GPL which can legally force a company to
loosen its death grip in its valuable IP. The GPL can subject a
non-compliant company to copyright infringement suits, fines, and
injunctions stopping distribution of a product. These are real risks which
should be understood by any company which is considering incorporating
GPL-licensed code into its products. But it is discouraging to see
representatives of the Free Standards Group and OSDL putting their names on
a report that brings back the "lose all your IP" scarecrow.
Oh, there is one other risk mentioned on the same page:
However, open source licenses, unlike proprietary software
licenses, are generally not irrevocable--meaning that a
company that has violated a license term may have its right to use
the software revoked. While we do not know of any case in which
this has happened, it remains a possibility that companies should
be aware of.
In fact, the revocable nature of the GPL came out at the end of the KDE wars, when
Richard Stallman revoked the right of the KDE developers to distribute the
FSF's code, then magnanimously forgave
them their sins:
More precisely, those who as of
September 4, 2000 have used some FSF code in violation of the GPL
solely by linking it with Qt, and thus have forfeited the right to
use that code under the GPL, will once again have full GPL
permissions to use that code upon switching to a GPL-covered
version of Qt.
The real point, however, is that revocability is certainly not a feature
which is unique to free software licenses. Consider the
Windows XP EULA:
6. TERMINATION. Without prejudice to any other rights, Microsoft
may cancel this EULA if you do not abide by the terms and
conditions of this EULA, in which case you must destroy all copies
of the Product and all of its component parts.
Almost any proprietary software license includes a term like this one.
Olliance's claim that such terms are unique to free software licenses is
So what does Olliance recommend be done to address those scary free
software risks? The first step is to perform an audit of every free
application in use in the company. Employees are to be required to
document every program they use, its version numbers, the dates over which
it has been used, the reason why it is used, the manager who approved its
use, and so on. A database is then to be built containing all of that
information. What then is to be done with this database is not entirely
Some other "best practices" include:
- Requiring written approval by an "open source review board" before any
open source application may be used.
- Requiring a separate approval before modifying any free software.
- Getting warranties from suppliers that they use
no open source software, or that any such use is documented and
In the midst of all this is a recommendation which actually makes sense:
Forbidding the modification of open source software or its
inclusion in any product that is distributed, without further
detailed analysis, and executive level management review, for
companies that have significant intellectual property at risk.
OK, so maybe it doesn't make that much sense. The core of this
recommendation is, however: think before you incorporate free software
into your products. One could extend that to "think before you
incorporate any software copyrighted by others into your products," but
that would be asking a lot of the authors of this particular work.
As far as your editor can tell, the goal of this particular white paper is
to stoke fears about open source licensing, and to urge companies to create
a vast, grinding bureaucracy to impede the adoption of free software
internally. Following its recommendations is unlikely to make many
companies safer, but it will increase the apparent costs of using free
software. There is a place for documentation of the real risks of using
code copyrighted by others - both free and proprietary - and on how to
avoid distributing products which violate free software licenses. But this
paper does not fill that role.
Comments (8 posted)
Sendmail has a difficult reputation. It is the canonical example of how
large, complex programs are subject to security problems. It has a
configuration file format which makes obfuscated Perl code seem highly
readable by comparison. Its performance when dealing with large amounts of
mail is held to be inferior. One could, of course, point out that
sendmail's security problems appear to be mostly behind it, that few people
ever have to look at the raw configuration file, and that sendmail was a
cherished gift, once upon a time, to anybody who had ever tried to convince
delivermail to route a message along a uucp bang path, by way of the
Arpanet, from a CSNet node. For all of its blemishes, sendmail has been a
crucial and valuable part of the network's infrastructure for many years.
After all those years, however, sendmail may just be due for a major
upgrade. As it turns out, work on the next generation of sendmail, called
has been under way for some time. Some early code has been made available;
sendmail X 0.0.16 is available from this page. Do note that
it is billed as "pre-alpha" code; using it on a server which handles real
mail is probably not a good idea.
lengthy design document for sendmail X is available; it gives some
insight into what the next version of sendmail will look like. The first
impression that comes out is that sendmail X will be so different that
one wonders why the "sendmail" name is being used at all. Sendmail X
is a completely new mail transfer agent, redesigned and rewritten from the
As is the norm for contemporary MTA design, sendmail X is implemented
as a set of (relatively) small, cooperating processes. The system is
divided in this way:
- The queue manager is the core of sendmail X; its job is to
manage messages as they move through the system, make delivery
- The SMTP server accepts incoming mail from the net and passes
them to the queue manager. Actually, the queue manager is involved
throughout the SMTP conversation; it is consulted on whether to accept
the connection in the first place,
and it may have actually delivered the mail before the text is
- The SMTP client passes mail on to other systems for delivery.
- The address resolver is charged with understanding - and
rewriting - recipient addresses. This process also handles DNS
blacklisting and other types of address-based filtering.
- The master control program gets all of the other processes
going and handles termination, restarts, and crash recovery. This
program is actually derived from the BSD inetd source.
In addition, there will be a collection of local delivery agents, mail
filter processes, etc.
Much thought has been given to performance, to the point that may cause
some to wonder if there might be some premature optimization going on. For
example, the SMTP server has been designed to use an Apache-style mode,
where multiple processes exist, each of which runs several server threads.
This design will certainly add complexity to the server, but few sites are
likely to benefit from the associated performance increase.
System administrators will be glad to know that the sendmail.cf
configuration file is gone. Sendmail X will use a C-like
configuration syntax, similar to that used by BIND. Configuration of
real-world mail systems will, perhaps, never be an entirely simple task, but
sendmail X should be easier to set up than its predecessor.
Unsurprisingly, security is said to be a core design goal. The
multi-process design is clearly motivated by security concerns, though the
relatively high level of interaction between these processes may complicate
things. The qmail design, for example, has a far lower level of
interaction and trust between its components - though that approach leads
to problems of its own. There are no setuid programs in
sendmail X. It is necessary to run the master control program as root;
it then handles any privileged tasks that it can before starting the
subsidiary processes under a different user ID. Thus, for example, it
binds to the SMTP port before starting the SMTP server. Since the master
control program does not actually handle mail or communicate with the
outside, it should be relatively hard to compromise.
The code consists of almost 600 C files. In some ways it resembles the
qmail code; it has many short files with reimplementations of many
functions normally found in the C library. A special string type is used
to avoid buffer overruns. A casual look suggests that the code really is
being written with security in mind. That much new code is sure to have a
surprise or two in it somewhere, however.
The author of sendmail X (Claus Aßmann) claims to have been running it
since the beginning of the year without losing any mail. Even so, it will
probably be some time before it is put forward as a viable option for
production sites. What happens then will be interesting. Sendmail X
will be jumping into an environment where several other options exist and
are in wide use. The MTA ecosystem has, over the years, gone from being a
single-program monoculture to a diverse field with several alternatives.
Sendmail X will have to be significantly better than those
alternatives, and much better than sendmail 8, to be widely successful
in that environment.
(Thanks to Xose Vazquez Perez for drawing our attention to this project).
Comments (17 posted)
After the Approaches to realtime
article drew a great deal of interest, we decided to drill down
and offer a closer look at one of the projects mentioned therein: The Real Time Application Interface
, whose developers felt that our portrayal of the project
was not entirely accurate.
To set things straight,
we touched base with RTAI hackers Philippe Gerum and Paolo Mantegazza.
First, we learned that
there are actually two ongoing projects, the first is the original RTAI
project, funded by the Dipartimento di Ingegneria Aerospaziale, Politecnico
di Milano (DIAPM). The other project is RTAI/Fusion, which is a different
approach that merges the RTAI interfaces with the Xenomai development framework.
The RTAI project with Linux RealTime (LXRT) uses several kernel modules to
gain the realtime functionality that one may need. RTAI makes changes in
the Linux interrupt and scheduling policies to provide real time
capabilities within the non-real time Linux environment. According to the
RTAI offers the same services of the Linux kernel core, adding the features
of an industrial real time operating system. It consists basically of an
interrupt dispatcher: RTAI mainly traps the peripherals interrupts and if
necessary re-routes them to Linux. It is not an intrusive modification of
the kernel; it uses the concept of HAL (hardware abstraction layer) to get
information from Linux and to trap some fundamental functions. This HAL
provides few dependencies to Linux Kernel. This leads to a simple
adaptation in the Linux kernel, an easy RTAI port from version to version
of Linux and an easier use of other operating systems instead of RTAI. RTAI
considers Linux as a background task running when no real time activity
The original RTAI project was designed specifically for DIAPM projects,
The whole of RTAI, so LXRT also, was born to satisfy DIAPM needs first, it
was made available much as it is in the form 'if you like it use it.' Bugs
fixing apart, there is very little of RTAI that has been done to show up or
to solve non DIAPM problems. However our applications are not trivial, you
can bet we have_pushed/are_pushing LXRT to the extremes.
On the other hand, Xenomai was designed to allow developers to port
applications from other realtime systems, and therefore it takes a different
approach. Gerum describes Xenomai as a "kind of generic RTOS (Real
Time Operating System) core" that enable a developer to plug in
their own real-time APIs. Gerum says the idea was that most RTOS vendors
offer the same functionality, but with "different API window
dressings." Xenomai was designed to "provide one generic core
running side-by-side with the Linux kernel" that would allow for
The RTAI/Fusion project that is now under development works with a
"vanilla" Linux kernel running on top of the Adeos (Adaptive Domain Environment
for Operating Systems) nanokernel. By running the Linux kernel and Fusion
under the Adeos nanokernel, Fusion cooperates with Linux and allows
developers to use "any number of real-time APIs at the same
Given that there are a number of real time projects for Linux, not to
mention the other various RTOSes, we asked whether it would be possible to
come up with a "one size fits all" solution for real time operating
systems. Mantegazza says yes, but Gerum is not so sure:
Since the traditional RTOS vendors did not succeed in capturing more than a
half of the real-time market during the last 20 years, the rest consisting
of home-grown solutions, I guess that the answer is no. This said, it
should be possible to have a real-time framework which is extensible enough
to allow people to build their real-time solution of choice over it. The
system would simply provide a few canned interfaces in order to be usable
out of the box, by people with common needs.
Simple design and straightforward code layers make the above possible. For
instance, DSP-like applications do not necessarily need a full-fledged
multi-tasking infrastructure; basic interrupt handlers with predictable
preemption time are often enough here. On the other hand, you are not going
to run a complete telecom software stack over interrupt service routines,
so you need a complete RTOS core and rich utility libraries.
It's important to note that RTAI/Fusion would not replace RTAI/LXRT so much
as envelope it, if successful. According to Gerum, the plan is to
"refactor the original RTAI 3.x interfaces over Fusion, if this
technology is successful."
What's left to implement in Fusion? Gerum says there are several things
left to be done:
What remains is about porting to other CPU architectures, extending the
toolset and the available canned real-time interfaces including new
traditional RTOS emulations.
Fusion already provides a full-fledged event-driven simulator with a nifty
GUI for debugging applications on the host system; GDB can also be used to
debug the real-time threads in user-space on the target. However, LTT
(Linux Trace Toolkit) support is missing, for instance.
Users that are interested in trying RTAI/Fusion can get a jump-start with
Debian, which has RTAI
packages in testing and unstable.
Though the Real Time market is a small niche of the Linux community, it's
good to see healthy projects like RTAI/LXRT and RTAI/Fusion that will give
Linux the opportunity to achieve the goal of world domination.
Comments (none posted)
Page editor: Jonathan Corbet
Next page: Security>>