LWN.net Weekly Edition for January 4, 2007

Looking forward to 2007

Predictions, as they say, are hard - especially when they involve the future. It's easy to get them wrong and look like a total fool. Your editor, however, has long since gotten over his fear of coming across as a total idiot in front of large numbers of people; when you have already tipped your hand, there is no point in holding back any longer. So here's a few things which, in your editor's view, might just come to pass in 2007. As always, these predictions come with no warranty whatsoever.

Legal issues

Version 3 of the GPL will be adopted, perhaps after one more draft round. Your editor has no clue of how the FSF will respond to the criticisms of their anti-DRM provisions. If that language remains, uptake of the new license will be somewhat lower; the FSF may try to avoid that scenario by making "distribution on restrictive hardware without the associated keys" an optional permission which can be granted by the copyright holders.

Somebody will be sued for distributing proprietary kernel modules. Threats of lawsuits have been muttered for some time, but the late-2006 discussion on banning those modules made it clear that GPL infringement suits are the strongest weapon available to those who oppose proprietary modules. Given the way the frustration level is rising, it is only a matter of time until somebody uses that weapon.

We will see the end of SCO in 2007. Chances are that the company's case against IBM will not even survive until the planned trial date in the (northern hemisphere) fall. Look for fun around March, when dispositive motions can be heard.

There will be serious talk of patent reform in the U.S. The EFF is unlikely to succeed in its attempt to get the U.S. Supreme Court to throw out patents on software altogether; the current chief justice places a heavy emphasis on deciding no more than the current case requires, and software patents are not at issue in that case. But the pain caused by these patents is severe and growing; something will eventually have to be done. Whether that "something" will help to lift the clouds of legal uncertainty from free software remains to be seen, however.

Development

Linux will have fewer problems with closed hardware one year from now. There is already a clear path to support for most wireless network adapters. On the video front, a palpable determination to address the problem has come together over the last year. The Nouveau project can be expected to make significant progress over the next twelve months, and developers are beginning to talk about a project to support ATI's R500 engine. A decision by AMD to open up ATI's hardware would be a nice bonus. But, either way, the need to solve this problem is well understood, and developers are increasingly interested in attacking it.

Closed hardware problems will not go away, however. The content industry, with Microsoft's help, is pushing for a new generation of hardware which is intended to be "trusted" not to give too much control to its owner. "Trusted content paths" are fundamentally incompatible with free software. So we will continue to have trouble in carrying out straightforward tasks - like watching movies - on our free systems until the industry comes to its senses.

The war on bloat will get serious as people get tired of running out of memory. The increasing use of Linux on small and embedded systems will also create pressure for lower resource usage. Tools are emerging which will help developers track down wasted memory; their employment should lead to leaner systems for all of us.

The previous item notwithstanding, Java will move into the free software community as Sun follows through on its promised code releases. Thus far, the amount of free software written in Java has been relatively small. Once free Java support is available for all Linux systems, the number of developers of free Java code can be expected to grow.

Fedora will come into its own as a free, community-oriented distribution. Fedora's transition from a corporate product into a community product has been slow at best, and it is far from complete. The right things are happening, however; the combination of a more open process, a 100% free software policy, and a high-quality base should lead to good things.

Debian will get the Etch release out this year. Honest. What could possibly go wrong? Thereafter, the Debian developers will go back to arguing about firmware in the kernel.

Free software will move into online gaming as a critical mass of interested developers comes together. Many of the necessary pieces exist now as free software, and the possibility of acquiring some cast-off corporate code still exists. Meanwhile, Second Life has shown the possibilities inherent in hackable online platforms. These environments are too much fun - and too much a part of our future - to leave to the proprietary software companies.

Commerce

The Microsoft/Novell deal will blow over with few consequences. Most of the angry ink has already been spilled, and it still seems unlikely that Microsoft will launch a patent attack against Linux. Novell will have lost credibility in the community, and may yet lose more developers, but it has not really changed the nature of the patent threat.

The "open source" term will take a beating as various semi-open companies try to look like free software operations. Some companies have already needed to be told to take the "open source" label off their code; others will certainly follow. The need felt by these companies to attach non-free provisions to their licenses may lead to the creation of a "shared-source"-like replacement term by the end of the year.

The first round of OLPC systems will be distributed to millions of children in the developing world. That much can be predicted by looking at the project's timeline. Much harder to predict is what will happen when millions of children learn to use systems which are open, Linux-powered, and network-connected. This project may well change the free software community - and the world as a whole.

Desktop Linux will grow as corporate managers realize they already have more desktop systems deployed than they had thought.

As always, these predictions will be reviewed in December of this year.

Comments (29 posted)

Trademarking the snake

A quick search shows that there are almost 200 trademarked terms in the U.S. using the term "Python." This name has been reserved for use with lacrosse sticks, bungee cords, musical instruments, tape libraries, arc welding torches, radio-controlled toys, wire rope, motorcycle exhaust systems, perfumes, cryogenic pipes, floor polishers, carbonated beverages, "providing online adult entertainment by means of a global computer network," orthodontic adhesive, herbicides, garage door openers, and much more. There is also a registration for a programming language. The term "Python," in this context, belongs to the Python Software Foundation (PSF), and has since early 2004.

In November, the PSF announced the adoption of a formal policy for the use of the Python trademark. This policy has version 1.2.2, despite being the first posted policy for the use of this name. The rules disallow calling any other language "Python," so it's no fair slipping in a Perl interpreter; they also forbid using the term "in ways that confuse the community as to whether the Python programming language is open source and free to use."

One clause regarding how the term "Python" can be used has attracted a small amount of attention in the Debian community, however. It reads:

