For quite some time there have been a number of open source
Java virtual machines implementations, it could be easily
understood that each project was trying out different ways of
implementing the virtual machine or had different goals,
milestones or requirements.
All of these JVM efforts at least shared the class
libraries (which is a large component of a Java VM) in the
form of the GNU Classpath, and this certainly helped these
The Apache Foundation is now starting up a new effort (Harmony)
to put together a virtual machine and its class libraries
under the Apache License. The FAQ posted is a bit short on
the motivations for this effort. I can only speculate that
this was done to avoid the side effects of class libraries
licensed under the GPL-with-exceptions or the LGPL which make
Depending on how this process is managed, this could either
become a big delay in bringing a full free software/open
source Java implementation (as people take sides on the
licensing debate) or if managed properly could make open
source java more viable.
The challenge that the Harmony project faces now is
significant. They need to convince enough of the existing
open source Java developers that they should abandon the
current GNU classpath effort and either relicense their code
to be Apache-license compatible, or that they should rewrite
their code to assist this new effort on the grounds that the
Apache License is better. This last point does not seem to be
very well articulated in the FAQ which merely dances around
the issue. The FAQ at this point seems to mostly focus on
spinning things positively while not explaining the rationale
for this split, as can be seen by the first follow
If they are not able to bring these existing contributors
over they are going to have to grow this codebase from scratch
and depend on member companies to contribute code to the
effort. IBM might be interested in donating parts of their
code (assuming they are allowed to) and might even be behind
We have been working on the open source Mono for almost
four years now and it has helped me put things a bit into
perspective. I can not blame the Apache folks for going down
this path. This should have been sorted out a long time ago
in GNU Classpath land, but am fairly skeptic about the
viability of Harmony's class libraries.
It is hard to tell what will happen, but without the
endorsement of the majority of the GNU Classpath developers
this is a major setback for open source/free software Java.
It might be a necessary step, but am skeptical of its success
In the meantime, gentlemen, you can start using Mono with
its lax license today! Get it while its fresh!
Mhm, sorry about that. I just felt like plugging Mono
again. Lets move on.
Class Library Licensing
Licensing wise, we went through a similar issue in the
early days of Mono. Our class libraries used to be under the
LGPL license. We switched the class libraries license from it
to the MIT X11 license in response to comments from our
potential users and contributors. Of course the MIT X11
license has pros and cons. On the pro side, it imposes very
few restrictions on the users and its very easy to mix and
match, and in general people feel comfortable with adopting
it. On the downside, it is possible for companies to
"appropriate" the code and never contribute anything back.
Certainly people have copied the Mono class libraries into
their proprietary products and not given changes back (mostly
people find Mono components easy to reuse on the Compact
Framework that lacks plenty of functionality), but even the
GPL and LGPL would not have changed things dramatically in
this case (only the receiving end would have the right to the
source, and for Compact Framework users, even more irrelevant
than desktop users).
When it comes to large users of the Mono class libraries,
Mainsoft is probably the largest consumer of it. Mainsoft has
a product that turns CIL bytecodes into JVM bytecodes and
allows users to port their C#/.NET code to a Java VM.
Mainsoft could have chosen to make a proprietary copy of the
class libraries, improve their copy and ship that to
costumers. But instead Mainsoft has chosen to become an
active contributor to the project, and is relicensing its own
code under the same terms, the MIT X11.
There are a number of reasons: it is simpler to get new
improvements from the community into your own code base, you
can drive the direction of the project, and they have created
a great aura around their company in the community: they are
not only socially responsible contributors, but the world can
see that their contributions are top-notch. In addition,
their customers get access to the code and can benefit from
the shared knowledge pool of the resulting code.
I mention this because a common reason to use the GPL and
the LGPL, as opposed to a more lax license like the MIT X11, was
that third-parties would tend to keep their improvements
to themselves and that only a license with stronger terms
could get them to contribute back. A few examples are usually
mentioned: the X11's own failure in the 80's to get vendors to
share their improvements and the success of GCC in forcing the
C++ front-end to be released.
Maybe those examples did apply in a poorly connected world
and much smaller ecosystem of the 80's, but none of the two
previous scenarios necessarily apply today for horizontal
software. The Mono class libraries have demonstrated that
companies are willing to contribute to the class libraries and
that collaboration will help them reduce the cost of
I am now less convinced that forcing people is the best way
of achieving collaboration. The GPL has certainly played a
role in educating people about free software, but for the most
part people who contribute to nascent open source/free
software projects have done so do for a plurality of reasons
that have nothing to do with being forced by the license,
including shared R&D costs, joy, need, curiosity,
challenge, sense of community, social responsibility, or fame.
This must be obvious to every Firefox user now, but am
still amazed at the simplicity and the beauty of Firefox's
Ever since I can remember GUI applications, searching has
been implemented as a popup box that pops in the middle of
your document covering the text you want to search.
Descriptions on how to float these dialog boxes and the
discussion about how to create these non-modal dialog boxes is
present in most GUI programming books that taught these
principles to developers.
The beauty of placing the search at the bottom as opposed
to using a sidebar is that the document is almost never
I find myself missing this interface on my applications.
Evolution for example still has the old-school search dialogs:
The new Adobe Acrobat pops up a small enough window with only
the basics: the text to search for, backwards and forwards
button, and configuration options are done from a button on
An improvement, but not as good as Firefox.
That being said, the places where I miss search the most in
my applications are: