LWN.net Weekly Edition for May 25, 2006

How Sun's Java got into Debian

One of the comments posted on last week's article about the Java license change asked: how can Debian distribute Sun's Java under the new license? A number of clauses, including the requirement that Java be distributed with the operating system and the restrictions on shipping Java "in conjunction with" alternative implementations, would seem to rule out a Debian Java package. It turns out that a number of Debian developers are wondering the same thing; in addition, there are questions about the process that was involved. Sun's Java was fast-tracked into non-free, with the traditional extended debate on debian-legal having been shorted out entirely. Since Debian does very few things without enduring a public brawl first, the addition of Java without discussion raised some eyebrows.

Various people have tried to answer the resulting questions. The definitive word, perhaps, comes from Debian Project Leader Anthony Towns:

There is a point here: Sun has been very public about how happy it is about Debian's inclusion of Java. For the company to suddenly say that it isn't happy after all would be a big, public turnaround and would invite a fair amount of criticism. There would have to be a big reason for Sun to make such a move.

Anthony continues:

The DLJ FAQ does, indeed, make a lot of encouraging noises about what the license terms really mean. It says, for example, that there is no problem with shipping other Java implementations. The FAQ leads off with this rather less encouraging text, however:

This is the text that makes many Debian developers say that the FAQ is irrelevant and should be ignored. It may well be that Sun has, by way of estoppel, blocked itself from a rigorous enforcement of the license terms by publishing this FAQ, but that is a question which cannot be definitively answered outside of a courtroom - and, even then, the answer only applies to one jurisdiction.

Finally:

So, if things go wrong, Debian can just stop distributing Java and the problems go away.

These arguments all make sense, but there is something important which should be noted about them: they are arguments of convenience. They could be loosely paraphrased as "it looks like we can get away with it, and, if that turns out not to be true, we'll just stop." Debian, however, has never been about convenience - the project is far more concerned with freedom and doing the right thing. Distributing software in a way which does not comply with its license is very much counter to the way the Debian Project works - even if it looks like the act would go unpunished. But there is little in Anthony's response saying that Debian is truly compliant with the Distributor License for Java.

Sun employee Tom Marble has argued that there is no conflict between Debian and the DLJ. Like Anthony, he refers to the FAQ, but without addressing the text in the FAQ itself directing people to the license for the "precise terms and conditions." With regard to alternative technologies, Tom says:

This could be a reasonable interpretation of the license, though it would be much nicer if the license expressed these terms directly. Anybody who finds this argument to be a suitably convincing and binding statement of the intent of the license can, perhaps, conclude that Debian's distribution of Java in non-free is compliant with that license. Of course, some of the other terms, having to do with choice of venue for legal disputes, export restrictions, and indemnification of Sun, may still be problematic for a number of Debian developers.

Regardless of whether one believes that Debian's distribution of Java is compliant, there is still the question of process: why was the Debian community not involved in the decision? The answer is straightforward: all of the relevant information was under embargo until Sun made its announcement at JavaOne. The only way for Debian to have a Java package when Sun announced - and for Sun to announce that said package existed - was for the process to happen in secret. So the new license was examined privately by Anthony Towns, James Troup, and Jeroen van Wolffalaar, and all three pronounced it to be acceptable.

Michael Banck had an interesting take on this process:

So Debian, by cooperating with Sun on the disclosure of information, was able to be a part of the initial PR splash. A question which has not been asked - in public, at least - is: just how does Debian benefit from participating in Sun's PR experience, and is it worth the cost of bypassing the usual public discussion?

Comments (39 posted)

Toward a free Java

Every year around JavaOne there is a lot talk about Java and whether we will ever see a free alternative for it. Since 2000, various projects aiming to provide a free alternative for the Java platform have been working together toward this goal. This cooperation became much stronger when in 2003 various developers from GNU Classpath, Kaffe, GCJ, JamVM, IKVM/Mono and others met each other in person during some informal meetings at Linux Kongress, FOSDEM and LinuxTag in Europe. What had before been competing projects became projects that would cooperate wherever technically possible, especially around the core class libraries as provided by GNU Classpath. The competition turned into something positive and playful. The GNU project even sponsored the Fast Free Eclipse contest which was ultimately won by GCJ in August 2003 (with JikesRVM and IKVM/Mono close behind).

At the end of 2004 Red Hat brought all these groups together again during the Alternative Runtime Summit at the MIT campus in Boston. They invited a large and diverse group of people to talk about their projects and also invited representatives of the traditional Gnome, GCC/GDB/GNU toolchain and Mono groups, plus representatives of the Apache and Eclipse groups, to discuss various ways to build bridges between the various communities. Richard Stallman gave a lecture on the Java trap and a Sun representative was also invited. Sun decided to not join the fun at that time, but we did establish that our goals were not that different.

Although none of us knew how the future would look, it was clear that everybody was very positive about sharing their experiences and working ever more together. Everybody left the Alternative Runtime Summit feeling our goals united us much more than the different technical paths we were taking to reach them divided us. There was also a definite feeling that we would be able to provide a full free alternative to the Java platform. And that the alternative(s) would be much more then Java and that it would go beyond and extend the traditional GNU platform.

