Building a service around crowd-sourced information is a difficult
undertaking — even top-tier projects like OpenStreetMap and
Wikipedia have had their share of troubles, particularly when it came
to steering the community of volunteer contributors. Now, the owner
of the once-dominant travel wiki Wikitravel is squaring off
against its former community members in an acrimonious dispute that
has already resulted in multiple lawsuits.
At the root of the case is the desire of some former Wikitravel
contributors to start a new
travel-oriented site and import the original site's data. Wikitravel
consists of user-contributed tourism and travel information for sites
around the globe; as with many crowd-sourced projects, the data is
licensed to permit re-use: Wikitravel uses Creative Commons
The site was founded in
2003, and was sold to its current owner Internet Brands (IB) in 2006.
IB owns a number of unrelated web properties, but it initially
pledged to the Wikitravel community that it would keep things as
it found them, and limit its revenue-seeking efforts to
"unobtrusive, targeted, well-identified ads." Like
Wikipedia, Wikitravel's content was divided into language-specific
subdomains, each run more-or-less independently by a local contributor
community. After the sale to IB, the German and Italian Wikitravel
communities promptly left and started the rival site Wikivoyage, but
other language communities stayed, including the largest, English.
Of course, the unobtrusive-advertising pledge was not a
legally-binding contract, and over the years the ads on Wikitravel
became more intrusive (including animated
Flash ads, which were frequently flagged by users as being against the
policy), which led to dissatisfaction among the remaining
editors. The community also complained that IB did not respond to bug
reports, and allowed the version of MediaWiki running the site to
languish several years without updates. But the final straw came in a
to integrate sponsored hotel-and-travel booking elements
directly into article pages.
Opinion might vary as to how
"intrusive" any given monkey-punching Flash ad is, but the booking tool
seemed to detract from the site's purpose as an unbiased information
source. Volunteer Peter Fitzgerald, like many others, voiced his
opposition, saying in the advertising policy discussion:
The more our site looks like a cynical tool for revenue, the less
people will be enthusiastic about volunteering their own time and
effort towards improving the site, and the less savvy readers will be
inclined to trust our information as impartial and sincere.
Nevertheless, IB proceeded with integration of the booking tool in
In April, Wikitravel volunteer editors decided
that they had had enough, and reached
out to Wikimedia (the organization behind Wikipedia and related
sites) with a proposal to start a new travel wiki, based on a merger
of content from Wikivoyage, Wikitravel, and a few smaller efforts.
became a formal "request for
comments" and was subsequently approved
by Wikimedia's board following a public vote.
IB, however, did not greet the proposal with similar enthusiasm. According to
Wikitravel contributor Jani Patokallio, IB responded
first by removing discussion of the migration from Wikitravel's talk pages,
blocking some participating users, sending threatening messages to others,
and removing the administrator privileges of several. On August 29, IB
stepped up its response significantly when
it filed a lawsuit against James Heilman and Ryan Holliday, two
volunteer Wikitravel contributors who participated in the Wikimedia
migration plan. The suit charges Heilman and Holliday with trademark
infringement, trade name infringement, unfair competition, and civil
[PDF] is eleven pages of lawyerly prose, but the gist of it is
the accusation that Heilman and Holliday offered a "competitive
website by trading on Internet Brands’ Wikitravel Trademark"
— which seems to mean that they used the name Wikitravel when
proposing and discussing the migration to MediaWiki. The suit also
repeatedly refers to the rival site as "Wiki Travel Guide," a name
that IB claims infringes on its trademark. Nevertheless, no actual site
has yet resulted from the migration proposal, and only on October 16
did the new project decide on a name — which will evidently remain
Wikivoyage. Patokallio examined
the suit in detail in another post, including the trademark infringement claims.
Claims and countersuits
Notably, the lawsuit does not take issue with the right of
the departing contributors (or anyone else) to take Wikitravel page
content and import it into a rival project, but it does suggest (in
claim 31) that the volunteers are misappropriating the
CC-BY-SA-licensed content by not properly attributing Wikitravel as
its source. This is still a problematic claim in light of the fact
that, when the suit was filed, the Wikimedia-run site did not yet
exist. But Creative Commons highlighted
the licensing dimension of the suit in a post on its blog, where it
observed that if the licensor of CC-BY-SA content (in this case, IB)
"wants to completely disassociate themselves from particular
reuses, they have the right to request that all attribution and
mention of them be removed, and those reusing the work must do so to
the extent practicable." Consequently, if IB so wished, it
could request that Wikitravel not be mentioned on the new site as the
source of the imported content.
Such an action would presumably stop the alleged trademark infringement at the new site, were it not that IB concurrently claims that the new site fails to properly credit Wikitravel as a source. To that, the EFF post also notes that even if
Wikitravel or another licensor feels that it is not receiving
proper attribution for a derived work, the license only requires the
creator of the derivative work to provide attribution in "a manner
'reasonable to the medium or means' used by the licensee, and for
credit to be provided in a 'reasonable manner.'" The Creative
Commons post does not go into detail, but the suggestion is that this
is simple to do — perhaps through the wiki engine's existing
revision tracking system at import-time.
Wikimedia took an even harsher view of the lawsuit against Heilman
and Holliday, calling
it a clear attempt to "intimidate other community volunteers
from exercising their rights to freely discuss the establishment of a
new community" that ultimately seeks to prevent Wikimedia from
starting a competing project. The IB filing does mention Wikimedia, though briefly,
alleging that it may add Wikimedia and other "co-conspirators" to the
list of defendants at a later time. Wikimedia then sued [PDF]
IB on September 5 seeking a declaratory judgment that IB has no right
to impede or disrupt the creation of a rival travel wiki.
Wikimedia's suit seeks to recover attorney's fees for the
defendants, but it primarily seeks relief by asking the court to keep
interfering either in the import of data from the Wikitravel site or
in communication between Wikitravel contributors — including
ex-contributors. Holliday has taken proactive measures, first seeking
to transfer the lawsuit from state to federal court, then seeking [PDF]
a dismissal of the case under anti-"Strategic Lawsuit Against Public
Participation" (SLAPP) legislation. A SLAPP suit is one in which the
plaintiff is primarily trying to censor or intimidate the defendant
(as opposed to one where it actually believes it will win at trial).
IB denied that assertion in an October
16 response [PDF], and argued that the case is
a legitimate dispute among business competitors. Holliday has until
October 22 to file a response to this latest response, and at present
the first court date is scheduled for November.
Where to now?
Reading through it, IB's suit does not seem to have much depth. It
repeatedly refers to the rival travel wiki site (and in particular to
the "confusingly similar" name of that site) in the present tense,
despite the fact that the site and its name did not exist when the
suit was filed, and it couches its allegations in business terms (such
as claiming the defendants are "profiting" from IB's trademark and
have subsequently been "unjustly enriched"), despite the projects' not-for-profit nature. The "civil conspiracy" charge is also puzzling, and appears to amount solely to the fact that the listed defendants discussed the project. But then again, one can
rarely predict where a lawsuit will head; IB is no stranger to
acrimonious litigation — it is currently embroiled in another
suit against former employees for writing a rival web discussion forum
package similar to IB's vBulletin product.
Alienating one's users and crowd-sourcing contributors is rarely a
wise move; actively suing them in addition probably guarantees that
Wikitravel (at least under IB's care) is doomed. But that alone does
not guarantee success for the new Wikivoyage project. Should the
lawsuit be dismissed or turn out in the new project's favor, the new
travel wiki project will still have a technical hurdle to overcome.
Although IB does not dispute the license under which Wikitravel's
content is published, the company has never provided database dumps or
other convenient ways to export the data in bulk. That leaves
page-scraping and other tedious procedures to extract the thousands of
pages and uploaded media, not to mention the extra challenge of
removing spam and vandalism (which have been on the rise since the
exodus of the main Wikitravel editor community).
A still bigger hurdle might be attracting the eyes of site visitors
— the web is littered with failed attempts to fork popular
properties, and even a powerful advocate like Wikimedia does not
guarantee success. For example, most of us have probably forgotten about
Amazon's "Amapedia" project, which attempted to build a crowd-sourced
product review wiki. Despite being directly integrated with the web's number
one retailer, it flopped.
No doubt Wikimedia is the largest player in
the open data and crowdsourced-material market, but that does not mean
all of its projects can automatically unseat pre-existing competitors;
consider the relative mind-share enjoyed by its ebook library
Wikisource compared to Project Gutenberg. The vast majority of the
old Wikitravel editors seem to already be on board with the new
effort, which is vital — but it could still be a long, rocky
Comments (7 posted)
On October 26, Microsoft will release Windows 8. Normally, a release of
that kind would be largely uninteresting to Linux users, but Windows 8
branding brings with it
a hardware requirement that will definitely impact those wanting to use
Linux: UEFI secure boot. Distributions such as Fedora, SUSE, and Ubuntu
have been working on their plans for supporting secure boot for more than a
year now, so it may be something of a surprise that the Linux Foundation (LF)
its own entrant into the secure boot derby. But the LF "pre-bootloader" is
mostly meant as a stop-gap measure for those distributions that have yet to
on their secure boot strategy.
Secure boot is meant to protect operating systems from
pre-boot malware by cryptographically protecting the first step of the boot
process. Only binaries signed by keys stored in the UEFI firmware will be
allowed to run when secure boot is enabled—which must be the default
for certified hardware. On Windows and other systems, the first-stage
bootloader will check the signatures of the next steps, but that is not
strictly required. Since the keys stored in the firmware are under
the control of the hardware makers, it is likely that there will only be
keys from Microsoft and the manufacturer stored there. That leads to the
distasteful, but unavoidable, need to get bootloaders signed by Microsoft
in order to boot on secure-boot-enabled systems.
Much of the hue and cry surrounding secure boot has been about the need for
Microsoft-signed bootloaders, but there is little alternative. One could
imagine some kind of "Linux certificate authority" that could get its key
installed on systems, but that ship has sailed at this point—hardware
will be available soon with just the keys from Microsoft and the vendor.
Any solution for booting Linux on those systems requires a bootloader
signed by Microsoft or disabling secure boot altogether. The solutions
vary on exactly what that bootloader
The LF approach is the "smallest piece of code we could think
of" that would allow Linux to boot on Windows 8 systems, James
Bottomley, member of the LF Technical Advisory Board (TAB), said in email.
Bottomley did much of the work on what he calls the "pre-bootloader" that
will boot any Linux—signed or unsigned—using a "present user"
test. That test ensures that there is a user present at boot time. The
pre-bootloader is, of course, signed by Microsoft, but instead
of requiring a signature on the next stage of the boot process (typically a
full-blown bootloader like GRUB2), it will load and run any code if the
user at the keyboard allows it.
Beyond that, if the system is in "setup mode", the pre-bootloader will ask
the user if they want the signature of the second-stage bootloader
installed into the
database. That will allow unattended booting of the system in the future.
While it is mandatory under the certification requirements for hardware
vendors to provide a way to put systems
into setup mode (or to disable secure boot), the user interface to do so is
left unspecified. That
means there will be several—possibly many—different ways to put
systems into setup mode. In order to collect information about these
different mechanisms, the pre-bootloader will refer users to an LF web site
that will be gathering and disseminating instructions for putting systems
into setup mode.
The intent, Bottomley said, is "to ensure that smaller
distributions [have] a policy free option they could turn to as an interim
solution while they sorted our what their own security policy around
secure boot would be". The pre-bootloader binary, once signed by
Microsoft, will be available on the LF web site for anyone to use.
Distributions that don't want to have their own bootloader signed or,
indeed, participate in secure boot at all, will be able to use the
pre-bootloader for both
live distributions (on CD/DVD or USB devices) and for installations to the
hard disk. However, users will either need to get their systems into setup
mode and install the second-stage bootloader signature/hash—or be present
on every boot.
Requiring users to find and enable setup mode has a minor side benefit,
Bottomley said. The information on how to do that will be useful for
others, to either permanently disable secure boot or to install their own
keys (either in addition to the existing keys or supplanting them). For
live distribution, though, testing for user presence should not be that much of
There is an alternative to requiring systems to be put into
setup mode or for users to be at the keyboard when booting: a
pre-bootloader being used by (at least) Fedora and SUSE, called "shim".
Shim takes a different approach, but still allows distributions to set
their own policies. There are two main differences between it and the LF
pre-bootloader, though. Shim can contain an internal keyring for keys used
to sign the second-stage bootloader (or just the cryptographic hash(es) of
bootloaders), which will be checked in addition to the factory-installed
keys. In addition, in its present incarnation, shim will not provide a way
to circumvent signature/hash checking with a present user test. According
to shim developer Matthew Garrett, there is strong consideration of adding
that kind of test for removable media in support of live distributions and
installation media, though.
Even a shim that has an internal keyring can support booting binaries that
are signed by keys that don't appear on that keyring (and are not present
in the firmware). It does that by using an idea that SUSE came up with for
storing keys and hashes without requiring users to find and enable
setup mode: the "Machine Owner Key" (MOK). It turns out that the UEFI
specification provides some secure storage locations that can only be
accessed (and, importantly, changed) during the boot process. Shim uses
that storage as a place to put keys or hashes if the user directs it to,
which avoids requiring user presence on subsequent boots.
Both Fedora and SUSE will be releasing shim binaries that
contain their distribution keys on the internal keyring and are signed by
Microsoft. Because of the MOK storage idea, though, those binaries could be
used by other distributions. Even distributions that are not planning to
sign their second stage (and their kernel) could use one of the signed shims. A
recently added shim feature will add hashes (rather than just signatures)
to the MOK. So a distribution
that wants to minimize its dealings with secure boot can simply ship one of
those shims and instruct its users to store the second-stage hash in the MOK as
prompted by shim. Or those distributions can use the LF pre-bootloader.
Pre-bootloader vs. shim
That last part is a bit of a sticking point, at least for Garrett. Because
the pre-bootloader comes with an LF "stamp of approval", it may well be
seen as "the Linux solution" for secure boot. But Garrett believes that the
pre-bootloader isn't "terribly useful". All of the
functionality that it provides is also available in shim, he said, except
for the ability to "hit y and it'll run whatever you want".
Instead, shim users can just use the interface to add keys or hashes to the
MOK and boot unattended forevermore.
There are also some dangers in the LF approach, Garrett said. Because
non-technical users are easily fooled into clicking through security
warnings, the pre-bootloader could be used to attack Windows:
Users are trained to click through pretty much any security prompt that
they see, and if an attacker replaces a legitimate bootloader with one that
asks them to press "y" to make their computer work, they'll press "y". If
that bootloader then launches a trojaned Windows bootloader that launches a
trojaned Windows kernel, that's kind of a problem.
While trojaned Windows binaries aren't directly a problem for Linux, they
could be a problem for signed first-stage bootloaders. Secure boot has a
database of blacklisted keys and hashes that can be used to stop malware
from running on the system. If the LF pre-bootloader is used by some form
of malware, it could be blacklisted. That's also true of any shim
similarly used, but shim's present user "test" is a bit more complicated than
that of the pre-bootloader, so malware authors may be more inclined to
target the simpler test.
In any case, signed Linux first-stage bootloaders are clearly at some level
of risk of being blacklisted down the road. That risk is inherent in the
fact that the secure boot requirements are set by Microsoft to further its
own ends. One would guess it won't use its power over the contents of the
blacklist indiscriminately, but there is no technical obstacle to it doing
An alternative that the LF could have taken would be to create a shim with
an empty keyring and get that signed, shim developer
Peter Jones said in email. A shim built that way would only run code
signed by the keys in the firmware. Since a shim built that way wouldn't
have the key
or hash for
the second-stage bootloader available in the databases it consults, it
the second stage, but it would
prompt users to add that
key or hash to the MOK on first boot. That would allow smaller
distributions or those uninterested in signing their binaries to use
shim—and avoid the present user test (or setup mode) except for the
Garrett in particular seems irritated by the LF approach. Because of the
uncertainty on how to get systems into setup mode, he believes the
pre-bootloader risks making Linux a second-class citizen. In the comment linked above, he warned:
Linux becomes the OS that can't reboot itself. It's the OS that pops up an
ugly text entry box every time you turn your computer on. It's the OS that
asks you if you're sure you want to run potentially insecure code. 10
years of progress in making Linux accessible to users, gone.
Furthermore, he is unhappy that the LF went its own way, rather than
working with Fedora and SUSE on shim. In another comment, Garrett is
not particularly pleased with the decision to build a separate
pre-bootloader after the TAB had been urged to work together on shim:
We encouraged them to, but they felt that it was too complicated and
violated their understanding of the trust model. I obviously disagree, and
I'm obviously not impressed by the Linux Foundation picking an approach
that's at odds with 100% of the member companies who've voiced opinions on
the topic, but the Technical Advisory Board is an autonomous group with no
community oversight so there's little opportunity to influence them.
That's not quite the way Bottomley sees things, however. The LF and TAB
were "exclusively concentrating on
tools that keep linux booting and installing", with an emphasis on
the simplest solution. As he noted, "Shim was originally designed as a solution to take advantage of secure
boot and enforce a security policy rather than one that simply permits
any linux distribution to boot". As a neutral party, at least with
respect to distributions, the LF did not want to take sides on what kinds
of secure boot policies distributions should choose:
Originally we weren't sure that the distributions would be ready (or at
least that the non-major distributions would be ready) for secure boot.
Later there were disagreements between distributions over what security
policies should be enforced.
It may well turn out that the LF pre-bootloader is simply a temporary
measure and that shim can handle all of the different use cases—the
LF code uses some parts of shim, after all. Or
perhaps the simplicity of the pre-bootloader code will be attractive to
some distributions. The pre-bootloader requirement to get the system into
setup mode might be attractive to some users or distributions that want to
ensure their keys are the only ones present in the system, for example. Bottomley and the LF would be fine with any of the possible
The only LF concern is that as an organisation enabling the Linux
ecosystem, we don't want to be seen as mandating policy for taking
advantage of secure boot. If all distributions decide to adopt shim +
MOK, we'd be completely happy, but if some decide not to, that's fine
with us too.
Booting Linux on new x86 hardware is clearly going to be a bit more
difficult than it has been in the past. Due to a lot of hard work from
various folks, though, it will be a lot easier than it could have been.
In the end, there is room for both solutions, though there is merit to Garrett's
concern that the LF solution will be taken as "the Linux solution" for
secure boot. At last report, Ubuntu planned to use its own
first-stage bootloader, and other options may arise, so the "one true Linux
secure boot solution" may never really exist.
Comments (21 posted)
The Linux Foundation held its first ever Korea
(KLF) in Seoul, South Korea, in mid-October. The stated
goal was "to foster a stronger relationship between South Korea and
the global Linux development community
." In truth, South Korea is
already a strong presence in this community; arguably KLF was more of a
recognition and celebration of that relationship. In any case, one
conclusion was clear: there is a lot going on in this part of the world.
Some years ago, the Open Source Development Laboratories recognized that
Japanese companies were increasingly making use of Linux but were not
always participating in the development community. To help close the loop,
OSDL began a series of events where Japanese developers could hear from —
and talk with — developers from the wider community; that practice
continued into the Linux Foundation era. Your editor was lucky
enough to be able to attend a number of these events, starting in 2007. These conferences cannot
claim all of the credit for the marked increase in contributions from Japan
over the last several years, but it seems clear that they helped. The
Japanese Linux Symposium has since transformed into LinuxCon Japan, a
proper development conference in its own right.
KLF is clearly meant to follow the same pattern, but there is a big
difference this time around: community participation from Korea is already
increasing in a big way. For example, Samsung first appeared in the list
of top kernel contributors in the 2.6.35
development cycle over two years ago; it has held its place on that list
ever since. Contributions from Korean developers are clearly not in short
supply. That made the job of the KLF speakers easy; rather than
encouraging Korean developers to participate more, they were able to offer
their thanks and talk more about how to get things done in the community.
The first talk (after the inevitable cheerleading session by Linux
Foundation head Jim Zemlin) was by Samsung vice president Wonjoo Park; his
goal was to make it clear that Linux is an important resource for Samsung,
the "host sponsor" for the event as a whole. Software, he said,
is the means for product differentiation in today's market; it is the most
important part of any product and drives the business as a whole. Samsung,
it seems, is a software company.
The company got its start with Linux in 2003, using a distribution from
MontaVista. Use of Linux expanded over the years: appliances in 2005,
televisions in 2006, and so on. Samsung's first Linux smartphone came out
in 2004; it featured a voice-activated phone book. In 2007 Samsung joined
LiMo; the first LiMo-based phone came out in 2009. In 2012, products
all across the Samsung line, from phones and tablets to home theater
systems, cameras and printers, are all based on Linux.
Now, of course, much of the company's efforts are going into furthering the
Tizen distribution. He mentioned the recently-posted F2FS filesystem: Samsung could have held onto
that code and kept F2FS proprietary, he said, but that would have deterred
innovation; sharing it, instead, allows the company to accept changes from
others. Samsung has also put together an extensive license compliance
process after a "rough start" that forced the company to apologize to the
community. One of the results is opensource.samsung.com, one-stop
shopping for the source code for Samsung's products.
In summary, he said, Linux has become a "core competitive competence" for
Samsung; the company would not be able to do what it does without it.
Korean rockstar hacker Tejun Heo gave a well-received keynote presentation
on what it is like to be a community developer. It is hard, he said, but
then, working in Korean companies, where the expectations are high, is hard
in general. Developers
who can succeed in the corporate setting can make it in the community as
well. Developing in the community has a lot of rewards, including the fact
that credit for the work stays with the developer rather than accruing to
the sponsoring company. It is a challenging path, but full of benefits.
KLF was, like the early Japan events, oriented toward information delivery
rather than the sort of critical discussion of ongoing work that one finds
at a serious development conference. That does not mean that there was no
development work on display, though. Arguably the most interesting talk
was Kisoo Yu's discussion of the big.LITTLE switcher (originally written by Nicolas Pitre). Big.LITTLE is an ARM-based system-on-chip
architecture that combines a number of slow, power-efficient processors
with fast, power-hungry processors on the same chip. In this particular
case, Kisoo discussed an upcoming Samsung Exynos processor combining four
Cortex A7 processors with four Cortex A15's — yes, an eight-core SoC.
Big.LITTLE poses a number of interesting challenges for the kernel: how
does one schedule tasks across the system to optimize both throughput and
power consumption? Kisoo described two approaches, the first of which
involves running Linux under a simple hypervisor that transparently
switches the hardware from slow mode (running on all four A7's) to fast
mode (all four A15's) without the kernel's participation or awareness. The
alternative approach has the kernel itself explicitly managing the SoC as a
four-processor system, switching each one independently between the fast
and slow cores as if it were simply adjusting the CPU's clock frequency.
Either way, a number of heuristics have been developed to
try to determine the best time to make the switch from one to the other.
This SoC offers an interesting hardware feature that can quickly transfer
interesting L2 cache entries from one core to another to speed the
switching process, which can be done in 30µs or so.
Perhaps the most interesting takeaway from the talk is that we still don't
really have a good idea for how to manage these systems. This SoC is a
true eight-core processor; it would seem that an optimal approach would
manage it as such rather than as a four-core system with a big "turbo"
button. The fact that we are, thus far, unable to do so is not an
indictment of the developers working on the task in any way; it is clearly
a hard problem without much in the way of useful solutions in the
literature. As is the case with many other hard operating system problems,
the work being done now will get us closer to an understanding of the
issues and the eventual development of better solutions.
One thing that became clear at the inaugural KLF is that Korea is
increasingly supplying a lot of sharp minds ready to work on problems like
this, and that this trend looks set to continue indefinitely. Energy
abounds, as does, seemingly, a good sense of fun. Your editor
would like to thank our hosts in Korea for hosting an engaging event,
treating us so well, and even for inflicting "Gangnam style" K-pop music on
us at the conference dinner. And, of course, thanks are due to the Linux
Foundation for supporting your editor's travel to the event.
Comments (4 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Do Not Track Does Not Conquer; New vulnerabilities in cxf, firefox, java, phpmyadmin, ...
- Kernel: 3.7 Merge window summary; EPOLL_CTL_DISABLE; Software interrupts and realtime.
- Distributions: Whonix for anonymity; NetBSD, OpenELEC, ...
- Development: Accessibility on the desktop; Plasma Active; gnutls; Wayland; ...
- Announcements: FSF campaigns, open source software in Portugal, ...