Installshield 6 (inter-proc) patches

[David Elliott]

On 2001.12.18 23:43 Dimitrie O. Paun wrote:
> On Tue, 18 Dec 2001, Roger Fujii wrote:
> 
> > "Dimitrie O. Paun" wrote:
> >
> > > Technicalities aside, the LGPL spirit seems to be accepted by most
> people.
> >
> > I have no problems with the 'spirit' of the GPL (or at least, how most
> > (ie, minus rms) people sees it).
> 
> Excellent. In fact, I disagree with RMS violently, I've read the link you
> sent me (about the glibc takeover) a long time ago. But this is why we
> have to separate out intentions from fact. Or semantics from syntax. Or
> whatever you want to call it. In other words, we can use the LGPL even if
> we disagree violently with RMS. Just like Linus chose the GPL for Linux,
> even if he can't even talk to RMS.
> 
> > > We've heard no end of discussion of what represents the code, and
> > > so on, but in reality (please Patrik :)), Wine is a _well_defined_
> piece
> > > of software.
> >
> > The problem is that it is *not* a 'well_defined' piece.  Is it a
> library?
> > An app?  You run it as an app, but the executable you're running it
> with
> > thinks it's a library.   Or is msword (or whatever you're running) now
> a
> > library.  I can see rational arguments either way.
> 
> That's a separte problem. Is your claim that we can't use the LGPL
> because
> we can't define what Wine is??? If this is _your_ problem, I truely
> belive
> that can be solved. And the solution is fairly simple: whatever code uses
> a DLL's internal functions (that is, functions that are not exported in
> the DLL's spec files), is said to link directly with Wine and thus is
> subject to the LGPL licence. In fact, Wine is the simplest project to
> LGPL
> because its boundaries are defined by someone else! Moreover, these
> boundaries are fairly well documented and accepted by most of the
> software
> industry.
> 

Dimitrie, this is exactly what Patrick and I have been trying to argue 
against.  If you read the LGPL it does state that you can statically link 
as long as you provide the means for your users to statically link with a 
newer version.  One way to do this would be to provide the object files 
from the compiler, or a .a file with all of the combined objects that can 
be relinked with a newer version of Wine.

The example we have been using is that you could write a proprietary 
CryptoAPI and link it with the rest of the advapi32 to come up with a 
libadvapi32.so which includes CryptoAPI.  You can call all the functions 
in the rest of advapi32 (i.e. the LGPL part) that you want to.  So long as 
you provide a way to update the LGPL components you are in the clear.  
This is covered by section 7 which states that you may place library 
functions that are a work based on the library (i.e. the original LGPL 
ADVAPI32) ... in a single library together with other library facilities 
not covered by this license.  The single library would be the libadvapi32 
including the proprietary cryptoapi.  In order to do this you must a) 
provide a copy of the work based on the library not linked with the 
non-LGPL stuff. and b) give prominent notice as usual.

Now, here's another something to mull over.  We've pretty much established 
that you could statically link something proprietary with something LGPL.  
One question I have is how much of the library are you allowed to use.  
Alexandre mentioned that while the CryptoAPI example would be a pretty 
clean-cut allowed case, a proprietary CreateWindow would not be allowed.  
His argument was that because it would necessarily use internal functions 
and data structures that it would be a derived work and thus subject to 
the license.

I think what Patrick has been trying to get at is that that is not very 
clean-cut and that in fact there is little to no precedent on what exactly 
a derived work is.  If Alexandre is indeed correct then we are pretty well 
protected.  If it is at the opposite extreme and anyone could statically 
link in proprietary versions of functions then we have very little 
protection and it really makes it not worth it to go LGPL. At least that 
is what I think Patrick has been trying to say.

Let me put it to you the way I see it.  Whether a function or data 
structure is exported or not does not matter.  It would be trivial to 
declare an internal structure or function as exported and thus the 
proprietary function is simply making use of the library and therefore not 
a derived work.  That is my argument that avoids all of Patrick's doctrine 
of derived work crap and gets right down to the fact that it's trivially 
easy to make your work fall under the work that uses the library category, 
so long as it is a seperate object file. That is, to put it in Slashdot 
terms, a "Big Gaping Hole(tm)"

Look at section 5 in the LGPL.  If you use (from the header files) only 
numerical parameters, data structure layouts and accessors, and small 
macro and inline functions then regardless of whether it would be 
considered a derived work it remains a work that uses the library.

