Optimal license for Java projects ...

[Gunther Schadow]

David Johnson scripsit:
>>You've completely misunderstood the nature of the BSD license. First, 
>>commercial parties cannot take source code away any more than they 
>>could take water away from an ocean. 
...
>>The point is, your [e&e] scenario has never occured. 

Well, I noticed that I wasn't quite true to history in my scenario
but I figured I had already written enough. The real szenario would
have been that multiple companies such as SunToast, DigitalToast,
AichPeeToast and GeneralToaster and many other companies would have
taken Hans Hacker's code release 4.2 and would have each made special
things to it and kept it closed source. Although based on the same
great kernel of code, soon everyone would be incompatible to each
other and no way for sanity because the vendor code would be closed
source. Furthermore, Hans Hacker's next release (4.3YML) would now
be much improved, but because of the many modifications that the
different vendors had already made no customer could actually benefit
of the better 4.3YML code. Of course the open source guys would have
a hell of a time porting their code to all the new Toaster hardware
that these companies were issuing. Then based on this fragmented
field of decent YML software, MicroToast would come an poo-poo the
YML field because it was so fragmented and they could make the
world believe the lie of YML really being so incompatible. Then
they would push their MT-YML stuff onto the market, and the result
would again be suffering and lots of burnt toast.

This scenario did actually happen in history :-)

And then John Cowan makes the case for where my original scenario
actually did apply:
> For example, Microsoft's command-line FTP client
> does incorporate BSD-licensed code; at least, a troll through ftp.exe
> with "strings" reveals the UCB copyright notice.  It is entirely
> unfree.  However, it dates from a day before the "passive" command
> was added to the source, and to this day you cannot use the client
> to make passive-mode FTP connections.  In this case, Microsoft is
> effectively practicing "embrace and dumb down", and there is nothing
> users can do about it (except replace the program, since fortunately
> it is a userland utility).

To my original question:

Is there any other licenses I should look into apart from the CLASSPATH
license, LGPL and MPL?

Specifically what is the practical difference between LGPL and MPL?

Both LGPL and MPL distinguish between use of the code and 
derivative/modification.

LGPL seems to be a little stronger on the binary linked distributions,
but since in Java we have late binding, it doesn't sound like that
big of an issue anyway.

The LGPL is less text (if you discount for the political statement in
the beginning :-) and is nice and readable. Conversely, the MPL is
more legalistic. How much do we know how well these things hold up in
court? Is there any case law regarding open source licenses that
had been contested?

Would it be considered bad style to take, say, the MPL and make the
notice requirement a bit stronger saying that credit to the original
contributor (and may be other contributors) needs to be given in
user manuals or splash screens etc.? I know Richard Stallman doesn't
think that's good. But as I said earlier, academic contributers may
have a better incentive when they actually get recognition from the
stuff they are doing. But then, a copyright notice requirement may
be enough for that too. So, perhaps the MPL does cover it all?

regards
-Gunther

-- 
Gunther Schadow, M.D., Ph.D.                    gschadow at regenstrief.org
Medical Information Scientist      Regenstrief Institute for Health Care
Adjunct Assistant Professor        Indiana University School of Medicine
tel:1(317)630-7960                         http://aurora.regenstrief.org


--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3