Leading items

Apple buys cups

One of the more strongly discussed bits of news over the last week is the announcement that Apple has bought CUPS (the Common Unix Printing system) and hired Michael Sweet, the project's primary developer. Indeed, this deal happened back in February; it just took a little while for the people involved to get around to telling the rest of the world about it. There is a great deal of concern over what this deal might mean, though most of it is probably unnecessary. Still, there are some lessons to be learned here.

CUPS is an important part of our core infrastructure. Those of us who can think back to the days of trying to create lpr input and output filters to make a specific printer work can only be thankful that CUPS came along. It could easily be said that lpr lasted at least ten years longer than it should have, but, over that time, there were no real attempts to create a viable alternative. Projects like LPRng were mostly trying to create a slightly better version of the same thing. Then, there was the print system which Sun inflicted on users of early Solaris releases (who, as your editor can attest, were already suffering enough as it was); replacing that system with some version of lpr was a common thing to do. It took CUPS to implement contemporary printing protocols, support current hardware, and generally make the life of printer administrators easier - though, as any administrator who has lost a day to an obscure printer problem will say, things could get a lot better yet.

CUPS has always been a corporate-owned free software project, meaning that it carries all of the potential problems that any other such project has. When a single company owns a project it can strongly control its development direction, take the code private, grant license exemptions at will, abruptly sell the code to somebody else, and so on. Many companies which own projects do many of these things. Dealing with corporations has its risks; it has often been said that the corporate personality is best compared to that of a schizophrenic adolescent. Even so, such relationships have worked out well for the free software community with very few exceptions.

In this case, the ownership of CUPS has been passed from Easy Software Products (ESP) to Apple. Since contributors to CUPS are required to assign the copyrights to their work, ESP was entirely within its rights to make this sale. There are few constraints on what Apple can do with this externally-contributed code in the future; if it chooses, the company could certainly treat the code in ways that the original authors would not like. This risk is inherent in the transfer of copyrights; any free software developer who is contemplating signing a copyright transfer agreement should always think hard about who the receiving party is and what they could do in the future. The usual rule for dealing with companies - assume the person you negotiated the deal with will be immediately replaced by somebody who hates you - applies in this sort of situation.

The worst thing that Apple can do, in any case, is to take future releases of CUPS private. The current, GPL-licensed releases will remain available and free. Should this happen, the community will have to pick up from the last free version and create a fork; it certainly would not be the first time such an action proved to be necessary. For now, though, the announcement of the sale says "CUPS will still be released under the existing GPL2/LGPL2 licensing terms, and I [Mr. Sweet] will continue to develop and support CUPS at Apple." Given that certain aspects of CUPS development - supporting hundreds of printers, for example - are best done in the community setting, it is not hard to believe that this state of affairs could continue indefinitely.

Apple just might create enhanced versions of CUPS for its own operating system or as a commercial product. The company has already published a GPL exception policy allowing proprietary derived products to be made from CUPS - as long as they are distributed exclusively for Apple's operating systems. So Apple's version of CUPS might have shinier widgets or a few more printer drivers. Not the best of situations, but it is not all that different from the rights Sun gives itself with the OpenOffice.org code base. OpenOffice.org lacks features, fonts, and clip art found in StarOffice, but few OpenOffice.org users have complained that they felt cheated. Companies like MySQL make a nice living selling GPL exceptions to GPL-licensed code, including code contributed by outsiders.

The real threat, perhaps, is that Mr. Sweet will find himself carrying a lot of Apple-specific responsibilities (his statement in the sale announcement carefully did not say how much he would continue working on CUPS) and that the rate of outside contributions might slow as developers worry about what Apple might do. That could significantly slow the rate at which CUPS moves forward, to the community's cost.

One other potential problem is the CUPS trademark policy which has been announced by Apple. It requires permission to use the CUPS name with any derived product; a distributor who applies any patches at all, even security fixes, would be affected by this policy. The good news here is that, if this policy becomes a problem, the name of the print system could be changed to "mugs" or some such and few users would even notice.

On the other hand, what this deal might do is bring more resources to the development of CUPS and contributions from a company which, for all its faults, is known to pay a great deal of attention to the end user's experience. Development could speed up and head in directions which make CUPS easier to use than it is now. That would be an outcome which would be hard to complain about.

Comments (24 posted)

A Tokyo trip report

The free software community is truly global in scope - we are all over the world. A casual visitor might be forgiven for thinking otherwise, though: the people found on our mailing lists and in our code repositories are, to a great extent, based in Europe or North America. There is no shortage of talented developers elsewhere, but they are hard to see; they do not participate in our community at anywhere near the same level. We are clearly weaker as a result.

One attempt to improve this situation can be found in the Linux Foundation Japan Symposium, held a few times each year in Tokyo. This event was started by OSDL, and is being continued by the Linux Foundation. The idea is to bring a few community developers over for a couple of days and have them talk with Japanese developers about what the community is up to and how they can be a part of it. Your editor was lucky enough to be invited to the July meeting where, between encounters with sushi, sake, and Japanese beer, he was able to get some interesting work done.

First, though, was an encounter with the Yokohama Linux Users Group, which had invited your editor to come talk seeing as he was in the neighborhood anyway. YLUG meetings, as it turns out, look much like LUG meetings just about anywhere: a couple dozen or so technical guys show up to hear somebody talk about free software. The beer and dinner (and more beer) gathering afterward was special, though; if more user groups included that sort of event, attendance at meetings would doubtless go up.

The symposium itself began with presentations from your editor and Paul Menage, author of the process containers patch. One of the important features of this event is that it includes simultaneous translators; said translators were somewhat dismayed by your editor's habit of changing his talks (and slides) right up to the point where the laptop gets plugged in at the podium. Their presence is important, though: it allows attendees to follow the talks without having to struggle with a foreign language; they can also ask questions in Japanese and still have the presenters understand them.

