Pronouncements from the Gartner Group have long been a good source of
amusement (and anger) in the free software community. Gartner has often
looked down on free software, claiming that it is not suitable for business
use. Over the years, however, Gartner's position has softened. Their latest
takes a different tack altogether. Now, rather than
avoiding Linux, companies are advised to set up proper policies and "best
practices." Some of their suggestions actually make some sense.
So what approach does Gartner suggest for the suits in the corner office?
The highlights are:
- Create formal guidelines describing the company's policy toward
free software. The sort of company that Gartner presumes to advise
will have such policies for every other aspect of its information
technology operation. The creation of more rules with regard to free
software is just the way these companies can be expected to operate.
- Rather than applying blanket policies to free software in general,
companies should look at individual applications to see whether they
make sense or not. Such advice may seem obvious, but some people need
to be told these things.
- If the company is going to depend on a free application (and
especially if the application needs an enhancement or two), somebody
should be given the role of working with that application's
development community. The company also needs to keep in mind that it
does not control the project or its release schedules.
- Gartner advises against making modifications to free software in
general. The expectation, of course, is that the company has a
support contract with somebody, and tweaking the software can render
it unsupportable. Gartner makes an exception, however, for cases when
the company has the requisite expertise and is willing to feed its
changes back to the development community.
- Care should be taken with regard to licensing, and especially in
mixing GPL-licensed code with the company's own proprietary code. As
Gartner notes, the resulting combination can only be distributed if
the proprietary code, too, is made available under the GPL. Since
this advice is aimed at big companies, Gartner recommends the
formation of the inevitable "code licensing and definition committee"
to oversee licensing policy and compliance. Some may see Gartner's
caution as more "GPL FUD," but the SCO lawsuit shows how careful
companies really have to be in this area.
- Pay attention to standards and certification. Distributions should
be certified by the Free Standards Group, and applications should be
certified by the distribution vendor.
- Make sure your staff is properly trained in corporate policy and
working with the free software community. Gartner recommends having
employees get LPI or SAIR certification (interestingly, they do not
mention Red Hat's RHCE).
Perhaps the most significant point in all the above is that Gartner is
advising companies to learn how to work with the free software development
community. Free software is not just another shrink-wrapped product you
buy from a store shelf or cologne-soaked salesman. It is the product of an
active community which must be dealt with in its own way. Companies that
work well with the development community will have a far better experience
with that community's software. That is good advice.
Comments (3 posted)
The next stage of the copyright wars has begun: the RIAA has filed suit
against four university students alleging massive copyright infringement
and asking for tens of millions of dollars in damages. That's the sort of
action that can make a serious dent in an undergraduate student's beer
budget. But these cases have a wider significance which merits a look.
The four complaints (which can be found over here)
share the same basic form and, indeed, much of the same language. The
first claim is that the defendants are directly making copyrighted
materials available on the net for copying. This act looks like a fairly
strightforward copyright violation, so the RIAA - if it can prove its case -
probably has a legitimate complaint there. Copyright is the law of the
land, and it's important (the GPL relies on copyright law). If you
directly violate copyrights, you should not be too surprised if the owners
of those copyrights decide they want to have a talk with you.
But the RIAA does not (yet) go after every student who makes a few MP3
files available. These defendants were chosen because, in each case, they
published an index of files available on a campus network. Through this
act, according to the RIAA:
Defendant has hijacked an academic computer network and installed
on it a marketplace for copyright piracy that is used by others to
copy and distribute music illegally.... Defendant has taken a
network created for higher learning and academic pursuits and
converted it into an emporium of music piracy where copyright
infringement is simplified down to the click of a computer mouse.
In all four cases, the actual distribution of files in this "emporium of
music piracy" was performed by others. The defendants just created an
index to enable others to find those files. In at least one case, the
index included all publicly-available files, not just music files.
The defendants, in other words, are being sued for creating a search
This is the point where the RIAA has crossed the line. Rather than go
after people who are actually violating copyrights, they are launching
million-dollar lawsuits to shut down indexing services. Once again,
linking becomes a crime. This is a direct attack on basic freedoms: it is
no longer possible to make an index of files available on a network, since
some of them might just be copyrighted.
No cost is too high, it seems, to save the recording industry from the
The cost is too high, however. The free software community (and
much of the rest of the world) depends on freedom of information flow to
function. Every time we are told that we cannot make links, or create an
index, or release a bit of scary code our freedoms are reduced and our
community functions a little less well. You don't have to be a music
trader to feel threatened by that.
(See also: Joseph
Barillari's analysis of the complaint against Dan Peng).
Comments (15 posted)
[This article was contributed by Joe 'Zonker' Brockmeier]
It's hard to believe that it's been five
years since Netscape released the source code for what was supposed
to be Netscape Communicator 5.0 under the Netscape Public License (NPL),
and less than a year since Mozilla 1.0
went "gold." In that time, Microsoft has managed to dominate the browser
market, Netscape got swallowed up by AOL and the Mozilla project has
tackled milestone after milestone to deliver an Open Source browser
though perhaps not as quickly as many would have liked.
More than 200,000
bug reports later, the Mozilla project has put out an excellent browser
and a codebase that's being used in a wide array of Open Source and
commercial applications. Perhaps even more important than the code
itself, Netscape's decision to plunge into Open Source helped to bring
the Open Source debate further out into the, well, open. The decision to
pursue Open Source was made when relatively few people had heard about
this thing called Linux.
You could say that Mozilla is more than the sum of its parts, especially
when you consider all that's been done with those parts. Mozilla's Gecko, which replaced the
original Netscape layout engine, is being used in the proprietary
Netscape offering, AOL's Mac OS X client, a native Mac OS X browser
called Camino, the
popular Galeon browser and
several other projects. It's also being used in products like
ActiveState's Komodo, an IDE for
Perl, PHP, Python and other popular Open Source languages.
The project has also designed a cross-platform installer (XPInstall), a Document Object Model
(DOM) Inspector, and several development tools that are now being
used on projects wholly unrelated to Web browsers. The Bugzilla bug
tracking system is used by quite a few Open Source projects (and
possibly by a few commercial companies behind closed doors). Bonsai and Tinderbox are also
by-products of the Mozilla effort that are being widely used elsewhere.
Mozilla's wealth of features has also attracted some criticism. Some
feel that Mozilla, with its huge array of options, is too slow and
bloated. Apple's decision to use KHTML rather than Gecko in the Safari
browser didn't go unnoticed, either. In the article "Browser
Innovation, Gecko and the Mozilla Project," Mozilla's Chief Lizard
Wrangler, Mitchell Baker, writes:
Some see this as traumatic or as a mark of doom... We would have
preferred to have Apple use Gecko or collaborate with us on the
development of the Camino browser, but providing an alternative to an
OS-sponsored browser is nothing new to us. The key goal of the Mozilla
project is to help keep content on the web open and help keep access to
that content from being controlled by a single source. Apple's decision
to ship a browser based on an open source rendering engine, with a focus
on standards compliance, is a good thing for the big picture goal.
Judging by the project's recently-updated development roadmap, the
Mozilla folks have taken the criticism seriously. The new mission for
Mozilla might be summed up as "do less, but better" and a move away from
the "swiss army knife" approach. The new development roadmap calls for a
switch from the current browser component to the standalone (soon to be
browser and an increased focus on the Minotaur mail
component. It also calls for a move away from the 1.0 branch to the 1.4
branch when 1.4 becomes stable.
More importantly, though less visible to the majority of Mozilla's
users, is the change in the development model. The current model is
being replaced by a meritocracy where a few project "drivers" will be
responsible for particular components of the project. From the roadmap:
It is time for Mozilla to "return to normalcy": great software is
originated by one or a few hackers building up and leading a larger team
of people who test, clean up, extend, and grow to join or replace the
first few. Code review, like testing, is an auditing procedure that
cannot make excellent code from mediocre input.
The end goal, according to the new roadmap, is to produce a simpler
browser with the potential to have advanced functionality through
optional toolkit applications. Kind of an a la carte browser, if
you will where additional components can be added easily but are
not required. This should be a big win for proponents of a scaled-down
Mozilla 1.4 alpha was released on April 1st (no, really), and the
final 1.4 release is likely around the end of May or beginning of June.
The ideal release date for 1.4 is given as May 21, but we all know about
ideal release dates. The alpha for 1.4 actually seems very stable, and
faster than previous versions of Mozilla, at least based on my
experience over the past week or so.
If the project sticks to the proposed roadmap, the next five years look
very good for Mozilla.
Comments (none posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Samba gets hit again; new vulnerabilities in apache, mgetty, ...
- Kernel: Dynamic device numbers; SELinux support; 2.5 DMA changes.
- Distributions: Source Based Distributions, Part 2
- Development: The Gaim Instant Messaging Client, ZopeMag #4, XFree86 teleconference minutes,
new versions of Demolition, MySQL, SquirrelMail, mnoGoSearch,
YaBB SE, PABlog, MusE, Evolution, GSview, Vstserver, KStars,
Gaim, Java, JML, Informa, OpenMCL, ROBODoc, Regina REXX.
- Press: Xbox mod chip retailer jailed and fined, Individualism Vs. the Company Line,
Oregon open-source hearing, your favorite Linux hardware vendor,
Web Framework Shootout.
- Announcements: OSAF Status Update, Real World Linux, Penguicon 2003,
YAPC::NA Schedule, ClusterWorld Conference and Expo.
- Letters: Red Hat Linux 9 and developers