Leading items [LWN.net]

On the defense of piracy enablers

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 there, however:

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 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.

Comments (97 posted)

OSI procedures - a study in quotes

The Open Source Initiative 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.

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 experienced....

And thus, I really have to question the process.

-- Bruce Perens

http://bastiat.org/en/the_law.html

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

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 the committee.

-- Russ Nelson

A priori, democracy is held to be good. This is faith-based reasoning.

-- 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)

Guten Tag from Avahi

August 24, 2005

This article was contributed by Joe 'Zonker' Brockmeier.

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 (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:

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 quite usable:

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 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.

Comments (7 posted)

Page editor: Jonathan Corbet
Next page: Security>>