Decision process on possible switch to LGPL

[Roger Fujii]

"Dimitrie O. Paun" wrote:
> > > If we agree up to this point, what is the 'syntax' I was referring to?
> > > Well, IMO this is a stronger Wine that keeps evolving and that has a life
> > > of its own. Wether this is good or not for users it's irrelevant.
> > You probably meant something other than what you wrote here.  Existence for the
> > sake of existence is useless.
> No, I meant what I said.  By 'syntax' I was referring to the 'what'.

Your statement implies that wine should do whatever it takes to remain alive (
go propriatary, emulate mac finder...) which is not what I think you meant.
 
> > I would presume the point of wine is to provide a WINXX environment on
> > top of x86 platforms.
> True, but that was not the point of the discussion. We weren't debating
> what Wine should do, we where debating what licence we should choose for
> Wine. I thought that was a well understood point in this thread.

But is it?  If what I said was paramount, one wouldn't hesitate to choose
a (complete wine + proprietary libs) over (incomplete wine that's nonproprietary).
Now, I will agree that a complete wine that's free is preferable, but is this
realistic?  It seems to me the argument here is whether to maximize the
free software base, or of maximizing the complete sw combo.

> > > Let's look at the first part: make Wine evolve faster.
> > >   LGPL
> > >     pros:
> > >         -- _far_ bigger code base for sharing/reuse
> > and how to do arrive at this?  the modified BSD license is professed by FSF
> > to be compatible with the GPL.
> Yes, one way. BSD-style code can be used in (L)GPL code, not the other way
> around. So, in our case, other (L)GPL projects could use Wine code, but
> Wine (with the current licence) can not make use of code from (L)GPLed
> projects.

ok... get what you were trying to say now.  Though one could use LGPLed stuff if it
is in library form (obviously).   Wouldn't think this is much of an issue though -
is there a lot that can be taken from somewhere else?  And one could always ask
for an exemption....
 
> > >         -- _far_ bigger developer base
> >
> > Can you actually say for certain that the gain of developers by using LGPL
> > is less than the loss of developers by using BSD?
> 
> Yes. I'm certain of this. Most open source developers prefer the (L)GPL to
> the BSD licence. Let's look at SourceForge (today, 20:05 EST):
>   OSI Approved:  19939
>         GPL:       14507
>        LGPL:        2016
>         BSD:        1331
>    Artistic:         608
>     Mozilla:         309
>         MIT:         301
>      Apache:         179
>   Propriatary:   449
>   Public Domain: 622

All this says is that on sourceforge, the number of GPLed apps is larger than any
other license.  Just because I like X11/BSD, doesn't mean I don't contribute to GPLed
projects.  Yes, there are some people that only do GPL stuff, just as there are
some people that don't/can't.  How does one quantify this ratio?

> GPL is one thing, LGPL is another.

I know that.  You know that.  Managers may or may not know that.  Plus,
there are various parts of LGPL that are quite fuzzy, which never builds
confidence in the legal realm.  I've had this argument happen to me a couple
of times in different companies.  And given that they like to choose the 
SAFER thing to do, we know what got axed.
 
> > I can also add a few more cons:
> >           --  FSF discourages use of LGPL
> I don't care what FSF does, or its political agenda. This is the very
> 'why' I want so much to avoid. However, not even the FSF would suggest GPL
> for Wine, due to its nature. Remember, FSF's own glibc is LGPL for crying
> out loud!

yes, but what FSF does influences how people perceive what the *GPL
means.  As for LGPL glibc, see: http://www.topology.org/linux/gpl.html.
It's stuff like this that give commercial companies the willies....
 
> >           --  Adds more confusion to the mix - LGPL ramifications is less
> >               understood than the GPL.
> Quite the contrary -- LGPL add _stability_ which should help businesses
> long term.

Statements like (From LGPL):
> When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the
> work may be a derivative work of the Library even though the source code is not. Whether this is true is especially
> significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is
> not precisely defined by law. 

is anything but stable.
 
> > > And now for the second part: Wine should have a life of its own. This is,
> > > to my mind, the crucial part. The problem with a BSD licence is that it
> > > does not ensure that.
> > and how do you arrive at this conclusion?  I would say that apache, X11, BSD
> > would disprove what you are saying.
> I am quite aware that there are successful BSD-licenced project. But it is
> my firm believe that in the long term, the (L)GPL creates the right
> framework to give a project a life of its own. Right now it's hard to say,
> because most projects are still maintained/developed by their creators, we
> don't know how things will evolve in 15-20 years and beyond.

X11 is ancient.  BSD is ancient.  Both have been relatively active in their
lifetime.  Contrast that with GNU projects of that same duration (gnuemacs, gcc)
and you will see that there were bigger dead times with those projects than
their non-gnu counterparts.  My problem with LGPL in Wine's case is that it
(LGPL) has a pretty dated notion of linking/executable.  Let say for speeds
sake that wine created a mmaped file which is an 'image' of a running
windoze executable's address space.  What this core image is (is it now a
derived work?) is really unclear.  As technology gets more sophisticated,
this whole notion of executable/libraries is going to go away, and it seems
to me that having a license based on a concept of "library" is not too
forward seeing.

> But from a business point of view, it is quite important that you can 'predict' a
> little the future long term, and the LGPL gives you _much_ better means
> than the BSD licence.

This can be answered off-line, but I'm curious how you come to this conclusion.  If
anything, I would presume just the opposite.
 
> > With this in mind, I think wine is better served
> > by having its use proliferate and being more complete (even at the expense
> > of having propriatary extensions), than having something that is incomplete but
> > "free".
> Certainly availability is very important. But not at all costs. If so,
> just use MS Windows, it's here today, and works a hell of a lot better
> than Wine does (or even hopes of working in the near term).

But I don't want to run an os that crashes on me every chance it gets.  Realistically
Wine's *real* problem has very little to do with the licensing,
but its competitors.   Programs like vmware and plex86 lessens the need for
something like wine, especially since wine is so far from being complete.
I doubt that wine will ever be as good as the the virtual cpus, but this 
may not be an option for some....


> > > Dan Kegel <dank at kegel.com> wrote:
> > > Could it be as simple as the wine cvs tree accepting LGPL'd
> > > contributions along with old-license contributions?
> > Not if you want a "pure" LGPL distribution.
> False. See above.

what I meant by "pure" is that it can ONLY be licensed as LGPL.
Since the original source was BSD, portions will always be BSD.
AFAIK, the current LICENSE file must still be included.
 
> > > Or need one go so far as requiring all new contributions to the cvs
> > > tree be under the LGPL?
> > even further.
> False. People can continue to submit code that's BSD-licenced. It will
> turn LGPL the moment it's applied to the tree.

I don't think "distribute under LGPL" is the same as "changing the source
license to LGPL".  Only the copyright holder can replace the header, as
the original permission for the copyright requires the original header
to be there.  I don't see how you can exclude the current LICENSE file
without agreement from the copyright holders, as your ability to
use the source is contingent on that file being there.
 
> Remember: any BSD-lincenced code can be used in LGPLed code, but
> not the other way around. If BSD-lincenced code is used in LGPLed code, it
> becomes LGPLed automatically, by the magic of the LGPL.

compatible with != IS.  If what you are saying is correct, then there
is nothing stopping FSF from commendeering all BSD software, slapping GPL
on it, and releasing that distribution.

-r