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
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
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
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.
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
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
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.
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
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)
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
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:
So I hereby declare my patience has ended here. I am determined to
bring those outrageous delays to an end. This will be one of my new
year resolutions for 2012: Use whatever means possible to make HTC
understand that this is not how you can treat Free Software, the
community, its customers, the GPL and in the end, copyright itself.
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
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)
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
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
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
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
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
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)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: A hole in telnetd; New vulnerabilities in ffmpeg, ghostscript, kernel, mozilla products, ...
- Kernel: IOPS-based I/O scheduling; SG_IO privilege escalation; VFIO; The logger meets linux-kernel.
- Distributions: RHEL clones: a surfeit of riches; Linex, Cinnamon, ...
- Development: Kdenlive 0.8.2; Calypso, Hadoop, Jato, Scribus, ...
- Announcements: Mozilla Public License, Doctorow: The coming war on general-purpose computation, ...