LWN.net Weekly Edition for January 5, 2012

ownCloud moves ahead

There are lots of cloud services out there these days—many of them free in the "beer" sense—but privacy-sensitive and free-software-oriented users have long been looking for alternatives. One of the few "free as in freedom" choices is ownCloud, which is the brainchild of KDE developer Frank Karlitschek. The project has been making steady progress since last we looked in on it back in June 2010, releasing ownCloud 2 in October, while preparing for ownCloud 3 in January. In addition, Karlitschek and former SUSE/Novell executive Markus Rex have formed a venture-capital-backed ownCloud company to foster the project while providing support and services.

The idea behind ownCloud is pretty straightforward: provide a way for users to replace closed source cloud services like Dropbox (or Ubuntu One) for file backup and sharing, Google Calendar and Contacts, picture sharing services like Picasa or Flickr, and so on, as well as providing storage for other web applications via the remoteStorage protocol from the Unhosted project. All of that functionality would be free software and user-installable so that the provider lock-in problems (as well as privacy concerns about what service providers do with the data they collect) can be avoided. Add in access from a variety of different kinds of devices (desktops, laptops, tablets, cell phones, ...) and it makes for a sweeping vision. There are many parts of that vision that still need to be filled out, but much progress has been made in ownCloud 2, with more to come in version 3.

ownCloud 2

For version 2, there are four different "applications" that come in the ownCloud web interface: Files, Music, Contacts, and Calendar. Files can be uploaded to the server from the browser, shared with other users of the ownCloud instance, or published for anyone to access via a URL. In addition, using the WebDAV protocol and the user-space davfs2 filesystem allows one to mount the ownCloud files directory locally, which allows local applications (and file managers) to access the files directly.

The Music application allows playing music files within the web application or, using the Ampache server, to stream the music to desktop players. Calendar and Contacts provide the basics of managing that kind of data in the web application, while also providing access to that data for other applications via CalDAV and CardDAV.

The server side installation of ownCloud 2 is fairly simple for anyone with root access to a Linux server. It is mostly a matter of getting the pre-requisites installed, which includes PHP, a database (MySQL, PostgreSQL, and SQLite are supported), and the appropriate PHP "connector" for the database choice. After a bit of Apache configuration, you point your browser at the site, which lands you on the installation wizard; after answering a few questions, ownCloud is up and running. WebDAV installation on the client side is also fairly straightforward (or was for Fedora 16 at least). That said, neither task is so easy that non-technical folks can be expected to handle it.

Overall, ownCloud 2 seems to work reasonably well. There are glitches and some oddities in the interface, at least in the released version. There are two other versions of the code available, including a Git repository for the latest development version. Neither of those options worked for me when I tried them in late December, but those problems are presumably solvable. The key functionality, sharing data between disparate devices, works well enough that I will be spending the time to get newer versions running in the near future—or wait for ownCloud 3, which is due at the end of January.

ownCloud 3

One of the areas lacking in ownCloud is data encryption. Connections are made to the server via HTTPS, so the network communication is encrypted, but files are stored in plaintext on the server. Encryption is listed as one of the features for version 3, but details are a little hard to come by. For users that set up their own server, encrypting and decrypting the data on the server side may be sufficient (depending on the key management) to protect against a system compromise that gives access to the stored data. That seems to be the feature planned for ownCloud 3.

But, for users that are storing their data on someone else's server (e.g. a friend or service provider), client-side encryption will be needed. That seems like a harder nut to crack because it requires code on each and every client. Without that, though, there can never be any real assurance that the data is not accessible to whoever provides the service—and possibly to attackers that compromise the server.

There are some other features listed for ownCloud 3, including a photo sharing application and a better interface for the calendar application with support for recurring events. There is also a mention of allowing external applications to integrate into the ownCloud web interface so that things like the Roundcube mail application could be added to ownCloud installations.

One area that the project could do better with is documentation. Information about ownCloud, its development, bug tracking, and so on are scattered across a number of different sites including Gitorius, Shapado, the mailing list, the ownCloud web site, and so on. It makes it a bit difficult for new users to track down the information they need—some sort of consolidation or master index would likely go a long way toward fixing that problem. The project does make it pretty easy to get a feel for what can be done with ownCloud on its live demo page.

ownCloud.com

