LWN.net Weekly Edition for April 3, 2003 [LWN.net]

The spread of "super-DMCA" bills

Much attention has been paid to copyright legislation at the U.S. Federal level. There is less awareness, however, of what is going on in state legislatures. In fact, something is going on: numerous states are considering (or have already passed) "super-DMCA" legislation based on a model law that is, according to Ed Felten, being circulated by the MPAA. This law has some unpleasant implications which are worth looking at.

Take, for example, the proposed law for LWN's home state of Colorado. The bill looks like a fairly mundane effort to (further) criminalize acts like the theft of cellular phone service. But, one of the acts criminalized is:

...to conceal or to assist another to conceal from any communication service provider, or from any lawful authority, the existence or place of origin or destination of any communication that utilizes a communication device;

Those who believe in freedom in general should certainly balk at a law which requires all communications to happen in the open. But this law also criminalizes many routine acts carried out by users of Linux systems (and computers in general):

Sending email over an encrypted connection.
Use of IP masquerading or network address translation. The DSL modems handed out by Colorado's alleged "communication service provider" would be illegal under this law. It would be interesting to ponder, actually, whether Qwest is guilty of "assisting another" to hide communication endpoints from itself.
Just about any sort of virtual private network technology would infringe the law. SSH tunneling, too, would be illegal.

And so on; the above list does not go near services like anonymous remailers or Freenet. It's a poor law, and deserves to be rejected. The Colorado version has already passed the state House, but the final debate in the Senate has been pushed back to April 7 as a result of expressions of concern from Colorado residents. You Colorado folks out there may want to add your voice; this page has the information you'll need. Residents of other states may want to have a look at Ed Felten's super-DMCA page to see the status of legislation in your state.

One might well ask what the MPAA's interest is in this law. It seems unlikely that Jack Valenti would be all that seriously disturbed by the theft of cellular telephone service. The most likely answer would seem to be in the MPAA's desire to crack down on peer-to-peer file sharing services. It is hard, after all, to shut down "pirates" if you cannot even find them. Rather than face the problem and come up with a better business model, the MPAA would rather just require us to carry out all our communications in the open. We should not allow them to do that.

Comments (15 posted)

A discussion with Keith Packard

The XFree86 project is important enough that the current discussions over how the project should be governed deserve continued attention. To that end, we had a conversation with Keith Packard, who was recently removed from the XFree86 core team as a result of his efforts to bring about a change in the project. Without further ado...

LWN: Could you describe the role you have played in XFree86 until now?

Since joining XFree86 a bit over three years ago, I've been working hard to rebuild X as a window system capable of supporting modern applications. Designed in 1987, X11 hasn't seen any significant architectural work in well over a decade, and it really shows.

Dirk Hohndel (while we were both at SuSE) encouraged me to build an extension that could expose the capabilities in modern graphics hardware to 2D applications, most notably anti-aliased graphics and image compositing. The Render extension is the result of that work.

This work was not done in a vacuum. Help from many people was critical in the design and implementation of all parts of the extension and supporting libraries. I've become deeply involved in KDE, Gnome, Mozilla and many other minor X projects. I've also been fortunate to have the assistance of people from the OpenGL community, the application community and one of the leading experts in computational geometry: Lyle Ramshaw.

LWN: Your "call for open governance" points out a few problems you see with the status quo. The first is "limited development resources" - XFree86 has a relatively small developer base for a project of its size. Why do you think that is, and what would you like to see done to change it?

Part of it is undeniably the steep learning curve for working within the X codebase; the project currently consists of more than 17 million lines of code, and a lot of the documentation necessary for writing device drivers is not available.

However, we cannot ignore the historical closed nature of XFree86 as another influence. Until I started at XFree86, the developer mailing lists and even the development version of the release in CVS was open only to people granted membership within the project, and such membership was granted only after demonstrating an ability to work with the code.

A certain amount of this was originally forced upon the project by the X.org contracts, but after the great licensing fiasco around X11R6, that reason disappeared and yet XFree86 remained a members-only project.

I pushed for changes in this policy, the result was a public CVS and some public mailing lists that I managed for quite some time. The old members-only developer mailing list remained, ostensibly for the purpose of discussions concerning non-public material, but in reality it was difficult to wean the existing members from a list not carrying traffic from new developers.

