Installshield 6 (inter-proc) patches

J.Brown (Ender/Amigo) ender at enderboi.com
Fri Dec 14 00:33:32 CST 2001


I probably am going to regret starting this conversation, but luckly I
havn't seen any of the traditional flame-war mentality sneaking in yet.

My 5c:

I -have- had to deal with companies stealing my GPL code and releasing
it in on-the-shelf commercial products. The GPL protected my rights very
well when said companies were confonted. The GPL is only weak in that most
people using the GPL do not have resources to enforce it.

If it came to that (which I doubt it will, as the GPL does have a
large part in the fact it discourages being stolen... for the PR points if
nothing else!) I'm sure the WINE project could find the ability to enforce
it.

Meanwhile, I do agree that changing the fundemental wine license for
libraries to LGPL is a good thing. Legally, wine is entitled to do so.
Anybody submitting code back to wine has done so under the modified BSD
license, from modified versions of code originally copyrighted to Wine,
thusly transfering licence rights back to the original owner under a
GPL-compatable license.

The LGPL will protect WINEs fundemental core. Naturally, Transgaming
currently use a BSD licensed version, and may continue to do so. If they
wish to import any new modifications from a LGPL'ed wine however - they
must accept the new licence on the library they are importing code
to/from. If Transgaming, or a third party, develop a whole new library
from scratch, which is a .so or other dynamically loaded library, the LGPL
allows them to do so with no repocusion. It's all-in-all a win/win
situation. Transgaming can protect their IP, and Wine can protect poaching
of their code from other sources for things which do not benefit the wine
core.

Let's look at the legality.. the clause below protects a large portion of
the objections most people may have with WINE becoming LGPL'ed:

d) If a facility in the modified Library refers to a function or a table
of data to be supplied by an application program that uses the facility,
other than as an argument passed when the facility is invoked, then you
must make a good faith effort to ensure that, in the event an application
does not supply such function or table, the facility still operates, and
performs whatever part of its purpose remains meaningful.

This protects many operations of WINEs functionality. In good faith, we
have tried to provide alternate functionality to allow the program to
operate without the presence of external files.

In the case of embedded systems, there are many libdl replacements out
there. I know not of a single embedded system that wine could EVER
feasibly run on that doesn't include some way of getting dynamic linking
capability.

As another issue, Lindows can simply be considered another distribution.
Fundementally it uses Linux, Wine and other free software (under GPL, LGPL
and BSD licences). They have already stated they will respect the
respective licenses, and open source to the components of thier code that
IS under a license requiring such. Thus there is no conflict.


Regards,	| Any significantly advanced technology is indistinguishable from
                | a perl script.
	Ender	|
  (James Brown) | 	 [Nehahra, EasyCuts, PureLS, www.QuakeSrc.org]

On Thu, 13 Dec 2001, Bill Medland wrote:

> Date: Thu, 13 Dec 2001 14:51:51 -0800
> From: Bill Medland <medbi01_1 at accpac.com>
> To: wine-devel at winehq.com
> Subject: Re: Installshield 6 (inter-proc) patches
>
> "Alexandre Julliard" <julliard at winehq.com> wrote in message
> news:874rmvggpn.fsf at mail.wine.dyndns.org...
> > Patrik Stridvall <ps at leissner.se> writes:
> >
> > > In short:
> > > Should the Wine project wait until you release or should it not?
> >
> > That's certainly a question we have to think about, but I think there
> > is a deeper issue: should we continue to release under a license that
> > allows people to use our own code to hurt the project?
> >
> > My concern is not so much about Transgaming, I trust that Gav means to
> > do the right thing, even if I don't entirely agree with his methods.
> > But I'm worried that if Transgaming succeeds, it will set a precedent
> > that others will follow, who may have no desire at all to do the right
> > thing for Wine. What will happen if 5 different dlls are improved and
> > released by 5 different companies under 5 different non-free licenses?
>
> It's been quite fascinating watching this discussion; it's nice to see that
> such issues are covered.  It raises two issues for me:
> 1. Where does Lindows fit into all this?  Does anyone know what's happening
> there?
> 2. Is the current wine license as loose as it appears to me?  My
> understanding is that "the license" is the file "LICENSE" at the root of the
> cvs tree and basically allows anyone to do anything with it provided they
> keep the license in there (and respect copyright).  I keep seeing quotes and
> things that suggest wine is under GPL, LGPL, BSD etc.; I presume that they
> are simple ill-informed.
>
> Bill
>
>
>
>
>






More information about the wine-devel mailing list