There's been a lot of press—and hand-wringing—about Google's
decision to withhold the source code for the latest Android 3.0
release. There have been claims that Google is (or will be) violating
various licenses by doing so. While that claim is overblown, there
are still reasons to be unhappy about the choice being made here,
while recognizing that it is Google's choice to make.
Business Week broke the story that, unlike
previous releases, Android 3.0 ("Honeycomb")—targeted at tablet devices—would
not be released for several months, possibly not until the next version
("Ice Cream") is completed. The article quoted Andy Rubin,
Google's VP for engineering and head of the Android group, as saying that
Honeycomb may not be suitable for phones:
We didn't want to think
about what it would take for the same software to run on phones. It would
have required a lot of additional resources and extended our schedule
beyond what we thought was reasonable. So we took a shortcut.
The concern seems to be that vendors might take Honeycomb, put it on phones
(or other small-screen devices), and create "a really bad user
experience". There has certainly been a number of vendors who took
previous non-tablet-oriented releases and put them on tablets with varying
degrees of success. Google appears to be worried that the Android brand is
being tainted by low quality implementations. That may be true, but there
are other ways that problem could be prevented.
One obvious choice is the Android trademark, which Google could use to
require devices to meet some minimum standards. Google already exercises
some control via its Google-branded Android applications (like Market,
Maps, and Gmail) that have to be licensed from the company. In order to do
that, a device must fulfill the Android
Compatibility Definition. But plenty of low-end phone and tablet
makers were willing to forgo those applications, take the source code, and
run with it—sometimes with less-than-stellar results.
So, Google has found a different way to enforce its will on device makers
that do not directly license code from the company: stop providing the
source. Since one of the goals
of the project was to "keep the GPL
out of user space", that means that the Android user space is licensed
terms. But even if it were all covered by the GPL, Google, as the
copyright holder, would not
be obligated to release the code. Copyright holders are
not beholden to the license they provide to others for using their code.
As it is, most of the code is under the Apache Software License or similar
which means there is no requirement for anyone to provide source. The big
of course, is the Linux kernel, and one would expect that Google is
GPL-savvy enough to not withhold that code. For the kernel, though, the
interesting parts are not necessarily in Google's kernel tree, as it is the
device makers that add support and drivers for their platforms. As we've seen,
GPL compliance in
Android tablets is rather spotty, at best, so that's where any license
problems are likely to be found.
Part of the uproar about Google's decision is based on the somewhat faulty
belief that Android was ever a real open source project. There were high
hopes early on that it might become one, and, up until now, Google kept
throwing its code over the wall to—more or less—continue the
open source spirit of the project. But, unlike real open source projects,
there were only limited attempts to build a developer community around Android
itself, instead, for the most part, there were just the periodic code
drops. Much of the effort was aimed at cultivating application
developers, which has worked out quite well. It's hard to say for sure,
but one might guess that the openness of the Android code played a role in
how quickly the platform was embraced by application developers.
One could argue that Google needed to keep Android development in-house, so
that it could keep up with the incredibly fast-paced smartphone
market—and that may be true. One could certainly point to MeeGo as
a counterexample of sorts, and one that has yet to really produce any
tangible results in the form of products for sale. MeeGo clearly has a
development community slowly growing around it, even though it is dominated by
two (now one, really) companies. While MeeGo is much more
upstream-oriented than Android, its governance has been largely
top-down. So far, Google's model has been much more
successful, but MeeGo is really only a year old at this point.
Google has made a lot of noise about how "open" Android is, including
things like Rubin's famous tweet
in response to Steve Jobs: "The definition of open: 'mkdir android ;
cd android ; repo init -u
git://android.git.kernel.org/platform/manifest.git ; repo sync ;
make'" For Honeycomb, at least for the next few months, that will no
longer be true, which is enough to sour some folks on the Android platform
as a whole.
Google has evidently weighed the benefits that it gets from opening the
Android code—bug fixes, enhancements, good public relations—and
found that it was not enough to
overcome its concerns. It is unfortunate that we won't be able to see what the
CyanogenMod folks (and others in the "mod" community) might have done with
Honeycomb, at least for a while yet. There are likely some low-cost tablet
makers that could have
done interesting things with it as well. While Google claims to be
concerned about "user experience", it's pretty hard to read this move as
anything other than a tightening of control over the platform. Hopefully,
this is just a blip, and things will return to "normal" with "Ice Cream",
but the damage may have already been done by then.
Over the last few weeks, we have defended the behavior of several companies
(Red Hat and Google)
when they have been faced with accusations of license violations. In
all of these cases, though, one does not have to like what the company is
doing to recognize that it isn't a violation of any licenses. Once again,
we would much rather see Google keep the Android project open—or make
it even more open—but recognize that it is well within its rights not
to do so. With any luck, other open source projects will show the way such
that Google finds it in its interests to open up Android further. Time
will tell ...
Comments (24 posted)
The PostGIS geographic database
system is nearing its 2.0 release, a major update that adds several
significant new capabilities. PostGIS is an extension to the PostgreSQL
database manager that implements GIS-specific data types and
functions. Equally important, though, is the fact that a wide range of other open source geographic information system (GIS) projects can use PostGIS as a back-end data source, including GUI applications and servers. This 2.0 release is poised to be an important milestone not just for speed and stability reasons, but because it extends the database into three new areas: raster data, topology, and 3D.
PostGIS adds support for geometric primitives (points, lines, polygons,
as well as "collections" and other data structures of all three), plus
reading, transforming, and writing a vast array of standard geospatial data
formats. GIS applications often require special operators for calculating
distances and areas, unions, intersections, and other set functions, along
with specialized types of searches.
PostGIS implements this functionality by adhering to the Open Geospatial
Feature Access for SQL standard, although the project does not pay for
the compliance testing necessary to advertise itself as an official
implementation. PostGIS has been in active development since 2001, and
built up a notable library of supporting GIS applications, including GRASS GIS, gvSIG, and MapServer; there are even commercial connectors available to tie proprietary GIS products into PostGIS databases.
Still, in all this time, PostGIS has focused on what you might call traditional, vector-based, 2D geometry. One should not see this as a weakness; the majority of GIS applications are 2D and vector-based. Vector-based data encodes geographic features as shapes: points and polygons on a map projection, lines connecting features, and so on.
There is, however, a lot of data available as raster imagery, too
— aerial and satellite photographs, for example, which can be
geocoded so that they can be properly aligned and transformed to fit onto a
map. In recent years, the PostGIS community worked on raster support via
an add-on package originally named WKT Raster, which was later renamed PostGIS Raster.
With 2.0, its functionality will be fully integrated into the main application. Raster images are supported in special raster tables, which can be loaded from any format supported by the Geospatial Data Abstraction Library (GDAL), and exported to any GDAL-supported format. The list of supported formats is constantly growing, but at the moment the GDAL project lists more than 120.
Naturally, loading and exporting is not the real work of supporting
raster images in addition to vectors, so PostGIS 2.0 adds a slew of
functions for analyzing and operating on the data inside the pixels.
Rasters can be "extruded" into geometry (for example, turning regions of
one color in the raster image into a polygon), averaged, and otherwise
inspected. Rasters can be operated on with existing functions (such as calculating where they intersect with vector geometric shapes). It will also be possible to edit imported rasters in-place in the database, which opens the door to all sorts of transformations.
The third dimension
There is also no shortage of 3D data that could prove interesting to examine, if the data types to store it and the functions to transform it are available. PostGIS 2.0 adds extensive support for 3D, starting with two geometry types: polygonal surfaces and triangular irregular networks (TINs). Polygonal surfaces are just what you imagine them to be: three-dimensional surfaces defined by connected polygons. TINs define surfaces entirely with triangles, but the size of the triangles is flexible — somewhat like a multi-resolution mesh in a 3D modeling program. A TIN can use very few triangles to describe flatter areas of the map, and more to describe important features. In both cases, support for the new geometry consists not just of the basic data types, but the support operators to do recurring tasks like finding areas (and volumes) of regions in the new format.
In addition to the new geometry types, the existing spatial indices have been made 3D-aware, and a library of 3D-functions added. This will allow GIS users to calculate distances in three dimensions, find 3D intersections of lines and shapes, and return 3D bounding-boxes or calculate complex things like 3D shortest-paths.
The most straightforward application of 3D in GIS is to
model landscape features in three dimensions, but there are more. Many
other kinds of geo-coded data could be imported into a 3D PostGIS
database for modeling and analysis. Consider calculating line-of-sight
visibility between buildings, radio wave propagation, or flight vectors,
for example. All involve familiar GIS operations, in 3D, even though
they are not strictly "mapping"-related tasks.
How best to output 3D data is a question that remains largely the domain of the front-end application (more on that a bit later...), but PostGIS 2.0 is adding support for direct output of 3D data to the XML-based X3D format. X3D is defined by the Web3D Consortium, which is working hard to get the format accepted into HTML5. Whether or not HTML5 ever allows the inclusion of in-line X3D scenes within page content, however, the format is likely to get supported in
<canvas> elements or as embedded objects.
The last major extension of PostGIS functionality in the 2.0 release is support for topology. In GIS terms, topology is not a reference to topographical maps. Rather, it means supporting data types and functions that implement mathematical graphs. In other words, instead of points, lines, and polygons, topology uses nodes, edges, and faces — potentially even directed and/or weighted edges.
Transforming vector geometry into topology data makes what was a collection of shapes into a mathematical representation of the scene, including how nodes and regions are connected. The human eye can make those connections instantaneously, but the database requires explicit support for expressing them. Incorporating the topological version of a map layer in the database allows the application to perform path finding, routing, and flow analysis that cannot be done on raw geometry.
The canonical example of this distinction is the Königsberg bridge problem: a human mathematician (say, Euler, to pick one at random...) can look at a drawing of the city and its seven famous bridges and work out its graph as nodes and edges implicitly. A PostGIS application cannot do the same with just the shapes of the river and landmasses. The data must be converted first.
PostGIS 2.0 will be able to transform standard geometry into topological data, validate topology, and edit nodes and edges. Topology can also be converted to standard Geography Markup Language (GML) for output.
This step represents the beginning of topology support in PostGIS. The
future applications include network flow (such as traffic modeling), crisis
management for disaster planning (such as minimum spanning trees and shortest paths for logistics), auto-map-coloring, "covering" problems, and considerably more. Those of us not in the GIS field may tend to think of GIS work at the national-mapping scale, for instance, but consider how valuable topology support would make PostGIS for network flow analysis, or for routing utilities within a building.
Application support and additional enhancements
Features like topology and 3D are of limited value without support in the applications that use PostGIS. On that front, GRASS and gvSIG are the first to include topology, with others expected to follow. MapServer and QGIS, on the other hand, have raster layer support already. There may be more in the raster data support category that inherit their raster functionality from earlier support of the PostGIS Raster plug-in; the documentation is not always clear.
For 3D data, the only application that appears to be readying support at present is gvSIG, which is scheduled to include it in the next release. This will reportedly be 3D viewing support only. Several of the open source GIS blogs are excited about the possibilities of 3D, though, including its potential for integration with virtual reality or augmented reality. That seems to be a few steps away, however, as does the possibility of combining topology and 3D data.
The raster, 3D, and topology support slated for PostGIS 2.0 are not the database system's only new features. The blogs and mailing lists repeatedly mention the improvements to the TIGER geocoder, which imports data from the public domain map data gathered by the US Census Bureau, and broke when TIGER changed its format in 2010. There is also a new "reverse geocoder" function that takes a map point and returns nearby address data or street intersections, and a revamped GUI shape-file loader that for the first time can load several files at once. Finally, there are experimental builds for Windows for the very first time — in previous releases, Windows users had to compile PostGIS from scratch. The project has a complete list of new, enhanced, and deprecated functions in its online documentation.
There may still be more enhancements to come; PostGIS reportedly has not
yet declared its final feature freeze, and there are funded contractors
working on some important areas, 3D included. The final release is
officially expected in (northern hemisphere) "early spring," which of course is only a few days old at this point. In the meantime, the suitably daring can get test packages from the PostGIS site. With this many substantial new features, it may be worth taking an early look.
Comments (2 posted)
There are rumors
suggesting that the CentOS 5.6 release is imminent - though that is
something we have heard before
release will certainly be welcome to numerous CentOS users, but there can
be no doubt that its tardiness - and, in particular, the absence of
CentOS 5 security updates caused by its delay - has been a bit of a
wakeup call for those users. If this much-used distribution is to remain
viable into the future, some important changes will need to be made and
those who depend on it will have to step up their support.
There will be no shortage of CentOS users who would like to get their hands
improvements and added hardware support to be found in the RHEL 5.6
and 6.0 releases. But the real problem is not delayed gratification; it is
that there have been no
CentOS 5 security updates since January 6, and only one since
December 14, 2010. During this time, RHEL 5, on which
CentOS 5 is based, has seen updates for
dbus, exim, firefox (twice), gcc, hplip, java-openjdk, kernel (thrice),
libuser, mailman, openldap, pango, php, postgresql, python, samba,
subversion (twice), tomcat5, vsftpd, and wireshark (twice). Since these
updates are based on the 5.6 release, CentOS cannot easily pass them on to
until they, too, have a 5.6 base. Since that base has been slow in coming,
all those security updates have been blocked.
Some of these vulnerabilities are more severe than others, but there can be
no contesting the fact that every CentOS 5 system out there is
with a significant set of known holes. That is not the sort of solidity
and support that CentOS users will have been hoping for. Many of those
users will, by now, be wondering whether CentOS is the right distribution
to base their systems on.
The CentOS mailing list has been filled with users asking when updates
would start flowing and why things have bogged down for so long. Some say
that there are too many RHEL repackaging projects out there, and that
CentOS should join forces with a distribution like Scientific Linux.
Others blame the 6.0 release for distracting the project from its 5.x-based
users - causing security updates for installed systems to languish in favor
of a shiny new distribution that nobody is running yet. Still others
complain that the project is insular, secretive, and hostile to new
contributors. All of these claims may or may not be true, but they are not
the subject of this article: there is
another aspect to the problem that is unambiguous and clear.
Many people benefit from the work of the CentOS project, but at the top of
the list must be managed hosting providers. Those companies get, for free,
a solid platform which they can install on thousands of servers and sell to
their customers. A site called tophosts.com maintains a list of the top 25
hosting companies; a look at that list leads to some interesting
conclusions. Of those 25 companies:
- One is a Windows-only provider.
- Two offer "Linux" with no way, short of actually renting a server,
of determining what flavor of Linux is involved.
- Three appear to offer Red Hat Enterprise Linux only.
- All of the rest (19 providers) offer CentOS.
(As an aside, it is amazing how hard many of these companies make it to
find out what it is that they are offering to sell. Hosting provider web
sites seem to all be designed by the same person; they are twisty mazes of
Represented on this list are the largest hosting providers in existence -
though it must be said that the list is US-centric. Together, they account
for many hundreds of thousands of systems, a significant percentage of
which are running CentOS. That's a lot of business - a lot of revenue -
which is being generated by CentOS-based systems.
The failure of CentOS - or even a significant tarnishing of its reputation
- would reduce the value of the services offered by these providers. Other
free Linux distributions exist, and some are entirely suitable for stable
deployment situations, but many customers want a distribution which is
compatible with RHEL. So said providers have a significant stake in
keeping the perceived value of CentOS high. Perhaps it is time that some
of them put some resources into supporting that value.
Said resources could certainly take the form of monetary donations to the
project. But far better would be for these companies to hire somebody to
work directly with CentOS and make it better. In return, they would reap
all of the benefits that come with open source participation: they would
have a better distribution to offer to their customers, they would get more
influence over the direction of the project, their participation
would enhance their reputation, and, crucially, they would improve their
in-house expertise which could then be used to support their customers.
All of the motivations for supporting free software development in other
parts of the economy apply just as strongly to hosting providers.
A look at the CentOS
Sponsors Page shows that quite a few hosting companies - including a
handful of the big ones from the list described above - are supporting the
project. In many cases, it seems, that support takes the form of a donated
server. CentOS certainly needs servers and bandwidth, but those, alone,
will not keep the distribution strong. Even the strongest contributor gets
a bargain from Linux - nobody puts in as much as they get out. But one
suspects that the hosting industry is
getting a better deal than many. Now would be a good time for the
top beneficiaries of the CentOS project to roll up their sleeves and put
some serious time into making it better.
Comments (78 posted)
Page editor: Jonathan Corbet
Next page: Security>>