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