Noted anti-patent activist Florian Mueller recently distributed a statement
regarding the Linux
trademark policy. This policy, according to Mr. Mueller, is just fine;
trademarks are not a barrier to innovation and free software in the way
that patents are. Opposing trademark protection, he says, risks making the
anti-patent community look like it opposes intellectual property in
general; that, in turn, could hurt the fight against software patents.
That could all be true, as far as it goes. Mr. Mueller does not stop
In addition to the debate over the Linux trademark, Mueller is also
worried over the role that some organizations play in an American
court by defending the developers of the "bnetd" software against
computer game publisher Blizzard Entertainment: "It's very unwise
for organizations like the EFF (Electronic Frontier Foundation) to
rush to the aid of piracy-enablers. It makes it look like software
patent critics are against copyright, which most of us are not."
This, in your editor's opinion, is dangerous and incorrect reasoning.
One could start by noting that bnetd was certainly not implemented as a
"piracy enabler." Bnetd is a game server for certain games created by
Blizzard Entertainment. It was created because its developers, having
experienced Blizzard's game servers, decided that they could create a
better environment for themselves. So they wrote their own game server
package which lacks some of the problems of Blizzard's Battle.net. It also
lacks Blizzard's authentication mechanisms (for which the requisite
implementation information is not available in any case). As a result,
bnetd can (unlike Battle.net) be used by multiple players who have made
copies of the same game
CD; this is an unintended side effect of bnetd's implementation, not its
purpose for existing.
It seems unlikely that any significant amount of piracy has been "enabled"
by bnetd. But it would not matter in any case. The issue here is not one
of piracy, it is, instead, about the right to create interoperable
software. If bnetd is illegal, then our right to develop software to
interoperate with commercial offerings is much reduced. That is an outcome
which is worth fighting.
We have seen this sort of issue before.
Dmitry Sklyarov's e-book processor could be said to be a "piracy
enabler." Adobe certainly made that claim. Fortunately, few people
questioned the correctness or necessity of defending Mr. Sklyarov.
Similarly, Jon Johansen was accused of facilitating piracy by releasing the
DeCSS code. But DeCSS is not about piracy; it is about our right to play
the DVDs we have purchased on our Linux systems. If we cannot write
interoperable software, we will be stuck with whatever others deign to sell
In the U.S., at least, the fight for civil liberties often requires
defending unpleasant people. It is the criminals, pornographers, drug
dealers, and others whose rights tend to be infringed first. But even the
sleaziest of people still have rights; if those rights are not defended,
they will soon cease to exist for everybody else as well. If the people we
disagree with do not have rights, we do not either.
Calling the bnetd developers "piracy enablers" puts them in the same camp
as other societal outcasts. Pirates are, after all, among the great
evildoers of our time - at least, according to some people. So casting
developers as pirates makes it easier to attack them. But even if bnetd
were truly a "piracy enabler," its developers would still deserve our
support. These developers did something that many or most of us believe is
within our rights to do. Should we write them off just because somebody
says they are helping pirates?
Anybody who believes that the bnetd developers do not deserve the
community's support would be well advised to think about what the next
"piracy enabler" might be. BitTorrent, perhaps. MythTV? Sound Juicer?
Gaim or Kopete? How about GreaseMonkey? Or XBox Linux? Or Linux in
general, for that matter. The fight against software patents is crucially
important, and it is well to think about how we might best win it. But any
victory which involves throwing members of our community to the wolves to
avoid any appearance of being soft on intellectual property rights will be
illusory at best. The EFF is doing the right thing when it defends the
bnetd developers; this fight is just as important to our rights as the
Comments (97 posted)
The Open Source Initiative announced
last April that it was forming a committee to address the license
proliferation problem. This committee is charged
task of coming to terms with this problem, proposing ways of improving the
situation, and sorting open source licenses into "tiers" as a way of
directing projects toward a preferred subset. The archive
of the committee's
closed mailing list suggests that, as of this writing, not a whole lot of
work has gotten done yet.
The issue of committee membership recently surfaced on the license-discuss
mailing list. Rather than attempt to summarize the discussion, your editor
decided to provide a few quotes and let the participants speak for
themselves. For the curious, the
entire thread is available from the archives.
Some time ago, I applied to be on the license proliferation
committee. I eventually got a form letter from Laura Majerus saying
that they had too many qualified people....
Most of you will realize that I am uniquely qualified as the main
author of the guidelines that OSI now seeks to interpret, and
someone who has assisted many businesses and legal professionals in
working within those guidlines since then. Two people with
experience similar to mine but less in duration were admitted to
the committee. There are a few legal professionals admitted. All
others admitted are extremely worthy individuals, and have been
working very hard at this, but I can't really say they are more
And thus, I really have to question the process.
-- Bruce Perens
It's very short. You should read it. I discovered something very
interesting in it: it doesn't matter who writes the law, as long as
the law treats everyone equally....
Rather than judging the process, you should judge the result.
Since there are no results yet, you have nothing to say anything
-- Russ Nelson
Several years ago I agitated strongly about the lack of any
semblance of democracy or transparency in the OSI. I stopped when
I realized that the OSI didn't really matter. Since then the OSI
has some to matter somewhat more--e.g., sourceforge.net looks to it
to ratify licenses. But it still doesn't matter very much....
Personally I think the OSI should drop any claims about
representing the community, and instead describe itself as a group
of self-selected experts who periodically issue opinions about open
source licensing-- i.e., more or less the same as any NGO. I think
that would be more honest and more helpful.
-- Ian Lance Taylor
How we do things is immaterial. What we do is the only thing that
matters. When you eat in a restaurant, you don't get to vote for
the cook. You voted when you walked into the restaurant. People
selected OSI because we matter.
-- Russ Nelson
I feel it's unfair to everyone, not just me, to keep my expertise
off of the committee. That's why I stated my case.
-- Bruce Perens
The license proliferation committee will have to make hard
decisions. We made one in your case, and you are attempting to
strong-arm us into changing our minds. This is evidence to me that
we chose well to keep you off the committee. The license
proliferation committees' continued rejection of you is necessary
practice for ignoring the anticipated pressure. Even though you
don't like the form of it, you are contributing to the success of
-- Russ Nelson
A priori, democracy is held to be good. This is faith-based
-- Russ Nelson
If the writings of Bastiat weigh stronger on the decision making
process of the OSI then those of Perens, then maybe it's better
that we don't get to watch...
-- Keven Bedell
In fact, you weren't rejected because you were or were not Bruce
Perens on the night of September 22, 1997. You were rejected
because you were person N+M on a committee of N people where M>0.
No malice intended; you just didn't make the cut; sorry that you
weren't even the guy out in right field; hope your feelings weren't
hurt (would it help to apologize?).
-- Russ Nelson
The committee as it presently exists is over-lawyered, and I would
have added some balance and a lot of skill. If you look at the
discussion list, it will be clear that they aren't getting very
much energy out of that group of extremely busy people. Turning
away an extremely-qualified volunteer who has already worked on the
problem isn't a good idea.
-- Bruce Perens
For what it is worth, the current committee membership is Brian Geurts,
John Cowan, McCoy Smith, Diane Peters, Cliff Schmidt, Laura Majerus, Karna
Nisewaner, Russ Nelson, Damien Eastwood, Eric Raymond, Mitchell Baker,
Rishab Aiyer Ghosh and Sanjiva Weerawarana. There are no indications that
any changes to the membership will be made.
Comments (24 posted)
Early this week, the Avahi team announced
the 0.1 release of Avahi, dubbed "Guten Tag."
Avahi is a framework for service discovery on local networks, using the
same specifications as Apple's Bonjour
"Rendezvous"), Multicast DNS
(mDNS) and DNS Service Discovery
(DNS-SD) from the Zero Configuration
(Zeroconf) working group.
So, Avahi allows programs to publish services that are available and to
discover services that are available on other machines. As an example, a
user could find local printers without needing to know their IP address, or
which computers are publishing file shares.
We asked two of the Avahi developers, Trent Lloyd and Lennart Poettering,
about this release and what we could expect from future releases.
Avahi is a framework, and is meant to be used by other programs that have a
need for mDNS/DNS-SD. It uses a D-BUS API, with
"implicit bindings" for Python, Mono and many other languages,
according to Poettering.
According to the release notes, a few of the "SHOULDs" for mDNS were not
implemented. We were curious about what hadn't been implemented, and
whether they planned to implement them in the future. Poettering explained
why some of the "SHOULDs" were not in this release:
This depends. Some of the missing "SHOULDs" are difficult to implement (or
at least I'm to lazy to implement them for what it's worth), some of the
"SHOULDs" are currently discussed to be removed from the RFC entirely, some
don't apply to our implementation and others I consider questionable.
Poettering also identified three "SHOULDs" in the mDNS specification that are not implemented in the 0.1 release of Avahi:
Unicast response bit generation (Avahi honours it on incoming queries but
doesn't set it on outgoing queries). According to Marc Krochmal (one of the
two Apple guys behind mDNS/DNS-SD) they're considering the complete removal
of this feature, as its added complexity outweighs the gain.
An extra delay should be applied when relying to packets with the TC
(truncation) bit set. This is on the TODO list. It's a fairly new addition
to the spec (only available in the spec as of 7th June 2005).
Passive observation of failures. This must be slipped from my mind
completely. I didn't have that one on my list. Since avahi doesn't
implement this (optional) feature at all, the "SHOULDs" don't apply to
Avahi right now. (Though I added this to the TODO list now)
Despite the low version number, and the fact that a few of the "SHOULDs"
have not yet been implemented, Lloyd said that this release is actually
Well the low version number is a bit of a misnomer it terms of featureness,
it does have quite a lot in it, there is some work for 0.2 to provide a
couple new resolver interfaces to the DBUS for better handling of services
changing their information, and it will certainly contain bug fixes.
Poettering also noted that Avahi "has lots of uncommon features that
even Apple's stack doesn't have." One feature that Poettering
highlighted is "avahi-dnsconfd," which "allows the configuration of
unicast DNS servers via mDNS in a DHCP-like fashion. This is especially
useful on IPv6 where address autoconfiguration is available out-of-the-box,
but DNS server configuration currently isn't."
We also asked if the low version number indicated that Avahi would be
undergoing major API changes. Poettering said that he doesn't see
"any major changes coming for the near future" but that there
would probably be some API additions.
One thing that Poettering stressed is that Avahi is not GNOME-centric or
KDE-centric. "We currently ship a glib adapter for our libraries, but
this purely optional... We are interested in adoption of Avahi in all
desktop environments, including both GNOME and KDE. Admittedly the core
developers of Avahi are all GNOME people, but that's just personal
There are other implementations of mDSN/DNS-SD available, but not under
what many would consider a "free" license. Avahi is available under the
LGPL, so it should be usable by nearly any project that would care to
At the moment, Avahi is only available for Linux. The only stumbling block
appears to be netlink, according to Poettering and Lloyd. Poettering says
that "as soon as the BSD compatible replacement for netlink is in
place, porting to other kernels should be really simple."
It should be interesting to see how Avahi is incorporated into Linux
applications and distributions. The ability to easily advertise printing,
file-sharing and other services for desktop users -- putting Linux on par
with Mac OS X -- is one more component in helping to secure Linux's place
on the desktop.
Comments (7 posted)
Page editor: Jonathan Corbet
Next page: Security>>