Another hurdle for new developers is the lack of any technical road-map for the project; releases are scheduled with no idea of what they will contain or even what people are working on. A new developer interested in helping out faces a difficult task in locating other developers even before attempting to learn the internals of the code. I attempted to suggest mechanisms to address this issue and was met with stiff opposition within the core team.

LWN: You cite slow release schedules; how is the XFree86 release schedule determined now? What would you change to speed it up?

The XFree86 release schedule is entirely determined by the availability of the release manager. Because XFree86 is released monolithically, minor driver updates like support for new versions of existing chips wait for the next release rather than being made available separately.

I would like to see each library, driver and application released individually. X has a history of strong interface specifications and this should be leveraged in the release process. Much like Gnome or KDE is done today, occasional packaged releases could be done that look much like the current releases but which would be built by collecting releases of the individual packages together rather than attempting a unified release process.

Separating the release schedule of each module would make frequent updates possible where necessary while not burdening the downstream maintainers with huge volumes of complete X releases; areas of rapid progress would see rapid releases while stable code could be released more slowly.

Possibly even more importantly, splitting the release into modules would permit each module to be separately maintained and replaced; the project would be able to effectively leverage many more people in the management of changes. Many other projects do this today to allow scaling beyond the ability of a single individual to incorporate changes into the project.

LWN: There are some interesting parallels with the kernel project, which also must manage large numbers of independent modules to provide support for the latest hardware and such. Splitting the kernel into multiple distributions is often suggested, but the idea never gets that far. The fear is that splitting the pieces apart will make it harder to keep the whole thing in sync, especially when APIs change. I take it you don't think that would be a problem with XFree86?

There are several interfaces within the current X architecture:

Protocol interfaces. These should be treated in much the same way as kernel/glibc interfaces where extrememly strong compatibility requirements ensure cross version interoperabilty.
Library interfaces. These are the same as the application/library interfaces present today and require the same level of interoperability as glibc versions do.
Driver interfaces. Because XFree86 encourages binary-only graphics card drivers, it should support that with strong binary compatibility guarantees. These are possible given the module loading mechanism in place, but are essentially untested by the development community as the whole system is built monolithically.

The only new interoperability requirement here is that the driver interface provide cross version compatibility, and this is already required to support binary graphics card drivers. Having it a regular part of the X environment will ensure that the interface is tested by all developers instead of only those few who produce the binary drivers.

LWN: Lack of cooperation: did GNOME and KDE approach XFree86 in search of cooperative development opportunities? How do you think XFree86 should work with the developer communities for X client projects?

I don't believe either KDE or Gnome have approached the XFree86 project as collective units, but individual developers from each project have interacted with XFree86 developers. One significant failing in X management today is the area of standardization. XFree86 plays little or no role in the maintenance of standards supported by the code, instead that role is left to the moribund X.org group. For KDE and Gnome, the result has been no progress in interoperability standards, most notably the inter-client communications conventions which form the basis for cooperation among applications, window managers and session managers.

KDE and Gnome ended up starting a new organization (freedesktop.org) to extend published X standards. Clearly, the responsibility for maintaining and extending that standard should lie within some X project, but the lack of a standards process within XFree86 has caused developers to take their ideas elsewhere.

X design must be done in a public venue with input from the projects layered on top. The current driver architecture within the server is a model of efficiency and performance when executing X protocol as presented by the x11perf benchmark. However, real applications take little advantage of that code as the X drawing model fits very poorly into modern graphical applications. X architecture should follow from application requirements, rather than benchmark racing.

One obvious first step is for X developers to start using modern applications; many key X developers wear the badge of 'twm' or 'fvwm' with pride. I switched to a mixture of KDE and Gnome desktops several years ago so that problems with those environments would be immediately evident as I changed code underneath them.

LWN: Opacity of the development process: is there anything there that a little documentation wouldn't solve? Is it matter of finding somebody to do that work, or is there a deeper problem which must be overcome.

Documentation about active projects and developers would help new contributors locate appropriate groups; splitting into many separate projects would limit the size of the codebase in which individual contributions could be made and publication of release schedules along with intended content would all help make the development process less opaque. Perhaps the most important thing of all would be an active participation by the key developers in conferences, mailing lists and IRC channels to make their contributions more visible and understandable.

