That could all be true, as far as it goes. Mr. Mueller does not stop there, however:
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 to us.
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 patent fight.announced last April that it was forming a committee to address the license proliferation problem. This committee is charged with the 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.
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 experienced....
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 about.
-- Russ Nelson
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.
-- Russ Nelson
-- Bruce Perens
-- Russ Nelson
-- Russ Nelson
-- Keven Bedell
-- Russ Nelson
-- 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.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 (formerly "Rendezvous"), Multicast DNS (mDNS) and DNS Service Discovery (DNS-SD) from the Zero Configuration Networking (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:
Poettering also identified three "SHOULDs" in the mDNS specification that are not implemented in the 0.1 release of Avahi:
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 quite usable:
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 preference."
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 incorporate Avahi.
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.
Page editor: Jonathan Corbet
Next page: Security>>
Copyright © 2005, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds