[Python-3000] C API for ints and strings (original) (raw)
Nicholas Bastin nick.bastin at gmail.com
Tue Sep 11 10:59:32 CEST 2007
- Previous message: [Python-3000] C API for ints and strings
- Next message: [Python-3000] C API for ints and strings
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 9/11/07, Larry Hastings <larry at hastings.org> wrote:
I guess anything is debatable, but the LGPL explicitly defines programs statically-linked with LGPL code as being "derivative works":
Where exactly does it do that? The GPL does that, but not the LGPL. In fact, the LGPL does not define nor reference "derivative works" in any way.
Earlier revisions of the LGPL were potentially somewhat more restrictive, and certainly harder to parse, but the current version is reasonably clear on this topic.
5. 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". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.
What version of the LGPL did you find this clause in? Section 5 of the current license says the following:
- Combined Libraries.
You may place library facilities that are a work based on the Library side by side in a single library together with other library facilities that are not Applications and are not covered by this License, and convey such a combined library under terms of your choice, if you do both of the following:
* a) Accompany the combined library with a copy of the same work
based on the Library, uncombined with any other library facilities, conveyed under the terms of this License. * b) Give prominent notice with the combined library that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work.
I feel it's intellectually dishonest to ignore the LGPL's restrictions on the basis that its definitions haven't been tested in court. You seem to suggest that, were Python to incorporate LGPL code, organizations which redistribute a statically-linked Python should ignore the LGPL-induced restrictions--is that really what you mean?
No, that's why I said that statically linking was out for distributions without their own legal department. That was supposed to be read as, "we don't supply legal advice, they have to make their own decisions". If they want to interpret it to mean that static linkage is fine, then that's their own decision. In my experience, lawyers don't view those kinds of decisions as "intellectually dishonest", but rather as "up for interpretation". I'll leave it as an exercise for the reader to determine what they think of that particular philosophy.
-- Nick
- Previous message: [Python-3000] C API for ints and strings
- Next message: [Python-3000] C API for ints and strings
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]