Distributions

Chromium API keys on Debian

Just over a year ago, Google started requiring an API key to enable certain features in the Chromium browser. For developers, it is presumably a minor nuisance to acquire the key before building the browser—or to simply ignore the features enabled by the key. For Linux distributions, though, a key is pretty much required. But, as Ignacio Areta pointed out on the debian-legal mailing list, the Terms of Service that go along with API keys may not be compatible with free software and with the Debian Free Software Guidelines (DFSG) in particular.

Areta noted that several different distributions he looked at (openSUSE, Arch Linux, and Debian) had their own API key, each with a warning that the key was only for use by the distribution itself. Those wanting to build or distribute their own Chromium using the source provided by the distribution are expected to get their own key. That seems to run counter to the normal expectations for free software.

Beyond that, the Terms of Service (ToS) for using the Google APIs has language that worried Areta. He was not alone as Ben Finney noted specific sections of the DFSG that seem to be violated by the sections of the ToS quoted by Areta. In particular, the ToS sublicensing language may run afoul of section 8 of the DFSG, while the "no reverse engineering" language may violate section 6, Finney said.

The key in question allows access to nine separate Google services including Spelling, Suggest, Translate, Geolocation, Safe Browsing, and so on. While some of those features could be considered optional, losing them would certainly degrade users' experience compared to Chrome browser users—or even Firefox users—in many cases. It's a little strange to see a feature added that requires a magic key in order to use it, but the restrictions on what can be done with the APIs and keys makes it all the more worrisome.

Paul Wise noted that the key strings themselves (which are stored in a Debian makefile) are probably not copyrightable, which means their license may be irrelevant from a copyright standpoint. But he also pointed out the real danger: Google could turn off access to its APIs for that key at any time. Someone using the Debian Chromium source (and key) in a way that violates the ToS might be enough to provoke the search giant into just that kind of response. That would, of course, damage all Debian Chromium users, not just the "guilty" party.

In a followup message, Areta pointed out another troubling clause in the ToS: "You will require your end users to comply with any applicable law and these terms." That seems to indicate that Debian would, somehow, need to require its users to agree to Google's ToS—yet another incompatibility with the expectations for a free software distribution. He also wondered whether other companies might start requiring keys to access their services. "That would be bad", Wise commented.

While Google clearly has the right to limit access to its APIs in any way it chooses, integrating features that depend on them into free software muddies the water considerably. No firm conclusion was reached about what to do in the debian-legal thread, but it's probably not the last we've heard on the issue. One might want to simply write off the API ToS as legalese that is unlikely to be invoked (at least against a distribution's key), but there is a risk in doing so. Some distributions might well write it off, but Debian has a reputation as a stickler on legal issues.

One could imagine that distributions could leave getting the API key up to the user, perhaps even providing an automated way to do so at package installation time. But that leaves a great deal to be desired as well. For one thing, it would allow individual users to be more easily tracked across the APIs—though signing into Google as Chromium suggests to users already makes that fairly easy. That has privacy implications, of course.

There is a balance to be struck here. Toning down the API ToS might be one way forward, as would turning off the Chromium features enabled by the APIs—or dropping Chromium entirely. Perhaps the most likely outcome, at least in the short term, is for distributions to continue on their existing course. Until and unless Google actually starts revoking API access, that seems fairly harmless. The scramble for a solution may only come later—or never. Only time will tell.

Comments (6 posted)

Distribution quotes of the week

— Tim Serong

— Jos Poortvliet

Comments (none posted)

Debian 7.2 released

The Debian Project has released the second update, Debian 7.2 "Wheezy", to the current stable version. As usual the update adds corrections to security problems and other serious issues.

Full Story (comments: none)

Announcing Fedora 19 ARM remix for Allwinner SOCs release 3

Hans de Goede has announced the third release of his Fedora 19 ARM remix for Allwinner A10, A10s, A13 and A20 based devices. The release is based on the official Fedora 19 for ARM release with u-boot and kernel(s) from the linux-sunxi project.

Full Story (comments: none)

openSUSE 13.1 RC 1 Available

The first release candidate for openSUSE 13.1 is available for testing. "As you might remember, we called for additional testing of btrfs specifically. It won’t be the default in this release but the next generation filesystem has been making steady progress and in the last month, over 25 bugs have been found and fixed. There is still more work to be done, but btrfs should be a safe choice for openSUSE 13.1 users and a good candidate for default filesystem for the next release."

Comments (none posted)

Slackware 14.1 RC1

The October 14 entry in the Slackware current changelog announces the first release candidate for Slackware 14.1. "UEFI (with the exception of Secure Boot, which will have to wait until we have real hardware) should be fully implemented in the installer now, which will detect and warn about common problems, set up the EFI System Partition under /boot/efi, and install ELILO and a UEFI boot entry automatically. There's a new README_UEFI.TXT file with detailed instructions for installing 64-bit Slackware on UEFI."

Comments (none posted)

Whonix Anonymous Operating System Version 7 Released

Whonix has released version 7 of its anonymity, privacy and security focused operating system. "It's based on the Tor anonymity network, Debian GNU/Linux and the principle of security by isolation. DNS leaks are impossible, and not even malware with root privileges can find out the user's real IP."

Full Story (comments: 2)

Bits from the Release Team (Jessie freeze info)

The Debian release team has announced a freeze date of November 5, 2014 for the next stable version, Jessie. Click below for the current freeze policy, the results of a porter roll-call, proposed release goals, and more.

Full Story (comments: none)

Distribution newsletters

• Debian Project News (October 14)
• DistroWatch Weekly, Issue 529 (October 14)
• Ubuntu Weekly Newsletter, Issue 338 (October 13)

Comments (none posted)