Leading items

Hackable devices: one step forward, one step back

LWN has (like many others) long argued that device manufacturers should leave their products open to modification. Beyond being a simple gesture of respect for customers, hackability increases the value of the device and opens the way to no end of creativity; owners of such a device will often take it in directions that the vendor never dreamed of. We have recently seen a couple of announcements in this area which demonstrate contrasting views on hackability.

On the down side, Sony recently announced a new set of PlayStation 3 systems, featuring more storage, a smaller box, and lower power consumption. This device also "features" the removal of the "install other OS" option. The "other OS" in question was invariably Linux. Users did not normally install Linux for its superior fragging experience; instead, Linux on the PS3 was most useful as an affordable way to gain access to - and hack with - the "Cell" processor architecture. Linux-running PS3 systems could be used to create low-end supercomputing systems and clusters or do any of a number of other interesting things. The locking-down of the newer PS3 models represents a real loss for the Linux community.

The reasoning for this change is said to be cost-cutting; Sony simply did not want to expend the resources to make the "install other OS" option work on the new system. A good chunk of that cost, it seems, is in the creation of a hypervisor under which secondary systems actually run; this hypervisor's reason for existence would appear to be to prevent other operating systems from making use of the 3D rendering engine. One would assume that the above-mentioned superior fragging experience offered by Linux (while legendary) would not be such a threat to Sony that it feels the need to wall off parts of its hardware, but that is evidently not the case. Evidently, the fear of high-performance nethack is enough to drive Linux off this platform entirely.

[PULL QUOTE: Evidently, the fear of high-performance nethack is enough to drive Linux off this platform entirely. END QUOTE] Sony can certainly build its hardware the way it wishes. But some of us might still wish that the company would look harder at where the raw materials for its products come from. Sony is, of course, a heavy user of embedded Linux; there is a whole range of Sony products with Linux inside. If you read books on a Sony reader, take pictures with a Sony camera, make movies with a Sony recorder, or watch movies on a Sony television, chances are that you're using Linux. Even the Sony WallStation Doorbell Adapter product uses Linux. It's interesting to wander through Sony's download page, where the company satisfies its GPL obligations, and see how many products are listed there.

Sony clearly is deriving great value from Linux. And that is great - that's what Linux is there for. And Sony is not absent from the contributor community; a quick look at kernel contributions since 2.6.26 shows 113 patches from Sony, putting the company just slightly ahead of LWN on the list. But surely Sony will find that Linux is a better platform for its products if it lets the development community play with those products. There are developers out there who (1) built the platform that Sony is using in its products, and (2) would love to help make those products run better. Frustrating those developers does not seem like a path toward long-term success with Linux.

The announcement of Nokia's N900 "mobile computer" shows a different approach. The N900 is a Maemo-based tablet, but, unlike its predecessors, it also functions as a telephone. It looks like a nice device, though, perhaps, a bit large for some pockets. Your editor is convinced that he must obtain one of these phones for review purposes; journalistic integrity demands it.

While the official propaganda attracted a fair amount of attention, many in the community were more struck by Quim Gil's posting on the subject. Cellular telephones are notoriously locked-down devices, but, it seems, the N900 will be different:

Nokia's path toward more open devices has been slow, but the company appears to really understand where its software comes from. Linux is not just a platform it can ship with its phones and avoid royalty charges; it's a living component which can be actively encouraged and helped to improve. If the N900 is successful, it will indeed encourage a new wave of developers who will help to make Linux better for all of us. And, in the process, they will make Maemo-based phones much better for Nokia.

What remains to be seen is how much of this openness remains when the N900 makes it to end users - especially those who buy their phones from their cellular carriers. Truly hackable devices may only be available to those who buy them through other channels, at full price. But the existence of that option is a major step in the right direction. Opening up the cellular carriers is a job for another year - and a lot more patience.

Here we have examples from two companies, both of which are known for making stylish, consumer-oriented devices. Both have chosen to base some of their products on Linux. One has moved in the direction of openness, providing full access to the device in the hope of energizing developers and taking market share from a dominant rival. The other has closed down a product, locking out interested developers, in the name of lowering prices. There is no doubt that the open approach is better for our community than the closed approach. Over the longer term, openness and support for the community really should prove to be better for business as well.

Comments (27 posted)

Fedora's trademark license agreement