So that's great, after I had pretty much convinced myself that the LGPL 
was still good despite some minor problems, I now find myself realizing 
that the LGPL has major holes written into it!

And so I emphasize my original statement now.  The only thing the LGPL 
really prevents is the direct use of the source code.  Anyone wanting to 
release a proprietary implementation of any function can do so fairly 
easily simply by 1) writing that particular function from scratch, and 2) 
keeping it in a seperate object file.



> > Try reading section 2C of the LGPL and tell me how it's good for
> commercial
> > companies.
> 
To respond to Roger: I fail to see how 2c makes any difference.  It only 
applies to derived works and only means that you have to release the 
code.  It's not like it says you must provide media at no cost.  Hell, 
this is one of the main points of having a (L)GPL license.

> Again, let's not look at the details of the LGPL. Let's stick to the
> spirit for now. It's difficult as it is to discuss about these things, if
> we start now to worry about every small detail, we will not get anywere
> anytime soon.
> 
Why?  Has anyone fundamentally disagreed with the spirit of the LGPL?  I 
thought it was a given that everybody likes the idea, but that it's not 
necessarilly going to work as advertised.

> 
> > If LGPL is so clean, simple and nice, why does
> mozilla/openoffice/apache/perl
> > not use it?
> 
> If the LGPL is so scary, how come the glibc uses it, and how come that
> does not scare people for using Linux in a comercial setting???
> 
This is a bit different.  As Alexandre has stated, if you are using Wine 
to port a Windows app to UNIX then the switch to LGPL really doesn't make 
any difference assuming Wine works.

The difficulty comes when Wine needs to be modified in order to accomplish 
the port, or if you are running a business selling improved versions of 
Wine (e.g. TransGaming).

For example, CodeWeavers (from what I understand) makes their money 
through contracts with parties who wish to have their Win32 software run 
on UNIX.  They are getting paid to do the port.  Sometimes (or I would 
think more likely most of the time) Wine needs to be improved in order to 
do the port.  CodeWeavers then releases those improvements to the Wine 
project thus improving it.

Now, look at TransGaming.  Their business model seems to generate revenue 
essentially selling an improved version of Wine (See Gav's mail for more 
detailed information).  Possibly switching to LGPL /HAS/ scared the shit 
out of them and after reading Gav's mail I definitely see why.

For another example, look at Corel.  Now Gav has stated that Corel would 
not have touched Wine if it had been LGPL or GPL.  Something about they 
needed to be able to use their code for Wine and also for their Win32 API 
on Mac thing.  I fail to see why this would have made a difference.  If it 
was Corel's code then they sure as hell have the right to use it in both 
places.  However maybe they also borrowed some Wine code for the 
Win32->Mac thing which under X11 is perfectly acceptable.  I personally 
have no interest in that and really I think any code they may have 
borrowed was probably much less than what they contributed to Wine and 
therefore overall was a win for Wine.  If they didn't borrow any Wine code 
but merely used their own code for both programs then had wine been LGPL 
that should have been perfectly acceptable, of course if they did borrow 
some code and wine had been LGPL then we'd be seeing a front page story on 
Slashdot on how crappy a company Corel is for using LGPL code in a 
proprietary product.

Anyway, getting back on track.  Corel's aim was to port their applications 
to Linux and the easiest way to do that was to use something like Wine.  
Pretty much follow the Codeweavers model above where LGPL should be fine 
with the possible exception of borrowing some code for other purposes.


> > > Now, I claim that the LGPL is _way_better_ for the commercial
> interests in the long term,
> >
> > I keep hearing this, but don't see any reasoning behind it.
> 
> I will cover the commercial stuff in a separate email, this one's getting
> long as it is.
> 

Hmm, I seem to have covered that.  Depends on your business model.

> > > Saying 'someday' is not good enough. Without a bound, it's
> > > meaningless. What if M$ says: we will eventually open source Windows.
> Will
> > > that make you happy? But more importantly, does it _mean_ anything.
> I'm
> > > afraid it does not (and that can actually be proven logically:)).
> >
> > er, huh?
> 
> If you don't put a bound on time, but simply say 'eventually', it can be
> proven that it doesn't mean anything, because it is as if you did not say
> anything in the first place. It does not give any additional information.
> 

Right, exactly..  I will eventually clean my computer room pretty much 
means hell will freeze over before that happens.  I haven't set a bound on 
it and therefore I might as well have said nothing at all about cleaning 
my room.

Although with that strict of an interpretation of a word, maybe you should 
have been a lawyer.

-Dave