About Jtrix
Jtrix
is a Java platform for scalable Web Services,
with the aim of turning Web Services into a
proper commodity (rather than an on-line version
of proprietary lock-in, or where the kind of
services on offer is limited to those suitable
for RPC). This enables us and others to turn
Web Services into a real business.
Part of the system is to have "services on
demand". That is, your application presents some
XML with which the Jtrix platform downloads code
for the service you want. The XML will have come
from the service vendor, vendor X, giving you
the right to access their Service X. However,
the only compile-time connection between the
Service X and your code is a Java interface:
your application and Service X must have this
in common. Any service Y which uses the same
interface(s) can be substituted --- all you need
is an XML document from that vendor Y. The Jtrix
platform manages the running of the applications.
We chose the LGPL for Jtrix. We don't mind
people taking our code and embedding it in
their application. If they sell the result,
good luck to them. But we do object to people
changing Jtrix and distributing the result
--- that would lead to an incompatibility and
destroy the potential of an open market in Web
Services. The LGPL is right for us.
About Mckoi
Mckoi
is an excellent, fully featured Java
database, in very late beta. It's been under
development since 1998 and Toby Downer, its
creator, has had the time and energy to create
a really robust system allowing transactions,
multiple clients, and so on.
Mckoi is licenced under the GPL for commercial
reasons. The GPL allows Mckoi to be used in
anger by many developers, to give them something
of production quality and also help guide its
development. But the licence also allows the
the creators of Mckoi to work like the people at
MySQL,
offering a free licence to those who
use it in a free context and an alternative,
commercial, licence to those want to use it
non-free ways, or those who want to get support,
and so on.
Unlike the LGPL, the GPL forces a developer to
make their code also GPL if they link it to any
of Mckoi's code. Ie if you include any part of
Mckoi in your code then your code also has to
be GPL.
What did we want to do?
I contacted Toby because I wanted to clarify
several problems.
For one, I wanted to propose working together on
scaling Mckoi. Jtrix provides the tools to do
this, and all these tools are under the LGPL. By
adding Jtrix- or Jtrix-compatible code to Mckoi
we'd be able to produce a database that grew by
itself as needed. Not even the big commercial
databases can do that. Under this scheme we would
produce a "database service on demand". And
I didn't want either of us to compromise our
principles or businesses. Toby felt the same.
Also, I wanted to make sure that GPL code such
as Mckoi could run on the Jtrix platform, again
without compromises.
Finally, I wanted to see under what circumstances
one application could use a GPL'd Jtrix service.
It was important to get agreement on these items
from Toby as a proponent of the GPL.
What were the results?
The technical developmental details are
outside the scope of this article and our
discussions. But Toby and I easily reached a
good understanding on the licencing issues.
The most important point, which doesn't
usually come up in (L)GPL discussions is that
the platform is completely independent of what
code runs on it. For example, it's fine to run
GPL code on the proprietary Windows platform,
just as it's possible to run a the proprietary
Oracle on the GPL GNU/Linux platform. In our
case, it's okay to run a GPL application on the
LGPL Jtrix platform. The platform does not rely
on the application to work and is distributed
separately. Personally, this gave me a whole
new respect for the GPL and further demonstrated
its author's intentions.
Actually, Mckoi doesn't run on the Jtrix
platform as-is. It needs some additions (call
them A). The additions would turn Mckoi into a
"Jtrix application" or "Jtrix service" (same
thing) which would make it Jtrix compatible.
These additions would form an application as a
whole (call it B) and would have to be licenced
under the GPL. This whole application B would
be a GPL Jtrix application, but the licencing
of the Jtrix platform is still a completely
independent issue.
But what about an application C running on the
Jtrix platform and which wants to use the Mckoi
Jtrix service B?
In order to create C its author would have to
borrow some code (Java interfaces, call them
D) and include that in application C. These
interfaces D would come from Mckoi's additions,
A. And since A is under the GPL, application
C would need to be under the GPL also. This
seems completely fair in principle, since
application C is explicitly linking to parts of
a GPL application.
However, this conflicts somewhat with Jtrix's
idea of making Web Services a commodity. In the
Jtrix view of the world if you don't like one
service vendor you can substitute another. So
tying your application C to the licencing
and library of one
particular vendor is wrong. It is as wrong as
tying your application to a Microsoft or other
proprietary vendor licence or library.
The happy solution is simply to ensure that
the Java interfaces D appear under some licence
"looser" than the GPL. For example, the LGPL,
Apache Licence, BSD Licence, etc. There are
two ways to look at this. One: write the Mckoi
Jtrix service B under the GPL and, when creating
the Java interfaces D, give them this second
licence as well as the GPL. Code can have as
many licences as its creator likes. Two: create
the Java interfaces D and build these into the
Mckoi Jtrix application B. The result is the
same either way.
Also, this doesn't compromise anyone's
principles. Mckoi is still a stand-alone
database under the GPL. No application can be
distributed with it unless it, too, is GPL
(or has an alternative licence from Mckoi).
On the other hand, the creator of application
C can still licence their software how they
like. They could choose to connect to a Mckoi
database, or they could connect to a proprietary
database from another vendor. Their application
is independent of the database.
Of course, the question remains: what does the
creator of the Mckoi Jtrix service B want? The
answer is that it's up to them. If they want
to force all clients to GPL their code then they
should stick to the GPL for Java interfaces D. If
they're happy for client code to have its own
licencing then they can make Java interfaces D
LGPL, Apache, etc. Either way it doesn't affect
the licencing of Mckoi, which is still GPL.
Postscripts
Two final notes.
Toby has commented that one downside of the GPL
is that it prevents other "good" projects (my
words), such as those from
jakarta.apache.org,
linking with Mckoi. This is of course true. My
personal feeling is that the GPL offers
protection and does not make value judgements between
"good" projects and "evil" projects where people
try to cash in on your hard work. It's up to
you to decide if you want this protection.
And someone with Apache-licenced software
can always "upgrade" that licence to the GPL
if they want to link it with GPL software.
As a second note, we didn't cover the issue
of the Jtrix platform downloading a "service
on demand". Does this count as "distribution"
under the terms of the GPL? My current feeling
is that it does. (I don't want to commit myself
on this point only because I'm not a lawyer!)
But I also think it's a red herring regards
the issues we're discussing. They key point
how you tie your application to something which
is partly or wholly under the GPL. After this,
how you distribute your code and/or the GPL'd
code is a detail.
Summary
So that's my adventure into the world of GNU
licences. I came out with a better understanding
of the licences and what their intended aims
are, and it gave me a new respect for them.
I hope these experiences help others, too.