It's also a bit hard to tell what, exactly, the plans are for the ownCloud company. It appears to have a commitment to open source and is being led by two longtime open source community members, so there is good reason to believe that the project will continue—and prosper—with some corporate backing. From the information on its web site, part of what the company is selling is the open-source nature of ownCloud, and its lack of vendor lock-in. All of that bodes well.

There are certainly some areas that need work in ownCloud, particularly in the ease of installation and configuration areas. One would guess that ownCloud.com will be putting a fair amount of effort into that, but it's not alone. The openSUSE project has also been working on ownCloud integration. From the looks of the ownCloud mailing list, there is an active community springing up around the project.

Hosting ownCloud instances for those who don't want the hassle might make a reasonable business opportunity for ownCloud.com and others. A reasonably priced per-Gigabyte subscription service could be attractive for privacy conscious users if the encryption issues can be resolved. Whether there are enough of those users to truly support that particular business model remains to be seen.

The ownCloud project shows a lot of promise. It is certainly usable today and will only get better in the near (and hopefully, long) term. It may only be interesting to a subset of internet users, since many are willing to trade their privacy and security for "free" services, but for the other folks, it will be real boon. Companies may also find that hosting their own instances of ownCloud (possibly with a support contract from ownCloud.com or someone else) makes a lot more sense than relying on Dropbox, Facebook, or even Ubuntu One. In any case, ownCloud seems to have a bright future and is well worth checking out.

Comments (8 posted)

Google's disappearing Android GPL compliance opportunity

All versions of the GNU General Public License require that anybody shipping GPL-licensed software in binary form make the associated source code available, either as an accompaniment to the binary distribution or, failing that, to anybody who asks for it later. Getting companies to actually comply with the GPL's requirements has always been a challenge, especially in the embedded systems world. The recent proliferation of Android-based devices has brought with it a whole new set of GPL compliance failures. Android is an interesting case, though, in that there is one company - Google - that is well positioned to require better behavior from those who ship Android.

Recently, Matthew Garrett, who has long tracked GPL compliance (or the lack thereof) in the Android world, has taken Google to task for failing to require better GPL behavior from Android distributors. His article (along with the followup on why GPL violations can make economic sense) is well worth reading in its entirety. In short, Matthew says that Google could force GPL compliance among Android distributors by either suing them or by requiring GPL compliance as a condition for use of the Android trademark (and, presumably, Google's proprietary Android applications). But, Matthew says, "Google makes money off other people's violation of the GPL", so it does nothing.

There is probably some truth to this argument. GPL compliance is not hard, but it is not free; skipping it makes Android-based devices a little cheaper to make and, thus, more competitive in the market. But there is almost certainly more to it than that - a fact that does not make this behavior any wiser in the long run.

One could start with the understanding that Google, and the Android part of Google in particular, suffers from a fairly strong case of GPL aversion. Considerable effort went into the creation of an almost GPL-free Android system; this included creating a new C library and a new Java virtual machine. Basing the whole thing on a GPL-licensed kernel may have been a necessary evil from the Android group's point of view, but accepting that evil does not require taking on an enthusiasm for enforcing the GPL's requirements.

Add to that the fact that the patent wars have put Android vendors into an unpleasant and uncertain legal situation. It seems clear that any commercial success in the mobile world is going to end up with patent leeches hanging all over it, but that doesn't change the fact that there is an especially visible legal cloud over Android at the moment. Adding GPL compliance problems to those already faced by Android vendors, especially if those problems come in the form of a copyright infringement lawsuit, could well be the straw that breaks the camel's back and causes those vendors to look more favorably on other systems. Anybody within Google who is considering a stronger stance on GPL compliance must certainly have that concern at the front of their mind.

Then, there is the little issue that few people want to talk about: what about those binary-only kernel modules? Google would not be able to take a position on GPL compliance in Android distributions without taking a position on binary-only modules. If use of the Android trademark is conditioned on GPL compliance, somebody will have to decide if distributions with proprietary modules (most of them, unfortunately) are compliant. A "no" answer would strip large numbers of devices of their trademark usage rights, while a "yes" answer would be a public statement that binary-only modules are OK. Given how few companies are willing to take a stand on this issue, it is unsurprising that Google does not want to find itself in that position.

Finally, it is worth observing that, for whatever reasons, companies almost never engage in GPL-enforcement actions despite owning the copyrights on large amounts of code. Almost all of the successful enforcement out there has been done by (or at least in the name of) individuals. The few exceptions, such as when IBM asserted GPL-infringement against SCO, show how serious the situation has to be before a corporation is willing to make such a move. So it could be said that Google is just behaving like all of its peers in this regard.

Having just made all of these excuses for Google's lack of action in this area, your editor would like to make one thing clear: a failure to insist on better GPL behavior may be entirely understandable, but, in the long (or not so long) run this approach is unwise and may prove dangerous for the Android market. If Google does not get Android vendors to clean up their act, others will lose their patience and do it for them. Indeed, as made clear by Harald Welte with regard to HTC's policy of delaying source releases, patience is already pretty well exhausted:

There are developers in our community who are prone to a certain amount of empty noise and bluster, but Harald is not one of them; this kind of threat, coming from him, is 100% credible.

One could say that this still works in Google's favor: individuals can force Android vendors to improve their behavior without associating Google's name with their actions. But if Google is worried about legal uncertainty surrounding use of Android, it must certainly worry about actions brought by individuals that are completely out of its control. That is especially true given that some individuals have been making ominous noises about GPL termination conditions and what might be required to regain GPL distribution rights after a violation. By looking the other way when Android vendors fail to live up to the GPL, Google may be helping those vendors set themselves up for attack by people or groups whose primary concern is not availability of the source code. Some of those people may be after serious financial gain or an opportunity to make the use of GPL-licensed code look like an inherently dangerous and risky thing.

If nothing else, contempt for the GPL will breed more of the same; as Matthew said, "In the absence of enforcement, GPL compliance only works if it's the norm". By ignoring its partners' GPL violations, Google is, at best, undermining that norm; at worst, it could be setting up Android (and possibly Linux) for a serious fall. Google still has the power to drive considerable improvements in this area if it takes the initiative now. Continued inaction, though, risks letting that initiative, and that power, slip away as others do the job that Google is unwilling to do. That does not seem like an outcome that would make anybody happy.

Comments (24 posted)

Linux at the end of the world (our 2012 predictions)

Welcome to 2012. This is the first LWN Weekly Edition of the year, and that can only mean one thing: it is time for your editor to go out on a limb and make a number of predictions for the coming year that, by the end of the year, will look thoroughly clueless and misguided. Even your editor can foresee, though, that it is going to be an interesting and highly political year.

On the political front, it is a fairly safe bet that the mobile patent wars will get worse. The participants in this battle appear to be tooling up for an extensive and protracted fight, and there seems to be a steady supply of new companies (British Telecom, for example) piling on in the hope of gaining a piece of the pie for themselves. Things may reach a point where it becomes impossible to market handsets or tablets in some parts of the world. One could hope that a paralyzed mobile market would suggest to lawmakers that the patent system is broken, and that those lawmakers would respond by reforming said system. Alas, a more likely outcome (though not in 2012) is the formation of a patent pool under strong "encouragement" by governments that ends the fights and establishes the positions of a small number of large players at the expense of new entrants. How free software will fare in such a world is far from clear.

The fight for a free Internet will also continue in full force in 2012. Your editor predicts that the current round of net-censorship bills in the US ("SOPA" and its variants) will be defeated. But the forces behind such laws never quit and eventually something distasteful will likely make it through the legislative process.

Laws like SOPA and governmental attempts to control the net in general seem to be causing concern beyond the small group of people who habitually worry about such things. As people wake up to threats to their freedom, they will see that free software is on the front line in the fight against censorship and repression. Hopefully that will result in a better awareness of the value of freedom. But it carries a risk that free software could find itself associated with piracy, crackers, and criminals. We could have an interesting public relations problem to deal with.

On the distributions front, it seems evident that Red Hat will have another great year. Various articles on the net are suggesting that 2012 will be its first $1 billion year, and that the company is looking to hire 1,000 more people. Red Hat has been helped by the growth of Linux in general, by its dominant position in the market, and, arguably, by the difficulties experienced by distributions like CentOS. It has become reasonably clear that, if one really needs the committed support that comes with RHEL, one really needs to just pay for RHEL. That said, the RHEL-rebuild distributions will certainly not be going away in the coming year; neither will the other commercial distributors.

But we will see more focused competition between distributors, with more attention paid to the addition of unique features to differentiate their offerings. There was a long period where most Linux distributions were about the same; the biggest differences were to be found in areas like package management, and they were easy to adjust to. Now we see distributions like Ubuntu focusing on their own desktop experience. Oracle seems to be trying to differentiate with more current kernels and an early move to technologies like Btrfs. Projects like GNOME are increasingly showing a desire to become distributions in their own right. Android and WebOS show the extent to which an ostensibly "Linux" system can differ from its peers. In a sense, the long-feared fragmentation of the Linux system is happening. It is good in that we have a diverse set of projects exploring ways to make a better operating system. But that diversity also threatens to scatter our efforts to the point that nothing ever becomes truly good enough to find widespread success.

Along those lines, Linux Mint will have a reckoning with reality in 2012. This distribution has gained a lot of attention with its approach to desktop design. But it remains a minor distribution, and, at some point, it can only become clear that the resources to maintain multiple distributions (Linux Mint 12, Mint Debian, Mint 11 LXDE, etc.), the MATE GNOME2 fork and the "Cinnamon" GNOME 3 fork simply are not there. Users will also eventually begin to wonder about things like security updates. Your editor fully expects Linux Mint to be a strong and popular project at the end of the year, but it will need to focus its efforts somewhat.

On a related topic, the GNOME3 wars will be long forgotten by the end of the year. Users will have either made their peace with GNOME3 or they will have moved on to something else. The growing availability of GNOME Shell extensions should help considerably. The various attempts to fork the GNOME environment or maintain GNOME2 will mostly fade away.

The fight for the attention of mobile device manufacturers will, instead, continue through 2012. Android is well established, of course, and it is hard to see that situation changing much. But there should be room for another free platform. Quite a few projects - GNOME, KDE, Tizen, WebOS, Boot to Gecko, etc. - would be delighted to occupy that space and be shipped on real products. They cannot all succeed, though. It would be a shame if they were to all fail and leave that space to Windows (which will make a big push on Nokia's handsets) in 2012.

Speaking of Android, mainline kernels will be able to run Android's user space by the end of the year - more or less. That is not the same as saying that all of the Android kernel code will make it into the mainline; some of it may be replaced by code with equivalent functionality. But a lot of hardware vendors are increasingly concerned with Android kernels, not mainline kernels, so the interest in closing the gap between the two will only grow.

The gap between Apache OpenOffice and LibreOffice will also grow. Over the year it will become increasingly clear that LibreOffice has captured the initiative and the developer energy in this space. LibreOffice will continue to improve while Apache OpenOffice struggles with the replacement of GPL-licensed code, adapting to "the Apache Way," and trying to produce a release based on a year-old beta. There are some good people working on Apache OpenOffice, but they are swimming against the current.

The kernel's "ARM mess" will be a memory by the end of the year as the effort to consolidate code and clean up subarchitecture implementations continues. The ARM tree was a victim of its own success; vendors actually listened to the pleas to work upstream and contributed vast amounts of code. Now that the problem is being addressed, the "victim" part will go away, leaving only the success; ARM will take its place as one of the primary Linux architectures, even if it does not become the primary architecture in 2012.

The security mess will not go away, unfortunately. Our widespread code repositories and distribution sites present an attractive target to anybody wishing to compromise large numbers of machines. Targeted attacks against these sites can only increase, and some of them will be successful. Our community as a whole is going to have to learn to take security much more seriously. That is starting to happen in some projects, but not in others. With luck, we will not wake up one morning to learn that we have distributed trojaned code to vast numbers of users - but there is no guarantee that we will be so lucky.

On a happier note, a longstanding request from LWN users will be satisfied in 2012: the site will finally use the UTF-8 encoding and will not be limited to the Latin-1 character set. So, soon, it may be possible to find text like "أي شخص يعتقد التوقعات في هذا الموقع هو أحمق" or "ನಿಮ್ಮ ಸಂಪಾದಕ ಒಂದು ಕಾಗದದ ಚೀಲ ಹೊರಗೆ ದಾರಿಯಲ್ಲಿ ಪ್ರೋಗ್ರಾಂ ಸಾಧ್ಯವಾಗಲಿಲ್ಲ" or "明けましておめでとうご ざいます" embedded directly within an LWN article without the need for obnoxious HTML escapes. Your editor predicts that change will come sometime quite soon.

Finally, your editor predicts that the world will not end in 2012. The Mayans, he claims, were worse at this prediction game than he is - and those who would draw conclusions from the Mayan calendar are even worse yet. Despite all the coming challenges, the free software world will not end either; instead, we will finish the year with more strength and momentum than we had at the beginning. It will be great fun to watch.

Comments (91 posted)