The realization that we were in this together and that a free alternative for Java should be integrated as much as possible with the rest of the free platform had some important results. Our next meeting at FOSDEM 2005 was all about building bridges. We focused on alternative execution mechanisms like GCJ and Mono, hooking into Gnome with java-gnome and doing continuous integration tests against the Apache Java code base through Gump.

Another way to cooperate and, at the same time, help our users to try out our work more easily was done by collaborating with the various GNU/Linux distributions to package traditional Java programs and libraries so they could be easily used with the various free alternatives. During the Oldenburg DevJam Meeting various packagers, compiler and runtime hackers came together to define standards for interoperability and packaging conventions. Users can now easily try out various compilers, libraries and the alternative execution strategies for their code. This effort was so successful that even Sun is now adopting the JPackage alternative ideas for their own (proprietary) packages aimed at the GNU/Linux platform (although their current license seems to disallow any mixing and matching with the various free subcomponents).

One of our success stories is the packaging of Eclipse for the various GNU/Linux distributions. Although Eclipse traditionally emphasizes the proprietary Windows platform, the Eclipse developers have been extremely supportive of our efforts and have helped find alternatives whenever the free toolchain didn't have a particular language or library feature yet.

After setting up Gump integration tests with Kaffe and seeing that we were almost there, the Apache group became very enthusiastic about joining in. Since a lot of the packages that are bundled by the free distributions were actually based on code by the Apache group, that seemed like a very cool idea. After a couple of conference calls between the FSF, ASF and various project members we launched the Harmony! project.

Unfortunately, from the start the project seemed plagued by miscommunication and confusion about intentions. The original announcement hadn't been proofread by some of the participants which lead to corrections by the Kaffe team, clarifications by the GCJ team and updates from the GNU Classpath team about the original intent of the project. Sadly, these first impressions were hard to shake off.

And soon a lot more miscommunication and confusion started. Some people joined that were very vocal about the project being Apache (and not GNU!), some people said that their company regulations didn't allow them to study anything on gnu.org, including the GNU Classpath VM Integration Guide. Others said that using anything that used the "gnu." Java package namespace would be impossible to clear with their legal departments. IBM wanted to donate code, but suggested using an alternative runtime interface which would be suitable for their proprietary J9 VM (but not for any of the 30 projects currently based on GNU Classpath).

After 9 months of trying to cooperate we organized a new meeting during FOSDEM 2006 to get all players together again. And, although 60 people attended, including core GNU Classpath, GCJ, Kaffe, Cacao, JamVM and IKVM hackers, only one Harmony person showed up, and none of the people from the backing companies. All this means that, despite the fact that there is now some code available donated by Intel, there is no practical cooperation between the original free software projects backing Harmony and the project now known as Apache Harmony. All this made some people think of Harmony as a company consortium in the guise of an ASF project and not a full community project. But there is still some hope that the final result will be merged with the existing projects at some point and that there will be more community involvement in the future.

One thing we had completely overlooked in our Harmony effort was the fear uncertainty and doubt in the Apache Java world about the GPL, the LGPL, and the GPL exception statements used by GNU Classpath and other GCC runtime libraries. At the Alternative Runtime Summit we had discussed The Free Software Community, the GPL, Compromising and Control. And David Turner from the FSF was present to explain LGPL and Java. We (the Classpath developers) had naively assumed that in turn for using an explicit GPL + linking exception for GNU Classpath, so it could be used with code distributed under the ASL, we would get back an exception to the ASL for larger works distributed under the GPL.

Sadly that did not happen. Partly because the Apache group doesn't hold the copyright on code contributions so cannot change any of the terms of the code it distributes (the FSF had offered to track down all contributors, but this proved to be too large a number to be practical) and partly because it doesn't want to make any exception for its code base since it fears that would confuse its users. But most Apache people did agree that it would be nice if code distributed under the ASL would be reusable in larger GPLed works, just like it is reusable for proprietary code. And the FSF agreed that none of the extra requirements in the ASL were inhibiting the freedom of users.

As a result, you will see various improvements in the GPLv3 draft based on our discussions. The GPLv3 clarifies the system library exception, explicitly states people can grant exceptions to the GPL, like the FSF has done for the various GCC runtime libraries, and adds compatibility clauses for certain requirements found in the ASL and EPL licenses. We hope that when GPLv3 is finalized we will see more code flow between the projects and reuse of various Apache and Eclipse technologies in the GNU, Gnome and KDE worlds.

One of the efforts that does seem to pay off is our cooperation on the Mauve Completeness, Correctness and Compatibility testsuite. Mauve contains more than 45.000 core library tests and has various modules for testing core class library implementations, byte code verifiers, source to byte code and native code compiler tests. It also contains the Wonka visual test suite and the Jacks Compiler Killer Suite. Every release of GNU Classpath comes with a little overview of how well we do on the tests. This is especially important because we have so many different compiler and execution mechanisms available. It also enables us to measure compatibility despite the fact that we don't have access to the TCK suite that Sun uses to determine whether something is Java compatible.

