Installshield 6 (inter-proc) patches

[Marco Pietrobono]

  Hi, I'm following this list for a while, and even if I still haven't
found time to devote to the project itself, I've seen few things in this
thread that I would like to comment on.

  Please note that I will be referring to the 2.1 version of the LGPL.

Il mer, 2001-12-19 alle 07:41, David Elliott wrote:
[snip]
> 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)"

  I don't think so.

  After all, with regards to a Windows Executable (and more so for
winelib ones) this is a library. This means that it has a well-defined
interface with a well-defined behaviours (btw, in our case, well-defined
means "as it can be defined by the code itself, not by some documents")
that you need to use to access its facilities. If you are crossing these
lines, you aren't simply using the library, you are actively changing
its semantics, or its expected behaviour. And I think that this can
clearly interpreted as a derived work.

  More so, the 2.d provision in the LPGL says that:

  "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, you must make a good faith effort 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".

  Please note that the "other than as argument" is quite clear regarding
its applicability. It means that both dynamic and static linking are
subject to this requirement, as well as that the magnitude of the
changes you can do is quite limited in functionality, or you will never
be able to fullfill it.

  Another problem is that your modifications to the semantic of the
library will be quite obviously refused by the mantainers of the
library, so you will need to maintain them by yourself, and since your
ipothetic function is using an internal interface that you have just
changed to an external one, you are even exposed to all nastyness
related to the changes that the original maintainers/developers can
introduce to this interface.

  I don't think this approach can work, as indirectly confirmed by the
last mail of Gavriel State with the regards to their current situation.
If you think of all problems they are having now with the current
license scheme, with a license like the LGPL this can easily become a
real nightmare.

> 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.

  this can done only if the impacted portion of code remains
"meaningful" even when you don't provide the rewritten function. If your
function is providing something that is not replaceable under the
current form of the library (as stated by 2.5), you cannot do such
thing.

  The provision of 5 are available only if you comply with their
premises ("A program that contains no derivative of any portion of the
Library, but is designed to work with the Library by being compiled or
linked with it, is called a "work that uses the Library""). This means
that your modifications to the library cannot be distributed together
with the program, but they must be distributed with the library or as an
additional package (I've just read the reply from Alexandre and it seems
that he's interpretation is similar).

  I think that even if the LGPL can be flawed, it is a minor one, since
the sheer size of the effort required to work-around this flaw and to
abuse the license wording, as well as to survive to the public outrage
that this will trigger, will require way too much time and money to be
done, especially with such a fleeble premise.

  BTW IANAL.

  bye,

/pietrobo

-- 
Stud. Marco Pietrobono            | Murphy's Law: if something could
v. del Calice, 39 - 00178 ROMA    |     go wrong, it does.
Tel. +39.06.7186329  339.7410893  | Legge di Murphy: se qualcosa può
http://www.pietrobo.com           |    andar male, lo farà.
------------------------------------------------------------------------
Strange game.
The only winning move 
is not to play.
What about a nice play of chess ?