While following the current SOA Flamewar
going on, I also found my way to a somewhat recent ServerSide thread regarding Terracotta's licensing
, and whether it was "real" Open Source or not. This, of course, degraded to, in many postings, a Apache License
license discussion, and which was "better."
In my opinion, you pick a license depending on your ultimate goals for the redistribution and usage of the software. In some cases, an AL-type license is the best choice; in others, something (L)GPL-like makes more sense. There is no one license to rule them all.
Yet this distinction seems to be lost on too many people, including people who really should know better. The idea that, no matter what, one should always
choose (L)GPL is crazy (and I use (L)GPL in this example because, almost without exception, that is the exact claim made).
I like the AL, and it is my preferred license, simply because of the fewest restrictions it places on the code, the developers and the end-users. If one defines "free" as "having fewest restrictions or limitations" then an Apache-type license is "freer" than others. Look at it from another perspective, and imagine that one's license defines freedom of movement. The AL says that one can go forward and reverse, left and right and diagonal. Basically, the moves of the Queen in chess. Other licenses place restrictions on the software; limitations that affect distributors, developers, or users. They take away some freedom of movement: you can no longer go diagonally, for example.
Also, I like the fact that the AL is business friendly; that it encourages the usage
of the code by commercial entities with almost no strings attached. It's been said that the AL license is the most "business friendly" open source license around, which I would agree with. But others believe just the reverse. And by following the ServerSide thread, I was reminded of (and pointed to) Fluery's "Business Friendliness" blog entry of 2004
which makes that claim.
Personally, I don't see how that could possibly be the case. Fluery claims that his example shows that AL is bad, creating forks, and (L)GPL is good because it prevents (or, at least, discourages) them. Well, IMO, the ability to create forks is a foundation of Open Source, but we'll let that slide. What is ironic is that he bashes the AL for allowing what he specifically did for Axis: taking the code and using it as he wished.
He also states that he had "no professional interest in giving this code back to our competitors." But since it's under the (L)GPL, isn't it "available" anyway? And certainly wouldn't that be a valid excuse for other commercial entities to not even look at a (L)GPL implementation in the first place? And isn't it just slightly hypocritical to claim the superiority of a license that forces others to do what you specifically decided not
to do ("give" your code to your competitors)? The AL allowed him to do exactly what he wanted with the code in his particular circumstance: use it as a basis for their implementation and then not provide any patches back to the original community; the (L)GPL would not have. It certainly would not have allowed him to relicense under the AL. If you can go from the AL to the (L)GPL, but not the reverse, I'd say that one has more degrees of freedom, wouldn't you? And recall that this was a business
decision. Seems you have more options on which decisions are available to you with the AL, dontcha think? And look what happened: a commercial entity grew and prospered and the Open Source community did as well (Axis got better, additional Open Source projects took foot, etc...).
What we see with many, many, many AL projects is that the threat of "proprietary" forking does not happen. Those commercial entities give back to the community not because they have
to, but because they want
to. The trust and altruism inherent in the AL is reciprocated. Sure, there are times when that doesn't happen. In which case, the hope and intent is that, by using an AL project to base your implementation on, you have no compelling need to waste resources on implementing "features" which defeat open standards. In other words, yes, you fork the code, but not the open standards and protocols that they implement... which sounds like a good deal to me. Good enough, at least.