While trademarks are often lumped together with copyrights and patents—under the poorly termed "intellectual property" umbrella—trademarks are quite different. One of those differences is that a trademark must be actively enforced, at least under US law, or the mark holder risks losing it. The Fedora community is currently discussing a license to allow community members to use the Fedora trademarks, while still protecting Red Hat's ability to defend the mark against those who would misuse it. But, requiring a signed license agreement in order for a community web site to use Fedora trademarks—on the site or in the domain name—seems heavy-handed to some.

Christoph Wickert brought up some concerns with the trademark license agreement (TLA) on the fedora-advisory-board mailing list. He was commenting on an earlier revision of the agreement, which has since been updated as a result of the conversation. One of the more controversial aspects of the agreement is that license termination requires that the domain registration be turned over to Red Hat:

The TLA allows either party to terminate the agreement "for any reason at any time upon thirty (30) days prior notice in writing to the other party" in section 3(a), or, in section 3(c), with no notice in the event of a legal claim against the site. Because of the domain transfer requirement, Wickert was concerned that it could lead to domain hijacking:

It should be noted that the TLA does not require that the contents of the website be handed over. Changes to the content may be required if the license is terminated in order to remove the trademarked items, but the contents would still be the property of the web site owner. Wickert's statement to that effect was simply a misunderstanding of the TLA.

Wickert also sees problems in the indemnification clause. By indemnifying Red Hat against various claims, without any kind of cap, he is worried that "a person could be bankrupt [for] the rest of his life even if he didn't damage Red Hat or Fedora in any way". In the end, he concludes that the TLA is not something he can recommend for others to sign, which is "a shame".

Fedora project leader Paul Frields responded at length to Wickert's concerns, noting:

Another concern was the specific requirements for how the trademarks needed to be used and identified on a site covered by the TLA. Richard Körber complained that those requirements were too restrictive, leaving his site at risk because of minor violations:

Körber concluded that the barrier was just too high: "Frankly, I would rather drop the domain or close down the entire site, before I would sign the TLA". Robert Scheck, who was asked to sign the original TLA back in March, agreed with Körber's conclusion. But, Luis Villa noted that, at some level, the existence of the agreement doesn't change anything:

There is a larger issue as well. Dimitris Glezos worries about the barrier created by requiring a signed agreement:

Glezos argues that any miscreants are not going to sign the agreement anyway, so requiring the TLA just makes it harder for those who want to help spread Fedora. Part of the problem is that the TLA is a legal document, so anyone considering signing it should either be very comfortable with what it means, or, as was suggested in the thread, consult a lawyer. That just creates an additional barrier as Wickert points out: "Is Red Hat really expecting their community members to pay for a lawyer if they want to contribute? That would be ridiculous."

Frields agrees: "If I thought that this process required people to go get attorneys I'd agree it's an utter failure." The underlying problem, though, is the need for active enforcement of trademarks. By licensing community members to use Fedora trademarks, Red Hat can still pursue other, unlicensed users—some of whom may be using those marks in a way that is detrimental to the project. Furthermore, engineers trying to solve legal problems may not be the best approach, Frields said:

As it turns out, those bug reports did reach someone who can help: Pamela Chestek, a trademark attorney who works for Red Hat. She had a lengthy response to the various questions and problems that had been raised in the thread. Chestek started by trying to allay fears that there was a Red Hat agenda behind the TLA:

In addition, she went point by point through the issues that had been raised. To start with, she explained the reasoning behind clause 3(a), which allowed Red Hat to terminate the license at will, noting that it allowed the Fedora community more flexibility should it decide to change the Fedora name at some point. But, she said, "Because this has been so controversial, though, we can forgo the flexibility and eliminate this basis for termination". The current version of the agreement now reflects that change.

While Chestek's explanation of the domain transfer requirement still may not sit well with some, it does at least explain why it exists:

On the indemnification clause, Chestek explained that it was there to ensure fairness for both sides. In any legal action that was brought against the site for content or behavior that had nothing to do with Red Hat, the site owner would be responsible, but "if the only reason you are in the lawsuit is because you are using the Fedora trademark, Red Hat has to pay the whole amount. That seems fair."

She also addressed the issue of minor problems with how the trademarks were used on the site noting that the wording requires a "material breach" of the agreement. Chestek pointed out that the trademark guidelines were included by reference in the agreement, "but it would take a flagrant disregard for the Guidelines before it would be considered a 'material' breach". Even if that were to happen, there is a cure provision that would give a site owner seven days to address a problem that Red Hat notified them about.

