Installshield 6 (inter-proc) patches

[David Elliott]

On 2001.12.19 12:22 Patrik Stridvall wrote:
[SNIP]
> > 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)"
> 
> ..but you are wrong that just because it falls under use,
> it is clear from the doctrine of derived work. That is
> the main problem, I have with it. That it might potentially
> turn somekind of uses into derivation and thus potential
> infringement of copyright.
> 
Nah, see next section.

> > 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!
> 
> Welcome to the club. :-)
> 
Seems to me that section 5 pretty much takes care of making sure that 
things which use the work are not considered derived works.  So IMHO the 
LGPL is basically nullifying the doctrine of derived work.

> > 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.
> 
> Agreed.
> 
> > > > 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.
> 
> Yes, it only applies to derived works, but since it is pretty unclear
> what a derived work is makes it quite unclear for commercial commpanies
> what that are legal forced to release or not that can't possibly be good
> when they are deciding whether to use Wine.
> 
> 

I now think I know why GNU does not want people to use the LGPL.  It's 
basically a useless license for all but a certain specific type of project.

That specific type of project would be something like glibc.  Where the 
interface is clearly defined and the implementation is good and needs to 
be free software.

Wine is actually very similar in concept to glibc.  I remember a few mails 
back I suggested that the real goal is to make sure the base system is 
free software because no one can expect people not to write proprietary 
applications.  And I don't think it would be good to not have proprietary 
applications (unlike RMS's views).  However, I consider Wine to be part of 
the base system since it's really not an application, but basically does 
for Windows applications what glibc does for POSIX applications: provides 
a free version of the API.

So far the discussion as seemed to center around licensing Wine as a 
whole.  Would maybe licensing certain specific DLLs be a better idea?

For example, would licensing the really core libraries as LGPL (i.e. 
kernel, user, gdi) be a good start?  Make each library have its own LGPL 
license.

Or maybe should we keep all the libraries as X11 and make the emulator 
itself full out GPL?

Wine is many many peices.  I think to try to place the same license over 
the entire project is absurd, except in the case of our current X11 
license.

-Dave