A tale of two licences

Posted 16 Jan 2002 at 13:48 UTC by niksilver Share This

This is the tale of how two software projects with different free licences learned to live happily together. It covers the different commercial reasons why Jtrix chose the LGPL and Mckoi chose the GPL, the pluses and minuses of each, and how they can interoperate without compromising principles or commercials.

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.


... or why not to use the GPL licenses, posted 17 Jan 2002 at 10:22 UTC by ask » (Master)

bagder said it very well in Working without Copyleft.

  - ask

Yes, there are other licences, posted 17 Jan 2002 at 13:50 UTC by niksilver » (Journeyer)

Thanks, ask, that was a good read.

Reese and Stenberg made many good points, and I wouldn't disagree. I think it's a question of horses for courses, and I hope my article didn't suggested that non-GNU licences were not options; it was just explaining how two GNU-based projects came to choose their licences and how they could interoperate.

Very interesting is their (underlying) theme that that those who want are not the same as those who give. Those who wanted the GPL are not those who contributed code, and those who gave code were not those who would have been happiest with the GPL.

One other reason reason we chose the LGPL, BTW, is that it is well-known and trusted. Apache might have been an alternative for us for that reason, but doesn't protect our platform from being changed in a closed manner. Platform-to-platform compatibility is important to us.

"Upgrade" to GPL, no, posted 20 Jan 2002 at 05:12 UTC by imp » (Master)

You claim that you can upgrade the license to GPL. However, the GPL is much more restrictive than the BSD license that apache uses. Therefore, it isn't an "upgrade" but rather a "downgrade" because it limits what people can do with your software. If it is free, why are there limits? Those people that claim you need limits to your freedom to keep things free don't understand freedom :-).

Of course I'm biased. I release all my code under either the BSD license, or Poul-Henning Kamp's Beerware license.

There's more than just "LGPL" and "GPL". That's like the scene in The Blues Brothers, where the waitress sais "Yea, we got both kinds of music here: Country *AND* Western."

"Upgrade" to GPL, no, posted 21 Jan 2002 at 17:57 UTC by slef » (Master)

There's actually another reason why you can't put Apache's code under the GPL. The "obnoxious advertising clause" is a restriction on use that is incompatible with the GPL. (See the FSF site for more.)

So you see, you should describe the GPL as "differently restrictive", not more restrictive than the BSD licence. Anyone considering which licence to use should ask themselves which is more important: Ensuring future freedom or controlling advertising? I'll pick future freedom... I'm not ashamed of wanting to avoid the mistakes of the past.

GPL vs BSD, posted 21 Jan 2002 at 21:45 UTC by imp » (Master)

Sigh. I'm not talking about the advertising restriction. That's long since been deleted from the BSD license (UCB sent a letter removing that clause about two years ago now). I'm talking about the ability to do anything you want with the code vs having obligations under a complex license. "upgrading" to the GPL is like having microsoft "upgrade" from common-law copyright to their ELUA. I know the FSF's take on the original BSD license.

Granted, the apache license is more restrictive than the current BSD license, since it also says that you can't use the name apache for your product unless you get permission of the apache foundation.

But you missed my point. I take strong exception to the characterization that the GPL is an "upgrade" from the BSD license. It isn't. It is much much more restrictive in what you can do with the derived work.

Of course, many companies flaunt their obligations under a strict reading of the GPL. While Linus has allowed them to, for example, not ship their source if they have a loadable module, there is no legal document, signed by all the copyright holders of the Linux kernel that releases one companies from doing this. Any one of them could assert their rights differently than Linus does and start demanding that the binary only modules be shipped with source. If this person had financial means, they could easly cause a whole lot of hassle in the linux community.

So be careful when choosing your words and characterizing switching from the BSD license to the GPL license as an upgrade.

Now who's losing the plot?, posted 23 Jan 2002 at 00:17 UTC by slef » (Master)

I think you are missing my point, perhaps intentionally. Apache uses a licence similar to the original BSD one, not the modBSD that UCB itself currently uses. Regardless of what UCB does, you cannot move Apache code to a GPL product.

modBSD probably is "freer" than Apache, LGPL and GPL in terms of what people can do to your code and if you want to do something similar to tossing your code into the public domain in jurisdictions without a concept of public domain, it's probably a good choice. Be aware of exactly what public domain means though: anyone can take your code and do anything they want to it, including building a binary-only product on top of it and selling it for lots of money (eg BSD TCP/IP stack in many OS softwares). If you'd like to help build a world out of free software, then help improvements to your code stay free by using the GPL.

Are there closed-source drivers in the mainline Linux kernel, or is that just your FUD talking?

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

X
Share this page