Overall, Chestek covered the main legal (as opposed to philosophical) issues that were brought up. She clearly listened to the suggestions and complaints, and made changes where she thought it appropriate. The interaction displayed is very different than the sometimes lofty—and unapproachable—position that lawyers tend to occupy. By engaging the community in its normal communication forums, Chestek is well on the way to heading off some serious unhappiness amongst some in the community.

There may still be those who disagree with the TLA, philosophically or because of the language it contains, but, at the very least, everyone should understand the reasoning behind it. Free software projects using trademarks is controversial; we have seen Mozilla also wrestle with the problem and are likely to see other projects do so in the future. It is in a project's best interest to ensure that something called Fedora (or Firefox) is, indeed, the "real McCoy" and not some malware-afflicted knock-off. How exactly that is done will likely evolve over time. Villa sees some hope in the distance:

Various projects have different ways of approaching the trademark issue. Mozilla has a trademark policy that does not require a signed agreement for using its trademarks on a web site, but does have a license [PDF] for using the trademarks in domain names. That license has much of the same content as the Fedora TLA, including transferring the domain if the license is terminated. Other projects, like Linux, have a different strategy: sublicensing the mark for use in other trademarks, but considering most other uses to be "fair use"—though still subject to proper trademark attribution.

Because trademarks have to be actively, and not selectively, enforced, there needs to be a clear delineation as to what is allowed, and what isn't. Whether it truly requires a signed license agreement is an open question, but clearly Red Hat lawyers think it is safer to do things that way. One alternative is for the mark holder to disallow any use by third parties—a much worse outcome.

While it may be distasteful to have to sign some kind of agreement, it may also be the only workable solution that will satisfy Red Hat, which, after all, does own the trademarks. It will be interesting to see how other projects—particularly those backed by a large company—handle the trademark issue down the road.

Comments (15 posted)

Toward a long-term SUSE-based distribution

A group of SUSE Linux users put plans in motion last week to create a free, community-managed server distribution that maintains compatibility with Novell's enterprise offerings, but guarantees the long-term-support not provided by openSUSE. The result, said organizers, would be similar to the relationship between CentOS and Red Hat Enterprise Linux (RHEL), and would ultimately be beneficial to Novell. There are numerous practical difficulties to be overcome in the creation of this distribution, though, and the form that this distribution might take is not yet clear.

The idea of a free SUSE-based Linux distribution suitable for server use has cropped up more than once in the past; what spurred action this time was the August 14th announcement that openSUSE was moving from a 24-month to an 18-month maintenance period. Boyd Lynn Gerber, a consultant who works with the SUSE Linux Enterprise Server (SLES) and Desktop (SLED) products and participates in the openSUSE project, voiced concern over the change, especially for small-to-medium sized businesses (SMBs) without the financial resources to purchase SLES and SLED support contracts (which start at $799 and $120 per year, respectively). For comparison, SLES and SLED receive general updates for five years, and security patches for seven.

Gerber argued that shortening the supported lifespan of openSUSE widened the gap in the product line between openSUSE and SLES/SLED, potentially making it hard for small businesses to smoothly transition into the enterprise line. He proposed starting a group to work on a distribution in between openSUSE and SLES/SLED — one that would be available without purchasing a support contract from Novell, but would offer a longer, multi-year lifespan with which businesses would be comfortable, in particular guaranteeing backports for critical patches and security fixes.

Multiple options

Gerber's initial plan suggested three possible courses of action: create a support structure to maintain openSUSE backports for a longer period of time (a.k.a. the "OpenSUSE LTS" option), create a new distribution built from the source code releases of SLES but with Novell's trademarks removed (the "OpenSLES" option), or create a new distribution using the latter model, but for SLED instead of SLES (the "OpenSLED" option). The subsequent discussion on the opensuse-project mailing list debated the merits of each alternative, but the level of response also led Gerber to start a separate mailing list on which to further pursue the idea.

The OpenSLED option was quickly dismissed, because the product would be too similar to openSUSE itself, and because SLED does not include any server-oriented packages, so it would do little to meet additional needs for SMBs. Between the OpenSUSE LTS and OpenSLES options, opinion on the new list was evenly split. The pros of OpenSUSE LTS include the relative legal simplicity — creating a derivative of openSUSE does not require permission or even cooperation from Novell — but the cons include significantly higher investment of volunteer time. openSUSE contains more packages than either SLES or SLED, so more patches and backports would be required to maintain it over time.