This rule would appear to take in commercial Linux distributors, all of whom should, from a strict reading, be getting permission from the Foundation. Debian, as a non-commercial distributor, should not be directly affected by this language, but anybody who redistributes Debian on a commercial basis could be.

The question which comes up is: what uses of the word "Python" fall under this policy? Is providing a python command sufficient? How about in the introductory text printed when python is run interactively? Does listing Python in an online package database count? Can the release notes brag about the version of Python shipped? How about running a "now includes Python 3000" Superbowl advertisement? The final case is covered by a separate term which forbids the use of "Python" in advertisements without prior permission. But the real location of the line separating free use from that which requires permission is not entirely clear.

At this time, there would appear to be little cause for concern; the PSF has little interest in harassing people who are using or distributing its code. After inquiring with the PSF, your editor was told that the policy was created as part of the legal requirement that trademarks be enforced if the holder wants to keep them. The PSF has not seen any misuses of the name that it felt the need to crack down on, and it does not feel that noting the inclusion of Python within a commercial product necessarily requires permission. Noting that a product contains Python is acceptable in just about any circumstances. The PSF wants to promote the use and development of Python; it appears to be uninterested in legal silliness.

That said, there are a couple of things which should be kept in mind here:

• The Python Software Foundation is a corporation, and corporations can change their minds quickly. Should the PSF - speaking entirely hypothetically now - decide to split off "Python Corporation" as a separate, for-profit entity, the approach to trademark policy and enforcement could change overnight.

• Trademark law (in the U.S., at least) requires the enforcement of trademarks. If a trademark holder can be shown to have overlooked known violations, it can lose its rights to the mark. The law, in other words, can force trademark holders to get into the cease-and-desist business, even if they would rather be writing code.

The number of free software projects with trademarks and associated policies would appear to be growing. The issues surrounding the Firefox trademark have been well discussed here and elsewhere. Xen has a trademark policy which is quite strict on whether a distributor can claim to ship Xen; see the Xen trademark FAQ for a view of their approach to trademark management. There are trademark policies for Perl, MySQL, GNOME, and, of course, Linux. The KDE and OpenOffice.org trademarks have been registered, but there does not appear to be a posted policy for their use. Fortunately, an attempt by Unipress to trademark "emacs" was not successful.

In recent times, there has been some concern over license proliferation, resulting in a determined effort to reduce the number of free software licenses in active use. It makes sense; every software license brings its own set of conditions and interactions to worry about. Every trademark license is unique, however; each one has its own set of quirks, any of which can be changed at any time with no public participation or notification. The continuation of this trend could lead to an increasing series of hassles for distributors; the long-term result could be more software shipped under iceweasel-like names.

It would be nice if free software projects would stop worrying about trademarks and get back to working on the code. Abuses of free project names have been few and far between. This outcome seems unlikely, however. Nobody likes to see their chosen name hijacked, and commercial organizations can be positively paranoid about the idea. So a more realistic solution might be the creation of some sort of standardized free trademark license. A known set of trademark terms, the same for each mark and drafted with an eye toward keeping the associated software free, could do much to make life easier for software distributors. It seems like a better alternative than being neck-deep in iceweasels.

Comments (10 posted)

No free Ryzom; what next?

One month ago, LWN looked at the Free Ryzom Campaign, which was trying to raise enough money to buy (and free) the source to the Ryzom game in bankruptcy court. The Free Software Foundation got into the game (so to speak) with a $60,000 pledge. On December 21, however, the bad news was posted: another bidder had come in with a better offer. The campaign was left with a pile of pledges and nothing to buy.

Whenever a project gets that sort of energy and resources together, it is a shame to just let it all fade away. So the campaign organizers have been discussing possibilities for achieving their goal by other means. One of the immediate outcomes is the creation of the Virtual Citizenship Assocation, which is essentially the Ryzom campaign with the brand names removed. The organization is still soliciting pledges on the chance that the source for an interesting game may come available from somewhere else. One expects, however, that the number of pledges is unlikely to grow quickly until prospective donors can see what the organizers would like to buy.

There is a real chance that a game platform could be obtained this way. The history of free software projects starting with freed corporate code is long; Mozilla, OpenOffice.org, and InterBase are just some of the more prominent examples. The online gaming market is tough, with many failed offerings. Perhaps one of those proprietary failures could yet be turned into a free software success. Beyond that, the possibility of an open-source Second Life is still real.

The history of corporate code offers other lessons, though; among them is the fact that such code can often require a great deal of work. Mozilla treaded water for some time until it decided to simply toss much of its Netscape legacy and start over. It would be a shame to put a large pile of donated money into a code base which, in the end, needs to be thrown out and rewritten properly. It might be better to just start over from the beginning and do it right.

Except that starting from the beginning would not be necessary. The NeL library - the engine at the core of Ryzom - is already free software. Arkhart is a project to develop a GPL-licensed engine and game. The Planeshift engine is also free software - though the associated artwork is not. The WorldForge project has been working in this area for a long time. Other interesting projects exist as well.

There are a couple of conclusions to be drawn from this situation. The first is that we do have the interest - and the ability - to create game engines which can implement compelling virtual worlds. The code and the developers are out there; we don't have to buy that code from a failing company. The other side of the coin, however, is that code is only part of the problem. Top-quality online games need top-quality artwork, sound effects, music, storylines, and more. If our community is going to create a great online virtual world, we must do a better job of soliciting and integrating contributions from artists, writers, and others who are not software developers. Without them, all we have is a pile of code.

So there are a number of challenges to the creation of truly successful, completely free online worlds. But our community has always been good at overcoming challenges. This one, too, will fall, and we will, eventually, have our free online worlds. Your editor's kids think it can't happen too soon.

Comments (7 posted)