LWN.net Weekly Edition for October 18, 2012

Wikitravel and Wikimedia on a collision course

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 Attribution-ShareAlike (CC-BY-SA).

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 site's advertising 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 2011 proposal 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:

Nevertheless, IB proceeded with integration of the booking tool in early 2012.

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. The proposal 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 conspiracy.

The filing [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 IB from 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 road ahead.

Comments (7 posted)

Another approach to UEFI secure boot

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) recently announced 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 decide 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 actually does.

The "pre-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 UEFI secure 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 booting a live distribution, though, testing for user presence should not be that much of a burden.

Shim

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 authorized 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:

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 so.

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 wouldn't run 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 first boot.

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:

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:

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:

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 outcomes:

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 (22 posted)

A report from the first Korea Linux Forum

The Linux Foundation held its first ever Korea Linux Forum (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 significant and 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)