Furthermore, adding LTS to openSUSE would require creating a framework for triaging, testing, and approving updates and backports well after an openSUSE release's end-of-life, whereas mimicking SLES's lifespan for an OpenSLES distribution could rely on Novell's tested patches. The down side of running an OpenSLES distribution, according to list traffic, is the risk of alienating or angering Novell if the company perceives the effort as siphoning away SLES customers. Gerber and others countered that an OpenSLES would, in reality, attract more customers to SLES by providing a lower barrier to entry, particularly for SMBs.

Supporters of the OpenSLES option compare it to CentOS, which they describe as a popular choice among SMBs either with smaller budgets or merely testing the waters before signing up for enterprise support with RHEL. CentOS, the "Community ENTerprise Operating System" is volunteer-driven, and since 2003 has built its releases from Red Hat's publicly available RHEL source code packages, with Red Hat's trademarks and branding excised. RHEL, like SLES and SLED, has a seven-year support life cycle.

Progress

Thus far, said Gerber, Novell has given the idea a chilly public reception, although he claims that in private conversation members of Novell management have been more open and expressed the view that an OpenSLES could be a tool to gain more SLES customers. "We will need to show or demonstrate to Novell and their upper management that this a good thing to support", he said.

Gerber believes that the OpenSLES option is clearly better than the OpenSUSE LTS option, and has started planning, laying down the groundwork for a non-profit entity to oversee the project, creating initial project guidelines based on the examples provided by CentOS and other derivative distributions, and looking for legal representation to assist with licensing and trademark usage concerns. Just a handful of people participated in the discussion on opensuse-project, but a dozen or so have already joined the new mailing list, and Gerber said the discussion is ongoing in the #opensuse-server IRC channel on Freenode.

Novell did not respond to requests for comment about the project, although SLES manager Gerald Pfeifer did ask several questions about the proposal on the opensuse-project list, particularly about the suggestion that Novell was not properly serving the SMB market.

Although SUSE Linux does not have an ecosystem of derivative distributions like those surrounding Red Hat's products or Debian, there does not appear to be anything preventing such spin-offs from starting up. openSUSE has detailed trademark guidelines [PDF] explicitly covering redistribution and modification projects. SLES and SLED are not covered by that set of guidelines, but Novell has a trademark usage request system through which interested parties can ask for trademark usage approval on a case-by-case basis. As for the software itself, openSUSE is of course a fully open project, and Novell provides source code packages for SLES and SLED on its web site.

Clearly SUSE users and resellers are interested in the possibility of a free alternative to Novell's current enterprise offerings. There are no hard numbers to back up the position that CentOS has directly increased Red Hat's sales of RHEL, but the company certainly tolerates its existence, and CentOS as well several other highly-focused RHEL derivatives like Scientific Linux have continued to thrive. Proposals to build a long-term-support option for existing distributions are no guarantee of success; several efforts to add that support to Fedora have come and gone in recent years. If it is successful, creating an OpenSLES may be the first step not only towards filling the long-term-support gap, but to expanding the SUSE-based distribution family.

Comments (12 posted)

Good news / bad news

It has been a while since the last LWN update. So here are a couple of items of LWN metadata.

On the "good news" side, we've finally managed to implement an often-requested feature: per-article RSS feeds for readers who want to follow the comments on a specific article in their RSS reader. The feed URL appears in the metadata headers for each article and comment, so subscribing to an article-specific feed should be a matter of a simple mouse click for most readers.

Of course, the unread comments page remains the best way to follow conversations on LWN, in your editor's humble opinion.

The not-so-good news is this: while LWN has held up reasonably well through this whole "economic crisis" thing, the simple fact is that its effects are being felt here. Some subscribers are not renewing, and others are moving to lower subscription levels. Costs have also increased - for example, our credit card bank evidently was unhappy with the size of its government bailout, so it raised credit card processing rates considerably. We are told that health insurance will be increasing 20-30% in a few months. Needless to say, these things are putting a squeeze on the budget.

What it comes down to is that something will have to change for LWN to continue operating. We very much intend to continue, so we're considering all of the options available to us. Since we're evidently not seen as being too big to fail, those options are generally unpleasant; they include price increases and/or staff reductions. No decisions have been made, but, one way or another, LWN readers are likely to see some changes as we get this operation back onto an even keel.

Thanks, as always, for supporting LWN.

Comments (109 posted)