On Fri, Aug 06, 2004 at 09:42:02PM +0200, Wouter van Ooijen wrote:
> > With the LPGP you can use the lib or whatever without
> > sharing your proprietary stuff: Would it be better to go for a dual
> > license of some form?
>
> I had the same idea with the Jal libraries, but after carefull reading
> of the LGPL it is a relaxation of the GPL *only* for dynamical-liked use
> of LGPL-ed code. For the Jal-libraries I/we are switching to the zlib
> license.

Wouter,

I hate sounding like a broken record (scratched CD? ;-). But I think that
it's important in this discussion to separate the right the LGPL imparts and
the mechanism by which that right is invoked. First the right:

The receiver of a work that contains an LGPL library has the right to update
the LGPL library against the work.

In short if you distribute yourcode+lgpllib, then the receiver of that has the
right to rebuild and use yourcode+newlgpllib. Let's call it the rebuild right.

Nothing is attributed to yourcode (or to the combo of yourcode+eitherlgpllib)
other than the above right to rebuild with newer library versions. You don't
have to release source to yourcode unless it interfere's with the abovelisted
right.

And that's what affects the JAL libraries. Now let's talk about mechanisms
for combining yourcode+lgpllib. The simplest and most obvious is dynamic
linking. Since only the runtime is linked, the user can simply update the
library and the next time yourcode is run it's automagically linked to
the new library. Done deal.

Next is static linking. While this creates a permanent yourcode+lgplglib
the two components (the yourcode object and the lgpl library) are separate
enough that you can simply provide the user with a yourcode object and they
can relink to a newlgpllib whenever they are ready.

Now here's the problem with JAL's libraries. Neither of those two mechanisms
are available. The only way to build yourcode+lgpllib is to compile the
source code for each together. So it's the mechanism that creates the
situation where the source of yourcode has to be available, coupled the right
that the user has to recombine the code.

It's a problem. But it's not as black and white as "a relaxation of the GPL
*only* for dynamic[al]-linked use of LGPL-ed code."

For clarity I would phrase the problem as follows: The LGPL grants the end
user the right to rebuild systems utilizing LGPL code. Because the only
mechanism available under JAL libraries is source recompilation, this right
can only be fulfilled by the release of the source code (of yourcode) to the
user.

Nothing's changed but it clarifies the problem.

Switching licenses is a prudent course of action. And of course you know that
I trust you to do the right thing. Unfortunately there will be developers
that will take your licensing generosity and exploit it. The LGPL also has a
second provision to protect the freeness of the code itself. Note in all of
the above examples that yourcode and lgpllib have been pretty much
separated.  However in the instance where the developer of yourcode needs to
add or change something in lgpllib to create
yourcode+newlgplupdatedforyourcode then the GPL effect kicks in for the
library. While there's still no encumbrance for yourcode (other than the
original rebuild right granted to downline users) the modified library is
subject to the GPL and the source for the changes must be distributed along
with the new combo. So the downline user can get both the ability to rebuild
and be able to use the updated library just like the original in both this
application with yourcode and with any other application the user so chooses.

Now by switching to a license with less restrictions developers can now
take code that was given freely to them, modify and possibly improve it,
and have no obligation whatsoever to share the results.

As much as some folks complain about L/GPL restrictions, it's really designed
to be fair: What is free remains free, what rights are given to you must
be transferred downline, and what's yours is yours as long as you didn't
utilize free software to get it.

But by switching to the zlib license (artistic and BSD are similar) developers
get the opportunity to retain any rights and code given to them, and no
obligation at all to share any of their contributions to their users downline
or others in the developer community. Not the stuff they generate themselves
(remember what's yours is yours) but the modification of the code that was
freely given to you.

In the free software pantheon there is a shift between the rights of what
I've been calling downline users and developers and modifying distributing
developers. Each license from the GPL to strict closed source grants rights
to one side or the other, and restricts rights for one side or the other.

Here's the list:

Most Free granting most rights to downline users/developers
----
GPL
LGPL
X
Zlib,BSDL, Artistic
Vendor community source licenses such as Netscape, Sun, Apple, and Microsoft
Closed source
Patents
----
Least free granting most rights to author/developers

Now the LGPL doesn't work in the JAL case. I agree. However I think there
needs to be something in spot X in the list. Zlib and friends takes away both
the rebuild right and the propagation of library source modifications right.
LGPL grants both of those rights. The license in X should drop (or modify)
the rebuild right but keep the propagation of library source modification
to the downline intact.

I'm not sure it exists. I just hope that JAL developers using the zlib library
will honor the sprit in which the code is licensed. Because the code is being
relicensed in order to work around a code combination mechanism that currently
doesn't have a fix. The LGPL is actually the right license overall, but it's
conditions cannot be easily met.

BAJ

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body