Re: Problem with InstallShield (Was Re: [Bug 629] Changed - Problemwith InstallShield: ole:CoTreatAsClass(stub), ole:CoGetClassObject)

"Sean C. Farley" <[email protected]>
Newsgroups gmane.comp.emulators.wine.license
Message-ID <[email protected]>
On Thu, 9 May 2002 15:58, Roland wrote:

> At 09:29 PM 5/8/02 -0500, Sean C. Farley wrote:
>
> > > But as Alexandre wrote, working on a community project is not
> > > about economics, its about having fun and developing together for
> > > ALL to benefit from it...
> >
> >If this is the case, someone making a proprietary version does not
> >affect a developer from "having fun and developing together".  If it
> >is "ALL", then explicitly excluding a type of development is
> >contradictory.
>
> The point here was, that for many it seemed that it was a one way road
> to TG. TG benefitted a lot, but gave back much less than they could.
> The idea of all benefitting would be everyone giving back as much as
> possible. Of course you are right, we shouldn't force anyone to do so.
> But then there is also no reason to have a X11 license. Just make it
> LGPL? I'm not sure though.

I believe in the minimal license to do open source.  Protection from
liability is the biggest goal of the BSD and X11 licenses.  The LGPL add
many more restrictions than I see as necessary to code.  This is as a
developer who does open source for fun.

> > > And when someone trys to make money out of it, the whole thing is
> > > endangered...
> >
> >FreeBSD did not suffer from BSDi.  In fact, it benefited from the
> >company.  This is not always the case, but I still have not seen a
> >company having a negative affect on an open source project with
> >regards to code.
>
> Well, how about the Wine project? Some people claim that the
> development of some code has come to a halt. Why? Because TG promised
> to submit that code.  So people stopped coding, waiting for that code,
> which didn't come till today. TG is not releasing it for free, but
> wants to trade it...

This is hard to prove.  My thoughts are that people needed WINE to run
business applications more than games and switched to making code for
those applications.

Think about all the talk in the last two or more years about getting
Linux into the workplace as a desktop.  Most companies use only
Microsoft Office.  Star Office was (is still?) the best at understanding
Word formats, but there were always little problems that kept people
from relying on those office tools.  This led developers to focus their
work on getting Office to run under WINE on Linux.

Games are important but the office tools rule in regards to demand.  If
you look at the application database, you can see that games outnumber
the productivity section.  This looks like games are in higher demand,
but you need to consider that there are a lot less productivity programs
as compared to games.

> > > Probably Transgaming gave the main arguments for switching to
> > > LGPL.  Here we see again that in the long run it pays off to be
> > > generous.  Share your goods instead of holding them back...
> >
> >or else we will use a license to force you?  Not exactly a good means
> >to sharing.  If people wanted others to share with them, coercement
> >does not provide a good example.  People might as well complain about
> >them "blackmailing".
>
> No one is forced to use the LGPL code. All companies use licenses to
> force users to pay for software. The point is, many perceived the
> license to be a disadvantage to the flow of the WINE project. So they
> decided that the LGPL would be better. Only time will tell if they
> where right.

No one is forced to use LGPL code.  In addition, no one is force to
refrain from developing game extensions to WINE if someone else is doing
it.

If TransGaming is able to continue on with the X11 tree, will the WINE
project still be unable to code for games?  Why develop WINE when a
person can just as easily use Windows for their games?  Will WINE
developers be able to write code to get games to work while the
proprietary "version"--Windows is sort of a proprietary fork of
WINE--can run all these games?

> > > PS: Another problem of the X11 license is, that it allows "embrace
> > > and extend" strategies.
> >
> >This is only a concern with a company that can actually afford to run
> >a separate fork by themselves.  I believe Transgaming unable to do
> >this even if they wanted to.
>
> Huh? AFAIK every companie has it's separate fork. Otherwise can you
> tell me where I get the code for WineX?

Are they maintaining a divergent fork that is far off from the WINE
tree?  Eventually, the costs can cause this to be too expensive to
maintain.  This is why BSDi gave a lot of code to FreeBSD.  Even if they
were ahead of FreeBSD, the did not want to diverge too much and lose the
ability to retrieve code from FreeBSD at a low cost.  They may have also
contributed code out of generosity.

> Let me finish by saying that I'm not against the X11 license, in fact
> I favoured it most of the time. Only I came to realize that both
> licenses have arguments in their favour and against them. It depends
> on the situation.

It is amusing, but I have found the only valid use of the LGPL and GPL
to be for companies to maintain control over a piece of code.  They do
it to prevent another company from gaining a technological advantage
over what they have.  Only if you are competing for money, do I see the
advantage for GNU licenses.

When I developing open source, I see no advantage.  I code for a number
of reasons:
1) To learn
2) For fun
3) Need
4) Others to enjoy
5) Feeling generous.

In none of these, do I have a need to go beyond the BSD or X11 licenses.
Reasons to use a GNU license:
1) Want others to have to give out their code
2) Hamper others from making money on the code

As you can see, none of these match the reasons I develop open source
code.

Sean
--------------
[email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.