Now that Sun is again thinking about whether and how to open up more we have even been in contact with some Sun engineers who would like to start some cooperation by combining out testsuites. For Sun compatibility has always been a very touchy point. So some hope this will be the start of a better cooperation of the Sun Java group with the rest of the free software community. It seems that our continuous progress and nice integration with the GNU/Linux desktop at least got their attention.

Comments (6 posted)

Coming soon: GnuCash 2.0

Back in September, 2005, the Grumpy Editor's Guide to Personal Finance Managers concluded that the development energy and momentum seemed to belong to the KMyMoney project. GnuCash, instead, seemed dispirited with little activity on its mailing list and little visible progress toward its long-awaited 2.0 release. Some distributors, hoping to be done with GTK1, were making noises about dropping GnuCash altogether. At that time, KMyMoney looked like the application with the brightest future.

Since then, there has been a significant surge in activity on the GnuCash side while KMyMoney, to an outside observer, appears to have slowed down. Clear goals for the GnuCash 2.0 release have been set, a series of pre-2.0 test releases has come out, and 2.0 final is currently planned for June 11. GnuCash, it seems, is back. Your editor, whose desperate attempts to balance the family budget are made on a system running the Fedora development tree, got a rather unplanned opportunity to try out GnuCash 1.9 (the pre-2.0 test release) when the Fedora hackers quietly slipped it in as a replacement for the stable version. A few months of financial firefighting later, it's time for a quick review.

Those who are expecting a lot of flashy new features from GnuCash 2.0 may be disappointed. The big change in this release is not the heavily-requested animated pie chart feature. Instead, GnuCash has made the (rather delayed) jump to the GTK2 toolkit. This change was a major bit of work for the GnuCash developers, who had to drop some discontinued libraries altogether and reimplement various features (graphical reports, for example) in a completely different environment. So what 2.0 brings is not a whole lot of new features, but a new platform which is ready for the creation of tomorrow's new features.

One thing seasoned GnuCash users will notice early on is the tabbed interface on the main window. In the stable 1.x releases, opening an account results in the creation of a new register window; in 2.0, a new tab is created instead. This behavior is arguably more consistent - even in 1.x, reports showed up in that version's form of tabs rather than in their own window; now everything works that way. But, for users who are used to being able to have more than one register on the screen simultaneously, the new behavior can be a little annoying. Fortunately, there is an option to move a tab into a new window, so users who like their screen cluttered should still be happy.

Other than the new tabs, the GnuCash user experience is little changed from the 1.x release. Things generally work and look as they did before. From your editor's experience, it all appears to be quite stable (though your editor has not spent any real time playing with the business features). Except for a couple of minor keyboard focus issues, the transition appears to have been completed successfully. For those interested in testing the development releases, it's worth noting that the file format does not appear to have changed, making it possible to make changes with a development release, then go back to 1.8.x without trouble. It is worth noting that the PostgreSQL backend is not yet working properly, but that is consistent with the earlier GnuCash releases as well.

Of course, no major release can be completely without new features. The GnuCash developers have found time to implement the use of UTF-8 for better handling of non-western characters and the ability to import the "MT940" files available from some banks. But the most interesting (for users) developments in the 2.x series are likely to show up in 2.1 and later releases. Now that the painful transition to a contemporary toolkit has been made, the developers will have the time to do fun stuff again, and the project should be more accessible for new developers as well.

The free software community has been surprisingly slow to push the state of the art in the personal finance area. One would think this particular itch would afflict a great many developers - even the hungriest of starving hackers has some financial management to do, and we can't all push the work off onto our Windows-using spouses. Be that as it may, the situation is slowly changing. Between KMyMoney and the new, refurbished GnuCash, the community now has two high-quality platforms suitable for the creation of tomorrow's personal financial software. Your editor is looking forward to seeing where things go from here.

Comments (9 posted)

Page editor: Jonathan Corbet

Inside this week's LWN.net Weekly Edition

• Security: Holes in the Linux random number generator?; A discouragingly huge pile of new vulnerabilities.
• Kernel: Virtualization: now what?; A new generic IRQ layer; Tainting from user space.
• Distributions: Fedora - back to the six month schedule; SUSE Linux 10.1 DVDs released; Mandriva Kiosk
• Development: The first modular release of the X Window system, BusyBox, CUPS, S60 WebKit, DataparkSearch Engine, HylaFAX, amaroK, aubio, Sonic Visualiser, PythonCAD, Asymptote, PLplot, GNOME, GARNOME, jLibrary, Gnucap, SQL-Ledger, EntityForge, Gideon Designer, PythonCard, Xara Xtreme, Wine, Wine-doors, KOffice, pari, PHP Yadis Library.
• Press: OIN gets more patents; OSU's Open Source Lab; The best of the Linux-related press.
• Announcements: Undo's bidirectional debugger, EC and software patents, DefectiveByDesign.org launched, KDE joins ODF Alliance, Plone Conference survey, Itanium Conf and LAC Coverage, php|works and Europython CFPs, GPLv3 Conf, KDE Multimedia, LugRadio Live, NY PHP, Web 2.0, Blender movie, Plone vs others.

Next page: Security>>