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.
Evidently, the fear of high-performance nethack is enough to drive Linux
off this platform entirely.
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
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:
If freedom is your concern then you don't need to 'unlock' or
'jailbreak' Maemo 5. From installing an application to getting root
access, it's you who decide. We trust you, and at the end it's your
device. Nokia also trusts the open source community in general and
the Maemo community particularly helping in getting casual users
through the experience path. The N900 might just be a new and
successful entry point for a new wave of open source users and
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
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
Comments (27 posted)
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 license to use the Licensor's Trademarks will cease immediately upon
the termination or expiration of this Agreement. On termination or
expiration of the License, the Licensee agrees that the ownership of the
Domain Name(s) automatically transfers to Licensor and Licensee will take
all steps necessary, including working with domain name registrars and
registries as necessary, to ensure that the legal ownership and control of
the Domain Name(s) is expeditiously transferred to Licensor or a party of
its choosing. Licensee agrees to remove any Web Pages content immediately
if in Licensor's sole discretion such removal is warranted.
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:
So even if the licensee follows all the terms of the TLA and the logo
usage guidelines, Red Hat can terminate the agreement for (a) no reason
and (c) even without notice at any time. If they do, they automatically
become owner of the licensees domain. This is a legal way of hijacking
the domain with all it's contents, all it's reputation and all the work
that was put into it. This just isn't fair.
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".
project leader Paul Frields responded at
length to Wickert's concerns, noting:
But Red Hat isn't interested in using this section to unfairly deprive
community members of the ability to create community web sites. If
that was the case, there'd be no reason to create an agreement in the
first place. In fact, there'd have been no reason to update our
trademark guidelines at all to allow domain name use by the community!
The agreement gives Red Hat a way to be very liberal in permitting
community members to use the Fedora trademarks on personally owned
sites to help spread Fedora effectively worldwide.
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:
Now when I take the TLA literally, then Red Hat would be allowed to terminate
the TLA immediately if I just forgot the trademark symbol on a very single
"first instance" of "Fedora".
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:
In the meantime, it is silly to talk about shutting down your domain
or 'extinguishing community' because of this agreement. If you're
using the Fedora mark in a domain name, Red Hat/Fedora can already
take it from you via ICANN. They're virtually guaranteed to win that
case. If they want, they can almost certainly go far beyond that,
using the rest of trademark law to shut down your website, not just
take the domain. Bottom line: even if you never sign the agreement-
even if the agreement had never been written- you'd still be at their
mercy when using the mark. All that unpleasantness is still there.
There is a larger issue as well. Dimitris Glezos worries about the barrier created by requiring
a signed agreement:
Right now we're putting obstacles and red-tape to excited community
members. But these are the people who power our own community, these
are the people who represent Fedora in conferences, local
universities, at their jobs.
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
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:
But just as I wouldn't expect an
attorney to figure out how to debug kernel problems, I wouldn't expect
us on this list to be able to debug a legal agreement. However, we
definitely can *report* problems and help in the testing. Both
activities are important, just as they are in our project when we deal
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:
It's important for you to know that when
I do work on behalf of Fedora, my only responsibility is to do what's best
for Fedora. The agreement is intended to protect the collective interest of
the Fedora Project and community as a whole. You may not like how the
agreement affects you as an individual, and you may disagree that the
decisions accomplish the goal. But Red Hat has no hidden agenda and the
only consideration when making decisions is Fedora's best interest.
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
While Chestek's explanation of the domain transfer requirement still may
not sit well with some, it does at least explain why it exists:
It would be exceptionally damaging to the Fedora
Project if a domain name that was previously used for the betterment of the
project fell into the hands of wrongdoers and was used in a way harmful to
Fedora. It would even be damaging if people were used to visiting a
particular site for Fedora info but that site just wasn't there anymore,
because we would have lost touch with community members and they might
think less of Fedora because of it. It's just not in the best interest of
the Fedora Project to let that happen.
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:
Look, I'm not a big fan of this trademark agreement; I think it is
probably overkill and certainly reflects a centralized view of
trademark that is harmful to how we operate as a peer production
community. If I had my way Fedora (and Mozilla, etc., etc.) would
radically reinvent how they license their marks. But that is a subject
for another day, because it is complex and will require many months or
years of lawyering to get completely right, and that is even if other
lawyers agreed with me- which most don't!
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.
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
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)
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
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.
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
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
Comments (12 posted)
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
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)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: A trojan for Skype; New vulnerabilities in dnsmasq, kernel, mono, squirrelmail,...
- Kernel: O_*SYNC; The offline scheduler; Ext3 and RAID: silent data killers?.
- Distributions: Slackware 13.0: now officially 64-bit; new releases from Slackware, RHEL, Lubuntu, CRK; reviews of SAM and Ubuntu.
- Development: The OpenEnergyMonitor project, new versions of ALSA, MPD, RunPON, CUPS, Alt_Key, Audacity, QARecord, KDE, gEDA/gaf, M2Crypto, Gnucash, OO.o, pylib, pylint, GIT, vadm.
- Press: Fake Linus Torvalds contest, new judges for SCO case, Linux aims at $1B market, RECAP update, Iomega NAS review.
- Announcements: Maemo 5 freedom, Tucows on Canadian copyrights, Where 2.0 cfp, Mini-DebConf TW, openSUSE Conf keynotes, Red Hat/Fedora/JBoss Dev Conf.