Leading items

The Ada Initiative takes a different approach

The gender imbalance in the free software world is largely mirrored in the related "open technology and culture" communities. Various efforts have been tried over the years to try to rebalance things, with varying degrees of success. The newly formed Ada Initiative is taking a different tack than those previous efforts: raising money to support full-time staff, along with various projects, rather than going the traditional all-volunteer route.

Valerie Aurora and Mary Gardiner, who are longtime advocates and organizers for "women in open source" projects, launched the Ada Initiative (TAI) on February 7 to "concentrate on focused, direct action programs, including recruitment and training for women, education for community members, and working with companies and projects to improve their outreach to women". While the first steps for the initiative are somewhat bureaucratic—filling out paperwork to put the organization on a sound legal footing along with raising the funds that it needs—TAI has some concrete plans for projects that it will be working on.

At the top of the priority list, according to Aurora, is a survey that will measure the participation of women in the open technology and culture communities. This would be something of an update to the FLOSSPOLS survey that was done in 2006. TAI is working on a methodology for the survey, so that it can be repeated over time to gauge progress. The survey is meant to answer a very fundamental question, Aurora said: "How bad is the problem, and is what we are doing making things better? If we can't answer these questions, we can't do a good job."

Another project in the works is "First Patch Week", which will be an effort to pair companies and projects with female developers to help get the new developers over the first hurdle in joining a development community: submitting their first patch. The idea is that the existing community supplies mentors who have been trained by TAI to bring these new developers along, and it will be beneficial to both sides: "Participating in First Patch Week is an excellent opportunity to get new developers working on your project (with the potential of hiring them later on, of course)." Like the survey, First Patch Week is going to take some time to get up and running, but once past the organizational set-up phase, TAI intends to put in "several months of full time effort" to find the right projects and train mentors.

So far, the response to the initiative has been "amazing", Aurora said, with inquiries from "enormous international corporations" as well as community organizations and individuals. TAI is in discussions with multiple sponsors, but it is really looking for more than money:

Linux Australia is the first TAI sponsor, and is providing some general sponsorship money that Aurora described as a "do the right thing" sponsorship. Because the organization is so small, general sponsorships, rather than those focused on a specific project, are what it is looking for. There's still plenty of room to become a sponsor, but "if your organization would like to be a founding member of the Ada Initiative, now is the time to be talking to us."

Discussions on the supporters mailing list have focused on individual contributions. While that is not the kind of funding TAI is looking for in the long term, it would help with the start-up process, so there will be some means of doing that (possibly through a Kickstarter campaign) coming soon. But there are ways to help beyond just the financial:

It is clear from the FAQ that TAI hopes that fundraising will provide the financial resources to allow the organization to dig into projects that are difficult or impossible for all-volunteer organizations to take on. By providing salaries to its employees (eventually, anyway), those people can concentrate solely on the projects, rather than having to work on them in "evening and weekend" time. It is a different style than that taken by existing organizations, such as LinuxChix and AussieChix, but one that TAI believes will be beneficial to the whole ecosystem, as Aurora pointed out:

The announcement was met with an "excited and supportive" reception, which, along with the sponsors that seem to be lining up, should bode well for TAI. According to Aurora, the initiative expects to be fully funded and working full-time on its projects by July. That means we should start seeing concrete results from those efforts in the latter half of the year. Gardiner and Aurora created TAI because it was "the right thing" to do, Aurora said, and they have been pleasantly surprised with the reaction from the rest of the open technology and culture communities:

The Ada Initiative—named for Countess Ada Lovelace, "the world's first woman open source programmer"—is a very interesting experiment. It will not only provide ways to increase the participation of women in free software and related fields, which is worthwhile goal in itself, but it may also provide an example of how to fund organizations focused on other specific initiatives within our communities.

There are a number of similar kinds of organizations in our community, the foundations for Linux, GNOME, and Apache for example, but those tend to be larger, umbrella organizations, whereas TAI is tightly focused on a well-defined, existing problem. There are certainly other technical and social problems in our communities that might benefit from a similar approach. More women in open technology and culture would be a fabulous outcome from this experiment, and finding more ways to fund interesting projects would just be icing on the cake.

Comments (56 posted)

FOSDEM: Icing the robot