LWN: There has been a lot of third-hand talk of what you were trying to do before the situation blew up, but not much from you personally. What were you trying to accomplish prior to your removal from the core team? Why do you think they responded in the way they did?

Over the last year or so, I have become convinced that XFree86 is headed for a success disaster -- widespread adoption of Linux on the desktop will cause a catastrophe for X development given the current lack of resources and inability to scale the project beyond its current bounds.

An urgent need to open up development and invite in new contributors while changing processes to make the existing contributors more effective seemed critical. I believed then that fixing the processes would avoid the impending disaster. However, my attempts to work within the existing structure have proven less than effective.

As I've attempted to open up the development process and prepare for a significant increase in Linux desktop deployments, I've run afoul of the current XFree86 leadership. My ability to contribute to the project was severely curtailed in stages, first administration of the public server, next permission to represent XFree86 to other groups, then administration of the public mailing lists, and finally CVS access.

I don't blame the current leadership for this problem; there are no guidelines or processes in place to deal with conflict in the development community. As the project has grown, it has failed to adapt to that growth by building formal structures necessary to govern a large and diverse group of people.

However, with my ability to effectively contribute severely restricted, I was forced to consider how to resolve the problems I faced. I discussed my dilemma both with members of the XFree86 core team and outside interests. I first learned that I was not alone in my views on XFree86 leadership; several prominent voices in the wider X community agreed with my assessment and encouraged me to find solutions.

The conclusions from this process were clear -- effective cooperation within the development community would require a government sanctioned by that community to run the X project as there was no other way to restore trust between the community and the leaders. The XFree86 by-laws provided no mechanism to force such a change on the project, and I was not sanguine that the XFree86 leaders would accept such change willingly, and hence I was forced to consider alternatives, even as I worked to find resolutions within the project.

Upon learning of my discussions, the XFree86 leaders were angry that I could privately disagree with their leadership while publicly supporting the project itself. The result was that I was summarily removed from the core team and subjected to censure on public mailing lists and web sites.

LWN: Is it your intent to create a fork of the XFree86 code base?

My goal is to promote development of the X window system. Right now, I don't believe it is possible for me to effectively do this within the structure of the XFree86 project. I have asked that they seriously consider changes that I feel necessary to restore public confidence in the project leadership and provide an environment where people can work together on the technical challenges facing the window system even if their individual goals are not identical.

LWN: Do you see any signs that XFree86 may be moving toward a more open system? Or does the status quo look likely to remain for some time?

The XFree86 leaders have only publicly discussed minor procedural changes which don't address the fundamental questions of authority, trust and governance. I hope they seriously consider these underlying issues instead of making only superficial changes in the project.

I held a conference call last Thursday with representatives from many projects and representatives from the XFree86 core team to discuss these issues. I'll be publishing detailed minutes of that call soon, pending agreement from the participants. The messages from that call have been taken to the XFree86 leaders and I expect to hear back from them shortly.

LWN: In your opinion, what should be XFree86's highest development priorities?

The highest priority should be to create an environment where people are encouraged to participate to whatever extent they are able, and where these contributors feel ownership of their code and pride in the community in which they work.

Actual projects should, as always, be directed by the contributors themselves. Personally, I will be working on ensuring that X applications have the support they need within the window system to provide the best user experience possible, and that the window system is a good citizen in the overall Linux environment.

Comments (13 posted)

Page editor: Jonathan Corbet

Inside this week's LWN.net Weekly Edition

Security: A new xbox hack; new vulnerabilities in ecartis and sendmail.
Kernel: USB gadgets; IDE changes; request queues
Distributions: Source Based Distributions, Part 1; New; PlumpOS and Linux/Epia
Development: The Analog Web Log Analyzer, Planet CCRMA Update, New versions of SAP DB, OMNI, KONTENTOR, Zope CMF, Red Carpet, Mozilla, PythonCAD, Nautilus, Samba, OpenSSH, Jabberwocky, OProfile, Anjuta.
Press: Open-source PR, Xbox cracked open, Fujitsu Linux robot, Oracle funds Linux desktop, Eric Raymond interview.
Announcements: FSF Corporate Patronage Program, Linux Audio Developers Conference slides and recordings, LPI Level 1 Exams, GCC Developers Summit.

Next page: Security>>