As it happens, language issues, while not on the formal agenda, were a big issue at this event. It is easy fall into the trap of believing that anybody who is sufficiently well educated to be part of our development community will, naturally, have learned the English language along the way. The truth of the matter is that there are many languages one could invest time in learning, English is a hard language (especially for those whose native language is far removed from English), and that many people who might have studied English for years have never really had a chance to use it enough to become truly proficient. English really is an obstacle for many potential contributors to our community. It slows down many developers, makes others afraid to participate in public forums, and blocks some entirely.

One step which is being taken to improve this situation is the translation of a number of core kernel development documents into Japanese. The documents of interest are primarily process-oriented - those which tell prospective developers how the community works and how to get patches accepted. Translation of serious technical documentation would require quite a bit more work and would be hard to keep up to date, so that is less likely to happen. Japanese versions of the documentation seem unlikely to go into the kernel repository itself, so they will have to be hosted elsewhere; they should, in any case, provide a useful resource for Japanese developers hoping to begin with the kernel.

The translators got to work in the opposite direction for a while as Akinobu Mita discussed his work on the fault injection framework. At any event designed to increase community involvement it is important to highlight the efforts of local people who have been successful; Mita-san's work, which makes it possible to find problems in difficult-to-test error recovery paths, is an important contribution to the kernel development toolkit. He has, recently, been posting fixes to a long series of bugs found through the use of fault injection, making the kernel more stable for everybody.

The afternoon included a panel session which, among other things, covered the kernel development process. One of the key points in your editor's talk on that process is that code must be posted early; if a company insists that code pass through all of its internal quality assurance processes before being submitted, it is likely to post code which is in need of major changes. It turns out that this can be a problem with Japanese companies; one developer talked about "stone-headed managers" who are deathly afraid that somebody will post something which embarrasses or shames the company. Strange as it seems, the stone-headed manager problem is not confined to Japan; there is little to be done except to continue to try to educate those managers - or wait until they get promoted to a level where they are no longer a problem.

The second day consisted of smaller sessions where developers from Linux Foundation member companies could talk about their work and get questions answered. Fault injection was on the agenda again, as were various virtualization topics and the translation issue. Closing statements were made, and the event shut down until next time - scheduled for November.

The key to building a community and keeping it together is good communication. By bringing in community developers, the Japan Symposium certainly succeeds in raising the level of communication with the Japanese community. There is no better way to learn about how a community works than to talk with those who are in the middle of it. This series of events might just be part of why contributions from Japan appear to be on the rise. A less obvious but equally important point is this: communication goes both ways. Any speaker who attends this event can only go away smarter, having learned something about how the wider world sees free software. That, too, can only be a good thing.

Comments (31 posted)

IBM pledges patent peace for interoperability

IBM's recent patent pledge significantly lowers the bar for using their patents to implement software standards. Rather than specifying particular patents, IBM chose more than 150 different standards for interoperability, pledging not to assert any of their patents that are required to implement the standards. Along with the carrot of that pledge, there is also an implied stick for companies that might consider litigating over their own patents that are required to produce the standard.

Software patents are generally problematic, but those which encumber technology standards can be especially so. When companies come together to form standards bodies, they have often agreed that implementations of the standard would be able to license any patents required, under so-called reasonable and non-discriminatory (RAND) terms. "Reasonable" is in the eye of the beholder, of course, and RAND terms have been used to lock out smaller companies from implementing patented standards along the way. Free and open source implementations are usually locked out, because "reasonable" terms almost always include royalties. Thus, RAND terms are usually discriminatory against free software.

This has led some organizations, notably the World Wide Web Consortium (w3c), to move to an agreement that patents required to implement their standards be licensed on a royalty-free basis. This simplifies things, but requires some amount of bureaucracy as standards participants need to list relevant patents and create documents that state the nature of the royalty-free license.

IBM's move circumvents all of that, by pledging not to assert patent claims against any implementation of the listed standards. The pledge not only covers free implementations, but competitive, commercial, closed source versions as well. The patents themselves do not need to be researched or listed as the pledge covers any that IBM has. It should be noted that this only applies to implementing the standards listed; IBM is not giving carte blanche to use their patented technology.

The only caveat is that IBM will revoke the pledge for any implementor who asserts patent claims on a covered implementation - against IBM or any other party. For any of the standards listed, IBM is thus creating a "patent shield" for anyone who plays fairly, with the implication that unfair play - in the form of patent attacks - may be met with similar attacks from the rather extensive IBM patent portfolio.

Because it is a pledge - not a license or agreement - projects or organizations that want to be covered by it need do nothing. There is no paperwork to file or license text to comply with. They will need to refrain from engaging their patent lawyers to attack others implementing the standards; this should be a constraint that most free software projects can live with. It is rather refreshing to see a company make a pledge that could plausibly reduce the amount of billable lawyer time required by technology companies. Patent lawyers may not agree, of course.

The list of standards that are covered by the pledge is an impressive array of technologies, mostly web standards along with OASIS document format standards. The FAQ accompanying the pledge states that IBM will be evaluating additional standards for inclusion in the list. They clearly believe widely implemented standards are good for their customers:

There is clearly a public relations aspect to this pledge, but one gets the sense that IBM truly does want to simplify the software patent landscape. They have, perhaps, the largest patent portfolio in the world, but they can also see the mess that software patents, especially patent trolls, are causing. If other companies make similar pledges, definite progress will have been made, at least for interoperability. Since it appears that software patents will be with us for a long time to come, at least in the US, any step forward should be cause for at least a bit of celebration.

Comments (21 posted)

Page editor: Jonathan Corbet
Next page: Security>>