Mario and David are annoyed that Android does not run on a normal Linux system, on any other operating system, or on any architecture except ARM (though they did note the in-progress x86 port). They like their Android applications and want to be able to run them on ordinary systems. To get there, they have developed a plan of decoupling the various parts of an Android system so that they can be replaced. Then they will implement whatever pieces are needed using ordinary Java and the openJDK; that includes implementing a Dalvik virtual machine (VM) in Java and/or running Dalvik as a standalone application. The result will be IcedRobot - an Android implementation built with ordinary Java and which can run on standard operating systems.

Why would one get into a project like this? As Mario put it: they like Google TV and want to run it on a desktop system. It might be nice to dispense with GNOME shell or Unity altogether and run in a pure Android environment. Or, on a traditional desktop, one could run interesting Android applications as "desklets." There is, they said, some potential commercial value for the Dalvik virtual machine which has been liberated from the custom Android kernel and libraries. They mentioned that a Dalvik VM running inside a normal Java VM might take the wind out of the sails of Oracle's lawsuit; since it would obviously be a pure Java application, Oracle's patent claims might not apply. And, they said, it's "time to do something crazy" now that the task of liberating Java is finally complete.

IcedRobot comes down to three separate projects aimed at different use cases. The first of these is gnudroid, which can be thought of as the IcedRobot "micro edition." For this incarnation, there is no interest in running on desktop systems. Gnudroid dispenses with the special Android kernel and the "bionic" libc replacement as well, going back to using standard system components. The Dalvik VM runs as a standalone application on such systems; the end result is something which is quite similar to standard Android in terms of functionality. The developers are removing "meaningless" code from the system - a move, which they say, cuts out 70% of the code. (Details on what is "meaningless" were not provided, though one assumes that removing the custom kernel is a big part of the total.) A new set of build scripts has been written, and the whole thing has been put into a Mercurial repository - they are evidently more comfortable with Mercurial than with git.

The next component, called Daneel, is a Dalvik interpreter written in pure Java. It's only an interpreter at the outset; they acknowledged that it may be necessary to add a just-in-time compiler in the future. This is the piece that, they think, might serve as a workaround for any Oracle patents which might otherwise be applicable. It is, they said, "a bridge between the worlds" of the Dalvik VM and pure Java systems.

Finally, GNUBishop is the "IcedRobot standard edition." It would be made up of three parts - a browser plugin, a desktop application framework, and a full standalone operating system. It replaces the Dalvik runtime entirely, using OpenJDK for the runtime system and Daneel as the core virtual machine. The plugin would allow running Android applications within a browser; most of the popular browsers are targeted. The application framework, instead, would allow the installation of Android applications on a normal desktop system. Linux systems are clearly targeted here, but the developers also have Mac OS and Windows systems in mind - and even QNX. The full operating system would be a Linux distribution built around the Android system.

This work is a volunteer effort for now, but Mario and David would appear to have some commercial goals in mind as well. They discussed the idea of the "GNU AppBazaar," which would be an IcedRobot equivalent to the Android Market. Evidently 10% of all proceeds from the AppBazaar will be sent to the Free Software Foundation. Also planned is "GNU AdNonSense," an advertising system for IcedRobot applications. They were quite firm that any such ads would be completely untargeted and that privacy is an important feature of this system. So no per-user information would be collected, and there will be no way for advertisers to target their ads to specific users. There was some talk of aiming IcedRobot at the automotive market, where, evidently, the developers see a fair amount of opportunity.

The current state of the code is not at all clear; it will, they said, be posted on IcedRobot.org soon, but, as of this writing, that site does not yet exist. From this weblog posting it seems that the process of decoupling Dalvik from the Android kernel is not yet complete; in the talk they said that the replacement of bionic is also an ongoing task. But there are apparently a number of developers working on the project, and they have that wild look in their eyes that suggests they may have the drive to see it through. The IcedRobot may yet walk among us.

Comments (37 posted)

PostgreSQL, OpenSSL, and the GPL

The OpenSSL license, which is BSD-style with an advertising clause, has been a source of problems in the past because it is rather unclear whether projects using it can also include GPL-licensed code. Most distributions seem to be comfortable that OpenSSL can be considered a "system library", so that linking to it does not require OpenSSL to have a GPL-compatible license, but the Free Software Foundation (FSF) and, unsurprisingly, Debian are not on board with that interpretation. This licensing issue recently reared its head again in a thread on the pgsql-hackers (PostgreSQL development) mailing list.

