New subject: BSD, Gav, LGPL, Jeremy, and business

15 Feb 2002

      "Dimitrie O. Paun" dimi@cs.toronto.edu wrote:
...
Can't you see that most Linux distributions _are_ made mostly of
xGPLed code, and that hasn't stoped a lot of proprietary companies such as
Oracle, SAP, IBM, etc. to release and develop code on this platform?
This is an apples to oranges comparison.  Things that CALL LGPLed libraries
are safe.  The problem is that things that work WITHIN a library is not.
You can *say* that it stops at the DLL boundaries, but the license does not
back what you say.  The LGPL has a "work as a whole" clause that can
easily be argued that it applies to anything within wine.  So, while
an installer for wine won't be affect by LGPL, any DLL that wine uses
can arguably be considered a part of wine (unless you go through the pains
of making sure that your DLL was added AFTER wine, and that the new
wine works without your dll.
If you want a LINUX analogy, look at device drivers.  The *GPLness of
the kernel means that no propriatary driver can be shipped as a part
of any distribution.
Steve Langasek wrote:
...
Since Jeremy has stated his intention to release future code changes only 
under Copyleft, the decision for Wine contributors to make is a simple 
one: do you believe that the benefits of potential additional corporate, 
closed-source adopters of Wine outweigh the certain loss of code 
contributions from Codeweavers, a known active contributor?
ok...  finally, a reasonable place to start, as it's finally an admission
that the choices are exclusionary to some respects.
re jeremy's posting:
It's pretty obvious that there's animosity between transgaming and
codeweavers.  Peronally, I think the main problem here has very
little to do with licensing, but rather that the commerical pie
for wine is really only large enough to support 1.3 companies.  
So, let's just go over some of the points:
...

The current license encourages forks.

a) the forks already exists - do you think changing the license will fold
   in any of the forks?
b) the forks are also signs of (new) development.  Presumably, no one
   would fork something just for having a fork.
...

The current license discourages competitors
from releasing their code.

s/discourages/does not encourage/
...
  Since I believe in the LGPL, but compete with Transgaming
  and Lindows, contributing my code under the current license
  is like giving my competitors my very best and getting nothing
  in return.  

So, are you saying that Gav is an insignificant contributer to wine? and
that all the code inside with is 100% written by codeweavers?
...
  You know, the concept of making money on Free software is crazy
  enough without enabling your competitors into the mix.

Think the problem here is that you guys are competing in the first place.
If you were in different markets, one would think you could "trade"
components into open source, thus reducing redundancy without having
to risk your business.
Also, I don't think it's unreasonable to ask (as a switch to LGPL might
discourage Transgaming from ever releasing the dcom code - gav, will this
affect your decision?) what exactly is codeweavers going to release LGPLed
in the short term and why the urgency?
...
3. The current license is harmful to the growth 
   of Wine, because it creates a murky, uncertain ground.

...
   Well, a Copyleft license provides potential
   corporate citiziens with written rules.

LGPL is not the only license that's a copyleft.  Just from cursory
reading, MPL seems more reasonable that LGPL since section 3.7 makes
a distiction between "covered code" and "larger work".
Personally, if a simple "requirements" list is made, some choice can
be made that isn't disagreeable to too many people (unless you have
philosophical restrictions like "it can/can't be GPL compatible").
If copyleft and commercial viability is the only requirement, MPL
would be a reasonable compromise.
-r

Re: BSD, Gav, LGPL, Jeremy, and business