Installshield 6 (inter-proc) patches

[Patrik Stridvall]

> Patrik Stridvall <ps at leissner.se> writes:
> 
> > > No, of course the LGPL doesn't provide absolute 
> protection; nothing
> > > does, and I don't think absolute protection is desirable 
> either. There
> > > are some things that the LGPL clearly allows, some that it clearly
> > > forbids, and a number of border cases, that frankly are only
> > > interesting to people who want to try to get around the license
> > > restrictions. And what would be the point of doing that?  
> > 
> > Making their business model work. 
> > Trying to ensure investment return.
> 
> That would be the case if the code they are using magically turned
> LGPL once they had invested millions. But that's not possible, since
> only new code becomes LGPL. 

Indeed and that makes any protection LGPL gives even weaker.
My earlier analysis was based a 100% LGPL:ed Wine...

> Now, if someone is basing his business
> model on turning LGPL code proprietary by exploiting possible
> loopholes in the license, I wouldn't suggest investing in his
> company... I don't think our goal in choosing a license is to make
> sure every flawed business model can succeed. There are lots of
> reasonable business models that can be built on a LGPL (or GPL) code
> base.

Lets arguments sake assume somebody is called Bar and have a business model
that might possibly be illegal under your interpretation of the LPGL.

What's preventing him from creating a library called bar under his
proprietory license as well as  supplying a patch under the LGPL
that results in code looking like:

void WINAPI Foo(void) {
#if HAVE_LIBBAR
   BAR_Foo();
#else 
  /* Old Wine code */
#endif
}

Wouldn't this always be legal under the LGPL?

In that case the only thing you did by threatening to sue him
was to increase his costs.

The point is, you didn't get his code, that it seems, that you hoped
you would get.
 
> > The current license is something that is easy to understand and
> > are unlikely to scare companies like Transgaming away, but can
> > you really say the say same about LGPL?
> 
> OK, now we are getting somewhere. So your argument is basically that
> the LGPL might scare some companies away.

Yes.

> Yes, I agree that's a
> possibility. 

Good.

> Most likely these companies will have been scared away
> from Linux already, since many other things they need are also LGPL
> (most notably the C library). 

That is a claim that makes no sense at all. Why should anybody want
to make a business model out of modify or making additions to
the almost 100% complete C library?

One of the main reason Wine has the possiblity at all to attract
companies like Transgaming is that it is not complete far from it.

> But of course this possibility cannot be
> excluded.
 
Indeed.

> I think that the risk of this happening is not larger than the risk of
> having companies hold hostage pieces of Wine, and the damage in the
> second case is much larger; so I think the LGPL would minimize the
> potential damage to the project, even if damage cannot be excluded in
> any situation.

Your analogy with hostage holding is a bad analogy, sure I 
understand that you are refering to Transgaming promises to release
eventually. If you don't believe them announce that publicly
and developers that might be hanging back in fear of doing "double"
work might step forward. They might not, of course, but then perhaps
nobody was intresting in doing work in that area, Transgaming or
no Transgaming.

> Of course only the future can tell us who is right.

Agreed.