For command-line-oriented programs, the GNU readline library, which allows various types for command-line editing, is a common addition. But readline is licensed under the GPL (rather than the LGPL), which means that programs which use it must have a compatible license and PostgreSQL's BSD-ish permissive license certainly qualifies. But the OpenSSL license puts additional restrictions on its users and is thus not compatible with the GPL. Whether that is a real problem in practice depends on how you interpret the GPL and whether OpenSSL qualifies for the system library exception.

Debian has chosen a fairly hardline stance on the matter, which is evidently in line with the FSF's interpretation, so it switched to the BSD-licensed Editline (aka libedit) library instead of readline. PostgreSQL supports libedit as a readline alternative, so making the switch is straightforward. Unfortunately, a bug in libedit means that Debian PostgreSQL users can't input multi-byte characters into the psql command-line tool when using Unicode locales.

For the PostgreSQL project, it is something of a "rock and a hard place" problem. The OpenSSL code works well, and is fairly tightly—perhaps too tightly—integrated. There are two obvious alternatives, though, GnuTLS and Mozilla's Network Security Services (NSS). Switching to either of those would obviate the readline problem because their licenses do not contain the problematic advertising clause.

There have been efforts to switch PostgreSQL to use GnuTLS, as described in Greg Smith's nice overview of the history of the problem, but they didn't pass muster due to the size and intrusiveness of the patch. Part of the problem is that psql is too closely tied to OpenSSL as Martijn van Oosterhout, who developed the GnuTLS support, describes:

Another route to fixing the problem might be for either the readline or the OpenSSL license to change, but that is not a very likely outcome. Some GPL-licensed code has added an explicit "OpenSSL exception", but it is pretty implausible to expect the FSF to do so for readline—it has long seen that library as a way to move more projects to GPL-compatible licenses. OpenSSL is either happy with its license or is unable to change it as Stephen Frost points out in the thread:

Robert Haas recommends revisiting the GnuTLS support for the PostgreSQL 9.2 release, but in the meantime there are some Debian users who cannot easily use psql. It goes beyond just Debian, though, because Ubuntu will be picking up the PostgreSQL+libedit version for its next release. That spreads the problem further, as Joshua D. Drake, who started the whole thread, notes: "As popular as Debian is, the 'user' population is squarely in Ubuntu world and that has some serious public implications as a whole."

Instead of GnuTLS, NSS could be used and has one major advantage: Federal Information Processing Standard (FIPS) 140-2 certification. FIPS 140-2 is a US government standard for encryption that is sometimes required by companies and organizations when adopting products that contain encryption. OpenSSL has been FIPS 140-2 certified, as has NSS, but GnuTLS has not been. For that reason, there is talk of making PostgreSQL support NSS rather than GnuTLS.

The Fedora project is also looking at NSS as part of an effort to consolidate the cryptography libraries used by the project. For a number of reasons, including FIPS certification and some features missing from GnuTLS (notably S/MIME), NSS is the direction Fedora chose. One would guess that the GPL-incompatible license for OpenSSL played a role in eliminating it from consideration.

On the other hand, Fedora does ship various tools with both readline and OpenSSL, including PostgreSQL. It would seem that Fedora (and possibly Red Hat's lawyers) are relying on a belief that OpenSSL is distributed as a system library, as Fedora engineering manager Tom "spot" Callaway has said in 2008 and again in 2009. The project (and other distributions) may also be relying on the near-zero probability that the FSF will ever make a serious effort to stop the distribution of PostgreSQL using readline.

For Debian, though, that's not enough. Another Debian bug report contained more discussion of the problem, and a workaround discovered by Andreas Barth:

    LD_PRELOAD=/lib/libreadline.so.5 psql

That's a bit of an ugly hack, and no one seems very happy about it, but the plan is to add the LD_PRELOAD (if libreadline is available) into the psql wrapper that is shipped in the postgresql-client-common package. Martin Pitt sums it up this way:

This kind of licensing clash occurs with some frequency, and the OpenSSL license is known to be problematic—at least for projects that use GPL code. The advertising requirement, which is something of a throwback to the early days of the BSD license, makes OpenSSL increasingly isolated. Distributions and other projects are likely to continue to search for, and find, alternatives, if only to reduce the licensing murkiness and associated questions from developers and users. It is unfortunate that an ego-stroking clause or two in the license of a useful library may reduce its usage but, as always, free software will find a way to work around these kinds of problems and move on.

Comments (95 posted)